Jump to content
Sign in to follow this  
dissaifer

Native FSM?

Recommended Posts

Beyond not being able to use the scripted commands in a native FSM, what purpose does it serve?

Is it faster? Does it run on all AI?

And what is the purpose of the formationEntity (the only native FSM I'm aware of)?

There is very little information on native FSM for the game, such as the wiki page and a discussion page in the wiki, so thanks for any detailed information.

Edited by Dissaifer

Share this post


Link to post
Share on other sites

Also interested to know more about FSM's, in particular about performance and scheduling. With no built-in option to yield (Sleep) are they then inherently less efficient than a script for tasks where state changes are only expected (for instance) every few seconds?

Share this post


Link to post
Share on other sites

Copy/paste from a discussion related to the now removed "findCover" scripting command:

From what I've seen, we have no scripting commands, only functions in native FSMs which are a blackbox, probably hardcoded in engine. Equivalents for "findCover" and "setHideBehind" would be, from what I can figure out from the CfgFSM in characters.pbo's config, "searchPath" and "formationHideInCover". You'd probably have to write your own native FSM to use them. A small example can be found in HeliJunkie's Wiki Sandbox

Maybe it can help?

Share this post


Link to post
Share on other sites

Native FSM are low(er) engine and have priority over scripts/normal FSM from what I recall.

Maybe it is time to gather the things we know, dissect the native FSM available and

build a BIKI page with that.

@ Defunkt

Are native FSM in all regards without scheduling (conditions vs states)?

And you can design less frequent condition checking too, no?

Share this post


Link to post
Share on other sites

You can create a pause in an FSM by setting _var = Time + 5.0 (for instance) and adding a condition node that returns on Time > _var but...

a) It seems contrary to the intended use of FSM's - otherwise why not just add/allow Sleep or WaitUntil?

b) I've always presumed it is more efficient to do Sleep 5.0 (and tell the scheduler precisely how long it can forget about you) than it is to do WaitUntil {Time > _var} which I assume requires the scheduler to check every frame (?) to see if you want to run. I imagine the FSM pause described above would be subject to the same or similar repetition.

Of course this is all assumption/presumption and it would be good to get some firm facts.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×