Jump to content

Do's and Dont's of thermal sensors on lines.


Recommended Posts

Hi!

It's Friday! And that means we all got a little extra time for entertainment.

Today I deal with some oddball behavior that I've been seeing on and off in a couple of builds involving aquatuners.

Story time: In the pursuit of even more compact builds, I'd resorted to slapping a bridge in the way of the liquid thermal sensor that governed the aquatuner's activation, against my best instinct. Listen to your inner voice, people...

The resulting issue appears to be like Schrödinger's cat, so don't be surprised if it works at first, when you're proudly staring at your build... Failing to account for this 1 segment error can only invite cat-astrophe. (Pun intended)

This is a screenshot of the wrong build and the correction proposed and I hope this gets through.

1311594208_SensorbridgeclutchDoSDontS.thumb.png.939f05567fb619b6b199b84d8ed7c409.png

So what is going on here is that a bridge's output is used in the same tile as a liquid thermo sensor. (red arrow)

The "corrected" position, if you really want a bridge nearby is the one shown by the green arrow. At this point the need for it is gone.

If you use a thermo sensor in the wrong position what will happen is that it will read the temperature and act accordingly, but it will sometimes not "receive" packages to update its data because bridges are too efficient so to speak, thus the readings will be set to the last valid packet that went through and was able to be measured.

This generates a clutching effect in the thermal sensor with predictably negative outcomes.

Hope this helps.

 

Link to comment
Share on other sites

It's funny that you post about that, I just got started investigating this exploit, that seems related:

Long story short, there is definitely something going on with pipe outputs and temperature: I've reproduced the build in the comment that I linked and it also happens, albeit much less reliably, with the Desalinator.

Those weird temperature reading you are seeing may very well be are a separate manifestation of the same underlying bug.

I couldn't find an obvious bug with code-analysis on the decompiled source, but I'll definitely have fun trying to pinpoint where it comes from this week-end. I'll report if I find anything interesting.

Link to comment
Share on other sites

6 hours ago, Fradow said:

Those weird temperature reading you are seeing may very well be are a separate manifestation of the same underlying bug.

I expect this to be in the same order of Heisenbugs. The sensor will be fine most of the time but will act up every once and then if it's on top of a bridge's output. As the saying goes, a watched pot never boils; one could build a mock-up of something that should have a problem and debug-turbo the mcnuggs out of it to see if it manifests to no avail...

I've corrected the buggy/offending setups in my builds so I won't have any vids showing this happy event (not going back and mock playing only so many cycles to get it to happen, so...)

 

This will be left as a mini-psa to those future builders that for some reason or another want to throw caution to the wind and place a sensor in this non-reliable way.

 

Link to comment
Share on other sites

1 hour ago, QuantumPion said:

This does NOT work (once the filter turns on, it stays on, letting the next item through. The sensor lags behind).

We might as well make the generalization that putting a sensor on the output side of a bridge can lead to unstable results. (Let's say we put forth this generalization cautiously.)

I feel the need to point out that your build does not take into account something very important if the 10w overhead in powering the shutoff most of the time is something you disagree with (both versions of your build have the "vamp" but this matters not if you're already generating gobs of power):

Temperature sensors do not bounce back (say to providing a red output, for example) and keep the last detected temperature in their internal memory so they will be stuck with the last known status until a new item/packet provides new data... So your shutoff will continue to consume power even after your line is empty even if the last packet was shipped.

You can find an example of a limited build that addresses that in the screenshot inside the spoiler; you'll need an element sensor, to say the least:

Spoiler

939407537_10wShutoffauto-justfix.png.56de9ed3e38730512fd2259f5435d511.png

This sadly turns the build into a single element line unless you want to use several shutoffs and tirelessly repeat the build... :apologetic:

That being said, I'm happy you caught it as I see this is a food chiller you've built. :grin:

Link to comment
Share on other sites

4 hours ago, Fradow said:

It's unclear to me if it's the same bug or not just from the description.

I don't believe it to be the same bug.

When we look at the post from QuantumPion above then we see what is borked is the timing to update the sensor's data that is on top of the output from the bridge.

Temperature sensors preserve last valid data and clutch because the bridge fails to provide a packet for the temperature sensor to update its own data on time.

I feel I should change the title from "Do's and dont's of thermal sensors on lines" to "Do's and dont's of thermal sensors on bridge outputs" but it doesn't do justice to the fact that we shouldn't build sensors on bridge outputs for now. (I would appreciate feedback on this.)

My purely speculative idealization of what's going on is that the packet that lands on the bridge output is still "in teleport limbo" and is not detected during the tick it's in that particular map compartment because the game still has to decide a route... a given route of one out four possible routes even if there is only one possible route. (Bridge outputs reliably alternate between all their facets/sides in a round robin fashion).

Why I consider this to be different to the current exploit regarding water sieves:

Your post relates to buildings mis-calculating an output value after the data has been input into the building. (Building = water sieve for now),

My post relates to sensors not being given data in a timely fashion because the data somehow skipped the tile it was in.

My hope is this distinction also helps isolate and track what's going on.

So far the only commonality I'm seeing is that of data not being updated on time.

This is probably unrelated, however, I believe it is still in the best interest to report that ethanol distiller outputs can also be borked; you may take this as anecdotal data but I consider it to be valid data to be checked.

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...