[2.0.11] desync in softmodded multiplayer (Comfy Mountain Fortress) with Mac

[dbt0]

Joining Comfy's Mtn Fortress scenario with 2.0.11 from an M2 Mac, desynced twice in less than two minutes. I didn't have any problem with 2.0.10 yesterday when I played for about an hour.

Desync reports attached.

[Gerkiz]

(Have /editor bound to some fast accessible hotkey (shift + tab))

I managed to desync everyone in game by doing:
1. Press shift + tab
2. Hop into 'forces'
3. Change force from 'player' -> 'bonus_drill'
4. Open "Edit other properties", but don't change anything.
5. Press "e"
6. Quickly switch the player force back to 'player' from 'bonus_drill' and press shift + tab
7. Desync

/Gerkiz

[boskid]

I looked at both desync reports and i am not interested in investigating it until a reproduction is given without any custom scripting. There are at least 4 characters all with the position desynced when it is {0,0} on the client while being reasonable on the server.

[coxsmds]

I also encounter desync problems on this scenario since 1 week, and can only play for a few minutes, then the local map is reloaded and then the desynchr occurs.

[zzh8829]

I looked at both desync reports and i am not interested in investigating it until a reproduction is given without any custom scripting. There are at least 4 characters all with the position desynced when it is {0,0} on the client while being reasonable on the server.

After debugging this for a long time I finally have a very reliable reproduction method and plausible guess.
- this desync happens when mac (M1) joined a PC game AND also when PC joins a mac game.
- It clearly does not happen when PC joins PC, I don't have two macs so cannot test mac joining mac.
- I looked at at least 5+ desync reports diff there always seems to be something to do with logistic robots.
- desync reports are very easy to create since when I join the MP server with mac it always desync in the first second.
- these reports are not very useful as you already noted, since its full of random craziness happing on MP server.

Now after I have the guess, after a long time trying different setups, I have a reliable reproduction.
- on PC loads my save file in MP, which is a brand new restart with almost no structure or anything going on.

mf-testing-delete-me-new-crash.zip

(18.96 MiB) Downloaded 26 times

Screenshot 2024-12-29 at 2.14.34 AM.png (321.56 KiB) Viewed 465 times

Screenshot 2024-12-29 at 2.14.34 AM.png
- mac player can now join the game without any desync issues at all I was able to play like normal.
- the PC player builds some roboports and put down some logistic robots to start some robot logistic.

Screenshot 2024-12-29 at 2.14.46 AM.png (400.47 KiB) Viewed 465 times

Screenshot 2024-12-29 at 2.14.46 AM.png
- mac player will desync very quickly after. desync will be triggered faster if you add more robots and also repeatedly add and remove roboports.

Screenshot 2024-12-29 at 2.17.51 AM.png (1.4 MiB) Viewed 465 times

Screenshot 2024-12-29 at 2.17.51 AM.png

It's unlikely this has anything to do with the mods or scripting since I didn't find anything related to logistic robots in the code.
However, I have not been able to reproduce this desync outside of comfy mtn.

With this setup I was able to produce very clean desync reports.

related issues 120244

[zzh8829]

Screenshot 2024-12-29 at 2.22.45 PM.png (210.2 KiB) Viewed 463 times

report

https://drive.google.com/file/d/1zMae7d ... sp=sharing

[boskid]

After debugging this for a long time I finally have a very reliable reproduction method and plausible guess.

Thanks for the reproduction steps. I was able to reproduce the issue. Root cause was that worker robot charging logic was using incorrect value for the max battery as this scenario has worker robot battery modifier set. When robot went to charge at some point it saw that it has 7.4MJ of energy when battery was only supposed to have 1.5MJ (because it was not accounting for force modifier) which caused the charging logic to think it still needs to get -5.9MJ of energy. This went into a "negative double into unsigned" undefined behavior which is known to desync between x86 to arm (on x86 it underflows while on arm it clamps to 0) from which a wrong amount of ticks to next update was computed causing a cascade of differences. This issue is now fixed for 2.0.29. This desync is completly unrelated to the original desync so i will not consider original desync to be resolved.