While experimenting with cell editor I made quite a big cell and game crashed while i was pushing an iron rock.
Sadly log is over 2.6GB so I can’t upload it to pastebin, your decoder or even open it in notepad.
Let me know if you want to even look at this problem as there is only a giant log that will take ages to upload.
Only data that I can send with ease is a screenshot of somewhat correct replica of this cell
If you want to face this log let me know where can I send it.
Only like the first 1 meg is interesting out of a huge log. There are some text editors meant for huge files that you can probably extract the info with.
However, as you were doing a physics interaction at the time, this is probably the rare physics related lockup inside Godot that causes it to just continually print the same message.
I had about 2-3 seconds to look at log printing before launcher crashed, I didn’t catch much but structure of error and lines before it seem familiar. I think this might be the same bug. Sadly I couldn’t check for similar cases since I couldn’t open the log.
Do you want me to extract first 1 mb or can I just delete this log?
If so please send me a link to a correct program or it’s name if it is hard to find.
And another a bit unrelated bug since there are no logs for it.
Cell can’t absorb clouds of elements that are in different “chunks”/zones when you put a cell close to a border it can absorb only from one zones and you have to go in slalom pattern, constantly moving between zones in order to collect everything.
It is more of a quality of life thing but maybe splitting zones into smaller pieces and keeping surrounding smaller zones loaded as well would solve the issue?
It would be helpful to confirm that it is the same issue. The part where the repeating log message starts being printed is the interesting bit. I can only recommend what I’d use on Linux, which is head and less commands to view only parts of the file.
This would be nice to have a video of. I’m having a hard time understanding what’s the problem.
From what you seem to say is that basically you find that the compound cloud resolution pixels feel like zones to you. It’s a performance reason that the clouds have way, way bigger pixels in terms of world size as other things.
you can also use glogg or even wordpad (if you are on windows) to read large files
I cant post more than 2 links so I created a paste with links to log parts
First log
I located variations in errors and there are a few of themlog is split into 4 parts:
1.begining
2.ERROR: Condition “!s->slot_map.has(target)” is true.
At: core/object.cpp:1573:_disconnect() - Condition “!s->slot_map.has(target)” is true.
3.ERROR: Condition “!s” is true.
At: core/object.cpp:1569:_disconnect() - Condition “!s” is true.
4.https://pastebin.com/qtVz8c6D
and this structure but length of it is not fixed and there is no indicator on when it switches between it’s parts
I also found a second log I guess this is the log created while I was building a copy on my cell for a screenshot
Second log links
I need some time to locate said border between chunks since the only way I know to find it is to swim around and by pure luck come across a cloud that is split between chunks
I guess your game can’t handle big cells
Here’s another log
I broke your game…
After last crash I can’t even play anymore I can start launcher but as soon as I click play it bugs out.
I’m not fast enough to generate logs smaller than 30mb but structure is the same.
Here’s part befor error spam
I’m afraid this will delay chunk info quite a bit
Btw my due to my rate of posting updates my posts were flagged as spam 
I hope you as a moderator are able to access them anyway
I’ve verified your posts as not spam.
Seems like these are the error lines that just keep repeating:
**ERROR**: Parameter "ptr" is null.
At: modules/mono/glue/mono_glue.gen.cpp:235:godot_icall_1_26() - Parameter "ptr" is null.
**ERROR**: Condition "!s->slot_map.has(target)" is true.
At: core/object.cpp:1573:_disconnect() - Condition "!s->slot_map.has(target)" is true.
**ERROR**: Parameter "ptr" is null.
At: modules/mono/glue/mono_glue.gen.cpp:235:godot_icall_1_26() - Parameter "ptr" is null.
This seems a bit of a different error:
**ERROR**: Method failed. Returning: Variant()
**ERROR**: Condition "!s->slot_map.has(target)" is true.
At: modules/mono/csharp_script.cpp:1734:call() - Method failed. Returning: Variant()
At: core/object.cpp:1573:_disconnect() - Condition "!s->slot_map.has(target)" is true.
**ERROR**: Error calling method from signal 'tree_exiting': 'Reference::OnMouseExit': Method not found..
**ERROR**: Condition "!s->slot_map.has(target)" is true.
At: core/object.cpp:1260:emit_signal() - Error calling method from signal 'tree_exiting': 'Reference::OnMouseExit': Method not found..
At: core/object.cpp:1573:_disconnect() - Condition "!s->slot_map.has(target)" is true.
**ERROR**: Method failed. Returning: Variant()
**ERROR**: Condition "!s->slot_map.has(target)" is true.
At: modules/mono/csharp_script.cpp:1734:call() - Method failed. Returning: Variant()
At: core/object.cpp:1573:_disconnect() - Condition "!s->slot_map.has(target)" is true.
**ERROR**: Error calling method from signal 'tree_exiting': 'Reference::OnMouseExit': Method not found..
**ERROR**: Condition "!s->slot_map.has(target)" is true.
At: core/object.cpp:1260:emit_signal() - Error calling method from signal 'tree_exiting': 'Reference::OnMouseExit': Method not found..
At: core/object.cpp:1573:_disconnect() - Condition "!s->slot_map.has(target)" is true.
If you delete the installed game version from the launcher, then it redownloads the game.
Can you get a crash / these problems to happen reliably? If so could you provide for example a save file that could be used to quickly test that?
Crash happened when I used creative cell editor
I made a big cell with nucleus chloroplasts mitochondrions and flagellums
moved from pangonian vents to tidepool
spawned my cell
After spawning since it is a big cell is gliched inside the other cell so I had to spin a bit to set it free
I started to swim to the left but it felt quite slow even tho cell had over 80 speed
than game crashed afeter a few seconds (maby 5) and any attempt of starting it gave the same errors
I don’t know if there are any saves of editor and making said cell in normal gameplay might take a bit
I managed to find cloud on the border you should be able to replicate this by simply making a fast cell spawning it waiting for a minute so clouds can spreed and than collecting them once I fing border in my regular game I’ll provide you with a save
There are screenshots and saves
First save look at the cloud of glucose on your right cell is close to the border so just try to collect glucose by swimming right
Second save same deal swim to the right you are right next to a cloud that is on a border
If the only thing is making a huge, cell, I’ve already tested that quite a bit. Even making a huge cell where I get just 1 FPS in game, it just doesn’t crash for me.
In this case I don’t know if size is a problem. the biggest cell I made is that hexagon I posted and it didn’t have any performance impact on the game
I also updated my post from 20 minutes ago to include info and files about border glich
I’m having a hard time seeing any (new) bugs there. The clouds don’t spread out super fast, so unless you swim over to where the compound concentration is, it will stay there. The toxins in a line are caused by this not being fixed: https://github.com/Revolutionary-Games/Thrive/issues/1758
It is hard to explain so I made the worst visual explanation of this situation is paint.
Black line is the border and purple cloud speaks for itself you have to look at a cell as a single point(it’s rotation center) depending on position of center you can collect cloud that is only on one side of the line if you are slightly below it only part that is on the same side of the line can be absorbed
If you are lucky you can locate cloud that is split between 4 zones cell can only absorb from 1 quadrant at a time and to absorb more you need to move to another quadrant
Small circle represents the “center of a cell” and bigger one how big collection area/cell itself is
in order to collect the rest of the cloud you need to move the center to each quadrant
Terrible paint images are added to google drive link
border2 image looks correct. The cloud is within it’s own internal density pixels, the cell is in a middle of a clearing that has some radius. 1 and 3 images look a bit suspicious. If you made a video that would really clear it up as to what you are seeing.
If it turns out that there is some kind of weird internal border inside the cloud, I can accept that as an issue. But the clouds is like a top 3 hardest issues to get anyone to work on them, so it will take a long time for someone to fix.
I never used any screen recording software but I think this video will do sadly it looks like google has some problems with google drive servers so I uploaded video to mega https://mega.nz/file/9BQSlLgK#gM5e3I3g31r7Izsw3LFPSAuCaimqngeQZUEDuTJCAlc
My friends say that if you want a program to crash just let me touch it… I start to believe them
If this one is also physics related as a hot-fix is suggest froce reloading cell when this error pops up. It won’t stop the error from happening but will stop log spam and probably prevent crash
Okay, that doesn’t look right to me, I’ll now open an issue, but can’t promise when anyone will take a look.
Those errors look to be the same as before.
When those error lines from Godot start appearing, there’s nothing we can do. I’m pretty heavily leaning towards this being godot engine’s fault. So we can’t really do anything. Of course there is the chance that we use some API wrong and cause the problem that way. But we can’t do anything when the engine gets into an error loop.
In order to understand this problem you need to look at the world as a grid
Your cell can interact only with one square at a time and that means you can’t collect from squares that center of rotation of your cell is not in
There are 3 situations compound cloud can be in
Pure(fully in one zone purple cloud)
Split(split between 2 zones green cloud)
multi split(between 3 or 4 zones orange cloud)
if you split each zone into 9 smaller zones it should be easier to force interactions between cell and clouds that are in nearby smaller zones
green squares represent zone with players cell and blue zones are force interaction zones overall there will be no increase in functional area as it will always be 9 small zones interacting with players cell
On logical side this will work but I don’t know how game code looks so I can’t say is it will be easy from programing perspective
That’s the strange thing, because the implementation is so that there is one big plane that has the clouds on it. The plane is moved when the player moves too much so that it is centered.
So there should not be able to be an edge near the player. Even if the big plane edge was where the player was, no compound clouds can render outside the plane.