FSM editing

[5133p39 12]

Please, vote for this feature on bugtracker: http://bugs.armed-assault.net/view.php?id=2702

[RN Malboeuf 12]

Quote[/b] ]As i wrote earlier it happens when unit gets in or out of a vehicle - and the AI is doing this on their own, for example civilian units will get out of a vehicle when under fire, and you have absolutely no control over this behaviour!

ghm. i thought civillians get out under fire due to there DangerFSM ? Isn't it stopped when doFSM executed ?

What about placing some variable into end state ? Will it be triggered when end is forced ?

[5133p39 12]

ghm. i thought civillians get out under fire due to there DangerFSM ? Isn't it stopped when doFSM executed ?

What about placing some variable into end state ? Will it be triggered when end is forced ?

Yes, it looks like the DangerFSM is the cause of civilians getting out of vehicle when under fire.

...at least units with altered config, from which the DangerFSM was removed, won't get out of vehicle when under fire (but that is not an option).

And yes, it should be stopped when you run any custom FSM (anyway, the DangerFSM shouldn't be running at the start, because the unit is not in danger), but SOMETHING will start it every time the unit is under fire - and it looks like this SOMETHING is hardcoded.

Placing variable into an end state? Which end state? Is there already any special "end" state as i suggested here?

...if you think whether any of your defined end states gets triggered when this forced ending occurs, then no, noone of them gets triggered.

[RN Malboeuf 12]

Any FSM gotits Start and End State. It's axiom. Can you place FSM_end=true or smth there and check thus whetherfsm is running ?

[5133p39 12]

Any FSM gotits Start and End State. It's axiom. Can you place FSM_end=true or smth there and check thus whetherfsm is running ?

Yes, any FSM must have a starting state, which can be named anyhow - even "End", and any FSM also can have any number of ending states, which can also be named anyhow - even "Start" or "Init" - the name doesn't have any special meaning, its just a name.

And yes, i already did that - i tried to get some indication, whether ANY of the end states gets triggered upon this forced ending, and my finding (and my answer to this Q) is "no, noone of them gets triggered."

(and yes, to be sure, one of the end states was named "End")

[5133p39 12]

I am not sure, but maybe there is a workaround in using the "init" eventhandler - its triggered after the unit gets out of vehicle, i could run the FSM again from it.

But i don't think it would cover also the event of fleeing (then the FSM gets interrupted again), it doesn't seems logical that "init" EH should be fired when unit starts to flee, but maybe it is fired after the unit switches to any native FSM? ...i need to test this.

Edit: the "init" EH is not fired when the unit exited any vehicle, or maybe the EH must be set in the unit's config.cpp and isn't working when set by addEventHandler command.

Either way, it cannot be used as a solution for the "forced FSM ending" problem.

EDIT: Possible workaround - using _unit setVariable ["fsm","travel"] to "remember" which fsm we have to run in case things go fahrbot, and use some script to continually loop through all units and check their return value of the currentCommand _unit command.

When the returned value equals to blank string (""), we will know for sure that our beloved FSM has been sent to hezmana, so we use the command _unit getVariable "fsm" to find which FSM we are supposed to run on the unit and we run it again.

Dirty as a bucket of dren, but it seems to be working.

[crashdome 1]

@5133p39

I know it sounds really frustrating because you want to have a single FSM control the unit throughout the whole game (atleast as much as possible).

However, I came to a different understanding after I completed a number of the same tests (btw an FSM can be run while a unit is a driver - the change of effectiveLeader probably has something to do with the FSM termination?)

I learned that an FSM is not meant to be run throughout the whole game and is for *temporary* behavior use only. I've been in almost every FSM thread here and the end result of why people get frustrated is because they wish to control the overall behavior of AI. FSMs cannot do that here. What you really need to do is work with waypoints for controlling the unit moving from city to city... or to perform a task (i.e. run to the market). That is what they are there for. Why use a tool for controlling detail to control overall when you have tools for controlling overall (waypoints and scripts). If you need to control behavior such as how a unit finds a vehicle, or when the unit needs to get around a roadblock, etc.. THAT is what FSMs are for.

So, go back to an SQF script, and use it to plot your waypoints to move units around the island. If you got units you want to make it appear to walk between shops and go window shopping.... use an FSM.

[5133p39 12]

I learned that an FSM is not meant to be run throughout the whole game and is for *temporary* behavior use only. I've been in almost every FSM thread here and the end result of why people get frustrated is because they wish to control the overall behavior of AI. FSMs cannot do that here. What you really need to do is work with waypoints for controlling the unit moving from city to city... or to perform a task (i.e. run to the market). That is what they are there for. Why use a tool for controlling detail to control overall when you have tools for controlling overall (waypoints and scripts). If you need to control behavior such as how a unit finds a vehicle, or when the unit needs to get around a roadblock, etc.. THAT is what FSMs are for.

So, go back to an SQF script, and use it to plot your waypoints to move units around the island. If you got units you want to make it appear to walk between shops and go window shopping.... use an FSM.

I learned that an FSM is not meant to be run throughout the whole game and is for *temporary* behavior use only.

...well, i think that the FSM should be able to run throughout the whole game - IF i have a damn good reason for this (and i do).

After all, the native FSMs are running/switching all the time, they aren't just *temporary* and leaves the AI brainless after few minutes.

So, the fact that scripted FSMs are interrupted is due to not very thorough implementation - bad design if you ask me. It should be optional, lets hope that some day it will.

If you need to control behavior such as how a unit finds a vehicle, or when the unit needs to get around a roadblock, etc.. THAT is what FSMs are for.

EXACTLY! And that is exactly what i am using them for - to get in a vehicle if available (and few other things).

Using scripts is much more resurce hungry than using FSM, so the suggested solution to get back to SQF scripts, use waypoints, etc., is not an option.

I'll give you an example, actualy i'll give you the description of the thing i am working on:

I spawn 50-144 (depends on the size of island) civilian AI units, scattered across the whole island, and 30-100 empty vehicles available for anyones use.

Now to make things more simple, lets say the civilian AI units can do two basic things:

1. they are idle, wandering around the town

2. traveling to another town

When they are idle, wandering around town, a very simple FSM is run on them, which is telling them to move to randomly generated position in the town vicinity.

This FSM contains also a random variable check, which eventually makes the AI to travel and switches to another FSM used to control the AI during its travel.

The traveling FSM is actually divided into three separate FSM files:

1. traveling on foot

During this FSM, i need to check for vehicles which the AI could use. When any vehicle is found, i have to check whether it is broken, or whether it already has a driver inside, whether it have enough fuel, etc., and if all conditions are satisfied, the unit is ordered to get into a vehicle (which must be done by ending the FSM and spawning special GetIn script, which will run the "traveling_in_vehicle" FSM after the unit gets into the vehicle).

2. traveling in vehicle

During this FSM, i need to check whether the AI arrived at its destination (i can't use waypoints, because the location can be unreachable for the AI, and then it will never complete its waypoint so the unit will be stuck - no FSMs running, nothing. So i need to run the script/FSM anyway to check whether a move-timeout ran out to cover for this possibility).

I also need to check whether the vehicle gets dammaged, so i can unassign the unit and switch back to the "on foot" FSM.

I need to check, when the AI is near its destination, to switch to the parking FSM, which chooses random parking slot where the AI leaves the car.

3. parking the vehicle

After stopping the car at the selected parking slot, the FSM is switched back to the idle - wandering around town.

All this (in reality i have 7 different FSMs which are used for different tasks, i have used only the most basic ones in this example) performs much better when using FSMs than when using scripts - and that is enough reason for me to have it as FSMs and not scripts.

If the ArmA FSMs aren't meant for this purpose, then i really don't know what are they for.

I really don't think that i am doing something the FSMs aren't supposed to do.

[5133p39 12]

(btw an FSM can be run while a unit is a driver - the change of effectiveLeader probably has something to do with the FSM termination?)

I am not sure whether i understand what you are saying...

I know from my testing that any FSM run on the unit, is terminated when this unit gets in, or out of a vehicle - it doesn't matter on which position (driver/cargo/commander), and ti also doesn't matter whether there is already any other unit in the commander or cargo position.

Of course that when the unit completes its get in/out procedure, you can again run FSM on it, but the termination caused by the get in/out is there no matter who is leader, or who is driver, or anything.

Can you reformulate that sentence? i don't get its meaning.

[crashdome 1]

All I got out of all that is that you wish the FSMs worked in a way that they don't. I can say I sympathize and actually wished they were something else also, but the reality is they, like functions, are special purpose tools. Thats all I am trying to help you with. You said you are considering going back to SQF and I think that is the better choice... then you lay out reasons why you can't. You also say scripts are more resource hungry but I cannot find out how you arrived at that conclusion. I guess I am the one who is confused..

Quote[/b] ]Can you reformulate that sentence? i don't get its meaning.

When a unit enters or exits a vehicle some strange things go on I've never put my finger on. Some people may have figured it out, but I ended up not caring so much to dive deeper. FSMs are group level I think.. not unit level. In OFP, you can see weird effects by joining units inside a vehicle with another unit outside a vehicle or vice-versa. I see the "effectiveCommander" command is new and having never actually used it I cannot comment on its purpose, but I am *guessing* that an FSm terminates when a unit gets in or gets out because the unit has to undergo some sort of command restructuring.

[5133p39 12]

You said you are considering going back to SQF and I think that is the better choice... then you lay out reasons why you can't. You also say scripts are more resource hungry but I cannot find out how you arrived at that conclusion.

When a unit enters or exits a vehicle some strange things go on I've never put my finger on. Some people may have figured it out, but I ended up not caring so much to dive deeper. FSMs are group level I think.. not unit level. In OFP, you can see weird effects by joining units inside a vehicle with another unit outside a vehicle or vice-versa. I see the "effectiveCommander" command is new and having never actually used it I cannot comment on its purpose, but I am *guessing* that an FSm terminates when a unit gets in or gets out because the unit has to undergo some sort of command restructuring.

Yes, i was considering going back to SQF, but that was before i realized that the FSMs are performing better - i'll get back to this later and post here my benchmark mission i made.

Ok, i understand now, and i agree, the FSM termination could be happening because some "command restructuring", or maybe just because some native FSM kicks in, whatever.

What we need is ability to catch this termination event when it happens, or ability to check which FSM is currently running on a unit.

I mananged to create a workaround as i mentioned earelier - the loop which is checking "currentCommand" of every unit, and which will eventualy run any desired FSM when some conditions are met.

I don't like it, but there seems to be no other way, so i'll have to live with that.

[crashdome 1]

I agree. There doesn't seem to be any other way.

I myself have created a system which is like you described. It loops and checks various conditions. I think of it as my own custom eventhandler system.

It would be nice to have like an FSM controller API whereby you could query the current executing FSM similar to how we can check "CombatMode". I am not sure if that is possible, but I really hope the right people are listening nudge-nudge wink-wink. As far as non-terminating FSMs, I have learned to work around them. I also have begun to think they are more trouble if they last that long.

[5133p39 12]

Does someone know more about the unit's fleeing process?

When a unit is fleeing, it is running somewhere aproximately in the opposite direction of the danger.

It looks like when the "fleeing" is activated, it creates some waypoint far away from the danger, and when this waypoint is reached it checks whether the unit feels safe, and if not then another waypoint is created, and so on.

But i need little bit different behaviour, so is it possible to somehow override the default fleeing by my own FSM or script?

I found that when the unit "allowFleeing" is set to 0, the "fsmDanger" will be still executed, but the true fleeing does not happen.

So i could use my fsmDanger to simulate/script the fleeing as i want it, but for that i need to know what is the unit fleeing from - is there any variable i can check inside the fsmDanger?

I could check for nearest known enemy, but that is not exactly correct - what if the nearest known enemy is a simple soldier, but on his opposite direction would be a tank from which the unit actually wanted to flee.

And the fleeing seems to be triggered also by near bullet impacts, and how can i know from which direction the bullets came?

[5133p39 12]

I remembered there is some "fsmDanger" in the game, and inside i found some function to determine the source of danger.

Looks like there are some variables available inside the "fsmDanger" like "_queue" and "_dangerCause", so hopefully this will help.

edit: the _dangerCause variable works, and contain different values depending on what scared the unit, but _queue seems to be allways empty, no matter which type of danger.

edit2: Seems like the function in the fsmDanger is obsolete, because _queue is not available, instead it is possible to use directly _dangerPos and _dangerUntil.

So my problem seems to be solved.

edit3: Its wrong to say the _queue is not available, instead i should say that in my case it was allways empty, but still available, and it is possible that under different circumstances it may not be empty and can be used to retrieve the _dangerPos etc.

[.kju 3240]

From what I know:

Fleeing units should run to

1) some/next supply units (ie. medic BMP)

2) first / last? recent waypoint

3) best hiding in the area

2 or 3 are used if the former option is not available.

[5133p39 12]

Thanks for clarification.

Now i have different problem:

I created a new civilian derived from standard civlian class, and i set his fsmFormation and fsmDanger to my custom FSM files.

(When my FSMs are running, they are displaying messages in global chat, so i know when they are running and when not.)

Now if the Civilian is unarmed, everything works

- at the start of the game, the civilian runs my fsmFormation until he detects any danger, then the fsmFormation is ended and my fsmDanger starts running.

When the danger disappears (the enemy soldier is killed, or the unit runs away to some safe spot and after some time forgets about the soldier),

the civilian automatically switches back to my fsmFormation.

(btw. the detection and switching to fsmDanger and back to fsmFormation is done automatically by game itself).

Now if i give the civilian some weapon and ammo, and he kills the enemy soldier (thus clearing the danger), the fsmDanger is ended, but it won't switch back to my fsmFormation.

I tried to set his behaviour to "AWARE" in the 'End' state of the FSM, i tried to Join him back to his group, set his formation, but nothing makes any difference, my custom fsmFormation won't start.

What could be worng?

How can i make the civilian to switch back to my fsmFormation automatically (without using doFSM command) ?

edit: I forgot to add that i also use <span style='color:blue'>_unit allowFleeing 0</span> to disable the ?harcoded? fleeing which would otherwise interfere with what my fsmDanger does (for example my moveTo commands would be overriden).

edit 2: i forgot to mention: when i give the civilian some weapon, but NO magazines, everything works. The problem occurs only when the civilian gets both Weapon and Ammo, and when he kills the enemy soldier.

[5133p39 12]

So, nobody knows?

Not even Suma?

edit: Isn't there anyway to "reset" the unit? something which would (even as a side effect, i don't care) run again the unit's initialization (and i don't mean some init.sqf, but the hardcoded stuff)?

Something like reset button on your computer, to make the unit "reboot".

[5133p39 12]

According to Suma, the fsmFormation is supposed to be running all the time - no need to end it (it is not meant to be ended when the fsmDanger starts).

While the fsmDanger is running, the fsmFormation shouldn't be stopped but the game shouldn't be executing it (as i understand, it should be freezed).

UkonÄování fsmFormation se mi zdá jako divný a nepotÅ™ebný obrat. Dokud běží fsmDanger, fsmFormation se nevykonává. NemÄ›lo by být tÅ™eba ho ukonÄovat - fsmFormation je myÅ¡lené tak, že běží trvale.

..the translation of the PM message above:

Ending the fsmFormation seems like a strange and unnecessary action. While the fsmDanger is running, fsmFormation is not being executed. It shouldn't be needed to end it - fsmFormation is meant to be running all the time.

Thanks for the explanation Suma.

[.kju 3240]

Thanks for posting the info 5133p39!

Even better would be to merge it into the wiki.

[5133p39 12]

Thanks for posting the info 5133p39!

Even better would be to merge it into the wiki.

Yeah, that would be nice.

I am currently too busy, but later i will try to do that (if somebody won't do it sooner).

[spirit6 51]

I got an fsm running pretty smooth for a group by patrolling some stuff my "zone manager" dictates. The only thing i cant get done is influence the speed.

In the init (start state) i have

_dude 	= _units select 0;
_group 	= (group _dude);
_group setBehaviour "safe";
_group setSpeedMode "LIMITED";

Thats fine.

Then he figures out the way point and gets :

_dude Moveto _tpos;
_group setBehaviour "safe";
_group setSpeedMode "LIMITED";

So the dude goes out witht he whole group and they do that again by awesome speed. Only thing is, its not limited. What is overruling the behavior here and what would be the way to go?

---------- Post added at 12:48 PM ---------- Previous post was at 10:58 AM ----------

Oh i call this by DoFsm

Edited September 2, 2009 by spirit6

[sakura_chan 9]

The default fsm use 'forcespeed' to control speed usually. BTW does anyone know how to get the default 'formation' fsm from the character config's cfgfsm section into the fsm editor? Its not in .fsm or bifsm format :(

[.kju 3240]

well one needs to adapt the layout :)

[spirit6 51]

Cheers for respons Saku. Gonna try that.

I am thinking of adding waypoints instead of moveto command. What i have seen so far is that my moveto command is overruled by default sfm the mometn they get into contact. it has one side effect and that is that the move order from my fsm is still in effect. this results in AI getting indeed shoot and go do combat stuff but still try to make it to the last moveto order.

I am wondering if moveto creates a waypoint actualy (going to check that) as in that case i can atleast cancel my waypoints the moment the behaviour goes up from "safe" to what ever they need.

Not sure if its possible to create waypoints actualy from fsm group lead perspective. Anybody know/sees limitations?

[haroon 10]

I wonder how to create such a .fsm file?

Is there any Editor/Tools for it??

And tut...for it will be nice :D