Crash when modifying energy network.
Splutty opened this issue ยท 10 comments
Seems this issue has been existing since 2018, and hasn't been resolved yet, with the threads being closed as duplicates to a thread that's locked.
Describe the bug
Modifying (removing/adding) energy sources to a quantum bridged network with multiple energy sources on both sides crashes the server.
To Reproduce
In a powered quantum bridged network, build a separate energy provider (acceptor + batteries + powersource) then connect it to the existing network. Crash. Remove it from the existing network. Crash.
Expected behavior
Not crashing when adding/removing new energy providers.
Additional context
Environment
- Minecraft Version: 1.12.2
- AE2 Version: rv6-stable-7
- Forge Version: 1.12.2-14.23.5.2847
** Additional Comments:
I've seen several of these being marked as a duplicate of another thread, and while this is probably true, it doesn't solve anything. This issue has occurred for me now with 2 servers I'm running, with different versions of Forge, and about 6 months apart. I'm running Enigmatica 2: Expert at this moment, so can't put up a second server just to create a test setup for reproduction. But I can currently trigger it 100% reliably in my existing network by connecting/disconnecting a separate 22 block of dense energy cells + RFtools powercell + acceptor to the quantum bridge.
This problem comes into existence for me when I'm required to put an extra set of power on the 'receiving' side of my quantum bridges, because it goes offline on a server reboot.
When that has all been fixed up, there's a chance it will keep occurring on subsequent reboots, but with the added fun that when AE2 tries to rebuild its power network, it triggers this crash itself, so you're not even able to log on any longer.
It would be appreciated if this could be looked into and hopefully be fixed, since it's a rather serious problem.
Can you reproduce this issue with only AE2 or potentially one other mod installed?
If so, please reopen an issue with that setup.
The only thing we can see here is: while power is being extracted or injected, something is breaking it's connection to the AE grid. Trying the most obvious version of this locally doesn't actually produce this error though.
The acceptors you have, what is powering those?
Oh and if you have a save that allows this bug to be reproduced, and your modpack is unmodified (so I can download it via Twitch), I might offer to debug it if you upload your save.
The power provider is an RFTools Power Cell. And it only seems to happen when I'm starting to get fairly complex quantum networks. I'm going to see if I still have my 'pre-crash' backups from months ago.
Unfortunately that's really hard to do, since it just starts happening at a certain level of complexity, and sometimes you can recover from it, and sometimes you can't. (Which is why I make half hourly backups).
When it starts happening it's 100% reproducable (remove this block, crash, place block back, crash), but other than that it's hard to specifically cause it. I've tried. But tearing down part of the network and then rebuilding it exactly the same almost never causes the same behaviour to occur.
When I run into this issue again I'll import a backup into a (mostly) clean world and see what I can do.
@Splutty You probably dont need to look specifically for your backups. We've made some changes to how multiblocks form/unform in reaction to neighbor updates, and there's an outstanding PR for at least crashing immediately when these invalid modifications occur (should we have missed one), instead of later when its impossible to track down.
So, going forward (1.15+) it should hopefully not be an issue anymore.
Additional information.
Taking out the energy provider (RFTools powercell) and acceptor, then reconnecting and rebuilding the energy storage as a 24 dense energy cell block only causes 1 crash, and no more after that. Then reconnecting the acceptor/powercell seems to not cause a crash either. Now to wait for the next server reboot or next addition to the network.
More info and another observation. :)
In attempting to circumvent the unpowered quantum bridge issue, I put a powercell/battery pack in one of the P2P output networks, and connected that to the quantum bridge with quartz fibers. This does not power the quantum bridge. Then after that I built the aforementioned powercell/battery block to connect directly to the quantum bridge cabling, which causes the crash.
I removed the quartz connection, rebuilt the battery block, and the crashes no longer happen. I rebuilt the quartz connection and the crashes still don't happen.
No idea if this is useful, but it might spark a light.
Not the same error, but also related to connecting/disconnecting energy from a quantum bridged environment. This was me attaching a new quantum bridge to my controller core.
Quantum Bridge has 3 dense energy cells and 1 controller connected to it, and the connection to the core happens with a smart cable connected to the controller on the quantum bridge and to the core through a fiber quartz bit.
This causes the server to keep crashing on loading, eventually giving up after 5 crashes.
First of 5 consecutive crashes (all the same):
https://pastebin.com/bk0Ls9K0
Just trying to add as much info as possible to this, since it's rather annoying to have to constantly restore from backups :D
More info on my particular setup, since I'm changing certain things around. I have/had certain cables connected to dense energy cells, however found out a dense energy cell can only accept 8 channels. Since in retrospect most if not all of my crashes were related to connections to dense energy cells, this might be an issue as well? No idea, just adding as much info as I can.
Nope. It just crashed on the simplest energy connection. Quantum Ring on one side with no connections other than 9 dense energy cells, 1 acceptor and 1 powercell. Quantum Ring on the other side with no connections other than 1 controller, 1 dense energy cell and 1 acceptor. Connecting a powercell to the acceptor crashes the server. Rolling back and testing again. (Rolling back because now it's stuck in an eternal crash loop)