States can define sets of flags to control what states an object can change to and from. This is particularly useful for advanced error handling, but has a few other specific use cases. The two fields for these flags are stateflag and statusc.

A state's stateflag and statusc values can be set in the state statements, like so: state FirstState { stateflag 0x20 statusc 0x12 ... } state SecondState { stateflag 0x10 statusc 0x12 ... }

If these statements aren't presented, default values are used instead. The default stateflag is 0x1 and the default statusc is 0x2. When an object's state is set (including when it spawns), the state's flags are copied onto the object's fields with the same names. An object can then modify these at will.

Whether an object's state can be changed into the target state is determined by whether the object's statusc has any of the flags in the state's stateflag, that is, whether the operation object->statusc & state->stateflag returns zero or not. If the result is true, then no state change is performed and the object continues to run as if nothing had happened. Certain scenarios imply some extra flags, for example certain events will check using the operation (object->statusc | 0x1002) & state->stateflag instead. TBD

In the code above, the object starts at state FirstState, and its flags are set appropriately. However, if the object now tries to change into state SecondState, it will fail to do so, because SecondState's stateflag and the object's statusc both share the 0x10 flag. The object must remove the 0x10 flag from its statusc field in order for the change to be successful.

You might have noticed that stateflag isn't used by the object in these calculations. This is because the field can be (and is) used to determine what kind of state the object is in. For example, you can know Crash is in a death animation if the flag 0x20 is set. stateflag also has other specific engine behavior, described in a later section.