Fatal crash (pushing iron chunk with big cell)

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 :frowning: 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.

I will try to dive into code but I wouldn’t conciser myself an expert in any shape or form.
There is a possibility that this is an engine limitation related to the way plane is calculated but don’t quote me on that I’ll need to learn how to code in order to give any confident answer

We only use the following from Godot engine:

  • A plane primitive
  • It has a shader on it
  • We dynamically create a texture

Everything else regarding positioning etc. is in C#.
With the previous approach where we used a bunch of planes that were dynamically positioned to provide continuity, we had just a tiny little bit of graphical non-interpolation between those planes. That’s why we moved to using a single large plane so that there is no discontinuity anywhere near the player in the clouds.

I realised that errors can be connected. Error during spawning of players cell could cause second one later on. Every crash happened during cell growing as a result of collecting/generating compounds. This alone suggests that there’s a mistake in organell scaling and spitting. I completely missed a possibly of growth stage of organells being an ongoing part of gameplay each time. Every error appeared only with not fully developed big cells. If I’m correct it’s caused by rapid bit uneven growth of organelles causing engine to get confused by holes inside the cell.
I will add some “art” to illustrate this in the morning.

left to right order

  1. is a fresh spawned cell

  2. is a cell that grew outer organelles but didn’t grow inner one yet(engine should handle that)

  3. is irregular growth of organelle first grew black bigger organelles than red one but there’s not enough space for it

I don’t think this is the reason of the bug but I’d rather say something stupid than not mention it and later realize that this was relevant