Bug #18951

AI infantry moving to the next cover ignores a new threat

Added by kju over 4 years ago. Updated over 3 years ago.

Status:Closed Start date:04/16/2011
Priority:Normal Due date:
Assignee:Dwarden % Done:

0%

Category:AI Issues
Target version:1.60.87580
Affected ArmA II version:1.60 BETA First affected build:
Reproduced by another DH user:No First affected ArmA II version:
I am using some Mods:No Single / Multi Player?:
I am using: BIForumURL:
Reproducible for you:Yes NGUrl:
Related to content of DLC: WIKIurl:

Description

Obs
When AI is moving to a cover, for example when in "fire at will" mode,
it does not react to the situation. Like if there is an enemy in sight,
it will not stop and engage, but blindly move on until it reaches the cover.

This makes the AI an easy target and reduces it combat abilities significantly.

Note
Most likely this applies to any reason making AI to move to cover.

Exp
The AI should evaluate, if it is better to move on to the cover or to open
fire when it has a hostile target in sight.
If this computation is too costly, it should stop and engage (rather to move
on playing an easy target).

Repro
  1. Run the attached mission
  2. The AI runs for cover after the first reload
  3. While doing so, it completely ignores the hostile threat
  4. Just wait to see this happening again and again

DemoAiBehaviorInCombat.Desert_E.7z (1.6 kB) kju, 04/16/2011 06:50

18951.avi (7.7 MB) kju, 08/04/2011 11:08

ignoreCloseEnemy.utes.zip (966 Bytes) Suma, 08/04/2011 12:29

ignoreCloseEnemy2.utes.7z - Player invincible and internal camera onto the bluefor AI (834 Bytes) kju, 08/04/2011 17:48

18951.Desert_E.7z (1.3 kB) kju, 08/05/2011 18:13


Related issues

related to ARMA2 Community Issue Tracker - Bug #18950: AI infantry with "engage at will" moves to next cover aft... Expired 04/16/2011 09/01/2011
related to ARMA2 Community Issue Tracker - Bug #18952: While AI infantry is moving from cover to cover, it hardl... Assigned 04/16/2011 07/01/2011
related to ARMA2 Community Issue Tracker - Bug #22935: CAN FIRE event reporting broken within danger.fsm + poss... Closed 07/29/2011
related to ARMA2 Community Issue Tracker - Bug #23237: AI does not compensate high weapon sway level Assigned 08/08/2011 11/01/2011

History

Updated by Voyage34 over 4 years ago

Right. This is clearly visible forcing the AI to walk (instead of running) by script: it doesn't stop to fire or fire on the move, even if comes under fire, until the position is reached.
This is the reason why static/not moving AI is so strong vs advancing/moving AI.

Updated by fabrizioT over 4 years ago

Right. Line-of-sight should be prioritized over movement.
In my opinion to decide whether move or not AI units should consider:

  • being under fire or not
  • line-of-sight on threat
  • distance to threat
  • speed of threat
  • direction of threat
  • whether threat recently fired

I scripted a raw workaround featuring this and it works better than vanilla, to some extents.

Updated by Suma about 4 years ago

What should I do in the attached mission to see how an AI reacts to a threat / situation? The repro seems to demonstrate issue #18950 (move after reload well), but without some additional steps I do not see how it demonstrated this issue. I cannot see AI encountering any new threat it should react to, or any tactical change in the situation.

Updated by kju about 4 years ago

One only has to watch. Or run to cover so that AI no longer able
to shoot onto the player once the AI go into position to do so.
(aka hide from the AI once it sees you and once it found you again,
move again)

After that AI ran for cover to reload,
it moves to the next cover a little while later.

During this movement it ignores the player/the threat
and only stops once in the next cover.

Basically while in danger mode, the AI seems to have prio
moving to next cover instead of engaging threat it could fire onto.

That event would probably be a DCCanFire one that seems to not happen.

Unfortunately i think at this point i cannot make a more precise repro
as the behavior before it has to happen and it may have issues/undesired
behavior on its own.

Does that help?

Updated by kju about 4 years ago

Here is a short 30s video to demonstrate the issue and how to repro it.

Notes
  1. The end shows it best
  2. The red sphere shows where the AI sees the player at the given moment
Course of action
  1. So the AI knows about a threat, engages it.
  2. The threat can no longer be engaged
  3. The AI moves
  4. The thread becomes visible again
  5. The AI becomes aware of it
  6. However the AI continues to move, rather to engage

The basic notion of the observed problem is that despite knowing about a threat
1) The AI decides to move away from it - instead of trying to keep it in view as much as possible.
+
2) Once the threat is visible and noticed by the AI again, the AI does not engage immediately.

Updated by Suma about 4 years ago

Here is a short 30s video

The video does not work for me (probably some codec is used which I do not have)

Here is my attempt to create a repro.

Repro

- run ignoreCloseEnemy mission
- observe enemy BLUFOR running from behind the corner on the right

Observed
- BLUFOR ignores you and continues running
- even if you do not hit it on the way it stands on a house corner where it is not protected against you at all

Expected
- when a new close enemy appears, AI should react by stopping and firing
- if AI is to run into a cover (e.g. it cannot fire because it needs to reload), the cover needs to be close and it needs to be effective against the new threat

Updated by Suma about 4 years ago

  • Subject changed from While AI infantry is moving to the next cover, it is sorta brain dead. Does not react to the situation. to AI infantry moving to the next cover ignores a new threat

Updated by fabrizioT about 4 years ago

Enough said :) Thank you.

Updated by Suma about 4 years ago

First debugging shows:

1) when the unit has a target assigned by the group leader, it attempts to fire at other targets only when it cannot fire at the assigned target
2) in this case the unit assigns the other OPFOR as a target to itself (technically it is a group leader)

1) also explains why CanFire is not triggered - the firing opportunity agains the other targets is not tested at all.

While 1) is kind of reasonable (think about it from a position of a group leader - if you assign targets, you expect your subordinates to prefer those targets), in current form it is a bit extreme. Targets presenting immediate threat should be evaluated.

Updated by kju about 4 years ago

thanks. good, fitting repro

just in case you are still interested - here is the video:
http://www.youtube.com/watch?v=IQt9M8xwDGY (got really bad quality though)

FFDShow was used for the video. Should be viewable with VLC or media player classic.

Updated by kju about 4 years ago

From what I can see your demo mission shows a couple of issues:

  1. The bluefor AI notices the OPFOR AI while still on the road
  2. Through the bush (uses 'unit switchCamera "internal"') - as player i could not see it behind the bush
  3. It continues to move along the house instead of opening fire
  4. It notices the player once leaving the road heading south along the house
  5. It does not engage the player (closer target), but moves on to take cover at the house edge
  6. It does not engage the player (closer target), but attacks his initial observed enemy (instead of the closer, likely more dangerous threat)
  7. It often uses first a grenade to attack the OPFOR AI rather to use the rifle (slower to engage)
  8. After the first reload it moves south west to the next house - even though the OPFOR is still alive (due to allowDamage false)
  9. After the second magazine the AI has such high weapon sway (where from?) that it reduces the rate of fire as it can no longer aim the center easily

One more aspect is that AI does not get into crouch but remains standing during the whole engagement.

All these points are close to 100% happening each run for me.


In terms of danger FSM events for the bluefor AI:

  1. DCEnemyDetected is caused once it spots the OPFOR AI on the road.
  2. DCEnemyNear is caused once it spots the player as second threat (different group?).
  3. DCCanFire is caused once it reaches the cover point at the house on the south side.
  4. DCExplosion is even triggered when bullets hit close to it
  5. DCFire is caused many times. It seems multiple times per bullet (also its own?)

Updated by kju about 4 years ago

Updated by kju about 4 years ago

Here is another demo mission. You only need to stand and watch.

The AI identifies the new threat pretty quickly (DCEnemyDetected).
But after that first comes a DCEnemyNear event a second or so later.
Only after that a DCCanFire event is created that make the unit stop and open fire.

The demo mission uses "open fire, fire at will" and "combat" mode.
Without combat mode, the AI has a DCCanFire event very fast (albeit after a DCEnemyDetected)
and returns fire effectively.
Fire at will seems to have little to no influence - combat mode seems to be the major reason.

PS: Both danger and stealth show this behavior. The others not.

Updated by kju about 4 years ago

The same is true for your demo mission.

In danger or stealth the bluefor AI continues to run,
while in aware or safe he decides to return fire after
identifying the new threat.

That said sometimes he has issues due to bush position
and decides to take cover at the house wall of the left side
or at the "barn" on the right side across the street.

Updated by Suma about 4 years ago

  • Status changed from Assigned to Resolved

While 1) is kind of reasonable (think about it from a position of a group leader - if you assign targets, you expect your subordinates to prefer those targets), in current form it is a bit extreme. Targets presenting immediate threat should be evaluated.

Should be fixed in 83471

Updated by kju about 4 years ago

  • Due date deleted (07/01/2011)
  • Target version set to 1.60 BETA

Confirmed.

This is a huge improvement - thanks a lot Suma!

Updated by Sickboy almost 4 years ago

  • Status changed from Resolved to Closed

Updated by kju over 3 years ago

  • Target version changed from 1.60 BETA to 1.60.87580

Also available in: Atom PDF