Hi,

First if all, sorry for the annoyance of the multiplayer desync issues. Our assumptions on the real source of the problems were not correct, so we have lost a lot of time trying other solutions, with no real improvement. The desync was insidious and random, explaining why it was difficult to find. Also, we thought the slight differences of floating point values (see below) were no big deal and inherent to the network simulation. That was wrong.

We now think that what is described below is the true source of the problems, but this will need to be confirmed by intensive testing, first with our QA partner, then with the community members who want to test a special version.



Conversion issues [Fixed]
Issues happening when converting some variables into strings upon game creation: In a MP game, the host will generate game elements on his side and then create a save that he will send to all other players in game. This process will ensure that every player has the same game data. We have found that in some cases, floating point values written in a save and their interpretation by players were slightly different (about 0,0001 or less difference between each player); this would lead to desynchronisations. Beside those saves, some orders (sent from one computer to others) use this variable conversion (Floating point number > String > Floating point number), which may cause desync in a running game (e.g. instant Dust consumption when buying a building).

Occurrence
Upon game creation, as players read a save created by the host.
When specific orders are sent (dust expenses, tax rate change).
When a player joins mid-game (reading a save created and forwarded by the host). The more the game is advanced when the player joins, the more there are data concerned by the desync.



Updating data simulation [Fixed]
Common point of these desync: modifiers applied with identical priorities but not treated in the same order (percentage type). When an order would differ from one computer to another, calculus could differ (once again, 0,0001 difference). We could then observe this snowball effect in these desync when the incremented variable was used in some other calculus (food is used to calculate food surplus, which is used to calculate the growth value of a system, which would evaluate new population spawn rate and so on).

Occurrence
First desync would appear pretty fast (between turn 5 and 15). The snowball effect could be quite important and then have consequences for a great period of time.



Initialising influence zones of home systems [Fixed]
On the first turn (and only), influence zones may differ. Those would immediately resync on the next turn. This came from wrong data initialisation to generate influence zones of home systems.

Occurrence
Turn 1. It would disappear on the next turn.



Latency [Workinprogress]
We have developed a tool which allows us to simulate latency and enables us to deeply test the new system of orders. This has allowed us to find several problems, which do not necessarily create additional desynchronisation, but stability issues. These are currently being fixed.


We'll continue working on this, we’ll try to make a special MP version available for those who would be interested in testing the latest version and help us out test the fixes and find the remaining issues. If everything goes well, it should be available next week. We’ll give you more info on this as soon as ready.