
Originally Posted by
FabrizioT
Most of the AI mechanics are hardcoded or buried into native .fsm files over which we have almost no control nor documentation, but some outcome of some internal mechanics can be observed.
I've no in-depth knowledge on how AI internally works, but having observed its "outcome" for about an year now, there's something i've found.
Let's start looking into danger.fsm, which is basically a "scripted" .fsm file run on a per-unit basis, into which some internal key AI "events" are piped.
It works as a loop and it holds a queue of AI events.
There you can get (almost) real time info on the unit having discovered some enemy, being near to it, having a clear line-of-sight on it, etc.
Each single event "type" as own a priority and only topmost priority event is processed as a state within the .fsm file.
I won't go into detail, but first (minor) problem is that doing so some potentially precious information is discarded whenever more that 1 events are present in the queue ...
However, one of the important events "piped" into danger.fsm is the CAN FIRE (on certain enemy unit) event.
When it's current "top priority", this event triggers a fsm state that does some interesting stuff: it just forces the AI unit to stop there and wait for some seconds, or to wait for the enemy to be dead.
Why? To me it's a "cheap" workaround to make the unit to open fire on a enemy in line-of-sight; it denotes an attempt to "externally" overcome a problem into "core" AI handling.
It's a weak solution and on a side note it may be accidentally overridden by scripting (unit forcespeed -1): that's clearly undesired.
To further depict the scenario of CAN FIRE event: let's imagine our AI unit has this event registered and its state triggered: it means that a enemy is in clear line of sight, it's a threat and should be taken out.
Let's suppose our unit has properly designated enemy as its target (as long as target prioritization does not fail, but this is another matter).
The problem ? Our AI unit won't eventually open fire as long as it's moving. We need to explicitly stop it (unit forcespeed 0) to allow it to shoot.
So here is the issue: moving units in ArmA 2 under (not rare) circumstances don't fire on an enemy (even when commanded to: e.g. through "dofire", editing-wise) even if they have a clear target and/or are directly threated.
AI units do need to be "manually" stopped, to consistently open fire, the same way it's done within danger.fsm.
Having a solid enemy detection routine that would not be a critical problem: the rather ugly code into CAN FIRE state would basically do its job, making the unit stop, allowing it to kill to enemy and go on ...
but that's not the case. Fact is enemy detection (at least into danger.fsm) is quite unreliable: the CAN FIRE event does quite a decent job in registering clear line of sight on newly detected enemies, but it severely fails in registering previously detected units coming again into line of sight. Sometimes they're simply ignored.
Hence AI units keep moving around even if well known threats are visible and close: behaviour pretty easily observable in CQB, because threats are often being detected during approach.
These 2 problems combined are enough to completely break CQB, but there's more.
I'm not positive that in ArmA 2 enemy detection is handled mainly on a per-unit basis, as expected.
We do have scripting commands (e.g. nearTargets) thats allow you to get the approximate enemy position for a single unit.
If you fiddle a bit, you'll discover that an enemy perceived position for a unit is not necessarily what you would expect: usually it tends being the most accurate enemy perceived position of the "most informed" unit in the whole group.
As long as enemy position info (as well as other data) is instantly shared through a group, we will register problems and distortion of AI behaviour, most notably in CQB.
There are other interesting issues, but i've already stealed enough space to this topic.
These were my 2 cents, people more informed than me may add to the matter.
Obviously i stand corrected.
Sorry for my poor english.