Bug #23160

DCFire is added to the _queue of the danger FSM for several seconds no matter the bullet lifetime.

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

Status:Closed Start date:08/05/2011
Priority:Normal Due date:12/01/2011
Assignee:Suma % 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:Yes First affected ArmA II version:
I am using some Mods:No Single / Multi Player?:
I am using:CO (OA+A2) BIForumURL:
Reproducible for you:Yes NGUrl:
Related to content of DLC: WIKIurl:

Description

Obs
The player fires behind a hostile AI a bullet.
The AI hears this and records its as DCFire event.

What is strange is that it gets new DCFire events for several seconds.

A single shoot into the horizon flying 1400 meters triggers almost 600
DCFire events and around 100 are processed by the AI unit.

It gets new events for about 4 seconds.
The bullet is traveling up to 1000 meters meanwhile away from the AI
and not in its field of vision.

However even if you fire into the ground next to the AI,
it gets new DCFire events for about 4 seconds.

Exp
Without knowing the inner details of the engine processing,
it is hard to make a good estimate here.

However is seems strange to see:
  • that many DCFire events for a single bullet
  • for such a long time
  • no matter if the AI can see the bullet or not
  • to get new events despite the bullet already hit (with the AI seeing it or not)
Repro
  1. Load the attached mission in the editor
  2. Fire a bullet north into the horizon
  3. Fire a bullet into the ground just infront of the AI

When you load the addon along, you get details about the amount of DCFire
events and how long new get added to the queue.

DCFire.Desert_E.7z (1.1 kB) kju, 08/05/2011 20:17

danger_fsm_logger_by_kju.pbo (27.4 kB) kju, 08/05/2011 20:17


Related issues

related to ARMA2 Community Issue Tracker - Feature #23250: Generate DCFire danger FSM events also when the unit is i... Assigned 08/08/2011
related to ARMA2 Community Issue Tracker - Bug #23153: DCCanFire has too low priority in CAManBase danger FSM Closed 08/05/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 #23301: AI is unable to pointpoint sound source (well) Duplicate 08/10/2011 11/01/2011

History

Updated by kju about 4 years ago

  • Description updated (diff)

Updated by kju about 4 years ago

From what I can see the AI reacts to DCFire by a stance change (lying down)
and looks for the shooter (even though it does not seem to be able to identify
the source direction correctly - bug or desired?).

However does this require that many DCFire events for such a long time?

Updated by zGuba about 4 years ago

  • Due date changed from 11/01/2011 to 12/01/2011
  • Status changed from New to Assigned
  • Reproduced by another DH user changed from No to Yes
  • I am using set to CO (OA+A2)

Updated by Suma about 4 years ago

I think this is a good example where we can check how is DCFire handled internally (and decided what how to alter it to make it more useful):

- when a unit fires, it is marked as "has fired recently". This tag is valid for a few seconds (depending on ammo config entry visibleFireTime)
- when a unit sees or hears another unit marked as "has fired recently" during a target scan, it triggers a DCFire event
- target scan happens regularly, and for near units in a simple mission (AI scheduler has plenty of time available) it can happen even several times in each frame.

My first reaction would be to call DCFire in its current form as broken beyond repair and to disable the event for the FSM completely, keeping only the builtin reaction (switch to combat and register the firing source as target). What I do not like about this was the danger FSM was designed so that it can handle each cause which could switch the unit to combat behaviour, therefore I would like to keep it in some form. One simple way would be to pass the DCFire even to the FSM only if the unit is not in combat yet. This would be almost as simple as disabling it, and it would solve most problems we have with the event now, both with priority and with frequency.

An alternative could be to rework it completely, so that it works in a sensible manner, however this can be difficult, as there is not enough information to be able to maintain 1:1 mapping from shots to events in target scanning function where the event is generated (we have only the "has fired recently" mark there, and a record telling us what target is the shot aimed for). What would be possible would be some kind of filtering, e.g. to report whenever we see a unit opening a fire against a new target.

Updated by kju about 4 years ago

My vote would be on:

pass the DCFire to the FSM only if the unit is not in combat yet

for now. And with lower prio/later on:

rework it completely, so that it works in a sensible manner

My reasoning is:
  1. if I understand it right, this would only affect (limit) community modding of the danger.FSM - no engine behavior
  2. it would solve the said issue and its undesired consequences
  3. to have (more) control over AI in combat mode would be good, yet I'd see more basics in terms of combat mode influencing possibilities aspects more important first

Like #23151: Add new scripting command: combatBehavior and setCombatBehavior

Updated by Suma about 4 years ago

  • Status changed from Assigned to Resolved

if I understand it right, this would only affect (limit) community modding of the danger.FSM

Almost. The event is not handled in the danger FSM, therefore not passing it there will do no harm. The event is handled by a civilian danger FSM, but as it is handled in the same manner as DCExplosion and DCEnemyNear and it is most often accompanied by some of them, I think the harm done there will be small (still, this is something which would be good test).

Note: preliminary testing shows that most often some other event (DCExplosion or DCEnemyNear) is generated before DCFire, therefore FSM most often does not receive DCFire at all. This should make no difference for the two danger FSMs provided by us.

pass the DCFire to the FSM only if the unit is not in combat yet

Done in 83496

Updated by kju about 4 years ago

  • Target version set to 1.60 BETA

Confirmed. Works nicely. Thanks.

Added the possible more complex redesign as feature ticket: #23250.

Updated by Suma about 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