Issue type:

• 🐛 Bug

Short description:

Occultism issue report: klikli-dev/occultism#338

I had made an earlier bug report to the Occultism dev but the issue is believed to be on the Integrated Tunnels side. rWhen linking an item interface to a stable wormhole (portable access to storage system), the wormhole will lose all its NBT data and disconnect from the main occultism network.

Steps to reproduce the problem:

1. Place linked wormhole
2. Attach interface -> wormhole loses nbt
3. Remove, link and re-place wormhole -> wormhole has nbt
4. Add cable to the network the interface is connected to -> wormhole loses nbt

Expected behaviour:

It should connect to the wormhole and use it to hold items for the network. Works as expected when used on the main storage block for the network.

Versions:

• This mod: 1.8.5
• Minecraft: 1.16.5
• Forge: Forge-1.16.5-36.2.2
• occultism-1.8.1

Log file:

After a few tests: It seems to be only the interface. The block reader does not cause it, nor do cables cause it, unless they are connected to an interface that is attached to the wormhole.

That's weird. CyclopsMC/IntegratedDynamics#1072 was triggered when any ID cable is placed, even if there are no parts on it. (For reference, I wasn't able to reproduce it on Forge 36.0.42 though, so it may also be a Forge issue)

I just did some further checks - when the interface is placed (or a cable is added to the network) onReplaced is called on the block the interface is connected to, and apparently it is supplied with the default state (which in Occultism's case causes the wormhole to be disconnected):

That is the difference to vanilla tiles - they do not use the block state that way.
I'm not familiar with ID/IT codebase, but does this ring any bells?

@klikli-dev Doesn't ring any bells, no. Is there a way to see the stacktrace to that point, then we might be able to how ID is (or is not) causing the call.

Thanks for reporting!

If I may add to this: The nbt is also cleared if the integrated tunnels "network" is updated - e.g. when placing a cable that is connected to the interface, but not adjacent to the target block, see klikli-dev/occultism#338 (comment)

If there's anything I can/should do on occultism's side, happy to :)

That's weird. ID/IT should only be reading capabilities from the target blocks, not modifying them in any way.
Does this also happen when connecting other ID parts? Like the block reader?
If so, this may be related to CyclopsMC/IntegratedDynamics#1072

Also weird that it doesn't happen with vanilla tiles.

I'll investigate further - the cable test makes me think it might be the same issue (i.e. it might happen even without an interface if a cable is placed in the same chunk) but I'll test that

I set up IT in my dev env and going through the stacktrace myself now - after sleeping on it I have a suspicion of how occultism might cause the onreplace itself (there's a fallback functionality if the linked block is not found that causes it to unlink), but have to figure out why it doesn't happen with other capability interactions. I'll update here in a while if I this issue can be closed.

EDIT: Found it. Problem seems to be threading, my GetCapability accesses another tile entity (the controller of the network), and `world.getTileEntity()´ fails due to the access not being on the main thread. I'll look into either caching the access or access it cross-thread then the access from IT/ID should work.

Solved in klikli-dev/occultism#338 - can be closed here :)

The issue was indeed cross-thread access to tile entities coming from ID/IT, but I mirrored how cyclopscore accesses tiles for the affected Wormhole tile and it works correctly now.

Hmm, good find.
That does indeed explain the problem.
While your fix will indeed solve the problem, I'm wondering if ID shouldn't be fixing the problem, as other mods will have the same problem (like CyclopsMC/IntegratedDynamics#1072).
So I'll keep this open for now.

Closing this in favor of CyclopsMC/IntegratedDynamics#1081

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

@klikli-dev I refactored things on my end, which should resolve the issues. Your workaround should therefore not be needed anymore.