Talk:States (Papyrus)
Using OnUpdate() event and RegisterForSingleUpdate() function in several States in a same script should be done very carefully ...Or, well, best, totally avoided.
It may drive you fast to insane asynchronous events impossible to debug :
Indeed, an OnUpdate() event of an older state where it was requested will still occur even if you are no more in this same right state
Worst, sometimes this remaining RegisterForSingleUpdate() will find you changed of state... And if you asked since another RegisterForSingleUpdate(), both will happen.
Just imagine the huge mess it becomes if you're trying to make happening antagonist things in the OnUpdate() event of many different states which ask sometimes for switching to each other !
Note: Although I had some hopes for this, UnregisterForUpdate() just won't help ; it is only useful for the so-claimed too dangerous RegisterForUpdate() method.
Erratic remaining updates of other previous states, whatever they find in-time the right state you are now in, will totally screw the synchronicity of your script, resulting in the end of the Dragonborn and the whole Tamriel continent...
A bit ugly if you ask me, but still up to you to take a decision :
If you still want to make some complex script using both states and OnUpdate(), you might give a look here about locking threads : [[1]]
However, really think about it twice : In many cases, using a simple string in which you are stocking your name for a "fake" state, and using simple "if / elseif" in methods will :
- Be enough to make it work with half the line numbers you would have being needed with states - Remember states need for example to include the same functions in each state (!)
- Be easier to debug if you are using many OnUpdate() related code or/and external call to your functions by other scripts
States remain cool blocks to use with for example slow-refreshing Quest-Scripts because it becomes nicer than to do many "IF/ELSEIF GetStageDone()"
My final advice : Avoid them for ObjectReference-Scripts with functions updated by several states or even by other scripts ( such as abilities spell ), unless you are masochist and wants to add "while loop"-lockers everywhere ; in such a case, states are more damaging than helping.
--FR dZastrX (talk) 2013-03-20T12:55:23 (EDT)
128 state limit[edit source]
There is a 128 limit to states on a single papyrus script. This consists of the empty state and 127 typed states. External compiling methods will not prevent you from compiling scripts with more than 128 states. Should you create or modify a script to exceed 128 states, the following types of errors will be received.
In the Creation Kit upon loading the script:
SCRIPTS: error: Class SB_MCM_Script overflowed the named state count field(s) while linking. The class is marked as invalid. A programmer must adjust the bit field sizes
In the papyrus log when running the game:
[10/29/2017 - 12:50:23AM] error: Class abim_test overflowed the named state count field(s) while linking. The class is marked as invalid. A programmer must adjust the bit field sizes
IsharaMeradin (talk) 2017-10-29T02:39:13 (EDT)