Bug #22935

CAN FIRE event reporting broken within danger.fsm + possibly related issue with AI target prioritization

Added by fabrizioT about 3 years ago. Updated over 2 years ago.

Status:Closed Start date:07/29/2011
Priority:Normal Due date:
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: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

PURPOSE
The attached repro should demonstrate 2 issues present in ArmA2 OA beta 1.60 (build 83181):

1) It shows that in "danger.fsm" the the "CAN FIRE" event is often not triggered as expected.
Due to this issue AI combat efficiency is heavily harmed, since units won't eventually stop and
fire on target, but will run into enemy. Problems arise particularly in CQB:
In this case units would run around without actually firing on target.

2) It shows problems in target prioritization:
Sometimes a AI unit prefers firing on a relatively far target instead of targeting an enemy which
is at point blank range.

Repro
  1. extract "Canfire_missing_repro.utes.zip" to your ArmA2/missions folder
  2. "danger_fsm_logger.zip", put the "@danger_fsm_logger" into ArmA OA folder. Add "-mod=@danger_fsm_logger" to your shortcut;
  3. Run ArmA2 mission editor, open "Canfire_missing_repro" on UTES island
  4. Accelerate time 2x or 4x to speed up things

Obs
See the OPFOR unit mowing down the BLUFOR riflemen which are automatically spawned.

Look at the "hint" which is showing the cumulative count of the events queued by "danger.fsm",
grouped by type.

Notice the "CAN FIRE" counter doesn't grow on par with body count (In average it's about 20%
of body count in my experiments).

Exp
1) The number of "CAN FIRE" events triggered should be at least on par (and possibly way superior)
to body count, since each enemy killed by a rifle is supposed to have been in clear line of sight,
hence triggering a "CAN FIRE" event.

2) Threats at point blank range should be prioritized against relatively distant targets.

V2_danger_fsm_logger.zip (4.8 kB) fabrizioT, 07/29/2011 18:33

V3_Canfire_missing_repro.utes.zip (1.5 kB) fabrizioT, 07/31/2011 10:47

danger_fsm_logger.pbo (21.6 kB) fabrizioT, 08/01/2011 15:55

22935.utes.7z (1.1 kB) kju, 08/03/2011 20:04

picture001.jpg (172.7 kB) kju, 08/03/2011 20:04

picture002.jpg (173.9 kB) kju, 08/03/2011 20:04

picture003.jpg (161 kB) kju, 08/03/2011 20:04

danger_fsm_logger_by_kju.pbo (23.4 kB) kju, 08/04/2011 17:15

Canfire_missing_repro2.utes.7z (1.1 kB) kju, 08/04/2011 17:15


Related issues

related to ARMA2 Community Issue Tracker - Bug #18951: AI infantry moving to the next cover ignores a new threat Closed 04/16/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 #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 #23160: DCFire is added to the _queue of the danger FSM for sever... Closed 08/05/2011 12/01/2011
related to ARMA2 Community Issue Tracker - Bug #23153: DCCanFire has too low priority in CAManBase danger FSM Closed 08/05/2011

History

Updated by fabrizioT about 3 years ago

As a sidenote: is the "DCDeadBody" event count supposed to be bigger than body count?
Forget about "In average it's about 20% of body count in my experiments", DCDeadBody count tricked me.
Repro still valid.

Updated by kju about 3 years ago

#18951 - While AI infantry is moving to the next cover, it is sorta brain dead. Does not react to the situation

Is very similar ticket for the seen gameplay problem.

Updated by fabrizioT about 3 years ago

I'm adding a revised repro adding explicit "body count" counter, see V2_*** files attached.
Let the mission run at least 10 minutes (600 seconds) and check counters.

Updated by fabrizioT almost 3 years ago

Adding "V3_Canfire_missing_repro.utes.zip" as mission repro.
Some bugfixing done (thx Protegimus).
Updated repro V3 is meant to be run with the already provided fsm logger ("V2_danger_fsm_logger.zip").

Issues are both confirmed within beta build 83281.
Need to retest with brevious builds, due to bugs in V2 mission repro.

Updated by kju almost 3 years ago

Can you please improve your demo addon that it doesn't required a specific modfolder naming. Ty.

Updated by fabrizioT almost 3 years ago

  • File deleted (Canfire_missing_repro.utes.zip)

Updated by fabrizioT almost 3 years ago

  • File deleted (danger_fsm_logger.zip)

Updated by fabrizioT almost 3 years ago

  • File deleted (V2_Canfire_missing_repro.utes.zip)

Updated by fabrizioT almost 3 years ago

Here you go.
See attached file "danger_fsm_logger.pbo".

It may be ALTERNATIVELY used instead of the files provided in "V3_danger_fsm_logger.zip".
Just put "danger_fsm_logger.pbo" in your ArmA2 "/addons" folder and run the mission contained in "V3_Canfire_missing_repro.utes.zip".

REMEMBER to remove the .pbo after testing.

Updated by Fireball almost 3 years ago

  • Due date set to 10/29/2011
  • Status changed from New to Assigned

Updated by Suma almost 3 years ago

  • Assignee set to Suma

Updated by kju almost 3 years ago

  • Description updated (diff)

Updated by kju almost 3 years ago

  • Description updated (diff)

Updated by kju almost 3 years ago

  • Description updated (diff)

Updated by kju almost 3 years ago

  • Description updated (diff)

Updated by Suma almost 3 years ago

The repro currently provided is interesting, but what I would like to see even more is a repro of visible problems caused by this CanFire not working - i.e. a repro which shows the AI not stopping to fire as expected, with as little units as possible, I guess having one AI and two or three enemy targets with carefully placed waypoints could work.

Updated by kju almost 3 years ago

Suma what do you mean with "AI not stopping to fire as expected"?

I can see:
  • DCCanFire triggered only very seldom (2-3 times)
  • The AI to attack not always the closest / most easy target (it should be aware of)
  • DCEnemyDetected and DCEnemyNear remaining at zero.

Updated by kju almost 3 years ago

@ fabrizioT

  1. Please remove the old files.
  2. Please log the danger events to rpt (diag_log).

Updated by Suma almost 3 years ago

A repro dedicated to only show the problem, short, simple and well documented is what I prefer much. It is possible the repro already shows the problem, but as it is not obvious from the description, and it seems the repro is a lot more complicated then needed, including scripted spawning, I consider it likely the first thing I would do would be to reduce the repro to a bare minimum. If someone else can do it, it will greatly help me.

Updated by Suma almost 3 years ago

As for "not stopping as expected" - the only thing default CanFire FSM does is to stop the unit. The repro showing CanFire consequences should therefore show a running AI which encounters an enemy target and does not stop to fire at it, but continues running instead. I expect in such repro it will probably be necessary to have multiple enemy targets (two or three might do), as it is a prioritization issue and as such will not show with only one target.

Updated by fabrizioT almost 3 years ago

@kju
I'll update the addon to log the data.
i think i already removed the irrelevant / dated files.
You want me to remove also "V2_danger_fsm_logger.zip" ? I thought it was useful to have the .fsm deployed "unPBOed" for people wanting to tweak it (as an alternative).

@Suma
As a direct consequence of the missing reporting of "CAN FIRE", the payload-code belonging to this state is not always triggered, hence AI won't "forcespeed 0" to shoot. That's a start.
The "real world" consequences are generally more easily observed in CQB. I will try to build the kind of repro you're asking for, since i understand it's useful to you (even if i think the current repro already shows enough to witness problems with event reporting).

Updated by kju almost 3 years ago

Here is a simple demo mission Suma.

Repro
  1. Run the attached demo mission in the editor
  2. Run behind the AI unit to watch it stop (or not) on a DCCanFire event
Notes
  1. The danger.FSM logging addon can be used alongside to see the danger.FSM execution stats.
  2. One can switch to the view of the AI unit via radio 0-0-1.
  3. One can activate a second AI by chancing its condition of presence via the editor to >0%.
  4. One can switch to the view of the second AI unit via radio 0-0-2.
Observations
  1. The DCCanFire event numbers remain very low (most times only 1)
  2. Often times there is one DCCanFire event at the start, but no more later on
  3. One reason seems that once the AI gets into the danger mode, it no longer gets triggered?
  4. The DCCanFire is lower prio that DCFire (see AI FSM) - this means when both are trigger on DCFire gets processed
  5. The DCFire events gets triggered a lot. This means DCCanFire (and others) might get dropped a lot in favor of DCFire.
  6. DCFire numbers are (a lot) more than shots fired and often at the mission start after the fire exachange the number instantly jumps to three digit numbers.
  7. The other DC events aside from DCCanFire and DCFire seems to be executed OK.
  8. One exception might be DCExplosion. Somewhat strange to see it triggered from bullet on fire.

Updated by kju almost 3 years ago

Additional thoughts:
  • Single unit group vs multiple units in a group might affect this?
  • Multiple groups fighting at the same time as part of one battle might affect this?
  • The AI "deaf" during combat mode might be related to DCCanFire no longer be triggered?
    • #19156: Danger mode: units moving extremely slow when ordered to move / advance, without Bounding Overwatch
    • #18950: AI infantry with "fire at will" moves to next cover after weapon reload rather to continue to fight.
    • #18951: While AI infantry is moving to the next cover, it is sorta brain dead. Does not react to the situation.
    • #18952: While AI infantry is moving from cover to cover, it hardly uses its weapon / has a very slow rate of fire.

Updated by fabrizioT almost 3 years ago

 One reason seems that once the AI gets into the danger mode, it no longer gets triggered? 

No, that's not true in my opinion. A CAN FIRE event is being reported on a unit which is already in danger mode. If you run my original repro you'll see that.
Problem is probably that a threat is not triggering a CAN FIRE event more than once in a while, for whatever cause.

 DCFire numbers are (a lot) more than shots fired and often at the mission start after the fire exachange the number instantly jumps to three digit numbers. 

The _queue array in danger.fsm sometimes contains duplicate events, meaning something is wrong under the hood. Hard to tell what exactly, since we can only see the effect of the issue here, not the cause. However i can witness duplicates exist.

The other DC events aside from DCCanFire and DCFire seems to be executed OK.

I think DCDeadBody is suspicious enough ...

The AI "deaf" during combat mode might be related to DCCanFire no longer be triggered? 

I think so, but there are also targeting prioritization issues.

Updated by kju almost 3 years ago

fabrizioT what do you mean with "your opinion" - your experience?
Best would be your facts - this is why I suggested to add logging.

I added a question mark as it seems to be the case for me, yet it
might not be true for whatever reason like special situation/too few
test runs/other danger events always taken prio.

You assume DCDeadBody must be the exact same number as real dead bodies.
I think this must not be the case. Humans can forgot too or can count
bodies multiple times by mistake.
Yes it could be a coding/design error, but it might be intentional too.

Updated by fabrizioT almost 3 years ago

fabrizioT what do you mean with "your opinion" - your experience?
Best would be your facts - this is why I suggested to add logging.

I added a question mark as it seems to be the case for me, yet it
might not be true for whatever reason like special situation/too few
test runs/other danger events always taken prio.

I apologize for my mastering of english language not being on par with my will to contribute, it's a handicap.
By telling "my opinion" i really meant this was a "fact" observed/reproed only by me, so deserving at least some confirmation.

Speaking of events "triggered" in danger.fsm: running my original repro long enough you'll hopefully see "DCCanFire" triggered multiple times on the OPFOR unit well after it comes in danger mode. By the way, priority override is out of question here, since the .fsm logger does show/count ALL the events queued, not the topmost one.
You'll eventually meant entering a state and not triggering an event ? Sorry, if so it was not clear to me.

EDIT: My comment:

Problem is probably that a threat is not triggering a CAN FIRE event more than once in a while, for whatever cause

makes sense with this recent comment by Suma on #18951, i think:

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.

Finally:

You assume DCDeadBody must be the exact same number as real dead bodies.
I think this must not be the case. Humans can forgot too or can count
bodies multiple times by mistake.
Yes it could be a coding/design error, but it might be intentional too.

What i assume is it's suspicious, again based on my tests on original repro.
There are 3 reasons i think it's suspicious:

1) it averages rawly 2x the body count at the end of my tests ( with only 1 unit involved );
2) it grows almost proportionally with body count;
3) I really can't figure the meaning of this kind of values (me dumb ;) );

BTW: i'll edit the addon for logging as soon as i will be able to put my hands back on the game, probably WE.
I hope you understand.

Updated by kju almost 3 years ago

Here is a vastly improved version of your danger FSM analysis addon.
It adds rpt logging, more chat output and applied danger events vs total.
It no longer errors if there is no "killer" unit present too.

Very important
You have to understand that it only uses the highest prio one if there are more in the queue and drops the rest.

Side notes
1) Interestingly with my modification I do get a lot of DCCanFire events.
You might have had a variable scope error in there or something similar.

2) That said there is still a lot of strange behavior going on. More details on that in a bit.

Updated by Suma almost 3 years ago

I have created a page describing basics about danger causes: http://community.bistudio.com/wiki/Arma_2:_FSM_Danger_Causes

Feel free to add any information you find important, even unverified theories (mark them as such), I will read it and verify.

Updated by fabrizioT almost 3 years ago

Here is a vastly improved version of your danger FSM analysis addon.
It adds rpt logging, more chat output and applied danger events vs total.
It no longer errors if there is no "killer" unit present too.

I love vastly improved stuff.
Thanks for fixing the overlooked issue with killer eventually not being present, while unnecessary for the scope if this ticket, will make for a perhaps better all-around logging utility.

Very important
You have to understand that it only uses the highest prio one if there are more in the queue and drops the rest.

You mean danger.fsm? If so, i have been well aware of that for quite some time now ;)
Side notes
1) Interestingly with my modification I do get a lot of DCCanFire events.
You might have had a variable scope error in there or something similar.

It's really interesting you are getting more DCCanFire events.
I have quickly tested your addon / repro within beta build 83343, no mods, on Veteran difficulty and can't really see any appreciable difference in DCCanFire numbers, compared with my own.
Since you had graciously added logging, here is the collected data after a 10 mins. run:

["DCEnemyDetected: 0(0)\nDCFire: 6(14)\nDCHit: 0(0)\nDCEnemyNear: 0(0)\nDCExplosion: 0(5)\nDCDeadBodyGroup: 0(0)\nDCDeadBody: 96(100)\nDCScream: 0(0)\nDCCanFire: 3(2)\nBody Count: 51\nElapsed time: 604.487"]

By the way, i had to manually add the following raw line into the OPFOR unit init field, since it was present in my original repro and without it the unit depletes all the ammo in less than 2 minutes, which is not enough to fully evaluate numbers in my opinion. It may eventually influence the result? I'll test in WE, no more time now.

dummyvar = [] spawn { while { true } do { sleep 5; killer setvehicleammo 1;  }; }

Since i can't reproduce what you are seeing, may i ask your build and settings? I'm missing this information.

Thanks, good night.

Updated by kju almost 3 years ago

Thanks a lot Suma for the details - very helpful!
You can find several questions in the talk page.
If you find the time to answer some of them, I'd appreciate it a lot.

Updated by kju almost 3 years ago

Thanks fabrizioT.

Only mentioned the VI fact as right now, from what i can tell,
DCCanFire will be dropped when DCFire happens at the same time.

For the analysis it is important to understand how many times
an event was triggered vs how many times actually reacted to it.

Updated by fabrizioT almost 3 years ago

Only mentioned the VI fact as right now, from what i can tell,
DCCanFire will be dropped when DCFire happens at the same time.
For the analysis it is important to understand how many times
an event was triggered vs how many times actually reacted to it.

kju,
let alone the priority of events, which may be (eventually) easily tweaked from within danger.fsm,
do you still confirm the core issue with DCCanFire rarely triggered as an event? That's what i still see even with your repro, but your previous comment made me doubt whether you are still seeing this as an issue. That's just to avoid some misunderstandment.

Thanks, keep up the good work.


Useful questions you posted. Let me add some very small bits posted by Suma on the matter some days ago.

http://forums.bistudio.com/showthread.php?p=1992149#post1992149
http://forums.bistudio.com/showthread.php?t=122947&page=8

Feel free to remove them if you found them being OT here.

Updated by Suma almost 3 years ago

  • Status changed from Assigned to Resolved

DCCanFire was significantly reworked to be more reliable in 83471.
DCFire was more or less disabled in 83496 (see issue #23160)

This together should solve the CanFire issue described here.

Updated by kju almost 3 years ago

  • Due date deleted (10/29/2011)
  • Target version set to 1.60 BETA

Yep confirmed for me. fabrizioT please confirm too.

That said the demo missions in here show a few other AI issues.
I will create new tickets for these in a bit.

Updated by fabrizioT almost 3 years ago

What i see is:

  • CAN FIRE event triggered up to 3x-4x the body count. So it's actually triggered multiple times for unit.
  • Target switching when a threat is very close.

So i think the issues portayed here should be considered fixed.
Thanks Suma.

BTW: I see some strange behaviour for the BLUFOR units in the repro and i'll further investigate it, but that's out of the scope of this ticket ...

Updated by Suma almost 3 years ago

  • Status changed from Resolved to Closed

Updated by kju over 2 years ago

  • Target version changed from 1.60 BETA to 1.60.87580

Also available in: Atom PDF