Talk:commandFSM

Ok I never heard of the term until the BIS Wiki sprung to life. So I did a quick search on the net and came across the term Finite State Machines (FSM). The site goes on to use Quake as an example:

Finite State Machines in Quake

I must admit I was a little disapointed, but thats probably down to me reading to much into what FSM means to Arma. I thought the FSM commands would add something very new to Arma scripting. But is it just going to make life a bit easier for those that don't already use the principle, which is not a bad thing BTW. But for the likes of myself and many more addon makers\scripters, will it allow us to do anything we couldn't already do with OFP?

UNN

It certainly is a "black box". My understanding from what's being said is that FSM is how they're defining AI behaviors, such as leapfrogging, and (another example from Placbo's RadioCheck gang-whatever) animal characteristics. Presumably, we can define our own states, and what to do in them: so we could have states say "Eating hamburger", "Playing Soccer", "Cruising Main Street for Girls". The next big question is: what are the inputs and outputs? Do we define relative attractors and repulsors? Can we get information such as "IsBeingShotAt", or even custom stuff such as "winkedAtbyHotBabe"? Dinger 13:08, 29 August 2006 (CEST)

Yes, I wouldn't be disappointed just yet. I remember glancing somewhere and seeing/hearing about it maybe being an event based FSM which would make sense. That is entirely speculation on my part though. It will make it easier and hopefully less CPU intensive to perform some complex tasks. I am guessing at this but I think it will be event-driven changes between states. If we can define our own states that is powerful stuff. --CrashDome 04:46, 30 August 2006 (CEST)

That’s what initially got me excited, but as I read more about FSM (outside of OFP) I started to think it would only use existing commands, like those already posted on the Wiki. But if Arma's FSM system has it's own internal set of commands and events, that may or may not be available outside the FSM blackbox. Then that’s a different thing all together. I'm using my own functions and events in OFP like IsBeingShotAt and IsBeingLookedAt e.t.c but it does require a lot of scripting to get to that point. So yeah, if that’s the case then it will be a huge step forward.--UNN 10:45, 30 August 2006 (CEST)

Good points, but take special note of the structure of the command. The two FSM commands we know of are commandFSM and doFSM just like doMove and commandMove. If you look at the two commands' examples you will see they order a unit to perform some sort of action as defined by an FSM file. There are also two additional parameters.. the target and the position. All the other "command" and "do" commands involve either a target or an object reference (hmm.. coincidence I think not). I am guessing, what you can do, is effectively order a list of actions (commandMove %position%, commandTarget %target%, etc..) using those two parameters within the FSM file. This is nothing new and is equivelant to many pre-defined scripts out there as you suggested, but I see one big possible difference: This is a structure of ordering a unit without the hassle of requiring "@unitready _unit" or time delay before executing the next command. Also, one doesn't have to worry about the leader of the group issuing a "Return to Formation" or some other command in the middle of your script and causing it to fail. Think of all the trouble scriptors originally spent trying to get an AI helo to fly to a destination and land properly, especially in MP. We have a solid script solution now as result of alot of people testing and collaborating, but it is messy for such a simple task and requires alot of code. In addition, another possible difference between FSM and a traditional script might be that these are more tightly broadcast within MP. All of what I said is speculation, but you have to admit two things: A) I'm probably really close to the truth and B) this is far better than using traditional scripting methods when ordering units around. --CrashDome 19:46, 30 August 2006 (CEST)

The point about the parameters is a good observation. The example used, PositonPlayer and Player might give additional insight. I'm sticking my neck out but, based on the fact that position can be any location and not just the position of the object in the second parameter (otherwise what’s the point of including them both).

About your reference to the old @unitready _unit problem. The reason I didn’t consider alternatives to these as new is. Addon makers and scripters could already included events to circumvent loops to detect such changes in state for thier own addons, with a bit of extra scripting. But in-context to OFP engine, yes that was the only way you could hook into these events, other than using the default events you get with OFP (fired,killed & damage e.t.c)

Someone else mentioned Palcebo's references to AI animals in context to the FSM system e.t.c How they react to surrounding events. So taking that into account, you could assume the parameter, position. Locates the epicentre of environmental changes and the player parameter represents the object designated to react to these changes. Ok so I won't take my speculations to seriously, but thanks to you both for helping me to get a little more excited once again, over the prospects of FSM system :) UNN 20:26, 2 September 2006 (CEST)

In other words, this doesn't add anything new in capability (there's nothing you couldn't do already) but it simplifies it immensely. (As I understand it, the 'native' stuff are only a faster version of a subset of scripting stuff, maybe automating whole routines so we don't have to script them. But what do I know?)

• What happens when a unit it is applied to dies? (Probably abrupt exit.)
• Would it be possible to apply FSMs to non-units? Doesn't look like it. You can make an approximation in a mission by using gamelogics and waypoints, but that's about it. Think strategic-level ai as one example of its application. Tying it to a 'general' type character is possible, but may be undesirable. (see above point)
• Can one FSM file call on another fsm file for part of its work, and 'continue when done', or will that terminate a running FSM?
• This probably requires the unit in question to be local, but what happens if locality changes? What happens if a client processing a unit (and its fsm) disconnects? (Probably, the FSM is silently terminated.)
• Can a running FSM be terminated by a script? (Probably, by command/do-SOMETHING.)
• Can native and scripted be mixed in the same FSM?

--MaHuJa 11:47, 1 March 2007 (CET)