This desync started to happen with updating server to 2.0.28 (from previous stable version, so from 2.0.24 I think?). Since then, it happens practically every time when the scenario "soft-resets" the map on public server. It still happens even if updated to 2.0.30 version.
The gameplay loop is that players start on new world, build base, launch certain amount of stuff in rockets. Then they get recalled to mothership, the chunks of nauvis get deleted, nauvis surface gets different map settings to emulate new world, then people play again.
I pinpointed this issue towards the chunk deletion phase, and found out exact time when it happens in one of the savefiles. However as this savefile is from public server and has a lot of "junk" in it, I also tried to recreate in some fresh savefile so it is easier to handle and managed to do so.
This savefile is paused when logged into. It is with no mods, only with "base" 2.0.28. As the deletion function is called during every 10th tick, the desync can be triggered by editor-ticking in step of 10 ticks. The function to delete chunks (it just calls surface.delete_chunk(position) ) has added logging of location of chunks currently deleted, so I could identify 12 chunks that are deleted during this step:
3663.319 Script @__level__/maps/journey/functions.lua:259: deleting chunk at -5, 1
3663.320 Script @__level__/maps/journey/functions.lua:259: deleting chunk at -5, 0
3663.320 Script @__level__/maps/journey/functions.lua:259: deleting chunk at -5, -1
3663.320 Script @__level__/maps/journey/functions.lua:259: deleting chunk at -5, -2
3663.320 Script @__level__/maps/journey/functions.lua:259: deleting chunk at -5, -3
3663.320 Script @__level__/maps/journey/functions.lua:259: deleting chunk at -5, -4
3663.320 Script @__level__/maps/journey/functions.lua:259: deleting chunk at -5, -5
3663.320 Script @__level__/maps/journey/functions.lua:259: deleting chunk at -5, -6
3663.320 Script @__level__/maps/journey/functions.lua:259: deleting chunk at -5, -7
3663.320 Script @__level__/maps/journey/functions.lua:259: deleting chunk at -5, -8
3663.320 Script @__level__/maps/journey/functions.lua:259: deleting chunk at -5, -9
3663.320 Script @__level__/maps/journey/functions.lua:259: deleting chunk at -5, -10
I tried to edit the script so it deletes just one chunk per iteration instead of 12 (to pinpoint the location closer), however then the desync didn't happened on those chunks, probably because the timing was different (or if it affects biter units, they could move during this different timing).
As this savefile is empty of base, and has just biters there, I suspect the desync has something to do with them.
I tried to load the savefile in the singleplayer with heavy-mode enabled and it indeed failed the check once I run 10ticks once from the start of this savefile.
I am not sure I can so far pinpoint the reason, or replicate it in non-scenario environment so far.
[boskid][2.0.28] Desync on Journey scenario
[boskid][2.0.28] Desync on Journey scenario
- Attachments
-
- desync-report-2025-01-14_04-39-05.zip
- (9.18 MiB) Downloaded 2 times
-
- just_before_desync.zip
- (2.05 MiB) Downloaded 3 times
Re: [boskid][2.0.28] Desync on Journey scenario
Ok i am narrowing down on the issue here. It looks like the culprit is a Cliff at position {-162, -289.5} because it is not destroyed when chunks are being destroyed but it is incorrectly just deleted from existence without properly unregistering from the map when chunk is deallocated. Because of this the server gets into incorrect state as its counter of entities was not decreased by 1. When client joins, it recomputes the entityCount from what is on the map and this value happens to be different than what server has and so the desync is detected due to incorrect value of entities counter. That is definitely game bug so i am taking this out of "desync with mods"
Re: [boskid][2.0.28] Desync on Journey scenario
Thanks for the report. Issue is now fixed for 2.0.31. This issue is related to cliffs and removing multiple chunks in the same tick. As a workaround until 2.0.31 gets released, if you only request removal of chunks in rate of 1 per tick the issue should not happen.