Logix Request: Previous Iteration Value

[Earthmark]

Right now to get the logix value from a previous iteration you need a delay value, but that's time based and seems to be problematic at times where the update time gets very small. Specifically with FireOnChange, often I want the previous value to make a delta from the previous value (such as driveable things that need to contain a current position and make deltas off that initial).

A node that provides the previous value of an iteration would be very useful for these systems, so I can make changes based on that! I think this may be doable via value + delta, but doing that with one node may be nice?

[H3BO3]

Updates Delay didn't work? There's a variant of that which can hold a value too.

Edit: That is an impulse node, so I'm not sure if it's what you'd need...

[Earthmark]

I don't have an impulse to grab with, I specifically need the value of the update cycle from before the impulse was started

[H3BO3]

Oh, I see what you mean. Something that just incorporates currentvalue - Delta together?

[Earthmark]

pretty much

[Earthmark]

It does seem like that pattern of nodes does not work successfully, so I'm still figuring that out.

[Frooxius]

I'm not fully sure what would "previous iteration" be here, since it's a bit harder to define rigorously. What if the value is changed in the previous iteration, but the FireOnChange fires in the next one? In that case the "previous iteration" value, would be the current one.

What could be done that's more specific (but also more straightforward) is have FireOnChange provide the previous value when it fires as an output. Would that be sufficient?

[H3BO3]

@Frooxius I think he means the equivalent of "Delay Value" but delayed by a given number of updates instead of seconds, in his case it would just be one update, the last update.

[Frooxius]

@H3BO3 I understood that part, I have talked about it in my previous message. I'm saying that it's a bit problematic and wouldn't necessarily solve the original problem he's proposing.

[Earthmark]

Does FireOnChange fire on the update where a change was detected, or the change after it was detected? I think either way if it's a delay that acts like an update iteration delay (like how one of the impulse delays work) then that may resolve this as well?

[Frooxius]

Any change will trigger a schedule for it to re-evaluate the input and then at the next available update phase, it will do that and fire. It's not 100 % guaranteed to fire within the same update cycle if the change happens after the update phase where it would normally fire.

This can lead to the scenario I described above - it would fire on change, but the value you'd get as value from previous iteration, is actually the changed value it's firing on, rather than the one it detected the last time it fired.

Delayed value by updates could be added as well, but it could be error prone for this specific scenario.

[Earthmark]

Ahh, I see now. Getting the previous value from an on change as an output would be extremely useful.

Thanks for taking the time to understand the root issue Froox.