Multiblocks fail to save the cache data on the very last server tick, resulting in injected contents being lost
Closed this issue ยท 7 comments
Issue description
An ordering issue exists with MultiblockData, MultiblockCache, and the server tick pipeline, where sync(T data) will be called, followed by other entities, such as any tube network, injecting their contents into the multiblock, and then save(HolderLookup.Provider provider, CompoundTag nbtTags) will be called finally to save the cache to disk, however the data fed to save will be one tick out of date since sync is called before the final content injection is handled by the multiblock
This all occurs on the last tick that is performed when the user presses 'save and quit to title' in the pause menu, and the cache data saved to disk will be one tick out of date regardless of how long the game was paused.
There is also a chance that other than this always occuring when a dedicated server is shut down, that it may also result in lost contents any time a user leaves an area of unloaded chunks containing the structures, at least long enough for save to be called
This directly results in fission reactor meltdowns, as cool sodium, hot sodium, water, and steam are all lost from tube networks in the last tick before server shutdown
Steps to reproduce
can be easilly reproduced by using a simple dynamic tank, injecting a known amount of content via an ultimate tank injecting into a basic tube, into the dynamic tank
what will happen is the basic tube will be saturated by the ultimate tank, but the tube will inject 100% of its contents into the dynamic tank as long as there is space available
so long as you save and quit, or shut down the server, during the time the contents are flowing from the ultimate tank to the dynamic tank, this known exact volume of the basic tubes will be lost in the final transfer after loading back into the save and waiting for it to finish
Minecraft version
1.21.1 (Latest)
NeoForge version
21.1.133
Mekanism version
Current Dev Branch (Manually Compiled, specify git commit hash)
Other relevant versions
exists on current branch with at least commit #6565620, probably has existed for a very long time
If a (crash)log is relevant for this issue, link it here: (It's almost always relevant)
No response
think i have a patch for this but just gotta test it around to make sure it doesnt cause side effects
turns out I also discovered another kinda separate issue where all of the multiblock data gets lost if the process terminates without safely shutting down, looking at the data file it seems to be the cache UUID getting lost on the tile side but the data still exists in the data file
PR created here #8387
Is this the same reason fusion reactors turn off when I leave the world? (seems to be a known bug judging the chats on the All The Mods discord server)
if you are piping in D-T fuel directly, yes this bug results in fuel starvation, due to D-T being fully consumed each tick.
inversely piping D and T seperately will not have the issue so long as more is generated to account for the missing fuel that gets lost world stop-start, however if you were producing either of these at the exact rate the reactor uses it, it will fuel starve, and of course the fission reactor is no different here if you were running one non-stop, although of course the catch with the fission reactor is it doesnt need a kick-start
can also confirm that the pull request patch fixes the issue for the fusion reactor as well, it will continue to run on being fed exactly 2mB/t D-T fuel (via limited use of speed upgrades) throughout the world stop-start, without needing a fresh hohlraum each time
of course as a temporary measure, or just one in general, you can simply have a bin full of ready-for-use hohlraums inserted into the controller block, it will simply use one when necessary, but do take care that the fuel supply doesnt get too limited as that could result in it burning through the hohlaums in a perpetual fuel starvation loop