It is always an assumption that one versus many is going to be better when you cannot compile before hand. This is assuming it needs to compile or read the file each call. What type of difference this makes is not known.
Don't thank me! I didn't write it
Originally Posted by [b
i just realized, that my logic regarding proof, that you can't run multiple FSM files, is seriously flawed :-)
In the example i gave, the termination of previous FSMs can be happening because we are trying to run agan same FSM file for same unit.
...however, i think that its impossible to run multiplne FSM files - why would you do that anyway?
Running multiple FSMs for the same object is ...contraproductive? contradictory to the purpose of FSM, in one word - a nonsense.
Or maybe i am too blind to see why would anyone wanted to do such thing.
Question: Is there any way of passing more parameters/variables to the FSM?
Anything other than what is available through _units, _unit, _destination, and _target?
So far i was able to devise only one primitive workaround, by creating a global array named 'somearray#'. Then i fill this array with desired values of desired types, and then i run the FSM while substituting one of the _destination array elements with the number #.
The FSM can then run some function which will take this # from the _destination array, and through "call compile" accesses the array 'somearray#'.
Any other ideas?
Whisper / Kalbuth / MrK
ArmA3 / Planetside 2, member of MercenaryS
Planetside / ET:QW / Tribes Ascend, member of Formido Clan
You are absolutely correct. You wouldn't want the headache with trying to run multiple FSMs. Also, there is some behavior changes in regards to coding with FSMs and these are not scripts which can be run in parallel and loop consistantly. It is not the purpose.
FSMs can be run on client PCs. Remember that your group of AI units are local to you.
Do NOT use doMove or move in an FSM. The reason they are not moving is because Move creates a waypoint and all waypoint following is suspended in an FSM while doMove will instantly terminate your FSM. Use moveTo or setDestination.
Right, gonna dig into this setDestination, but its parameters are really strange. Any better description than Biki's one?
I ask cause once I'm @home able to edit a bit, I don't have access to Internet and I'm completely blind, no comref, no Biki, searching in the mist, so any bit of advice is welcome beforehand
I answered your ? at OFPEC which might give you headway, but I'll reiterate here in a diff way:
Originally Posted by (whisper @ June 19 2007,09:47)
Try using your FSM to create a waypoint structure rather than controlling all movement at all times. I found you can create a whole series of waypoints that the AI will promptly follow once you kill you FSM. Now, I believe that some waypoints you can even attach another FSM using setWaypointStatements command.
<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[grp,2] setWaypointStatements ["true", "grp doFSM ""MyFSM.fsm"";"][/QUOTE]
i.e. when the above waypoint is reached (and set 'true' by waypoint condition) the FSM will engage. I have not tested this myself, but might provide you insight.
My whole point is to - instead of disregarding waypoints and trying to control everything yourself - use the FSMs as a tool to make the AI behave and create/use the waypoints properly.
Also, setDestination I think is more for formation behavior and things like flanking/combat maneuvars because you need to set it for each individual unit.
Thanks a bunch, I gonna try that tonight.
It works flawlessly now (well, 1% of the work is now done, I now can go on completing the other 99 )
Thank you CrashDome
It seems the orderGetIn command interrupts my scripted FSM.
I need the unit to get in a vehicle, while the FSM is running.
I hate the idea of spawning a script only to wait until the unit is inside the vehicle to run the FSM again.
Any usable workaround?
EDIT: now that i am thinking about this problem, it seems logical - the FSM was initialy run for a MAN, but when this man gets into a vehicle, he becomes "something else" - he becomes a VEHICLE, so it seems logical that the old FSM will end because vehicles often need to be treated differently.
Therefore i think it's not possible to prevent stopping of the previously run FSM - it seems to be on purpose. I need only some reliable way to start new/same FSM after the original one is stopped.
Maybe some special named state exists, which, when present in the FSM file, is being used when the FSM execution is interrupted?
I need help with this.
Originally Posted by (5133p39 @ June 29 2007,08:46)
I made a workaround - i am stopping the FSM myself when a unit is about to get in or out of a vehicle, and before stopping the FSM i spawn a script which waits until the unit gets in or out of a vehicle, or until a 10 seconds timeout runs out (could be less, maybe, but i better be safe than sorry), and then it will start the FSM again.
The problem is, everytime this happens, the unit is just standing/sitting and doing nothing for 10 seconds, which is little awkward.
I tried the unitReady command, but it doesn't help - either it's functionality is disrupted because of the doFSM or other commands i used, or it won't help simply because the unit is in middle of something (a MoveTo which it hasn't completed yet).
I need some reliable way to determine when it is safe to run the FSM again - if i run it too early after the unit's get in/out action, it will be still stopped by something unknown (by native FSM?).
The 10 seconds delay works, but i don't want any unnecessary delay.
Please, give it some thoughts, i really really need help with this.
(It would be VERY nice if we could get at least a little comment from the developers, regarding this issue)