Sometimes when I log back into our server at least one of my ID networks have stopped working. The indication is at least one of the writers showing the status "network corrupted", although in one or two cases I've seen that status although it still seems to work.

So far I've been able to fix it by either pulling out the data card in the writer and re-inserting it (rarely) or breaking a couple of cables around the writer and replacing them (usually).

I was reluctant reporting this because I have no idea what causes it could have. It doesn't seem to happen while I'm online, so my suspicion is that it either happens when the server restarts or is related to the chunk loading issues we have on the server (our version of ftbu seems to be rather random about actually keeping the chunks loaded I set it to).
Both networks I have this happened on cross chunk boundaries.

One other thing I noticed (which I'm just going to mention, not sure if that is ID's fault), if I "repair" a network after such an incident, my fps in that region often go to hell although the regulation shouldn't have set anything off that causes it.

I will pay attention to that next time it breaks. As far as I remember I can only say not all writers on the same network break down at the same time, at least not always, that much I know.

Chunk (un)loading indeed sounds like a reasonable cause, I'll have to investigate this.

In the meantime, if you notice any other details when it breaks, please let me know.

When a writer in a certain network is corrupted, do all the other writers in that same network stop working as well? Perhaps only the writers in that same chunk?...

@Belgabor I just did several tests with chunk boundaries and world reloading, and I can't seem to reproduce this problem.

If this problem occurs again in the future, could you let me know the following things?

• What kind of error is shown in all of the writers in the network? There should be an red cross icon that shows an error message when hovering over it, waila/top also shows this error message.
• Could you also let me know if the writer model also shows an error state? Normally, the model should have some green lines, while the error state will show some error lines.
• What kind of variable in the writer cause the issue? Is it a constant? Does it refer to a reader, variable store or proxy?
• Some more details about the network structure would be nice, a screenshot for example if possible.

Ok, I have a bit more information for you, albeit it was the simpler network that broke down. We updated the server to the newest version of ID and things slightly changed.

It being the simpler network makes things actually more clear (Since you've seen the video, it is the network that regulates the oil generators based on the RF contained in the IE capacitors). It definitely looks like it is a chunk boundary issue. The network is all in one chunk except for the variable store. The readers all showed the "inactive" red color on the model and no message/status on the status line. I am not sure if they showed the error cross next to the card slot initially, but they did once I pulled them out and reinserted them. The message was that the referred variable cards where inaccessible, so the network had apparently lost connectivity to the store in the adjacent chunk. Breaking and replacing the connecting cable between the chunks fixed everything.

@Belgabor Does it still happen in the latest version of ID? if so is it possible to send screenshots/video with chunck boundries so we can try to reproduce it.
I tried reproducing on a dedicated server, starting/stoping it and flying away and coming back

@Runesmacher This is the video: https://www.youtube.com/watch?v=gWMvC3hKZ6Y
It's unlikely to be fixed in the latest version though, since nothing major has been changed since then.

Sorry, I can't reliably test this atm, the server we played on has switched packs unfortunately.

@Belgabor I just implemented a fix for another issue that caused a crash with chunk unloading. This change may very well also fix this issue, so if you're interested, you can use the latest dev build to see if this resolves your issue.

Version 0.6.9 should have fixed this, if anyone else is still encounter this with the version or later, please reply to this issue.

Playing with 0.6.9 on a Sky Factory server, and every network i create gets corrupted each time it unloads.
They are as simple as a redstone signal to turn on when a certain amount of items in a container or a comparator output are reached.

@Iranite Please send me the full forge log.

I'm sorry, as this was a public server, I do not have acces to those.
I just wanted you to know, that the problem is still there and thus for me the mod is basically useless, except for the pretty trees and torches.

@Iranite Note that the latest version is 0.7.2, so you're probably just using a version that still has the issue. If you're able to use the latest version and provide me with the full logs, feel free to ping me here.

I'm not sure how to begin? But this bug is still happening. I'm playing on a public server and all my networks were inside of one chunk, but I find it also happens if they are in multiple chunks. It only happens sometimes when I rejoin. I can't seem to repeat it consistently, but when it does happen it is very obvious. I join and find none of my networks are working and they are all showing me the "NETWORK CORRUPTED!" message. The only way I've been able to fix this is to break a cable in line with the network and replace it, but this doesn't stop them from becoming corrupted. When it does happen it happens to all of them. I was planning on using integrated dynamics a lot in my base but this bug makes it completely unusable as I would constantly be replacing cables for every single network in the base.
The mod version I'm using is 0.11.18 for Minecraft version 1.12.2
I'm also using integrated tunnels version 1.5.6
This is currently happening to me on a public server running Stoneblock and has happened to me on another public server running the DireWolf20 1.12 pack.

New issue: #648