Issue description:

Energy cables randomly stop working sometimes , having to replace the malfunctioning one in order to repair the energy chain , and sometimes after replacing it stops 1-2 cables pieces further

Steps to reproduce:

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

Forge: 32.0.67
Mekanism: 10.0.2

Other relevant version:

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

[gist / pastebin / etc link here. Please make sure that it isn't set to expire.]

Here are... a lot of messages

I have a similar issue. The cable is connected to the generators and the Network Reader clearly shows it has some energy stored, but the machine next to it is not getting powered.

I can fix it by placing a single cable block next to another one and breaking it. Then the machine is getting powered again.
Notice that the "Acceptors" value changes.

The issue reappears every time I port to nether and return to my base (it's not chunk-loaded) so I can easily reproduce it on my world save. But I was not able to reproduce in another save.

Mekanism: 10.0.21.448
Forge: 36.0.40

I'm not using Optifine/Performant etc.
@pupnewfster I can PM you client+server should you need them.

So I've loaded my old world to perhaps help with tracking down the issue. The procedure I use to recreate the issue is the same as mentioned in my previous posts (base->go to nether->let the chunks unload->port back to base through portal).

This time I've found /mek watch command and used it on one of the chunks that had issues with cables failing.
So here it goes:

At first everything is working, acceptor count is 24, as in the image I posted before as it should be (image is outdated).
Going into nether - chunk is getting unloaded
[Server thread/INFO] [Mekanism/]: Dealing with 1 invalid Transmitters [Server thread/INFO] [Mekanism/]: Dealing with 125 invalid Transmitters [Server thread/INFO] [Mekanism/]: Dealing with 25 orphan Transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: Dealing with 25 invalid Transmitters [Server thread/INFO] [Mekanism/]: Dealing with 4 orphan Transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 3 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters

Getting back to base - chunk is getting loaded
[Server thread/INFO] [Mekanism/]: Dealing with 133 orphan Transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 116 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 6 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 2 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 2 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 2 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 1 transmitters [Server thread/INFO] [Mekanism/]: Dealing with 18 orphan Transmitters [Server thread/INFO] [Mekanism/]: Merging 3 networks with 11 new transmitters [Server thread/INFO] [Mekanism/]: Adding 3 transmitters to single found network [Server thread/INFO] [Mekanism/]: Merging 2 networks with 4 new transmitters [Server thread/INFO] [Mekanism/]: Dealing with 4 invalid Transmitters
At this point I'm in base, acceptor count is 2. Machine is not getting power and is not displaying energy (in the connected sides) when probed with network reader (but still displays gasses as it should).

Placing basic universal cable next to the others.
[Server thread/INFO] [Mekanism/]: Dealing with 1 orphan Transmitters [Server thread/INFO] [Mekanism/]: Adding 1 transmitters to single found network
At this point I'm still not getting power into the machine, neither energy displays as connected side.

Breaking that one additional cable.
[Server thread/INFO] [Mekanism/]: Dealing with 1 invalid Transmitters [Server thread/INFO] [Mekanism/]: Dealing with 133 orphan Transmitters [Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 133 transmitters
At this point the machine is getting power and right-clicking with network reader at the cable gives the correct acceptor count(24).

I can trigger this bug on demand by going into the nether and coming back to base so feel free to give me any ideas that could help debug it further. The mekanism version is the same as mentioned in my first post.

What seems strange to me is this part of the log that gets printed after breaking a single cable (my network has over 100 of them).
[Server thread/INFO] [Mekanism/]: Dealing with 1 invalid Transmitters
[Server thread/INFO] [Mekanism/]: Dealing with 133 orphan Transmitters
[Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 133 transmitters

So it looks like it fails to create a network on the chunk load and does so ONLY AFTER I've broken a cable (or am I wrong?).

Nope you have pretty well nailed it on the head and with the logs should help the developer narrow it down further.

The work around in the mean time is to make sure that chunk is has a machine with the anchor tag in it like the digital miner. That will prevent this problem from occurring.

What seems strange to me is this part of the log that gets printed after breaking a single cable (my network has over 100 of them).
[Server thread/INFO] [Mekanism/]: Dealing with 1 invalid Transmitters
[Server thread/INFO] [Mekanism/]: Dealing with 133 orphan Transmitters
[Server thread/INFO] [Mekanism/]: No networks found. Creating new network for 133 transmitters

So it looks like it fails to create a network on the chunk load and does so ONLY AFTER I've broken a cable (or am I wrong?).

Hmm I'm not so sure about the failing-to-create-network-thing though... Because probing with the network reader shows the correct transmitters count, but the acceptor count is 2 instead of 24.

So my guess is that somehow it fails to load the acceptors on chunk load (bad caching?) but breaking the universal cable causes to invalidate entire DynamicNetwork and creation of new one.

EDIT: Adding new machines to this mentioned network (with 2 acceptors instead of 24) seems to work fine - they get the power and so do new cables (they get added to the transmitters). The only things that aren't working are those machines that were placed before going into nether (again caching?)

EDIT: !!!IMPORTANT!!!
Use seed: -4061316498582132254
(including - sign)

I have managed to make the issue REPRODUCIBLE. Here's my setup

Clean MultiMC Instance
Forge: 36.2.4
Mekanism: 1.16.5-10.0.21.448
Java: jdk-16.0.2+7 from adoptopenjdk.net (hotspot)
Java args: -Xmx1G -Xms1G
Every other config/setting is on default.

Steps to reproduce:

1. Boot Minecraft
2. Create a new world (USE SEED, Creative, Type: SUPERFLAT, Preset String [110*minecraft:bedrock])
3. Teleport to 849.5 111.0 2110.5 (/tp 849 111 2110)
4. Follow exactly this block placement:

• 2 crushers at: 849 110 2110 and 851 110 2110
• 7 basic universal cables at: (849 111 2110), (849 111 2111), (849 111 2112), (850 111 2112), (851 111 2112), (851 111 2111), (851 111 2110)

5. Check if the setup resembles the one from the picture and probe the cable with Network Reader. It should say 7 transmitters and 2 acceptors.
6. Build a nether portal with corners at: (849 110 2105) and (852 114 2105)
7. Go into nether
8. Fly for a while to let the chunks unload (That's why we're using Xmx1G and Xms1G) - I used to fly for 1-3 minutes.
9. Go back through the portal
10. Probe any of the cables with the Network Reader if it shows 0 acceptors then you have reproduced the bug. If acceptors are still present then repeat from step 7.

Observation: Attaching a new cable to this broken network doesn't seem to update it but breaking one does and fixes the issue.
I have managed to reproduce this issue on Java 8, 15, and 16 so I guess it's not version dependant.

Final Setup Pic:

After probing the right cable(attached to one of crushers) in the network's broken state the debugger shows that the cable is having correct cachedAcceptors count but the network shows 0 acceptors in total. So the TileEntity seems to correctly update it's acceptor's count but theNetwork doesn't seem to update it accordingly.

Here's a pic:

Will have to look at the network update code next...

Digging deeper into the broken network I found that the cable(Transmitter) can have forceUpdate flag set to true, but never update it's acceptorCache before DynamicNetwork commit() function is called. So the network is created as if the cable doesn't have any acceptors connected to it. And after the network creation process is finished the cable finally updates it's acceptorCache - but it's too late.

So in conclusion:
The problem is that the commit() function of DynamicNetwork is called before refreshConnections() function of Transmitter
We're creating a network so fast that no ticks have passed???

I can think of 3 solutions to the problem:

1. Loop through all Transmitters to be added to the network in DynamicNetwork class (commit() method) and check their forceUpdate flag, if it's true then refreshConnections() / do the same in the already existing loop.

2. Do the same but in the updateTransmitterOnSide() method in NetworkAcceptorCache class (but on single transistor) - check it's forceUpdate flag and refreshConnections() accordingly (before calling transmitter.getAcceptor(side)).

3. Check the forceUpdate flag in getAcceptor() method of Transmitter, refreshConnections if needed and only then return acceptorCache

We can achieve all of above by either exposing forceUpdate flag and allowing it to be set to false or just simply calling tick() method of tile entity.

Personally I think the third option is the best one - Transmitter shouldn't return values from outdated/not initialized cache.

Now since I'm not a forge dev I have two doubts:

1. Is the forceUpdate flag always set to true after chunkloading a transmitter tile. I believe it should since it is considered a new instance of an object.
2. Don't we have to ensure that the connectionTypes array in Transmitter.class gets filled with values before calling getConnectionTypeRaw()? Does read() method of Transmitter get called on block/tileentity creation?

So here's code example
In Transmitter.java replace this:
@Nonnull public LazyOptional<ACCEPTOR> getAcceptor(Direction side) { return acceptorCache.getCachedAcceptor(side); }

With this:
@Nonnull public LazyOptional<ACCEPTOR> getAcceptor(Direction side) { transmitterTile.tick(); return acceptorCache.getCachedAcceptor(side); }

I believe that calling single tick on chunk-loading won't affect performance that much. But we can also consider exposing forceUpdate flag and acting accordingly in aforementioned places.

BUT IT DOESN'T SEEM TO FIX THE BUG ENTIRELY - NETWORK IS DISPLAYING THE CORRECT NUMBER OF ACCEPTORS NOW BUT MACHINES ARE STILL NOT GETTING POWERED... MORE DEBUGGING NEEDED...

The mentioned change fixed incorrect network readouts but also MADE ALL MACHINES NOT ACCEPT POWER MORE OFTEN, EVEN AFTER WORLD LOAD...

To be more specific - cables are getting power from cubes but not sending it.

So the main problem for now is that commiting the DynamicNetwork can happen before acceptorCache is updated in Transmitters. But manually calling refreshConnection() which sets forceUpdate flag to false causes issues with machines not being able to receive power. I don't know yet why?

Edit: So it seems like by adding tick() into getAcceptor() we never allow the changedAcceptors to change from 0 in acceptorCache. So they just appear in cachedAcceptors.

So despite calling Transmitter.refreshConnections() before DynamicNetwork.commit() happens we're still not getting energy transfer because of the isValid parameter being set to false... At least all acceptors now show in network but some of them (the ones that were not working are flagged as NOT VALID and cannot transfer energy anyways...

Thank you for looking into this so extensively @MizozPL. Sometime this week I am going to try and finish rewriting a system I was in the middle of working on when I took a bit of a break from modding, and then afterwards I will look into this further. I don't think your solution is quite right but your analysis of the issue and how to reproduce it looks promising. I am not quite sure yet if it is something I will try and patch, as the network formation code is quite a mess currently and I think it may be more worthwhile for me to try and rewrite it in such a way that would better handle the weird edge case ordering of how things are being ran.

Thank you for looking into this so extensively @MizozPL. Sometime this week I am going to try and finish rewriting a system I was in the middle of working on when I took a bit of a break from modding, and then afterwards I will look into this further. I don't think your solution is quite right but your analysis of the issue and how to reproduce it looks promising. I am not quite sure yet if it is something I will try and patch, as the network formation code is quite a mess currently and I think it may be more worthwhile for me to try and rewrite it in such a way that would better handle the weird edge case ordering of how things are being ran.

Sure, the solution isn't right as per my last post - it only makes acceptors always register in the network but for some reason the isValid flag of LazyOptional ACCEPTOR is set to false. So yes they show up in network now, but energy still does not flow. Now I'm trying to figure out what can cause this flag to be false.

So it isn't as simple as forcing a refresh on Transmitter before accessing it's cache, because acceptor that was queried that way gets invalidated...
One thing for sure is that network.commit() can happen before cable tilentities had a chance to update their cache...

Ok so a bit more digging and I found that the following happens (using my test setup):

• There are 4 transmitters without a network
• 2 networks are being created (with 2 transmitters each)
• DynamicNetwork.acceptorChanged() is being called for each (since wwe have 2 crushers) and so those 2 networks are added to networksToChange in TransmitterNetworkRegistry
• onTick is called and before networksToChange is allowed to be processed (adding missing acceptors) getNetworkFromOrphan() is merging those two into a new one without considerring those two needed an update

I think we should call commitChanges(); before network = finder.createNetworkByMerging();
And so calling it fixed the issue in my test setup! But I didn't test it for too long...

#7308 Possible fix

@Forzii (or anyone who reliably is reproducing this with 10.0.22) could you try replacing the Mekanism-1.16.5-10.0.22.449 version on your server with this build and let me know if it fixes the problem? If it does I will commit the changes I made, and release a 10.0.23 build.

Edit: It probably is worth backing up your world first, even if it is probably safe. Just because I think there is a chance my above "fix" in its current state may not always properly respect that two chemical or fluid networks can't be merged if they have different types if that network connection is also a position where this bug would be occurring. Though for purposes of seeing with the more common network type that breaks (energy) it should work fine if it does actually fix this issue.

Unsure if this is related, but I recently updated my server from ATM6 1.8.5 to 1.8.8, which appears to have included an update to Mekanism 10.0.22. After the update, all of the basic universal cables that we were using in ~2 chunks needed to be broken and re-placed before functioning again. Strangely enough, the cable line we're using appears to run across ~4 chunks, and the other 2 chunks were fine.

I wasn't too worried about it, since updates often cause ephemeral issues, but when I logged in today the cables in those same 2 chunks that were broken after the update seem to be broken yet again. Quick-ish search lead me to this recently closed issue. Same symptoms as OP and others described.

Edit: Checked the server and it's more specifically 1.16.5-10.0.22.449. Also have MekanismTools 10.0.22.449, MekanismAdditions 10.0.22.449, MekanismsGenerator 10.0.22.449, and kubejs-mekanism 1605.1.2-build.2 ... and everything else in ATM6 1.8.8.

If you right click the transmitters with a network reader are the working and "broken" cables in two different networks?

If you right click the transmitters with a network reader are the working and "broken" cables in two different networks?

Looks like it? The broken ones each show 1 transmitter, 0 acceptors, etc. The ones that are working show 43 transmitters, 10 acceptors, etc.

Edit: Actually, that doesn't seem like two different networks... more like one network and then a whole bunch of isolated cables. There's an energy cube on the broken side that the cables are not pulling from either. - Correction, only the cable directly attached to the cube is pulling energy from it.

Hmm that definitely does seem like it is the same issue, though unfortunately means we are back to not being sure how to fix it really as I still have yet to been able to reproduce the issue myself, though I will try looking into it at least once more before 10.1 to see if any other issues in the code potentially stand out to me.

@Forzii
Could you send me your world as .zip, so I could test it?

@Seniorendi I grabbed a world backup from earlier today, but it's 822MB. Do you have a preferred way for me to send it?

Maybe Onedrive, but I don't know a better way

Alright, the file is here: https://vault.elephantdrive.com/web_access/shares/v2/links/redeem_share.aspx#/AAAAAAAAAACtBZhfcxKKuA/1 . The link should expire in about a month, unless someone asks me to leave it up or I decide to end it early.

Room where the cables have been having issues is around 5302 103 446. There's a service tunnel underneath where the cables have been breaking about halfway through it - access door at around 5271 103 445 (we took over an illager mansion). Please ignore the crappy setup, I actually removed most of the cables in the room (should be after the backup I'm giving access to) because I realized I was being dumb and didn't need the majority of them.

As a reminder this is ATM6 1.8.8, which is a pretty heavy modpack.

As a reminder this is ATM6 1.8.8, which is a pretty heavy modpack.

Good that I have a heavy computer

So I finally got a bit more of a chance a little while ago to look into this and I believe I fixed it for 10.1 in 7354e9c, though I still wasn't able to reproduce the issue locally (though maybe I was just getting lucky and the few times I tried Mizoz's reproduction steps it didn't break for me), but when I asked Mizoz to test if my change fixed it it seemed to so I am going to mark this as fixed in dev for now.

A bit of background on the issue is it seems that when I rewrote our transmitter networks for V10 to be able to cache acceptors, I forgot to include the adoption of acceptors that have "changed" and need to be rechecked. This then was creating some "dead" connections for transmitters, so that they were in different networks than each other and/or couldn't "see" neighboring tiles.

I am not quite sure yet when this will get released as 10.1 will hopefully be released in the next couple months, and I am currently undecided on whether or not I want to go through a bit of a process and just release a 10.0.22 in the mean time or just spent my time focusing on getting 10.1 to a ready state.

10.0.22 has been released and should fix this. I am going to close this for now, but if anyone is still running into this issue with 10.0.22, please comment and we will reopen this.

Doesn't seem like it. Switched out the jar, replaced all the cables, went to the end for some resources and when i got back all the cables are on the separate networks

@jexom would you mind trying this build and sending me the server's latest log after it breaks again? That build won't fix the issue but I added some extra logging that hopefully will confirm if I am on the right track with my thinking of what the issue may be.

Fixing this one-year-old issue will be amazing <:

@jexom would you mind trying this build and sending me the server's latest log after it breaks again? That build won't fix the issue but I added some extra logging that hopefully will confirm if I am on the right track with my thinking of what the issue may be.

Here are the debug and latest logs:
debug.log
latest.log

Although i didn't notice anything different in them

Hmm, ya you definitely are right that the logging messages I added didn't show up, which means that those potential edge cases I was wondering if are not being handled properly aren't the cause of the issue, so I will keep looking to see if I can come up with any other ideas what areas seem like they may have some issues.

@jexom There is a chance this build will fix the issue (though at this point who knows), at the very least it hopefully will print some messages to the log that might help me track the issue down better/know what it was, as I added a fair bit more logging to it.

Hmm, I will do a bit more cleanup then and probably try to release an actual build either later today or tomorrow, going off the assumption that it is fixed now if you can't reproduce it anymore. I am sort of surprised that none of the messages I added ended up getting logged, but I did do a bit of general cleanup to network registration, so it is possible one of the things I fixed while cleaning it up ended up fixing this issue as a side effect.

This may have fixed it. Still didn't see anything different within the logs but couldn't reproduce the issue. Here are the logs just in case
latest.log
debug.log

Lets try this again... 10.0.23 is now released, so I am going to close this, if it turns out it isn't actually fixed comment and we will open this yet again.

https://discord.com/channels/554379889122213888/560583846509281280/912041633334296667 Seems like this may not be entirely fixed after all...

My guess is this isn't the case but I forgot to actually confirm it with the person who reported still having this in 10.0.24 on discord, but @sippeeey are you able to reproduce it if you test without Mohist?

It seems to be the same problem in version 10.0.24. (Mekanism-1.16.5-10.0.24.453.jar)
It is randomly, sometimes the multi block structures are connected and any other are disconnected. Is also happens with the "induction casing battery" or "Thermal Evaporation Tower"

And its fixed randomly after Server restart. Before i restarted, the i had fix the left tower by replace on block from the multi block, but the right tower was broken. after restart also the right tower was fixed, although i dont replace a block from the multi block structure.

! To Replace a pipe on the port doesn't fix anythere.

Server java version:
openjdk version "16.0.1" 2021-04-20
OpenJDK Runtime Environment (build 16.0.1+9-Ubuntu-120.04)
OpenJDK 64-Bit Server VM (build 16.0.1+9-Ubuntu-120.04, mixed mode, sharing)

Client java verison:
Java 1.8.0_51 64bit

Minecraft Server version:
mohist-1.16.5-778-server.jar

Modlist:
ae2wtlib-0.3.2-1.16.5.jar
alexsmobs-1.12.1.jar
appleskin-forge-mc1.16.x-2.2.0.jar
appliedenergistics2-8.4.4.jar
Aquaculture-1.16.5-2.1.21.jar
BetterThirdPerson-Forge-1.16.4-1.5.1.jar
BiomesOPlenty-1.16.5-13.1.0.477-universal.jar
blockcarpentry-1.16-0.4.0.jar
Bookshelf-Forge-1.16.5-10.3.29.jar
carryon-1.16.5-1.15.5.15.jar
cfm-7.0.0pre22-1.16.3.jar
cgm-1.0.1-1.16.3.jar
Chisel-MC1.16.5-2.0.1-alpha.4.jar
chiselsandbits-1.0.43.jar
ChunkAnimator-1.16.5-1.2.4.jar
chunkloaders-1.1.7-mc1.16.5.jar
citadel-1.8.1-1.16.5.jar
CodeChickenLib-1.16.5-4.0.4.435-universal.jar
CraftTweaker-1.16.5-7.1.2.468.jar
create-mc1.16.5_v0.3.2g.jar
CreativeCore_v2.2.1_mc1.16.5.jar
CTM-MC1.16.1-1.1.2.6.jar
Cucumber-1.16.5-4.1.12.jar
Cyclic-1.16.5-1.5.11.jar
DynamicTrees-1.16.5-0.10.0-Beta25.jar
DynamicTreesBOP-1.16.5-2.0.6.jar
DynamicTreesPlus-1.16.5-0.1.0-Beta10.jar
elevatorid-1.16.5-1.7.13.jar
EnderStorage-1.16.5-2.8.0.168-universal.jar
fishingoverhaul-1.16.5-1.0.2.jar
FluxNetworks-1.16.5-6.1.7.12.jar
flywheel-1.16-0.2.5.jar
gravestone-1.16.5-1.0.6.jar
Hwyla-forge-1.10.11-B78_1.16.2.jar
invtweaks-1.16.4-1.0.1.jar
ItemPhysic_v1.4.18_mc1.16.5.jar
jei-1.16.5-7.7.1.137.jar
JEITweaker-1.16.5-1.0.1.35.jar
JustEnoughResources-1.16.5-0.12.1.128.jar
kotlinforforge-1.16.0-obf.jar
lemonlib-1.3.6.jar
Mantle-1.16.5-1.6.127.jar
Mekanism-1.16.5-10.0.24.453.jar
MekanismAdditions-1.16.5-10.0.24.453.jar
MekanismGenerators-1.16.5-10.0.24.453.jar
morecfm-1.3.1-1.16.3.jar
Morpheus-1.16.5-4.2.70.jar
MouseTweaks-2.14-mc1.16.2.jar
MysticalAgriculture-1.16.5-4.2.5.jar
obfuscate-0.6.2-1.16.3.jar
OreExcavation-1.8.157.jar
simplegens-1.16.5-3.0.9.2.jar
Space-Bosstools-1.16.5-5.4.jar
StorageDrawers-1.16.3-8.3.0.jar
supermartijn642configlib-1.0.9-mc1.16.jar
TConstruct-1.16.5-3.2.1.296.jar
TravelersBackpack-1.16.5-5.4.5.jar
valkyrielib-1.16.5-3.0.9.5.jar
vehicle-mod-0.45.2-1.16.3.jar
WailaHarvestability-mc1.16.x-forge-1.1.15.jar
WAWLA-1.16.5-8.0.1.jar
Xaeros_Minimap_21.22.2_Forge_1.16.5.jar
XaerosWorldMap_1.18.3_Forge_1.16.5.jar
xlfoodmod-1.16.4-1.2.0.jar

Problem still exists in Mekanism 10.2.2

Here's a picture showing it happening within one chunk. Granted, I left said chunk and came back to this error, but still.

@pupnewfster

This bug tastes good

I believe this is fixed in 10.3.2 (for MC versions 1.19.1 and 1.19.2), if anyone can reproduce it on that version or newer please let me know and I will reopen the issue. Unfortunately due to the changes required for the fix it is not practical/feasible to backport the fix to unsupported MC versions (1.16 and 1.18).

On MC 1.20.1, mekanism 10.4.5 and forge 47.2.16 it happens again. Im playing on ATM 9 version 0.2.33 and using FTB chunks to load base sometimes when i log back to server cables stop transmiting power, breaking 1 cable and placing it back sometimes fix it or propagate it to next cable. One fix to that i found is unload everyting, move away and load chunks again.

Tbf I never had this issue in my worlds
But I also don't have large cable networks, I use quantum entangloporters a lot

Still happens, currently on ATM9 version 0.3.5, MC 1.20.1, Forge 47.3.11, super small setup: one solar panel hooked up to an ultimate energy cube, and from there one longish cable connecting to Refined Storage controller + 8 Mekanism machines and a chargepad. Had to replace all the cables since replacing the faulty one propagated it to the next one.

Argh, how is this bug still a thing, several years later? I'm beginning to wonder if it's not directly something in the cables themselves, but something elsewhere that points at the cables themselves in the code instead...?

still happens 1.20.1 10.4.11.67

I believe what is happening is that for some reason the networks are not "joining" together, but I am not quite sure why or how as I am unable to reproduce this. I would be interested in seeing the latest log the next time this happens and also what the network reader outputs about the network if used on both the working section of cabling, and the "broken" section of cabling. Also how often does this end up happening or was it only a odd one off occurrence that you haven't had happen again since?

I've ran into this problem on my server too. It happened from a different issue. Refined Storage bugged out when I connected external storage to a Immersive Engineering fluid tank. It broke the entire RS system. The grid wouldn't allow me to access the storage. Or pull things out. The grid would stay on, when it was fully cut off from power and the network. After Disconnecting it from the tank. It got "fixed". But than the power problem with mekanism started. It first happened to the RS Controller block losing power. The pipe lost power at the connection point, like here. Than followed by all Meka machine blocks losing power.

I did attempt removing the whole cabling in my base. It didn't fix it permanently, when the server is restarted. Also, the cabling storage amount will keep going up infinity, as you disconnect the problematic section. So say you have a purple cable. The internal buffer is 400MFE. Removing and adding it back on will increase it by 40 units. And you can do that till it has thousands of MFE units. And it will just drain. Even when nothing is using it. The piping problem can also spread to remaining pipe blocks and other devices that use power, on other mods. Deleting even the machines doesn't help. Either the entire map or chunk is permanently corrupted.

Also, the server was throwing out a error with the Mekanism energy cube. When this issue started. It saw the Controller block from RS as a energy cube. The error the server threw out in the console: https://imgur.com/i2HK5AW

This also happens for me on my friends server, and it always happens when we unload the chunks and then load them again. It's a pain to go through the entire cable and reconnecting all the cables. And when I reconnect them at one place it usually breaks at another place. https://imgur.com/a/AmmZApx

Ok a few things:

1. What version of Mekanism are you on
2. Just to confirm all these cases are on a server
3. If you could provide a list of mods that would be useful given I am not currently sure (as I haven't been able to reproduce it) if this is mekanism, so getting a list of mods from everyone it is happening to may help narrow down what is actually causing this.

Here's my server mod folder as I left it since the bug occurred: https://imgur.com/CEjg7oW Minus Quark. That was added post bug.

I'm on a server running mekanism 10.0.6.429, these are my mods: https://imgur.com/a/U4AKxXh

Edit: It also seems to be occuring a bit randomly now as it hasn't happened in a while but when it happens it's because we enter the chunks in a portal or unload and load them again

I have had this issue recurring for several weeks now. I am not running a server. Started with the Refined Storage controller losing power but most recently I have noticed several Mekanism machine were losing power. Advanced Smelter, Rotary Cond. etc. I seems that it will happen either when I quit to title or if I AFK and Minecraft goes to the Game Menu. My mod list is rather long so I'll see if I can generate an easy list. Forge 108, 1.16.1

Update 1 : This is happening every time I log in and is occurring on 2 different power grids that are not connected.

So I'm operating a server using the Valehlsia 3 modpack on Version 3.0.11, which is running Mekanism 10.0.8 on Forge 32.0.106.

I've been running into this issue with cables running through my base, each cable thinks that it isn't connected to any other cables or machines, they can be manually fixed by replacing every 2nd cable (Replacing a cable seems to fix any cables adjacent to it, possibly because of the blockUpdate?)

I checked the server logs for the last week, and while there were some references to Mekanism finding unexpected tileEntities (always expecting an energy cube and finding something else), none of these were referencing blocks within the network I know to have broken.

I did find however that when I restarted the server (to get the log files), the cables had fixed themselves after the restart, so this may be a workaround for users experiencing this issue.

Screenshot of a "broken" cable according to HWYLA, showing that it isn't forming a cable network.

Screenshot of a working cable according to HWYLA.

Output from cables using a network reader. (Broken cable above, working cable below with the broken/not broken connection point visible just to the left of the minimap, the "full" cables are broken).

I can report the same thing is happening in my single player world. I'm playing Valhelsia 3 (Mekanism version 10.0.9.432) This is happening a lot at the time of writing this. I have not left the chunks that the cables are in or quit to the game menu. It just
randomly happens to different sections of cable, sometimes replacing a section of cable fixes it, others you have to replace an entire length of cable. I have even tried upgrading sections of cable to higher tier to see if that would kick it into life but it is still the same.

Attached screenshot where you can see the power just stops.

I would be interested in knowing if anyone is still running into this with Mekanism 10.0.18 as various things have been fixed including some issues related to capabilities/chunk unloading/reloading.

I am playing Valhelsia 3 and I can confirm that this issue is still happening as of Mekanism v10.0.17.444.

If I want things to reconnect I have to break cable and replace it

I am playing Valhelsia 3 and I can confirm that this issue is still happening as of Mekanism v10.0.17.444.

If I want things to reconnect I have to break cable and replace it

I said 10.0.18 not 10.0.17, whether it is broken on 10.0.17 or not is irrelevant to my question.

Playing Valhelsia 3 with 10.0.18.445 and have this issue.

There I updated to 10.0.18.445 and I still see the issue.

The cable I have is 1k long and it has random values moving along the cable.

Upon further testing if I place Digital Miner's across the length of the pipe with the anchor tag the piping doesn't stop over that distance.

So my hypothesis is the anchor tag loads in chunks nicely, while pipes struggle in some aspect of this.

i have the same issue and they do stop on chunk borders still

This issue seems to also be apparent on version 10.0.18.445 running on forge 36.0.1

It seems to not only happen with energy cables but any piping from mekanism.

@jwiley17 Agreed it happens with all pipe types. Could you do me a favor and test if putting a digital miner with an anchor tag along these pipes that drop out and see if that fixes the issue for you?

It fixed the issue for me. Just curious to see if this is just a one off event or there is something to it.

Try without Performant and/or turn off things like Load balancing for AI/Entities, Tileentities and Events as this will break your pipe networks.

I have a similar issue. The cable is connected to the generators and the Network Reader clearly shows it has some energy stored, but the machine next to it is not getting powered.

I can fix it by placing a single cable block next to another one and breaking it. Then the machine is getting powered again.
Notice that the "Acceptors" value changes.

The issue reappears every time I port to nether and return to my base (it's not chunk-loaded) so I can easily reproduce it on my world save. But I was not able to reproduce in another save.

Mekanism: 10.0.21.448
Forge: 36.0.40

I'm not using Optifine/Performant etc.
@pupnewfster I can PM you client+server should you need them.

out of curiosity if you sneak right click the machine with the network reader does it show that the cable is connected to it? Also are any parts of that cable's network chunk loaded?

When the glitch happens shift-right clicking the machine with the Network Reader doesn't output anything to the chat. After I place and break a cable to un-glitch the network, it then shows:

I have also removed all the other mods and config folder for Mekanism (to use the default configs). The issue still happens.
Nothing on the entire map is chunk-loaded.

I am playing Valhelsia 3 and I can confirm that this issue is still happening as of Mekanism v10.0.9.432 with Forge v32.0.108:


This is on a cable crossing ~12 chunks to power a Digital Miner.

Happening to me.
Valhelsia+3-3.3.2a
Mekanism-1.16.5-10.0.21.448

I tried to remove Performant, no change.
This problem is killing the game experience for me, everything I have that needs energy stops working all the time..
I'm gonna try to reproduce on a new world and give more information here.

Have this happening to me lately randomly.
I'm using uptodate Valhelsia 3 modpack, in survival single player world.
Probably started to happen around modpack update to V3.3.3 (I've started with 3.3.2), or after I've moved some machines around (digital miner to a neighboring area, factories inside the base, and removed heat generators).
Additional behavior, is that I can change the cable from plain to pushing, and the machine continues to accept the power for a while longer.
Will world folder help you investigate it?

I'm having a similar issue, but with item, gas, and fluid pipes instead, where the endpoints will randomly reconfigure themselves to either push, pull, or neutral. Also, random breaks in the cable path sometimes just happen.

This is such a great mod but this ongoing issue really really hurts this mod.

Perhaps it's time the pipes and cables etc got recoded from the ground up; they've been around a while.

Some kind of workaround that I've found:
Splitting the single network into small islands interconnected by entangloporters seems to avoid this issue.
I've also made sure that each such island is confined inside single chunk, but not sure if it's required.

Tbh, I've had this happen to me on isolated lines, not just part of a network... I once used a set of item transporters to drop stuff from a vanilla funnel to a Create conveyor belt, which worked well enough until the bloody thing reconfigured itself at the "put on the belt" end. Had to re-place half the pipes to get it to work properly. I also think that one of the water pipes we were using on our reactor went fritzy and made it blow up, despite literally everything being placed perfectly a few days back. Unless it's one of those Goblin Traders from one of the other mods in the pack tampering with things... Idk if they can actually do that or not, or if I'm just paranoid, but it's not stated on their resource page(s).

Yeah I had the biggest reactor size go nuclear because the water line stopped working.... I mean it was ehh fun having to move just a lot of work walking in and out of radiation to collect stuff.

There are commands to remove that...

Also, did you encase the reactor in obsidian or something similarly blast resistant?

We ran into this... Nuking performant out of the server fixed this (and other) issues

Can't confirm pipes "disconnecting" from each other, but can confirm that energy cables sometimes refuse to pump energy into machines. Interestingly though, machine and cable are not on chunk border (they are in same chunk when this happens).

Can this happen due to how TileEntity getting deserialized on chunk load (their order)?

I am not running Performant or other serverside performance "improving" mods

Forge: 36.1.3
Mekanism: 10.0.21.448

Same issue happening on my server

Happens when I go far away from an area. When I come back, power isn't transferring through any of the cables.

Most of the type it's enough to replace a single cable in the network, but rarely I have to replace all the cables in the network.

While I was replacing them it appeared that whenever I replaced a cable, energy would be going through all cables until the last one I replaced (they are green) that cable does however appear to be connected to the next cable (the yet to be replaced one) although energy isn't being transferred between them.

Mekanism Version: 10.0.21.448
MC Version: 1.16.5
Forge Build: 36.1.0

Here's my mod list: https://imgur.com/W4kEw7N

Hope this helps you fix this bug :D