pipe render bug
ouroborus opened this issue ยท 17 comments
Issue description:
Cables attached to another mod's cables do not connect visually on server (chunk?) load. The pipes are connected and power is transferring, they just don't look like they're connected.
Steps to reproduce:
- Place pipes connected to another mod's pipes.
- Restart server.
- Note graphical issue.
Version (make sure you are on the latest version before reporting):
Forge: 14.23.0.2517
Mekanism: 9.4.1
Other relevant version: ATM3 4.4
I couldn't reproduce in dev with just Mek & TE/TD etc. Can you reproduce it with just those?
Ah, okay. I wasn't aware that was a thing you could do. I'll see about trying to reproduce this that way then.
Doesnt ATM have a server pack? just use that and remove everything but the COFH mods, Mek, and MCMultipart if present.
Not reliably. I suspect it might be one of the underlying libraries. I just updated to ATM3 v5.1. we'll see if it still happens.
Welp, CoFH says the fluxduct is sending out neighbor changed messages correctly.
I figured he'd say that, I once traced through his code and found him clamping stack sizes to 1 (should have been 0 in this case) and he denied that his code did such a thing.
I will double check later if it's an issue with the transmitters joining networks, but on such a small scale I doubt it.
I've generated a single player world using the mods listed below. The render issue shows up reliably but only on world load, not chunk load.
Even though the screenshots show all the crossover boundaries as disconnected, some connections will properly render. Connections that render incorrectly will always render incorrectly on world load. Connections that render correctly will always render correctly on world load.
CodeChickenLib-1.12-3.1.3.313-universal.jar
CoFHCore-1.12-4.3.6.14-universal.jar
CoFHWorld-1.12-1.0.1.8-universal.jar
jei_1.12.2-4.8.0.114.jar
MCMultiPart-2.3.3.jar
Mekanism-1.12.1-9.4.1.326.jar
MekanismGenerators-1.12.1-9.4.1.326.jar
MekanismTools-1.12.1-9.4.1.326.jar
RedstoneFlux-1.12-2.0.1.2-universal.jar
ThermalCultivation-1.12-0.1.1.6-universal.jar
ThermalDynamics-1.12-2.3.6.13-universal.jar
ThermalExpansion-1.12-5.3.6.20-universal.jar
ThermalFoundation-1.12-2.3.6.16-universal.jar
Thanks, managed to reproduce it in dev. Seems having RF in the pipes is the key, my setup that had just the pipes loads fine
The connections of the mekanism conduits need to be on two opposite sides of a specific block; having adjacent sides connected prevents this issue. It seems that there needs to be power connected during world load for this to most reliably happen. It happens more reliably if that power is supplied to the fluxduct. Once it loads that way, it can become electrically disconnected (rather that just visually) if you try to move the power around without fixing it. Once the pipes become broken, they'll generally stay broken regardless of power.
EDIT: Yeah, just discovered the RF requirement myself.
I'm thinking it might be race condition, or a TD issue, as the Mek cable is not finding a valid acceptor.
I have no idea if the TD cable triggers a neighbour update when it establishes its network. If it did this probably wouldn't happen.
It seems weird that valid acceptors aren't found only when the connections are arranged in certain ways.
Doesn't seem to happen with the other types of fluxducts. The cryo-stabilized fluxducts are odd in that they don't appear to have internal storage and claim "infinite" transfer rate. They act more like a proxy rather than a conductor.
Yeah if it only happens with one type of cable, I'm gonna lean towards it being a TD issue, nothing really that we can do there if it's not sending out a neighbour changed message.