Mechanical Pipe disconnected on game start

[blackdrag]

I originally opened this issue here erogenousbeef-zz/BigReactors#256 But the author there identifies this as a Mekanism bug.

This is from the Yogscast complete pack (2.9.2.3) which contains 0.34A2 of Big reactors and Mekanism 6.0.5.46. and Minecraft 1.6.4

I made a test setup in which I transport steam and water between my turbines and passive cooled reactor using the Mekanism mechanical pipe. This seems to work well, but when I quit the game and log in again the pipes are no longer connected to the coolant ports outside of the chunk I start with. A block update seems to be enough to trigger the pipe connection again.

[blackdrag]

I wanted to try to get away from the test area of BigReactors to see if chunkunloading may affect this like in #1109 but it seems I fall victim to #1363 if I go too far away

[blackdrag]

I just tried again and I can confirm, that if the chunk is reloaded, the mechanical pipes are disconnected

[aidancbrady]

A strange bug, that's for sure. I ran into this a few times, and I indeed have talked to E. Beef about this. Will try and find a fix.

[unpairedbracket]

Could it be (just a stab in the dark here) that the fluid ports are not accepting fluid connections unless they're part of a multiblock, and that for some reason they're not putting out a block update when the multiblock reforms on chunk load? Then if the pipes load before the multiblock reforms they wouldn't reconnect?

[aidancbrady]

I thought this was the issue originally, but it turns out BR does push out a block update when the multiblock forms (according to Beef). I'm assuming it's something on our end, but I don't know what.

[blackdrag]

In erogenousbeef-zz/BigReactors#256 he points to https://github.com/erogenousbeef/BigReactors/blob/release-0.3/erogenousbeef/bigreactors/common/multiblock/tileentity/TileEntityReactorPowerTap.java#L52 Now I am no mod maker, but I somehow doubt that sending an inventory update is enough to for an adjacent block to notice that something has now an inventory, that did not have one before.

So I made some more tests. I produced an incomplete 4x3x3 reactor and put a mechanical pipe at the coolant port. As to be expected, once I complete the reactor, the mechanical pipe does still still not connect. This could be proof for the multiblock forming theory.

Then I remembered that Mekanism too has a multiblock structures, so I made the exact same test with a Dynamic Tank of the same size. Here the mechanical pipe connects. Well, could be that Mekanism does something special to Mekanism pipes I thought so I was going through the modpack and tested some more fluid pipes.

First the Fluiduct from Thermal Expansion. It connects to coolant port and dynamic valve, even before the multiblock is complete. It seems to know that this eventually has an inventory for fluids, even if it is not yet usable. Same for Ender IO Fluid Conduit and Steve's Factory Manager.

Next I tested BC Transport Cobblestone Fluid Pipe. In case of the dynamic tank it connects, once the tank is formed, in case of the reactor not. The same goes for a Logistics Fluid Connector Pipe.

Transfer Pipes from Extra Utilities connect to both once the multiblock structure is formed.

So to me it seems that both mods do not behave ideally, but I strongly assume that a onInventoryChanged() is not enough. What does the dynamic tank code do additionally? Maybe it causes a block update. I checked this using Extra Utilities Block Update Detector, which emits a redstone signal if a block update occurs nearby. Completing the dynaimc tank does cause a block update, completing the big reactor does not. This confirms for me that onInventorChanged() does not causing block updates. But it seems without a block update the mechanical pipe will not detect the inventory.

[unpairedbracket]

I can confirm from code that the onInventoryChanged() method only seems to update comparators, there doesn't seem to be any way for us to detect it. I can only assume from the available evidence (given no access to sourcecode) that TE conduits don't enforce as strong conditions on acceptors to connect as we do. We came up against this kind of thing before in #1262, which turned out to be TiCon saying we couldn't fill their tanks and TE filling them anyway.

[aidancbrady]

Ah, yes - that is the issue. Upon further inspection of markDirty(), it DOES notify other blocks, but via a different Forge-based method that is not in any way linked to the normal method. I actually had no idea this method existed - we may want to port over our multiblock/transporter code to use this instead as it passes over the coordinates of the notified block.

I'll upgrade our implementations and then mark this as closed.

[unpairedbracket]

Aha, onInventoryChanged() did not do this in 1.6, I don't think. Yay for 1.7!

[unpairedbracket]

Oh, I stand corrected. It was added in MinecraftForge/MinecraftForge@5d5d4cb a year ago...

(onInventoryChanged was triggering that method in 1.6 as well, I was mistaken due to not having a 1.6 workspace any more, was looking at non-forge source)

[aidancbrady]

Should be fixed in v7.1 :)

[unpairedbracket]

And with BigReactors 0.4, looks like EBeef has added the Block Updates that we were already detecting, as of erogenousbeef-zz/BigReactors@9c15e8f

[aidancbrady]

I just walked with him, he's going to remove it in favor of the old one. Better to only have one network refresh than two :)