ArmA 2 OA Beta Build 83181

[Protegimus 0]

Ok, but i'm missing something: i'm logging the events relative to a single unit, which is the only member of its group and the only one opfor unit in the mission. That would mean it's detecting dead units (killed by it) more than once ... Or i'm wrong?

Hi fabrizio,

I looked at this with great interest and have found a few things that profoundly affect the outcome of the test mission:

1. Place (not spawn) a West (BlueFor) soldier on the map away from the combat zone

2. Amend your init.sqf

from

_opforGrp = createGroup East;

to

_opforGrp = createGroup West;

Now re-run the test, first with version 1.59 build 79384.

Version 1.59 build 79384 now behaves as expected with all danger.fsm _dangerCause values observed & DCDeadBody in sync with Body Count.

What about the "can fire" event? Can you take a look? Thanks.

EDIT: looks like all these problems are there from ArmA2 (not OA) first release (or at least v. 1.02.58134).

I hope we'll get them fixed, i think solving these problems will be a great step forward, AI wise.

With beta 83281, the danger.fsm _dangerCause values do not increment as expected.

No DCFire (fire visible) cause, only DCEnemyDetected and CAN FIRE appear to increment as expected.

I triggered DCEnemyNear and DCExplosion by manually (as the civie) picking a weapon and frag and attacking the Russian rifleman.

DCDeadBody is twice Body Count.

With beta 83181 and 83281 AI aim is very poor in single fire mode - appears (from observation) to be fine in burst.

Now a couple of questions of my own:

fabrizio, you were spawning USMC soldiers in an East group - was this purely for the purpose of testing?

The pre-requisite for spawning West units:

_sideWestAIHQ = createCenter West;

did not correctly initialise the AI behaviour (danger.fsm causes not being detected) in my testing - is there something else that needs to be done when you intend to start a mission with no OpFor present, but spawn them all in during the course of a mission?

@Suma: please could you explain how the DCFire event is incremented - it appears to jump in orders of magnitude when enemy fire is observed.

Also, is there a significance to the priority values in the Reacting on Danger init?

_priors = [3, 4, 5, 1, 4, 1, 1, 2, 2];

Protegimus

[fabrizio_t 58]

Hi fabrizio,

I looked at this with great interest and have found a few things that profoundly affect the outcome of the test mission:

1. Place (not spawn) a West (BlueFor) soldier on the map away from the combat zone

2. Amend your init.sqf

from

_opforGrp = createGroup East;

to

_opforGrp = createGroup West;

Now re-run the test, first with version 1.59 build 79384.

Version 1.59 build 79384 now behaves as expected with all danger.fsm _dangerCause values observed & DCDeadBody in sync with Body Count.

With beta 83281, the danger.fsm _dangerCause values do not increment as expected.

No DCFire (fire visible) cause, only DCEnemyDetected and CAN FIRE appear to increment as expected.

I triggered DCEnemyNear and DCExplosion by manually (as the civie) picking a weapon and frag and attacking the Russian rifleman.

DCDeadBody is twice Body Count.

With beta 83181 and 83281 AI aim is very poor in single fire mode - appears (from observation) to be fine in burst.

Now a couple of questions of my own:

fabrizio, you were spawning USMC soldiers in an East group - was this purely for the purpose of testing?

The pre-requisite for spawning West units:

_sideWestAIHQ = createCenter West;

did not correctly initialise the AI behaviour (danger.fsm causes not being detected) in my testing - is there something else that needs to be done when you intend to start a mission with no OpFor present, but spawn them all in during the course of a mission?

@Suma: please could you explain how the DCFire event is incremented - it appears to jump in orders of magnitude when enemy fire is observed.

Also, is there a significance to the priority values in the Reacting on Danger init?

_priors = [3, 4, 5, 1, 4, 1, 1, 2, 2];

Protegimus

Thanks Protegimus!

Sorry, too much "cut&paste" ...

I have already fixed the 2 obvious problems present in the V2 repro, by adding a Blufor unit (to initialize West center) and correcting the side for spawned group.

V3 repro is on CIT.

I've run V3 repro within build 83281, it confirms the problems originally seen despite the V2 repro bugs: CAN FIRE event not triggered correctly and some "suspicious" values for other events.

I will check out build 79384, just to confirm what you observed.

For now:

* I confirm the problem with firing accuracy, not restricted to single fire mode in my opinion. It may be related to fatigue. It probably deserves another ticket.

* Priorities array: the higher the value, the higher the priority. Values are for events from 0 to 8. Only the maximum priority event in queue is handled by .fsm, that's the reason for this array.

* I'm missing the problems with DCFire values , i bet you saw them in build 79384 or older? Seems fine in build 83281.

Edited July 31, 2011 by fabrizio_T

[Protegimus 0]

Yes, please test carefully, as further runs with build 79384 aren't providing consistent results...

DCDeadBody is frequently 2x Body Count, but appears to vary. Will test further.

Protegimus

[fabrizio_t 58]

Yes, please test carefully, as further runs with build 79384 aren't providing consistent results...

DCDeadBody is frequently 2x Body Count, but appears to vary. Will test further.

Protegimus

I am testing it just now.

As far i can see the results with 79384, "fsm events" wise, are pretty the same as with beta 83281, no real difference.

Please let mission run at least 600 seconds, as at first events may look fine while they're eventually not.

EDIT: tested repro V3 in ArmA2 v. 1.02.58134: rawly same results as with latest beta.

Firing accuracy looks being fine in 79384, whereas looks broken in 83281 as well as in other recent patches.

I bet it broke since 79600, but it should be verified.

Please people help us out with testing and vote for the ticket(s) if you think it's worth.

See for reference:

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

http://dev-heaven.net/issues/22935

AI Infantry can't shoot very well

http://dev-heaven.net/issues/22974

Thanks.

Edited July 31, 2011 by fabrizio_T

[suma 8]

Interesting idea. I am afraid such conditions are a bit too much complicated (target state needs to be knows very often), but perhaps something similar could do. One simple attempt: as long as there are any group members alive in group owning the vehicle, the vehicle in working state is considered to be dangerous, as the group members might still crew it.

A change like this was implemented in 83273. It takes the distance of the units in group into account as well to certain extent.

The careful and experienced part of me tells me I should not mess with thing like this at all as this stage, as I can easily break many things. The brave and adventurous part of me tell me it is only beta and if it does not work out well, we can always revert it. Please, test extensively - as a result of this change AI can engage empty vehicles which were not engaged before, provided there is some crew ready to board them.

[Bouben 3]

Amazing. Finally some extensive AI tweaking. AI is the key element of the game. Keep it up!