Issue type:

• 🐛 BiggerSeries/BiggerReactors#21

Short description:

Something breaks with chunkloading/unloading and NBT, causing weird multiblock behavior including loss of NBT

Steps to reproduce the problem:

Move outside of spawn chunks (unable to repro in spawn chunks), build reactor entirely within a chunk, place logic cable in same chunk, reload world

Expected behaviour:

Not loosing NBT.

Versions:

• Integrated Dynamics: 1.9.0
• Cyclops Core 1.11.7
• BiggerReactors: 0.5.1 (dev env)
• Phosphophyllite: 0.5.1 (dev env)
• Minecraft: 1.16.5
• Forge: 36.1.63 (dev env)

What appears to be happening is that a chunk containing ID blocks is unloaded at world load, which somehow results in NBT for my blocks not being reloaded probably, causing their loss.
The exact behavior described in BiggerSeries/BiggerReactors#21 is directly related, as its caused by me attempting to grab a chunk that doesn't exist, while not forcing chunk loading.

FYI: for the fastest response from me, find me on discord, RogueLogix#5271, among other servers you can find me on ForgeCraft

@RogueLogix I seem to be unable to reproduce the problem myself it seems.
I've been using Forge 36.0.42 instead of 36.1.65 though, so that may have something to do with it.
(out of time to work on this for now, otherwise I would have tested with another Forge version)

I've seen similar issues in the past with OpenComputers.
The problem there was that OC's TileEntity class did some state handling within TileEntity.write().
Since this method can be called quite often by ID, this could cause issues.

Any chance something similar is going on @RogueLogix?

Thanks for reporting!

I will note, I'm not 100% sure if this is an Integrated Dynamics issue or if its something wrong with my multiblock system, or both.

Oh, that sounds odd.
No idea what could be causing that tbh :/

It's the first time in years I hear of an issue like this with ID, so I would be very surprised this is caused by something on ID's end.

FYI, ID doesn't do any explicit chunkloading, or manipulation of chunks.

There also does appear to be an element of a race condition here as the behavior consistently changes from just NBT deletion to the reactor assembly failure seen in BiggerSeries/BiggerReactors#21 if i stall the main server thread for a few seconds during initial load.

I don't think that's the problem as it persists even if its just a single logic cable not directly touching the reactor but still in the same chunk

Test setup I used has a single logic cabled placed a block away from the reactor.

I would also be surprised if its something with Phosphophyllite (multiblock library) as it also doesn't do any chunkloading or chunk manipulation. One thing I did find when attempting debugging is that chunks containing ID blocks are unloaded immediately after chunk load when loading into a world, and i have no idea why and couldn't trace it back to a call made by ID.

Do you know if there are specific types of ID networks that cause the problem?
E.g., does the problem occur with a single cable (no parts)? Or does it only occur when there are (certain?) parts attached to cables?

No clue what could be causing this tbh, the behaviour you are describing doesn't ring any bells as to how it may be related to the ID codebase. Most of this code has remained unchanged for the last couple of years. Happy to make changes if you were to find anything wrong on our end though.

Closing this in favor of #1081

For anyone running into this problem, disabling ingredientNetworkObserverEnableMultithreading in the ID config should fix the problem for now.

@RogueLogix Should be fixed in the newest ID version. Could you double-check if it's fixed on your end as well?

updated to ID 1.10.2, issue persists in my dev environment, same world, cleared config
disabling that config option also did not fix the issue.

Then I guess the problem must lie elsewhere, as a similar issue (CyclopsMC/IntegratedTunnels#242) was fixed by this, and AFAIK, ID doesn't do any other multithreading that could cause this problem. (but definitely open to be proven wrong :-) )