If you want to start scripting you need at least one state in every script. But we only use one special state see below. At the example you will see all 3 script layers, The "state" (layer 1), the "event" (layer 2) and the "conditions" and "actions" (layer 3). I use the Notepad++ to edit my script you can also use Ultra Edit or similar editors. To comment your code use "--".
ScriptExample
Scripting with States[]
Until now we have worked with scripts that consist of only one state. As our scripts conceive so-called "state machines" they can have many states.
What does that mean?
A statemachine is always in one state, it is never in two states or in no state. It can change its state.
In our scripts, the states are containers for events. Only those events are checked which are in the active state.
States
In the example script there are 3 states, each containing different events.
When a script is executed, the first state in the file becomes active (here: state 1). In state 1 there are the events 1,2 and 3 - which means that as long as the script is in state 1, only the events 1,2 and 3 are checked (their condition blocks are checked) and can be executed (the actions blocks are executed if conditions are true).
There are also transitions between states: For example if the script is in state 2, and the event 4 is executed, the script changes into state 1. Only state located in the same file can inter-connect. It is not possible to refer to a state located in another file.
Why to use states?[]
Using states is a natural way to break down large task in smaller logical segments, and has several benefits:
Using states is generally good for performance & memory usage (fewer conditions need to be checked at any one time) If you have a script with 1 state containing 50 events, the condition blocks of all of these events have to be checked permanently. If you have a script with 10 states containing 5 events each instead, only 5 events have to be checked permanently.
Performance is one of our top-critical issues - so use states to keep performance high.
Using states makes scripts easier to debug (you know where you are when something goes wrong, you can avoid a lot of undesired side-effects, you need to use less "state" variables)
Using states generally results in fewer conditions (no need to recheck conditions from events in previous states), thus making scripts easier to understand. Scripts with states are easier to maintain and extend
Note: try to avoid creating too many inter-connected states. From experience most scripts can be divided into states in a very simple (often linear) fashion. Mostly the flow of States in a script goes primarily from top to bottom. Some scripts need to loop and thus later states connect to an earlier State, that is ok too. But if you have many states connecting to each other there's a good chance that you should rather be using one
bigger state, or multiple scripts, or a completely different approach altogether. Good indicators for too many interconnected states are lots of connections in different places either going "up" or "down" in the script, and mostly connecting states far from the current (and surrounding) states. If it is even hard for yourself to follow the flow of State connections, then there's definetely room for improvement in your script logic.
When to use states?[]
If things happen in a linear order.
States
How to use states?[]
Every state has a StateName. If you want a script to move into a different state, you need the GotoState command. This is linked to an event and it is only executed if the conditions of this event is true - but it is NOT put into the actions block of that event. A minimum version might look like this:
States
back.