Wait Causes Dynamically Assigned Variable to Revert


#1

This is kind of an obscure one, which I only discovered when my brother-in-law asked me to diagnose a piston that had been working prior to some recent tinkering. I think like many others here I’ve instinctively avoided ever structuring my pistons this way, although webCoRE seems to imply that you can.

Bottom Line: If a user assigns an initial value to a non-constant (or dynamically assigned) variable, then modifies that value during a piston run, the variable will maintain that modified value only as long as no WAIT statements are executed during the run. A simple example here:

This behavior doesn’t surprise me given my marginal understanding of how webCoRE handles waits, however, when assigning an initial value webCoRE warns:

By assigning an initial value to the variable, you are instructing the piston to initialize the variable on every run to that initial value. While you can change the value of the variable during a piston run, the variable will revert to its initial value on subsequent piston runs. If you plan on storing data in this variable that needs to persist between piston runs, leave the value as Nothing Selected.

I don’t think most people reading this would realize that a ‘wait’ effectively terminates a piston run, causing the variable to revert.

Again, I would think this has to be pretty rare, and so I’m doubtful that this warrants any attention other than a mention here in the forum for future reference.


#2

Just to add a bit to this observation… If the Wait is 4 seconds or less, it does not start back over at the top.

jpg


#3

That being said, I agree with @bthrock. I only force a variable in the top section when I don’t plan on changing it during execution. If the variable changes throughout the day, then leaving it:
temp
is the way to go.


#4

I suspected that might be the case as I seem to recall there is a limit in webCoRE where a piston actually waits rather than setting a timer. But rather than testing it further, I just told my BIL not to do it that way. :smirk:


#5

I honestly thought that 9 seconds would have been the threshold.
(the longest loop time without scheduling a wake up)

I was surprised it had to drop to 4 seconds for this test…
The underlying code must be different for those two cases.