.thumb.png.22c2d8a7c6c01c02875b5bff4df934ee.png)
SimDLL.dll settle pipeline (Sim::UpdateData and friends) exhibits timing-dependent nondeterminism, causing mob placement to differ as that relies on the 500 ticks of simulation. For identical inputs into SIM_HandleMessage, the final cell state differs across repeated runs of the same worldgen coordinate. A 1 ms sleep between `SIM_HandleMessage` calls is enough for deterministic behavior for the purposes of worldgen, which is proof there is some thread/data concurrency shenanigans going on with the sim. Given there was some effort to using a PRNG for the headless sim, this leads me to believe that mob placement was meant to be completely deterministic rather than intended/emergent behavior.
V-OASIS-C-57458-0-0-0
Non-deterministically gets me this 4 sweetle version by the teleporter.
It should deterministically give me the 3 sweetle version (see bandaid below)
Aside from the above seed, for a minimally reproducible example, copy this python harness script replay.pyand trace.bin trace.binwhere SimDLL is located (OxygenNotIncluded_Data\Plugins\x86_64) . The python script passes messages into SimDLL.dll using the same byte buffer as an actual grid in headless sim mode.
Example run where the fingerprint changes when messages are handled in a tight loop (via python replay.py trace.bin | Select-String final_fingerprint).
Example run where the fingerprint changes when messages are handled with a 1ms sleep via (python replay.py --fix trace.bin | Select-String final_fingerprint).
I was also able to get completely consistent worldgen mob placement with a mod that introduces a 1ms sleep to HandleMessage.
KleiPlsHelpMyDeterministicWorldgenIsntActuallyDeterministic.zip
There are no comments to display.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now