New meter valve mechanic, a mini "just in time" study.

[JRup]

I took the opportunity to move this to a separate thread. A relevant link can be found in the spoiler:

Spoiler

 

Recap:

Edit: The change has been reverted for U50 (581698)

The most recent update will alter how meter valves work: they will no longer provide a stream of material with a steady green signal on their reset port. Which is fine, because it's a reset port, not an input port so signaling should count once. (I know, semantics, but it is how it is.)

This new behavior solves an aberrant scenario where the the meter valve would ship more than requested if the context allowed it to. Seeing it send two 0.5 kg packets with a short signal was not uncommon. Been there, seen that.

Meter valves are stalling on occasion when a meter valve is used to provide a stream of material (fractions are popular). This is due to automation timings when using the meter valve's own output port in combination with an AND gate, for example. It might not be seen happening early game but felt later on...

There are alternative builds for liquid and gas valves that make use of a valve and shutoff combo to dispense "exact fractional amounts" on demand, but there are no native "valves" for the conveyor system which makes this issue a tad troublesome in that context. This kind of build is bulkier.

 

On 11/15/2023 at 3:22 AM, blakemw said:

However I'm not sure the issue still happens in the latest Patch. Has it definitely happened for you in the latest patch?

I'm currently on the latest patch. That I'm only testing into this now is related to the current enforcement of the activation port being a reset port rather than an input/enable port.

I've just tested this on a very sparse map that barely has anything to discard lag of any kind besides the automation delay, the added verbiage on the automation is due to a related mod:

Now the pipe overview for this:

The meter is buffering the reset signal as expected. I suspect that when signal timings and duration combine to make it encounter a problem fulfilling the order then it stalls.

Does this issue affect other meter valves, short answer, yes. I didn't find the need to include a video for this as they all exhibit the same behavior, a screenshot will do:

 

---

The duration of the reset signal provided in the output may be at fault, so edge detector it is... I've also included the filter gate to mimic the original setup as close as possible. The reset signal duration is trimmed by the forced edge detector achieved by the signal counter configured to "Advanced mode" with %1 as the setting. (Its reset port is not connected to anything other than a single cable there because old habits die hard.)

Conclusion: an edge detector may help with the meter having that funny business. Will it fit your build? Y.M.M.V.

[blakemw]

So it seems that with that layout it deadlocks if the FILTER is set to 0.8, 1.8, 2.8, 3.8 (etc) but doesn't deadlock for other values. At least in zero lag environment with nothing else going on.

It seems to be the case that when the RESET signal is received at a certain point in the Meter's tick-by-tick state progression. Here is my speculation:

1. The Meter in a state where Amount == Limit
2. The Meter receives the RESET signal.
3. The Meter sets Amount to 0
4. The Meter emits a packet because Amount is less than Limit.
5. Amount is now Limit again.

Because everything happened in the same update (in the same tick) it never actually sent a red signal, it started the tick sending a green signal, and ended the tick sending a green signal.

If the RESET signal occurs at any other point in the Meter's state progression, there is reliably a gap between steps 3 and 4, so the Meter actually sends a red signal for some amount of time.

 

 

[hydrotoast]

9 hours ago, blakemw said:

So it seems that with that layout it deadlocks if the FILTER is set to 0.8, 1.8, 2.8, 3.8 (etc) but doesn't deadlock for other values. At least in zero lag environment with nothing else going on.

It seems to be the case that when the RESET signal is received at a certain point in the Meter's tick-by-tick state progression. Here is my speculation:

1. The Meter in a state where Amount == Limit
2. The Meter receives the RESET signal.
3. The Meter sets Amount to 0
4. The Meter emits a packet because Amount is less than Limit.
5. Amount is now Limit again.

Because everything happened in the same update (in the same tick) it never actually sent a red signal, it started the tick sending a green signal, and ended the tick sending a green signal.

If the RESET signal occurs at any other point in the Meter's state progression, there is reliably a gap between steps 3 and 4, so the Meter actually sends a red signal for some amount of time.

Based on this analysis, here are two minimal circuits to reproduce the behavior. If we recall that components have a minimum propagation delay of 0.1 s, then the two components AND + Filter 0.8 s have a cumulative propagation delay of 0.9 s.

The circuit on the left uses Filter 0.9 s; the equivalent circuit on the right uses 9x ribbon readers for 0.9 s cumulative propagation delay. In both cases, the meter valves send 2 packets at 1 kg each (the configured limit).

Note. The gif is recorded at 1x speed, but we slowed the frames down by 2x and added a progress bar for visual aid.

[JRup]

3 hours ago, hydrotoast said:

The circuit on the left uses Filter 0.9 s; the equivalent circuit on the right uses 9x ribbon readers for 0.9 s cumulative propagation delay. In both cases, the meter valves send 2 packets at 1 kg each (the configured limit).

Thank you very much for this one, guess what? I think my prior testing did hit a minor snag with this corrected information. I've re-run the test with a 0.7 s delay accounting for the signal counter, we've stalled yet again:

 

 

[blakemw]

1 hour ago, JRup said:

5 hours ago, hydrotoast said:

 

Thank you very much for this one, guess what? I think my prior testing did hit a minor snag with this corrected information. I've re-run the test with a 0.7 s delay accounting for the signal counter, we've stalled yet again:

It's notable that even with the 0.8s signal delay it doesn't always stall. In particular it tends to not stall if you advance time really slowly.

Some games have very strict tick based simulation such that everything executes very precisely, ONI seems to have more of an asynchronous style possibly even with "do something some amount of time in the future or do this when you get around to it" style of events such that the simulation changes with game speed, the reason for this insanity may be to allow sacrificing accuracy for improved framerate.

In this sense, whether the two things happen "simultaneously", or what we really mean, without time to do something else in between the two things, seems to be highly dependent on the pace of the simulation.

[Saturnus]

Has anyone tried using the AT pulsing trick on the meter valves in the preview?

Using the appropriate sensor type trigger for each meter valve

However, I would not be too worried about getting it to work in the preview branch since

I do not see how Klei can release the preview branch into the main game as is,
essentially bricking the game for everyone, and losing 95% of their customer base.

The devs have to solve this and other issues before release. It is not a request. It is a demand.

[JRup]

6 hours ago, Saturnus said:

Has anyone tried using the AT pulsing trick on the meter valves in the preview?

I use both a pulse generator and an edge detector in my updated designs, this addresses any timing issues that arise from controlling the meter valves with additional logic gates. It's turned out rather well and the challenge has been enjoyable besides the fact that compactness has gone out the window...

 

This is the automation for my hydrogen/LOX pre-chiller array. The meter valves are used to send super-coolant to the ice block that well, pre-chills the gases prior to final condensation (elsewhere). I must add it tiled nicely.

Before:

After:

.

 

As for the change? The writing had always been on the wall. The meters' automation never had an input port like the shutoffs; it had always been a reset port. I always try to solve problems with automation; here it had originally failed when trying to keep it simple. The reason, timings. I'm still on the edge (pun intended) on whether this is a bug or a consequence of the game's current design. What I do know is that meter valves will need some additional thought when used.

[JRup]

I'll also leave this here on account of its inherent value:

23 hours ago, Xirema said:

Alternatively, a non-automated Conveyor Valve a'la what Liquids and Gasses have wouldn't be a terrible idea...

[blakemw]

16 hours ago, JRup said:

As for the change? The writing had always been on the wall. The meters' automation never had an input port like the shutoffs; it had always been a reset port.

I don't follow this reasoning: I'm trying to think of all the reset ports in the game, and I think there are only two others:

• Signal Counter: Continuous Reset
• Memory Cell: Continuous Reset

In other words, consistency would be green signal = continuous reset, not a reset port only accepting a rising edge. For the Meters a truly continuous reset makes them nearly unusable for metering out precise amounts of material, but that can be addressed in other ways, such as resetting only at most once per second, or resetting only when Amount == Limit.

16 hours ago, JRup said:

I'm still on the edge (pun intended) on whether this is a bug or a consequence of the game's current design. What I do know is that meter valves will need some additional thought when used.

I'm also on the edge as to whether it's a bug or not. So obviously it's doing exactly what it's meant to: it's sending a green signal whenever Amount == Limit. And it so happens that with the "wrong" timings it's possible to dispatch a packet in the same moment that the reset signal is received, such that the period of time when Amount < Limit is zero. This clearly frustrates any scheme which wants to make use of the output port while sending less than or equal to one packet per second.

With luck this will be treated as a bug and we'll get a guarantee for some amount of red signal duration after a reset, that's really all that is needed, a guarantee of 0.2 seconds of red signal after a reset before it starts comparing Amount with Limit should be enough.

 

Nevertheless, unless/until that happens, I don't think I can trust the output signal for "Valve" applications. I'll be using Implicit OR with a Timer Sensor and inverted logic on the Thermo Sensor (or whatever).

The Timer Sensor is actually 0.2/0.8 it just rounds to integers

If a continuous green signal into the Meter makes it not emit just as well as a continuous red signal would, I'm gonna send a continuous green signal because it's easier. And I'll do this first because it's the simplest possible scheme in terms of part count and complexity which matters especially when automation ports are congested, and secondly because I know it's utterly bombproof because I don't even have to think about that dumb outport port and whether my setup will satisfy its fickleness in all possible circumstances including those I don't know about.

For metering larger amounts, such as feeding the Interplanetary Payload Launcher with 200 kg of stuff, my understanding is that the problematic deadlock can only ever happen if the entire Amount can be sent as a single packet, if it takes 2 packets there should be at least 1 second of red signal. So for multi-packet schemes the simple outport port into an AND gate should work just fine. When using a Meter as a better and more awesome Valve I can't see when it would ever practically matter if it is reset prematurely before sending Limit - this scenario probably means it's input starved. But for something like feeding the Interplanetary Payload Launcher it's vitally important to wait until Limit has been sent.

[JRup]

6 hours ago, blakemw said:

I don't follow this reasoning: I'm trying to think of all the reset ports in the game, and I think there are only two others:

• Signal Counter: Continuous Reset
• Memory Cell: Continuous Reset

In other words, consistency would be green signal = continuous reset, not a reset port only accepting a rising edge. For the Meters a truly continuous reset makes them nearly unusable for metering out precise amounts of material, but that can be addressed in other ways, such as resetting only at most once per second, or resetting only when Amount == Limit.

There's the catch, isn't it? The only other instances of a reset port are found in logic entities, the meter valves are buildings. I know I'm stretching it with this but the intention is to separate it from the notion that it is an input port commonly used as the enable port for buildings as well. I guess it's best we leave the design semantics to boss Klei here.

I did like the change in that it corrected a double shipping issue that was timing dependent. It was something that made me change a minor build that luckily didn't require dealing with solids so I swapped to a liquid shutoff. A comment from hydrotoast on discord did remind me of one prior existing report in this context. Checking it did give me pause and an "ooh" moment. Bug report: Meters inconsistent with automation

It's hard to say where this will go from here now that the change has been reverted to the original behavior and it the din it made might have been lesser way back when the meter valves were introduced.. (We know what's "20/20"...) The automation changes made to my builds while the testing lasted will remain, I find them to be better. Some builds will need tweaking to bring them up to par, still...

 

[blakemw]

So coming back to this topic.

I just got around to playing ONI again, and am I going crazy or were these changes not implemented in the final Packed Snacks build?

So that at present we still have the original, unmodified continuous reset behavior, such that Meters still have the same behavior as Shutoffs, and Meters cannot in practice be used to deliver a precise Amount unless you do significant manipulations to ensure the Meter can't grab a packet while the reset signal is green.

As such it would seem the devs agree with the sentiment that this implementation was unsatisfactory and not fit for release.

So it could be that:

1. The devs are generally happy with the "rising edge" reset behavior, but there are too many bugs with the implementation that make it frustrating to use, so it was reverted until these issues can be addressed.
2. The devs decided it isn't a good implementation and will implement a generally backwards compatible behavior (with respect to desired behaviors), such as reset when Amount == Limit, or reset only once per second instead of truly continuous reset. So it was reverted until this alternate implementation can be coded and tested.
3. The devs consider it a fail experiment and we are stuck with the old behavior.

I am not unopinionated on the matter, that I would greatly prefer backwards compatible behavior.

[Saturnus]

The problem as I see it stems from not having a conveyor valve like we have for liquids and gases.

That means that many people, and by that I do think most that used the conveyor meter valve used it as a replacement for the non-existing valve.

To me that's the root of the problem. If you're adamant about not making a regular conveyor valve available then you really can't change the behaviour of the conveyor meter valve.

EDIT: The most obvious solution is to have an "advanced mode" tick box like you have for counters. In regular or "legacy" mode it works completely as it does now. And in advanced mode it works like it did in the latter stages of the preview. Well, more or less.

[JRup]

5 hours ago, blakemw said:

So coming back to this topic.

I just got around to playing ONI again, and am I going crazy or were these changes not implemented in the final Packed Snacks build?

So that at present we still have the original, unmodified continuous reset behavior

That is the case, as a matter of fact.

As seen in U50's release notes:

Also, as Saturnus said, the game's still missing a "valve" for conveyor lines. Conceptually, I think it should be a powered building as such an action would require some kind of mechanical actuation.

So, more than a valve, it would be something in the line of a "shipment splitter". An added power requirement can also signify it being on par with the research tier it should be put in: "fairly advanced, non-free, 5w please." At this point, it does look like a simplified re-hash of the conveyor meter, without the automation, of course.

This brings us to "legacy/advanced mode" for meters as well. I'd also like to see the improvement brought about by the conveyor meter's "memory" as teased in the public testing phase become a reality in the end, without the stalling. (Hmm, "memory mode", sounds fancy.)

Finally, in the spirit of showing what the alternative build with the shutoff/valve combination looks like when you need precise flow on demand:

Totally not compact, right?