this means there's no point in trying to minimise state activity by remembering the current rate, instead just remember the last value of time, perhaps as $(key;:time)
the time attribute name is to be consistent with !physics
adding initial makes sense as it avoids having to always add a starting point into the counter value otherwise.
If key isn't found in the state then it is initialised with the value of initial and time is recorded at key;:time. Each frame I calculate the delta between time and the last value from the state and then multiply this by rate and add it to the current key value in the state. I can just use normal vector multiplication and addition here so n-vectors are supported automatically.
Interestingly, rate, time and initialcannot be explicitly null – any of them being null is the same as the attribute being unset and therefore the default value. However, any of them could be non-numeric, which would result in a null calculation, so I'm going to assume that non-numeric vectors are implicitly null, and ignore them.
If I'm going to change counters, I should do so before 1.0.0.
I dislike that
counter()is a function with side-effects. The proper thing should be that counters become very simple renderers. Something like:!counterstate=keyrate=0 [time=frame-time ] [initial=0 ]$(key)time, perhaps as$(key;:time)timeattribute name is to be consistent with!physicsinitialmakes sense as it avoids having to always add a starting point into the counter value otherwise.If key isn't found in the state then it is initialised with the value of
initialandtimeis recorded at key;:time. Each frame I calculate the delta betweentimeand the last value from the state and then multiply this byrateand add it to the current key value in the state. I can just use normal vector multiplication and addition here so n-vectors are supported automatically.Interestingly,
rate,timeandinitialcannot be explicitlynull– any of them beingnullis the same as the attribute being unset and therefore the default value. However, any of them could be non-numeric, which would result in anullcalculation, so I'm going to assume that non-numeric vectors are implicitlynull, and ignore them.If I'm going to change counters, I should do so before 1.0.0.