RE: [misterhouse-users] Internals of state change

[Bruce W. <br...@mi...>]

> I was trying to decipher the Generic_Item.pm function
> &set_states_for_next_pass() and the accompanying datastructures
> @reset_states, @states_from_previous_pass.
>
> On first thought, it seems that it would be simpler to change the state
> immediately instead of deferring it via @states_from_previous_pass.  The
> only theory that I have come up with for the defer is to ensure that the
> tied triggers are called with a consistent view of the states.  Is that
> indeed the goal, and if so, is it the only goal of this code?

Tied triggers were indeed one goal for that code.  The other goal was that
the item have a consistent state all the way through 1 and only 1 pass.  If
we set it in immediatly in the middle of a pass, the users code before that
test would not see it changed on that pass, but the code after it would.
This is particularily important for state_now, which must be true just one
complete pass through the user code loop.

Bruce