Issue type:

• 🐛 Bug

Short description:

• All of this info is what I can gather from experimenting. It is extremely hard to work out what is actually happening.

• Networks seem to corrupt when their chunk is reloaded.
• Only seems to happen with I. Tunnels parts and not I. Dynamics ones.

Expected behaviour:

• Networks continue functioning

Actual behaviour:

• Network function is ceased

Steps to reproduce the problem:

1. Have a network with at least one item interface on it (for simplicity)
2. Make sure that at least a part of said network isn't chunk loaded - preferably the whole network. My networks would sometimes break even though part of them was loaded, but I think that was because of server restarts.
3. Leave the area that it is in (I like to change dimensions) and wait a good amount of time for it to unload (I'd like to say a few minutes)
4. Test by placing a redstone writer on the network and sticking a blank card into it.
   

Exmaple of my lab setup that breaks reliably in the End:

Having a network with an R. Reader or Writer on it will unreliably prevent corruption in its chunk from what I can tell - perhaps they're just keeping the chunk loaded or for longer than I am waiting. This may extend to other I. D. components as well.

Honestly at this point I've tested this (and myself) to within an inch of it's life, so I'll just get this out to you guys for now and I'll be happy to give any info to the more educated questions that you can give rather than my arbitrary experimenting that I've been doing.

Versions:

• This mod (Tunnels): 1.12.2-1.5.5
• Integrated Dynamics: 1.12.2-0.11.9
• CyclopsCore: 1.12.2-0.11.5
• Minecraft: 1.12.2
• Forge: 14.23.1.2601
  (I am using Horizons III and just updated I.D. and I.T. in a -failed- effort to fix this.)

Log file:

N/A

Could you try reproducing this with just ID+IT (and dependencies) installed?

Still happens... and quite reliably too.
Plop one of those and an end portal down, hop back through, wait 30 seconds and return back.
Had it break 100% of the time.

• ID - 1.12.2-0.11.9
• IT - 1.12.2-1.5.5
• Cyclops Core - 1.12.2-0.11.5
• Forge - 14.23.2.2639

Ok, that's not good, will have to look into that.

Tested this a bit with the time I had, and I wasn't able to reproduce this.

Note that I used Forge 14.23.1.2555 instead of 14.23.2.2639. If I find some more time (probably end of next week), I'll try it with that newer Forge version as well.

Thanks for your testing effort ;) The ticking vs non-ticking parts do indeed sound like an important factor in the problem. I'll look into it soon.

Note to self: test with pure passive item interface networks.

My god, this turned into a wall of text. I hope at least a small part of it is helpful...

It isn't an issue with Forge from what I can tell because I used 14.23.1.2555 (your version), 14.23.2.2640 and 14.23.2.2611 with no noticeable change between them.

I discovered that you don't actually need any parts on the cable at all for it to corrupt, and also that I can simply teleport myself 5000 blocks in a cardinal direction on a flat world, plop down a cable, then -5000 back to spawn (to unload the chunks) and then +5000 again to return to them to see that it is corrupt.
Armed with this new testing ability I tested it with different parts and here's what I came up with;

• Leaving it with any part that is, I assume, "ticking" - eg; Item Importers/Exporters, Redstone Readers/Writers and so on will prevent corruption completely.

I wondered why this was, so what I did was;

• Leave an empty Redstone Writer on a single uncorrupted cable
• Grab the coords of a block in the same chunk as that cable and r. writer
• Then grab the coords of a block in the chunk next to that one
• Teleport myself back to my starting point 5000 blocks away
• Tried to use the setblock command on the two coords.

I don't know how reliable the setblock command is for testing loaded chunks, but the chunk with the Redstone Writer in it seemed to stay loaded permanently - as in the setblock command continued saying The block couldn't be placed which means that the block was already air to start with, while the chunk next to it that just had a single cable in it responded with Cannot place block outside of the world.
When tested, the single cable was corrupted, while the cable with the r. writer on it was not.
The same effect occurred with any "ticking" parts that I could find - such as importers and exporters from I. Tunnels, and anything similar to the r. writer.
This indicates to me that the r. writer is actually keeping the chunk loaded for whatever reason until the world is unloaded (by logging out of my SP world for example).

I had a thought that it wasn't getting enough time to save the network info when the chunk was unloaded (you may be able to also answer this), but I don't really know how I would prove or disprove that. Again just a thought tho.

Oh, hey I just realised... this doesn't seem to be an issue with Tunnels at all, and rather a problem with Dynamics, as even a single cable left to unload gets corrupted. Does this mean that this issue needs to be moved or something?
I was originally was under the impression that it was the interfaces causing it... just didn't click that it was ticking vs non-ticking parts.
Note that I haven't actually tested without Tunnels installed, just merely not using the parts.

No, it's fine, this issue can stay here.

Note to self: test with just ID.

Ok, just managed to reproduce and fix this issue.

Feel free to use/test the latest ID dev build (see readme) in the meantime.