Please use the search functionality before reporting an issue. Also take a look at the closed issues!

Issue description:

Whether or not you are running a chunk loader (FTBUtils for example) .309 still loses all connections
and all my machines shut down. Including my reactor.

Steps to reproduce:

1. Chunk load using FTBUtils (or any other chunk loader
2. Make sure area is showing chunkloaded
3. Go outside what would be the normal distance for the chunk to be unloaded

Version (make sure you are on the latest version before reporting):

Forge: 8.0.99.99
Mekanism: 9.3.2.309
Other relevant version: Minecraft 1.11.2

If a (crash)log is relevant for this issue, link it here: (It's almost always relevant)

[gist/pastebin/etc link here]

@aidancbrady this is still happening in 1.12, allthemods 3 v5.8

If i leave my chunk for too long and come back every single cable/pipe/etc has to be replaced in order to work.

A) this issue was created for 1.11
B) did you bother searching? #4676

@thiakil no i manually typed this GitHub url guessing the issue #4507, what are the chances.

Sorry. Forge 13.20.1.2393. My bad

Did you verify it still happens with another chunkloader? I could be completely mistaken but I remember reading something about FTBLib lets the chunk unload and then reloads it chunkloaded.

Yes. I tried using one called "achunkloader" and it does the same thing. But thanx for the suggestion!

-Rick

hopefully this will give some additional insight to this problem.
MC 1.11.2
Forge Version 2393
Mek Versions 311

I wasn't using a chunkloader, logged in to find all mek. pipes not working. All pipes had to be busted and replaced. This includes pressurized, Mechanical and universal. RF readers would show universals running at anywhere from -21 to 4RF. Any universal that was already in place had to be broken and replaced, not even connecting them to newly placed working universals would fix them. The RF flow would stop at the ones that have not yet been replaced.

Things to note:
I was running the digital miner a few chunks away using an entangelporter. So maybe something went wrong with that interaction while not logged in (??). But, I have done something similar a day or so ago with no problems either.

Can anyone provide a strict reproduction scenario which will lead to this issue? I'd really like to get this solved soon but I've been unable to reproduce anything similar.

Forge: 13.20.0.2310
Mekanism: Mekanism-1.11.2-9.3.2.309.jar

I am using Silent's Gems, which provide an item that can teleport you. If I set it up so that I can get from one place to another using them, and the chunks are far enough apart that they unload when I move to the other one, I can pretty reliably cause it to happen by teleporting between the two places. If I then teleport away and back, often everything will start working again.

Notably, going between dimensions seems to make it happen far more regularly. For example, since I have Galacticraft, teleporting between say the moon and the overworld base will trigger it in either location, but then teleporting back and forth will get things going again. Also, Galacticraft pipes don't seem to be affected if that helps. It's .. Interesting to return to your moon base and the oxygen system has failed! :)

Forge: 2426
Mekanism: 1.12-9.3.3.homebaked
Server: yes

Digital Miner lost all upgrades and setting after leaving dimension it was in/ just being unloaded even with an anchor upgrade. I feel those are somewhat related.

Digital miner is a totally separated issue, this is about transmitters (fluid, energy, heat, gasses) losing connections. The digital miner has several other issues ;)

@thommy101 i think it actually is related being that the issue is the failure to recover from a chunk load/unload

If that would be the case, a lot more than only transmitters and digital miners would be affected. Digital miner has some known bugs with chunkloading not working and missing settings which are unrelated to this issue.

I've spotted the issue; definitely wasn't an easy task. I'm experimenting with fixes right now and should have this addressed in a public release by the end of the week.

Fixed in 1.11 and 1.12 development branches!

@aidancbrady do you mind pointing/referencing the commit and/or PR for educational purposes?

9801b12

Here's a quick explanation I wrote up when I found the issue:

Basically, every time TransmitterNetworkRegistry is ticked, orphan transmitters are handled: either a network is created for them, they are added to an existing network, or a new network is formed that merges several and also adds new transmitters

Transmitters are not immediately added to the actual transmitter set of a DynamicNetwork, however. TransmitterNetworkRegistry needs to be ticked again for the changes to be “committed.”

Now, let’s say multiple network merges happen in a single tick to try and form a single large network. If a network has “pending” transmitters when it is merging with a larger network, those are going to be lost in the change.

This results in transmitters not being added to the complete network, and the existence of “ghost” networks of unadded transmitters that are not registered with TransmitterNetworkRegistry.

Because they’re technically in individual networks, they’re not considered orphans. This is why you still have to break every single one to get the network to work again.