A.I aiming Speed (dead zone)

[tomolyons 23]

Hi all

i dont know if anyone else has noticed this but part of the A.I's aiming speed is to do with the aiming deadzone, much like the setting in "game options" If the A.i had aiming deadzone on 0 then they would be able to aim much faster and in close quarters it would be a lot harder,

Heres a video example

Does anyone know a mod that fixes this or can it be fixed?

thanks

[froggyluv 2136]

I think we've all noticed that and yes, thats an area screaming for improvement. AI slow scanning is fine fore medium/long range but just makes no sense when you're obviously right in front of him. Also the running away (im guessing to find cover) looks pretty bad as who in their right mind is going to turn their back and run when an an enemy is at point blank range ready to fire - hell I'd rather he charge you screaming Banzai!!

[tomolyons 23]

Indeed it does need improving and it becomes annoying when it comes to close combat. there must be some coding somewhere that stops the a.i from using aiming deadzone, and would be brilliant if someone could somewhat disable it.

[Opticalsnare 12]

Had this so many times its just ends up becoming completly unrealistic and a comedy show. Anyway you can change the AI aimming speed in the configs which might help but im not sure if it will solve the problem, considering just how bad the AI is in this game its just one of the of many things which need improving concerning AI in this game, they are sometimes borderline broken.

[-Coulum- 35]

Yeah it is a really big problem when concerning close combat. At far range, its alright because it looks like the ai is scanning the horizon with his rifle and then lines it up with you and starts firing. But in close combat it just looks retarded. I'm hoping that in Arma 3 there might be new animations that fix this, or better yet make it so ai reaction time is based on the distance to the target or something like that.

[maturin 12]

The AI's rules of vision and tracking need to be completely re-written for engagements under 100m.

[-Coulum- 35]

The AI's rules of vision and tracking need to be completely re-written for engagements under 100m.

Unfortunately that seems to be the case. Now the question does bis have the power to do it. From the little emphasis on ai improvements for arma 3 I and kind of doubting it. But maybe thay are only trying to show off the exciting and cool stuff and ai improvements don't always seem that exciting or cool to most...

Anyways, heres a really informative post by FabrizioT from another thread on the issue.

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.

[.kju 3245]

cfgAISkills tweaking should help or AI config values in cfgVehicles

[Tonci87 163]

Something that I have noticed:

AT AI under your command are the most stupid bunch of artificial intelligence I have ever seen.

They take ages to attack a tank. Even if it is only 100 mters away from them in clear line of sight.

They generally aim to high and are missing the target.

Experienced with BETA+ACE+ASR_AI

[Opticalsnare 12]

Does anyone know what FSM's do extactly or how they work, there seems to be a bit in there which im not sure but may be what what controls the AI actions and when they do it. For example when they return fire and attack and when they go prone or when to go to cover.

Im trying to make them less retarded by stopping them going prone all the time ie run 3 meters go prone, get up go prone get up run about like a moron go prone get mowed down by tank cause hes too stupid to stay down or simply get mowed down by machine gun fire.

I Just had a simple test where i had 12 riflemen vs 1 machine gunner (Dshk) in a bunker, it was so stupid to watch i needed to FIND something to do they basicly reported a enemy machine gun in a fortified bunker so they get orderd to engage so the next thing they do is run DIRECTLY at the machine gun, some of them start taking popshots which are useless then the enemy machine gunner opens up mows them down while the other half of them start running about going prone running going prone that usual cycle whilst getting in the end they all died and failed completly to secure a machine gun.

[maturin 12]

There isn't any right way to attack a fortified machinegun, fyi. You either have some sort of defilade, concealment or cover that you can use to flank it (which the AI can't recognize because the map is a hundred square miles), or you suppress the position, bound to assault and hope for the best. Aka, just what the AI will do if you put them in that hopeless situation.

Bounding overwatch is important behavior, but it only really helps before contact is initiated, or if they are concealed when prone.

[Opticalsnare 12]

I wasnt really on about what tactic the AI decides to use but actually how they perform that action. They get stuck in endless cycle of moving, going prone and repeating.

[maturin 12]

Until they take out the enemy, generally. One problem is that you can't take them out of that behavior reliably without putting them in some weird (and random) formation like column or delta.

[wipman 1]

Hi, on the ArmA2 the AI seems to don't have ADZ at all, they don't turn the hip when they're scanning and seems that they don't have any inertia from their weapons neither, the AIs remain on the still standing possition aiming and turn the whole body instead turn the hip to scan while keep aiming and once they've check that that fire sector is safe then turn the feet to scan another sector. The AI is not tunned for the close combat and much less to the indoors combat; is as it wasn't possible to have 'em well for booth open field combat and close combat and much less CQB, where the AIs go prone indoor, turn the whole body from feet to head instead turn the hip first and then align the feet with the shoulders for advance as for scan so they don't give any human like shape as they act as silly robots with laser guns. The coding of the AI must be the hardest part of the whole game for the developers... . Let's C ya