Issue type

• 🐛 Bug

Short description

My two Integrated Dynamics networks often, seemingly randomly, stop working. When this happens, the world item exporters and world block exporters that I have hooked up to the networks say “NETWORK CORRUPTED!” at the bottom of their GUIs.

It seems to occasionally happen when I exit the world and come back on.

It fixes itself when I break the item interface and place it back down (or cause a block update to any part of the network), but this is annoying to have to do every time this happens.

This issue seems to be similar to #648 from last year; however, the issue was automatically closed since the issue author never provided any further information. Also, that person was using SpongeForge, but I am not. I’m playing single-player and am not using SpongeForge, Bukkit, Spigot, or anything of the sort. I’m not sure if it happens when I exit the world and re-enter it similar to how it happened when the person who submitted that issue had the problem occur after server restarts, but this is something that I can test.

Steps to reproduce

1. Create a Integrated Dynamics network in Enigmatica 2 with a function, such as placing and breaking blocks.
2. Wait a while.
3. Observe it not working.

Expected behaviour

The expected behaviour is, surprisingly, that networks should not randomly stop working.

Versions

• Modpack: Enigmatica 2 (version 1.65a, latest)
• Minecraft: 1.12.2
• Forge: 14.23.5.2781
• Cyclops Core: 1.1.1 (latest)
• Common Capabilities: 2.2.0 (latest)
• Integrated Dynamics: 1.0.11 (latest)
• Integrated Tunnels: 1.6.8 (latest)

commenting anyway even if it is closed and gone, here in 2021, on 1.12.2, multiblock madness, which is a current modpack on an active server network that is popular right now, we have Integrated Dynamics, and it all works great UNTIL you have to log off, then come back the next day/hour/minute/second, then none of the ID stuff you set up works, most of it ends up being corrupted (for what reason, i have no idea why). If you break all the cables, put them back (WITHOUT CHANGING ANY ITEM IDs MIND YOU) then everything works again. It's like the cables forgot what they were connected to. There is no significant information in the client-side logs about this, so, I am assuming it must be server-side (but still in the mod's domain). We all love this mod, it would be nice if there was some sort of solution to this one thing that keeps us from using the mod entirely.

I suggest updating to MC 1.16, all issues have been fixed there.
1.12 is more than 4 years old already, and 1.18 is even already out now...

I know this would probably not get a fix any time soon (or at all), but I just would like to point out (since I still deal with 1.12 servers quite often) that there might be some issue with writeNBT or readNBT methods with network parts, causing the endpoint to forget what part they're connected to.

A strong chunk load ticket, for example the one from railcraft's worldspike, would force the network to stay loaded, meaning that all the NBT data are still in RAM and won't be lost. However, when player log off or leave the area, even if there are weak load ticket (e.g. FTB chunk claim), the data are serialized. And, for some unclear reason, the network data are not serialized properly, causing the network to become corrupted.

I'll try to pin down the issue - I think I have a general idea of where it might be. If I succeeded on fixing it, I will submit a PR.

I'm still trying to dig deeper into how chunk loading or other things could have caused this issue. I currently am unable to reproduce the issue in a world with only forge and this mod loaded, so I'm making my further investigation with the assumption that some other things have been messing with the way TEs interact with the world.

A thing this assumption help brought to attention is that in the previous few time where my player started to report a corrupted network, the server are all based on 3rd party software, for example sponge. With just forge it appears to have not been a issue... at least for now.

And whats more is that I know sponge is doing stuff with ticking events and chunk loading, so I highly suspect that caused the issue. This means, if my theory is correct, I can also assume those corrupted network on so-called vanilla servers were impacted by similar coremods such as VanillaFix. I'll try do some controlled variable experiment and if that proved my theory I'll report back here.

P.S. don't tell me to just leave it and update to 1.16. A lot of mods won't update past 1.12, and also 1.16 have much worse performance compared to 1.12.

Note to self: check how PartStateActiveVariableBase#getVariable behave. See if different mod combinations cause that to change for the same network, especially on chunk load.

I'll add my "fix" for anyone who stumbles across this corruption issue for 1.12.2, playing the E2E modpack v1.83 I had an issue with advanced rocketry causing my server to crash every time I joined a dimenion, when I finally got that fixed, ALL of my integrated dynamics networks were corrupted.

I found that either breaking the cables and replacing or picking up the variable store fixed the issue... And I was able to use the Mekanism packing box to pick up the variable store without spilling all of the card contents on the ground.

Wait a while.

This is unfortunately not enough for me to reproduce the bug. This is probably due to a very specific kind of network setup.

@Dimentive Can you share your logs after such a corruption just happened?

Running a dedicated server for SkyFactory 4, I have just experienced the same bug with a very complex Integrated Dynamics network. There's no error in the logs, everything is perfectly fine.

What I have started doing is isolate parts of the network by breaking out the cables. As I was doing so, they became uncorrupted. I believe network loops are what caused this to happen, like making a circle with cables. Similar to an issue with Applied Energistics networks where 2 paths with equal weights prevent the network from finding an optimal path and thus shutting down the whole network.

I'm pretty sure that loops do not cause a problem, I have checks in place for that.

As I was doing so, they became uncorrupted.

Corrupted with the “NETWORK CORRUPTED!” message? Or just variables that can not be found? Because the latter is normal when you start decomposing networks.

Yes the whole network had "Network corrupted!" message on all connectors. After I broke a few cables it all became uncorrupted everywhere.

I can provide any additional information you need, as I still have most of the network in place. But I've split it up into smaller "islands" to hopefully prevent the bug from happening again in future. The original network had about 70 to 80 machines connected for power, about 20 of them for various fluids, and other bits and bobs. It was spread over 10 chunks, on multiple Y layers.

Sounds like the same problem I have.

Same problem here. Playing Direwolf20 1.12.2 modpack. I have one bigger and some smaller networks. All of them occasionally stop working. Because these networks are unattended (mobfarm, ore-sorter, etc) but have high througput, every cleanup is a mess and/or much work. For now, I made a OpenComputers script for supervising the networks. It feels a little liek real life... XD

I can also provide additional Information. Please let me know what you need. Maybe it would help to send a savegame to you.

A good thing would be to have a command line command to "reset" all networks as a workaround.

To everyone posting here, please send me your full Forge logs, otherwise I can't know what is causing the corruption.

I encountered a similar problem in the server, the network will become "corrupted" when you back online.
I slove this problem by using Railcraft's Standard Worldspike to load target chunk.
But some chunk loading can't slove problem, such as FTB Utilities' chunk loading.

I'd love to fix this issue, but there's really nothing I can do without full server logs...

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

Well, for the part that @Loner-Knowledge said, I did found the following stack trace that are thrown each time someone login into his area. I have no idea why this is happening.

Hope this issue could be re-opened

@Water-Moon Could you share that log file with me? It looks like that may help out with fixing this issue.

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

Bad bot

@Water-Moon Could you share that log file with me? It looks like that may help out with fixing this issue.

sure, I will restart the server and grab the log for you soon.

OK, I got the log here.

2019-05-29-2.zip

It is extremely long...and is full of the 'network corrupted' information... QAQ

@Water-Moon Thanks for the logs!

I have not yet been able to reproduce this issue, but I was able to pinpoint a potential cause of the problem based on your logs.
Could you try out the latest ID dev build (build 1341, see link in readme (still building at the time of writing)) to see if this changes anything for you?
If this does not fix anything, could you send me the new logs again?

Note to self: if this doesn't fix the problem, have a look at Network#isValid, and add a check there to ensure revalidate was fully successful, and a valid network carrier was found.

That's pretty fast responce. Sure I'll install it to my server and test. Thanks!

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.