[BUG] Multiblock output hatch sometimes don't output

[galyfray]

Describe the bug
Sometimes for no real reason the output hatch of some multiblocks don't output to connected pipes.

Versions
Forge: 14.23.5.2854
GTCE: 1.14.1.705
Other mods :
Better Builder's wand : 0.13.2
BetterFPS : 1.4.87
Chamelon : 4.1.3
ChickenASM : 1.0.2.7
Code chickenLib : 1.0.2.7
COFH Core : 4.6.6.1
COFH World : 1.4.0.1
CT2 : 4.1.20.594
Garbage bin : 1.1.1
JEI : 4.16.1.302
TOP : 1.4.28
Redstone Flux : 2.1.1.1
Storage Drawer : 5.4.2
Thermal Expansion : 5.5.7.1
Thermal Foundation : 2.6.7.1

Modpack: also append in the modpack Gregicality Skyblock edition in muliplayer

Setup
Playing Both multi and single player
tested in new world generated

Steps To Reproduce

1. build a large tungstenesteel large boiler
2. start the boiler with water and whatever fuel you want
3. put large tungstensteel pipe next to the output hatch
4. wait until the heat goes over 100°
5. no steam in the pipe

Expected behavior
steam get outputted

Screenshots

[warjort]

Did you log out or stop the server at some point? See #1357

[galyfray]

no most of the time login out and in or restarting the server fix the problem but sometime restarting the server each time someone has this kind of problem is not really possible

[warjort]

Does placing a block next to the pipe or hatch fix the problem? I think the former should cause the fluid pipe network to be recalculated.

The fluid output hatch auto outputs so the only way I can see that the fluid pipe would not accept inputs when empty would be if it thinks the fluid pipe network has 0 capacity and/or it hasn't formed properly?

GregTech/src/main/java/gregtech/common/pipelike/fluidpipe/tile/FluidPipeFluidHandler.java

Line 32 in 11d757f

public int fill(FluidStack resource, boolean doFill) {

#1357 could also cause the problem since restarting the server would empty the pipe's tank. But without new steam going into the output hatch it probably would not know to push to the empty pipe without a block update?

[galyfray]

I tried placing block next to pipe, replacing the pipe, adding new pipe to the network fill the pipes with a little of steam. The only one some times fixing the issue is replacing the pipe so I think the problem comes from the output hatch.

[warjort]

Replacing the pipe will also cause a block update for the output hatch so it knows to try to push fluids.
Did you try putting a block next to the output hatch?

The output hatch uses a "list" of forge fluid tanks. The only recent change I can see is a change to allow manual removal from import tanks:
https://github.com/GregTechCE/GregTech/commits/master/src/main/java/gregtech/common/metatileentities/electric/multiblockpart/MetaTileEntityFluidHatch.java

Maybe there is something changed in Gregicality? I know they at least override the recipes for the large boilers.

[warjort]

Replacing the pipe will also cause a block update for the output hatch so it knows to try to push fluids.
Did you try putting a block next to the output hatch?

Scratch that, the fluid hatch uses the MetaTileEntity.pushFluidsIntoNearbyHandlers() inside its tick handler so it won't need a block update or new fluid being added before it tries to push fluids.

[galyfray]

Maybe there is something changed in Gregicality? I know they at least override the recipes for the large boilers.
this also appear without gregicality

new behavior once unglitch it is really hard to make the multiblock glitch again on purpose I will do more testing

[warjort]

I have been testing as well and can reproduce the problem but I am not sure at the moment where the problem lies.

I tried replacing the pipe with a normal tank and it works fine, which suggests the pipe is wrong.
But I also changed the hatch to not output directly and instead used a pump from the side of the hatch to the pipe and that also worked fine, which suggests the hatch is wrong.

[galyfray]

I can only replicate the bug on a brand new multiblock in a new place.

• breaking and replacing the controller of a glitched multiblock doesn't change anything.
• replacing an hatch fixes the problem for the hatch only if multiples hatches are on the multiblock
• breaking and replacing both the controller and a working hatch doesn't glich the hatch again
• updating the hatch with block or redstone doesn't change anything

[warjort]

From my testing if you break and replace the output hatch while leaving the pipe in place it always glitches after you reboot the boiler, or maybe I am just being (un)lucky?

[galyfray]

I tried replacing the pipe with a normal tank and it works fine, which suggests the pipe is wrong.

also tried and I can't reproduce the bug with the tank I might have a theory I will do more testing to see if it can be this

[galyfray]

From my testing if you break and replace the output hatch while leaving the pipe in place it always glitches after you reboot the boiler, or maybe I am just being (un)lucky?

it work for me replacing the hatch without touching the pipe unglitch it

[galyfray]

disconnecting and reconnecting the pipe with a wrench doesn't change anything, changing the output side of the hatch too
found an easy way to re-glitch place a pipe connected to the hatch on a side which doesn't output change the output side and tada get a glitched pipe-hatch system. this doesn't work with tank suggesting pipes are the issue

[galyfray]

some unglitched hatch can't be re-glitched with this method though.

[warjort]

I know what is happening now. It is the #1447 change.

Before the tanks were hidden behind a proxy which was configured so that the export hatch couldn't import fluids.
But now the fluidTankHandler is exposed directly as the capability.

So the hatch is pushing the steam into the pipe which is pushing it straight back into the hatch.

This explains why the bug seems so random.
The pipe has to tick at just the right time to refill the hatch while it still has some space before the multiblock refills it.
In my case I must have had the pipe in just the right direction to achieve this, while you were seeing different behaviour because the ticks for the blocks (controller, hatch, pipe) were in a different order.

I would suggest #1447 is reverted (it is only a visual gitch) and a better fix found.