The client joining the host desyncs immediately after downloading the map from the server. It desyncs both ways with either player desyncing after downloading the map. We have tried removing recent mods as well as other mods unrelated. We are able to create a new world with every mod enabled and join without issue.
I have included the client mods, the hosts mods (which should be identical), the desync report and a client save of the game made at the time the server was closed. We are unsure of the issue. Thanks for the help in advance.
https://drive.google.com/drive/folders/ ... sp=sharing
[1.1.19][Desync] Desync immediately after connection to host (Better air filtering)
-
- Manual Inserter
- Posts: 2
- Joined: Wed Feb 03, 2021 2:56 am
- Contact:
Re: [1.1.19][Desync] Desync immediately after connection to host
Ok i looked into this desync and i was able to reliably reproduce it when hosting the reference save file in local MP.
When i was running that map with single ticks and doing crc checks, it made a clean diff saying that pollution values are different and evolution by pollution values were different.
After mod bisection i found that when running that save file with all mods except "better-air-filtering" runs stable for period of time i was testing it with while running with only base+"better-air-filtering" it was desyncing in the same way. Because of that i would say it is a "better-air-filtering" mod desync.
-- edit:
I looked a little into that mod code and why it desync: i have added some prints and host produces this:
while client produces this:
So on the host there are twice as many update calls done and they are all coming from local variable `air_filtered_chunks` which is not save-loaded but it is filled by `init` function. Host runs the init function twice (because of on_init and because of on_configuration_changed) but the `air_filtered_chunks` is not cleared by the init function. For my own testing purposes i was able to fix those desyncs by changing:
into this:
(literally one line added) and the desyncs are not happening anymore. You can also fix this temporarily by opening that save file, resaving it with current set of mods and loading that new save file: that way when loading new save there will be no migrations because of mod changes and so the host will not do twice as many updates in the "better-air-filtering" mod.
When i was running that map with single ticks and doing crc checks, it made a clean diff saying that pollution values are different and evolution by pollution values were different.
After mod bisection i found that when running that save file with all mods except "better-air-filtering" runs stable for period of time i was testing it with while running with only base+"better-air-filtering" it was desyncing in the same way. Because of that i would say it is a "better-air-filtering" mod desync.
-- edit:
I looked a little into that mod code and why it desync: i have added some prints and host produces this:
Code: Select all
suction update tick=4087059 e=nil dx=-2 dy=2
totalSuction= 0
totalSuction= 0
totalSuction= 0
totalSuction= 0
suction update tick=4087059 e=nil dx=-1 dy=3
totalSuction= 0
totalSuction= 0
totalSuction= 0
totalSuction= 0
pollute: tick=4087060 surface=nauvis p={x = 0, y = 0} a=-0.31546306824535
suction update tick=4087060 e=nil dx=-1 dy=0
totalSuction= 0
totalSuction= 0.66666666666667
chunkFrom= {filters = {{__self = "userdata"}, {__self = "userdata"}, {__self = "userdata"}}, surface = {__self = "userdata"}, x = -1, y = 0}
chunkFrom::pollution= 0.083333328155883
totalSuction= 0
totalSuction= 0.66666666666667
chunkFrom= {filters = {{__self = "userdata"}, {__self = "userdata"}, {__self = "userdata"}}, surface = {__self = "userdata"}, x = -1, y = 0}
chunkFrom::pollution= 0.083333328155883
Code: Select all
suction update tick=4087059 e=nil dx=-2 dy=2
totalSuction= 0
totalSuction= 0
suction update tick=4087059 e=nil dx=-1 dy=3
totalSuction= 0
totalSuction= 0
pollute: tick=4087060 surface=nauvis p={x = 0, y = 0} a=-0.31546306824535
suction update tick=4087060 e=nil dx=-1 dy=0
totalSuction= 0
totalSuction= 0.66666666666667
chunkFrom= {filters = {{__self = "userdata"}, {__self = "userdata"}, {__self = "userdata"}}, surface = {__self = "userdata"}, x = -1, y = 0}
chunkFrom::pollution= 0.083333328155883
Code: Select all
function init()
-- gather all filters on every surface
global.air_filtered_chunks_map = {}
Code: Select all
function init()
-- gather all filters on every surface
air_filtered_chunks = {}
global.air_filtered_chunks_map = {}
-
- Manual Inserter
- Posts: 2
- Joined: Wed Feb 03, 2021 2:56 am
- Contact:
Re: [1.1.19][Desync] Desync immediately after connection to host (Better air filtering)
Thanks for looking into the issue. We never would have suspected better air filtering to be the cause. Big props for the quick response too!
Re: [1.1.19][Desync] Desync immediately after connection to host (Better air filtering)
JoeyDP reported this as fixed in better-air-filtering 0.3.2 (https://mods.factorio.com/mod/better-ai ... 2b356c2d1a)
Re: [1.1.19][Desync] Desync immediately after connection to host (Better air filtering)
Factorio did a minor update today (to 1.1.25) and our savegame from yesterday didn't work anymore - desync everytime the second player tried to join.
Disabling only Better Air Filter alone confirmed that it was this mod which caused the desync. Going back to Factorio 1.1.21 (second newest available on Steam) did not help.
Better Air Filter was already on 0.3.2 which should include this fix.
However the workaround mentioned above (Loading and saving the game once in Singleplayer) did solve it and we could then continue playing (including this mod).
So many thanks @boskid for both finding the issue and providing a workaround as well
*purrrr*
Disabling only Better Air Filter alone confirmed that it was this mod which caused the desync. Going back to Factorio 1.1.21 (second newest available on Steam) did not help.
Better Air Filter was already on 0.3.2 which should include this fix.
However the workaround mentioned above (Loading and saving the game once in Singleplayer) did solve it and we could then continue playing (including this mod).
So many thanks @boskid for both finding the issue and providing a workaround as well
*purrrr*