I am developing a new method to try to test the cause of this and other desyncs: I have just pushed a change to the code in which, if the preprocessor directive DISABLE_RANDOMNESS is defined, the random number generator will always simply return half of the maximum value, and the function for getting the random number generator seed will always return 1. I am in the process of rebuilding the Bridgewater-Brunel server with this option enabled. This means that it will not stay in sync with any normal client, but should be able to stay in sync with a client compiled with DISABLE_RANDOMNESS.
When a client with DISABLE_RANDOMNESS connects with the server, it should be possible to see in the game itself where the desyncs arise without this affecting lots of other unconnected areas of the game at random by changing the random number generator seed. Also, because the random number generator seed is fixed, the client should not be kicked from the game unless and until a more major difference (such as in the number of convoys) emerges. This system is intended just for testing (it would be no good in a real game, as there would be no randomness), but it should help to highlight where the problems are.
It would be very helpful if anyone with the ability to compile the game were to connect to the Bridgewater-Brunel server with a build with DISABLE_RANDOMNESS compiled with two separate clients (both built with DISABLE_RANDOMNESS) to try to spot how, if at all, they diverge from one another. It might be hard to spot, as the game currently running on the server is a big map; if anyone can find a smaller, simpler map which will reliably desync with a normal build between Windows and Linux, it would be helpful to use that for testing, too.
Thank you all in advance for any help with this: it would be much appreciated.
Edit: Having now tested this briefly, the special DISABLE_RANDOMNESS build does appear to stay in sync, as expected. Any help in tracking down actual divergence would be very much appreciated.