New to ArmA 2: FSM - Scripted FSM by xeno

So what is a scripted FSM ?

A scripted FSM is simply spoken a replacement for a (SQF) script. The benefits are (from my experience) that the conditions (not the states) of a scripted FSM don't fall under the time limit per frame that normal SQF scripts can suffer from (see ArmA:_Editing#Scripting for an explanation of time limits for scripts in A2).

It may also be an easier way to design scripts as you have a WYSIWYG editor (FSM Editor from BI) to place conditions (diamonds) and states (squares) and link them together.

How to setup a scripted FSM in the FSM Editor

After you have started the FSM Editor you'll see an almost blank white page with a red dot in the middle (this is the initial Start state).

Now open the FsmAttributes -> Fsm name menu.

Follow up:

A new window pops up, enter the name that you want to give the FSM and press the Ok button.

Next, open the FsmAttributes -> Fsm compile config menu, a new dialogue appears:

Hit the Browse button, in the Select Compile Config dialogue navigate to the directory where the FSM Editor Personal Edition is installed and select scriptedFSM (this is the config for scripted FSMs, you'll see other configs too but we choose scriptedFSM).

You have done the basic setup for your first scripted FSM.

One more thing. You should now save the FSM for the first time. A dialogue will ask you again for the name of the FSM, just hit Ok.

The save dialog wants to save the FSM as "Bistudio FSM (*.bifsm)" file. The bifsm format is the standard save format for the editor but it can't be compiled to scripted FSM.

So instead of "Bistudio FSM (*.bifsm)" select "Compiled FSM (*.fsm)" which will save the scripted FSM in the correct format usable by A2 (via execFSM command).

Enter the filename and hit the Select button, done.

Every time you save the FSM it gets automatically compiled when you have chosen Compiled FSM (you will see a DOS window pop up for a short time). If you want to compile a FSM manually navigate to File -> Compile menu or hit F7. Then the "Compilation result" dialogue will stay on screen and you can check if your FSM has any error.

Some rules...

FSM should always start with a Start state. After a state the next is always at least one condition, every condition follows a state... and so on. You can't link two states nor can you link two conditions, but you can link multiple conditions from a state or to a state or link multiple states to a condition (for the later the compiler moans with the following warning:

1. (1)     Warning: Condition has in degree greater than 1

but it has no effect for scripted FSMs). If the FSM is not a looping FSM add an End state.

How to use the WYSIWYG editor

The most important tools in the editor are the four tools on the left side of the editor window:

With the first tool you can paint a new box (it can be changed to whatever you like by opening the context menu with the right mouse button over the new box, state, condition, etc.).

The second tool is for resizing and moving boxes (states or conditions).

The third tool is used to link states and conditions. You can either link from a condition or state to an empty area in the editor workbench and it will draw a new state or condition (depends from what kind of box you started) or you can link two existing states and conditions.

The fourth tool is the zoom control. Zooming is also possible with the mouse wheel.

The fifth tool resets the zoom.

All other tools are used to change text settings like font and color and so on.

To select a state, condition or knee simply choose the resize control or select more than one by drawing a select box arround the boxes you want to select.

Resizing is done by dragging the sides or edges of a selected box.

States, conditions, links, knees in the WYSIWYG editor

In the WYSIWYG editor states are represented by squares:

Conditions are represented by diamonds:

Links are lines that point from a state or condition, the target has a little arrow:

Knees are just little helper objects to make your FSM look better in the WYSIWYG editor, they have no real purpose:

(Although the two conditions are near each other they are not linked).

By double clicking with the left mouse button over a condition or state you can add comments into the state or condition boxes like "I am a state" in the pictures above.

Getting in deeper

After we now know how to use the editor and how states, conditions, etc, it's time for our first scriptedFSM.

But before we begin, let's see how you actually add script commands to conditions and states.

When you select a condition or state the FSM editor will present you new controls on the right side of the FSM Editor window.

For states it looks like this:

and for conditions it looks like this:

The difference is that conditions can have a priority. The reason is that from one state multiple conditions can be linked. The condition with the highest priority will get checked first and so on. If all conditions should be checked at the same priority just leave the 0 untouched.

For scriptedFSM we only need the InitCode text editor in states and the Conditon text editor for conditions.

The first easy scripted FSM, a simple vehicle respawn FSM

Looks simple, is simple.

Let's begin with the Start state:

Like in a normal script we setup variables.

You start the fsm for example like this:

1. [MyTank1] execFSM "simplevehiclerespawn.fsm"

or in an init field

1. handle = [this] execFSM "simplevehiclerespawn.fsm"

The not Server condition simply checks for !isServer to run the fsm exactly only once when called from an init line or wherever. not Server has priority 1 while !alive vehicle condition has priority 0 to make sure that not Server gets checked first. In the !alive vehicle condition text box you will only find a !alive _vehicle.

The Respawn state looks like this:

Well, as you can see, a simple vehicle respawn code.

What's special about all this is that the !alive vehicle condition and the Respawn state are linked together in both directions. This means it is an endless loop. Vehicle not alive, respawn it and check again for not alive and so on.

How to delay in a FSM

As sleep doesn't work in a FSM we have to use a little trick to delay the execution of a FSM.

First we assign time to a variable in a state, for example:

1. _timenow = time;

In the following condition we wait until time - _timenow > waitime (in seconds):

1. (time - _timenow) >= 2

In the example above the condition will wait for 2 seconds.

--------

As you can see FSM is not magic. What I often do is prototype in sqf and then transfer it to FSM, but it isn't needed. Start with easy FSMs to get used to the editor and the overall handling of FSMs. Try to avoid deadlocks, means try to avoid getting stucked in a FSM (a condition that will never be true or whatever).

xeno