Connectors and pipes don't connect visually to the blocks

[calloatti]

• The version of the mod you are using BetterBoilers-1.1.1
• Your Minecraft version 1.12.2
• Your Forge version 14.23.1.2594

They work, but don't connect visually:

(Edit: I changed some of the textures)

[LemmaEOF]

I am aware of this issue, and I'm afraid it's very much a cantfix as far as I know.

The way that the valve, vent, pump, and hatch work is that they act as a proxy for the CapabilityFluidStorage or CapabilityItemStorage for the boiler controller. When separate from the multiblock, they don't have a capability, period. However, because of the proxy nature, they still for some reason don't connect up to pipes. I'm gonna have to check with some other devs I know to see if they know how to solve this.

[calloatti]

Even when part of the multiblock they don't connect, as you mentioned.

This mod seems to do it right:

Maybe you could check out their code.

https://github.com/CyclopsMC/CapabilityProxy
https://minecraft.curseforge.com/projects/capabilityproxy

[LemmaEOF]

Oh boy, Cyclops. Pretty much all of Cyclops' capability stuff is his own witchcraft from CyclopsCore, so I'll see what I can do.

[DaedalusGame]

could it be that this is a client-side issue? controller could be null on the client, which causes it to not return a capability?

[LemmaEOF]

Hm, that could be something to test. I'll take a look when I have the time.

[pupnewfster]

Not quite sure if this is the same thing, but this is the same as how for example after restarting the server pipes get disconnected... Then I believe the issue may just be that as you said, since the proxy blocks do not have a capability unless they are part of the multiblock, that once they become part of a valid multiblock (and have a capability) they do not send a neighbor notify update to inform the pipes to recheck if they can connect.

[LemmaEOF]

That actually might be it. I might have them expose a dummy cap until they get connected.

[pupnewfster]

The other option is assuming your setController method gets called both when it is unsetting and when it is setting it again, you could then just call notify neighbor/on neighbor change there.

[DrUltraLux]

This will be fixed in the next commit now.