Liquid Pipe Thermo Sensor gives inconsistent readings on liquid bridge output

I build in constrained spaces all the time and always avoid placing a value sensor at the bridge output. Sensors at the outputs of bridges have never been reliable, likely due to the pulse (on/off) effect.  I only ever use the liquid element sensor (yes/no) on a bridge output that's wired to a buffer to test for blocked flow, and even this can be unreliable because it may stop pulsing.

I would argue that since bridge outputs have four possible outputs the sensor can't always detect the packet in time all the time, even if there is a single route to be had.

That said, here's a read that can be related:

 

The thing is, I never ever had this issue prior to PPP so I register it as a regression. That being said, being a software engineer myself, I fully see what kind of race condition or other arbitrary code ordering can cause those issues and how those things can change when chasing performance gains or depend on hardware, so I am fully aware that the best move might be to issue a "won't fix" or a "not actually a bug, this never was a feature" here. I just want it to be clear,... and if it is indeed something that isn't to be fixed, perhaps it could be made that you no longer can place a sensor on the same tile as the input or output of a pre-existing bridge nor a bridge input or output of a bridge on the same tile as a pre-existing sensor. If people get surprised by this behaviour on a regular basis, I then see it as a sign that something is to be done about it.

I suspect that this issue only occurs with bridges (and perhaps conduction panels) because it is the only component whose input/output can overlap with a sensor, but that it could occur with any building's input/output if they could stack with sensors, but they can't because of the building collision layer. Bridges (and conduction panels?) are the only exception. May I then suggest that sensors be made to be present on their respective "port" collision layer in some way so that it is no longer possible to place them on any building's input/output, bridges included?

Edited July 14, 2025 by gigamoi

Thing is, this behavior has been a "gotcha" even since before Spaced Out! came to be so I can't in good conscience argue for a regression here. Some builds will still function appropriately even with this happening, it's until they perform unexpectedly that one takes note of the irregularity. That's how it happened for me.

Bridge outputs can have mildly unexpected behaviors when dealing with certain sensors, particularly thermal ones. And yes, I'm generalizing with bridge types so we can choose our pick as it happens with all of them. I haven't tested on conduction panels, though I would expect it to happen for them too.

I would rather see devs. opt to looking into a possible fix for this instead of limiting build possibilities that could introduce further gotchas into the mix.

I know it is most likely not a regression. It just looks like it from my perspective.

That being said, I can see how fixing the root cause could imply a noticeable performance loss and therefore be an undesirable outcome. That's why I suggest, if that's the case, to make it impossible to build a glitchy setup instead since the rules seem so easy to implement and restrict so little. Not much would be lost by adding those limits IMO because the newly impossible builds are mostly non-functional anyway.

Be it fixing the core issue or preventing players from falling prey to it, something aught to be done about it. You can't just let players run into glitches.