[Scripts] About states

[Zorkaz]

Just wanted to ask other scripters about this:

Is there any need for using states (In Papyrus)?

I have yet to come upon a problem where I can't solve the issue by using different INTs/FLOATs/GLOBALVARs

[SKKmods]

I mostly use Bool bRunOnce or bIsDone flags for switching or stopping single events or functions, but have used states to totally stop a script receiving (well processing) any events for elegance, performance and hygene to avoind persistent hanging or orphan scripts, example:

 

Event OnWorkshopObjectDestroyed (ObjectReference akWorkshopRef) ; crap can still hang around
  Self.UnregisterForAllEvents()
  Self.GotoState("DoNothing")
EndEvent

State DoNothing 
   ;do nothing
EndState

[LarannKiar]

For performance, script states are a bit better.

Personally, I prefer to use Const scripts whenever I can, so I rarely use script states. But there are some ScriptObject functions e.g., GetState(), OnBeginState() and OnEndState() which can come in handy sometimes.

[Zorkaz]

GetState(), OnBeginState() and OnEndState()

I overlooked them. Any new Events could prove to be super useful

[niston]

The principal purpose of states is to simplify your scripts, by limiting the amount of possible paths of execution.

This is most relevant if your code is event driven, because you (as a coder) cannot reliably predict when a given event could possibly fire.

By packing event handlers into states, you can limit that number by choosing an appropriate state (where only event handlers contained in that particular, appropriate state could possibly fire).

 

States also allow you to handle events differently, based on what state your code is in.

For example, with an elevator, consider event handlers for the floor buttons in the cab. When your elevator is at rest, it makes sense to handle these events, as they would probably indicate player's desire to travel to a particular floor. However, if your elevator was already travelling, then you'd probably want to ignore -or store to memory, rather than immediately process- any button presses (event handlers firing).

So you could use one state representing the elevator at rest, and another state representing the elevator during travel between floors. You would handle the button events when the elevator is at rest, but you would ignore (or commit to memory) these events if the elevator was already travelling.

 

Of course, you could use a boolean value to represent the elevator travelling, i.e. bIsTravelling. But this becomes unwieldy rather quickly, as more conditions are to influence the behavior of your buttons. For example, you'd not want the buttons to react at all, unless the elevator has power. So instead of adding yet another boolean (bHasPower) that needs to be IF/THEN/ELSE checked in all the event handlers, you'd rather add a state like "UNPOWERED". That state could then simply have dummy event handlers (which do nothing) for the cab's buttons, instead of checking both bHasPower and bIsTravelling booleans in all the button event handlers, which you'd have to do if you didn't use states.

[PJMail]

I pretty much agree with SKK that the only real use is in some final stage (such as 'Dead') when really you don't want anything to happen.

 

Everytime I have started using States I have found 3 things-

- Many of the events are very broad in what triggers them (like onanimationevent, onactivate) so every state has to deal with 'cross state' events.

Example is whether the event was triggered by the player or an NPC. If I could have 'sub-states'... Basically the number of 'combination' states quickly becomes enormous.

- 'things happen' and you invariably miss some triggering event so find you need to handle 'state A' work when you are in 'State C'.

Example is many script function generate an 'onload' event even though the object is next to you and loaded, or no onload at all (like restarting a game with you next to the scripted object), or no unload, or the occasional missing animation event...

- Trying to break scripts up into smaller self contained scripts (so each can have their own states) always requires 'communication' variables between them and there is no nice way to have this as even a 'common variables' script introduces thread locking etc.

 

Sorry for the ramble but I love the idea of states but so far anything complicated has just turned into a mess trying to handle all possible 'error' conditions.