We are playing a heavily modded and the server desyncs when rampant is enabled, but does not desync when it's disabled.

We are not sure if rampant is the root cause but it's very likely.

(We have tried multiple versions of rampant, the one in this desync log is most likely an older version but it also desyncs on the latest version)

Could you please look into this and see if it's an issue caused by having rampant enabled, since the desync only happens when rampant is loaded.

Desync report link: https://www.mediafire.com/file/396c50teny1rqqr/desync-report-2022-08-16_19-32-25.zip/file

the log was downloaded, the save was started.
I hope the error will be reproduced on the windows server.

Prior to version 1.0.17, there was desynchronization in the windows client, when an entity of the "mine" type was spawned by Hive. But since 1.0.17, these entities have been removed from "Rampant Fixed". So, if the reason for desynchronization is still in the Rampant, then it can be caused by anything.

Most likely, it will take some time

an attempt to start the 1.1.65 server (even without mods, on a newly created map) ends with an error:

0.756 Info HttpSharedState.cpp:54: Downloading https://auth.factorio.com/generate-server-padlock-2?api_version=5
0.831 Error HttpSharedState.cpp:138: CURL failed: code:35, 23; Send failure: Connection was reset
0.831 Info HttpSharedState.cpp:147: Downloading https://auth.factorio.com/generate-server-padlock-2?api_version=5
0.832 Info HttpSharedState.cpp:148: Status code: 0
0.832 Info AuthServerConnector.cpp:21: Failed to reach auth server: code(520) message(Send failure: Connection was reset)
0.833 Error ServerMultiplayerManager.cpp:92: MultiplayerManager failed: "Unknown key: "Failed to reach auth server. Code: 520. Error: Unknown error.""

at the same time, the server version 1.1.49 starts without problems.
Perhaps you have already encountered this problem? (windows 10)

Sorry i haven't encountered that error, i use the Linux x64 server so i don't have experience running a server on windows

the most interesting thing is that the stable version (1.1.61) also runs without problems. But it will not be able to start this save.
I will look for options, but I promise nothing

I have an idea what might cause desynchronization.
While I'm changing this part of the code, you can uncheck "World: Long range immunity for some factions" and "World: Oneshot protection for some factions".

Also, the combination of mods "K2+SE+Combat Mechanics Overhaul" breaks the steam-attack of fire and inferno spitters. Due to incorrect replacement of attack parameters, it begins to cause zero damage. While I'm writing an alternative attack that will be used when a combination of these mods is detected, I recommend disabling the settings of the Combat Mechanics Overhaul mod: Spitter spit blockable and Worm spit blockable

I'm now the new server owner of that server. We're still experiencing desync issues as before, sadly. We changed the startup settings and the issue still persists. Furthermore, we even removed combat mechanics overhaul to try to fix it that way, but with no success.
The desync report: https://filen.io/d/c3ff4926-d231-4324-9b5f-aa7b7e9babd7#!GxV4SCz8vUicBzDMuGDyX1HKeExBUsi7

In May, when I was playing on the server, some people (including me) never got out of sync, and some (always the same people) - sometimes. At the same time, it was possible to play for many hours and not get out of sync
Is it the same for you?

It is always that everyone desyncs at the same time. In the beginning of the game we had no desyncs, now we're like 85hrs in and keep on desyncing if we play with the mod.

windows server 1.1.68 started successfully. Tests are underway...
Testing on the first save, because the second log interrupts the download by 99.68% and, of course, is not unpacked

upd:
in an hour - there are no desynchronizations.
There was a noticeable lag when loading the save. From what was noticed: the autosave has a size 3 times smaller than the sent save (22Mb vs 68Mb). Sometimes - small delays during the game

The hypothesis is tested that one of the character parameters from the rpg-system can cause desichronization. There is a genocide of biters with the aim of raising the level ... )

Unfortunately, the error could not be reproduced.
Further testing is not possible, because the 1.1.68 server now also does not pass authorization.
In the version 1.2.6, removed the setting "tiles affect the biters", which theoretically could cause desynchronization. However, I don't think it's about it.

It was possible to partially unpack the last desynchronization log. From what I noticed - after resaving in a single game - its size decreased from 168 to 55 megabytes. Perhaps this somehow affects what is happening with you

kneesox, most likely, you are no longer playing on the server, but just in case:
in another branch, we managed to find out the reason for desynchronization and fix it.
Since version 1.3.5, there is no desynchronization when playing on a Linux server