Hey Folks! Still struggling with the pressure-controlled air pump. It's starting to get a bit disheartening, but I also know that's partially due to being mentally exhausted at the end of the day.
Previously, I tried to make one single item that could detect multiple gas partial pressures, switch pumping on from separate inputs, and switch on and off based on supplied power. The logic turned out to be way too complex to model in my data-driven system, and I got lost in abstract data across many text files.
Today, I tried a different approach: what if there was a separate item for each of those functions? What if there was a detector for O2 pressure, a separate one for N2 pressure, and a pump for each? And let's forget about N2 for a moment, and limit discussion to O2. With this setup, I need an air pressure alarm, and an air pump, and I could add some sort of signal to the alarm that the pump could watch for.
I basically have all of these pieces already. My air pressure alarm could be switched to just monitor O2. The air pump doesn't care what gas it uses, the user decides that when they hook it up. The only thing missing, really, is the talking between the two.
And in theory, that's already there too! I setup this signal conduit stuff a while back to connect UI on one item to remote items at the other end of conduits.
Turns out, that wasn't exactly the situation. The alarm and pump were pretty easy to tweak for this new setup. And I even got as far as connecting them via conduits, and opening up the pump's guts to select the alarm as the thing to watch.
The trouble is, the conduit system wasn't setup for "headless" operation. By that I mean, it was only meant to work when the user was sitting there looking at the UI. Like flipping switches to remotely activate items, or monitoring how much fuel was in a tank. As soon as the UI closes, the conduit info is not available to the item anymore, and the pump code needs access to it to work.
Well, not all the conduit info. Our pump can know which conduit the UI was looking at, which technically leads to the item we want. But most of the code to find that item lives in the UI (since that UI is the only thing that needed it until now). I might be able to do something to tell the pump what object was being looked at, and there are two ways I can think of.
First, I could store the ID of the item we're looking at when the user chooses the conduit in the UI. I think this'll work fine, though making that non-specific to just this case might be tricky.
The other solution, which I'm kind of liking more, is to make the code to trace conduits to the remote object available to everybody. That way, I don't have to change what data I'm storing anywhere. I just put the tracing code somewhere the pump can use it, and feed it the info from the UI that it does have access to and...voila?
I realize this sounds like it might be a fool's errand, since it's really kicking my ass getting this working. And I was just about to throw in the towel myself. However, as is often the case, simply explaining the problem in this devlog revealed some potential solutions I hadn't thought of until now. So I'll give those a go.
I'm thinking there's value in trying to get this working, because it should theoretically mean I can reuse this ability for all future items I want to control remotely. In other words, if I can solve this without writing bespoke code for each case, this should enable more stuff like it down the road.
We shall see tomorrow!