To reproduce: wait for or cause a large change in water levels and run the game at a high speed as the simulation ticks.
Example: desync.zip
What happens: The game desyncs due to (at a minimum) soil moisture levels getting out of sync.
Why: Timberborn currently runs a bunch of simulations in parallel each tick. The result of one simulation seems to depend on another, specifically:
SoilMoistureSimulator, which reads the results from WaterSimulator.
In theory (at least as I understand it), these simulations are designed to have threadsafe data, and they read from the prior tick's results, not the currently processing tick. However, I get non-deterministic results.
One fix may be to investigate when the results flip from the prior to the current tick's simulation results. It's possible this is what's nondeterministic.
Can currently be fixed by setting #NO_PARALLEL, but this would also deteriorate performance, so I'd like to find a workaround if possible.
To reproduce: wait for or cause a large change in water levels and run the game at a high speed as the simulation ticks. Example: desync.zip
What happens: The game desyncs due to (at a minimum) soil moisture levels getting out of sync.
Why: Timberborn currently runs a bunch of simulations in parallel each tick. The result of one simulation seems to depend on another, specifically:
SoilMoistureSimulator, which reads the results fromWaterSimulator.In theory (at least as I understand it), these simulations are designed to have threadsafe data, and they read from the prior tick's results, not the currently processing tick. However, I get non-deterministic results.
One fix may be to investigate when the results flip from the prior to the current tick's simulation results. It's possible this is what's nondeterministic.
Can currently be fixed by setting
#NO_PARALLEL, but this would also deteriorate performance, so I'd like to find a workaround if possible.If not it may have to be a configurable setting.