ArmA 2 OA Beta Build 83181

[mr_centipede 31]

For me the AI unit never engage the AI static weapons. They just got mauled instead by the Dshkm. Never return fire once. Test it on utes. 1 USMC squad vs 1 ChdKz Dshkm. USMC was slaughtered without firing a shot... so never gotten to test that they will stop firing after the static weapon was empty...

[icebreakr 3107]

If you see that, by all means, provide a repro and I will check what can be done against it. Or would you prefer the "engaging obviously empty" unfixed instead? Or what other options do you see?

Well, I just know that players use this exploit against AI (far most popular gamemode). If I would see an armor that enemy forces use, just hanging around the battlefield, we would probably take it out asap. Same goes for transport vehicles. Deny mobility of their troops. Dunno what are logic options in this kind of situation, but I believe its not something easy... personally I would:

- leave the vehicle a valid target until at least 30 seconds pass since last driver/gunner left it or got killed in it.

[alef 0]

So, AI now knows when vehicle is empty even behind tinted windows and inside the hull? Is this a joke? Coop players will again jump from vehicles when deadly AI unit is spotted... in order to keep it safe (i.e. mission objective)...

Rergular difficulty: when I player target an empty enemy vehicle with the Javelin, the HUD color turns grey. This is probably related: unit's brain does know it's empty even if he didn't see infantry disembark.

[maddogx 13]

As far as AI logic goes, I would say have the AI treat an "empty" vehicle as hostile when:

The vehicle was most recently hostile while occupied AND known hostile forces are still within ~250m (or more?) of the vehicle.

OR

Known hostile forces are within ~50m of the empty vehicle AND no friendly forces are closer to the vehicle.

Edited July 29, 2011 by MadDogX

[suma 8]

As far as AI logic goes, I would say have the AI treat an "empty" vehicle as hostile when:

The vehicle was most recently hostile while occupied AND known hostile forces are still within ~250m (or more?) of the vehicle.

OR

Known hostile forces are within ~50m of the empty vehicle AND no friendly forces are closer to the vehicle.

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.

[maddogx 13]

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.

Sounds good to me. :)

[CarlGustaffa 4]

No objections from me.

[metalcraze 290]

Good to me as well. Waiting for the next beta now ;)

[fabrizio_t 58]

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.

Very nice solution , as long as the vehicle itself gets lower prioritization as target (AI should take out remaining group units first).

[metalcraze 290]

And while you are bothering with tweaking AI engagements can you also improve AT gunners?

They often take a long time firing at a tank, just sitting with a launcher, aiming, and tend to die when taking too long and getting spotted.

[Muahaha 10]

And while you are bothering with tweaking AI engagements can you also improve AT gunners?

They often take a long time firing at a tank, just sitting with a launcher, aiming, and tend to die when taking too long and getting spotted.

You referring to AT team or AI in a tank? If AT team afaik only against vodniks has such an issue, while against other armor they will fire their AT weapons almost upon detection.

[metalcraze 290]

I had this little test mission where I was setting up a BMP facing the road and AT gunner coming to that road from behind a corner.

In 1.57 in 2 out of 3 cases AT gunner could take out his AT launcher and blast the BMP away before it could kill him

Since 1.59 he waits too much before firing - leading to his death in 100% of cases.

[Muahaha 10]

I had this little test mission where I was setting up a BMP facing the road and AT gunner coming to that road from behind a corner.

In 1.57 in 2 out of 3 cases AT gunner could take out his AT launcher and blast the BMP away before it could kill him

Since 1.59 he waits too much before firing - leading to his death in 100% of cases.

I tried with my version of test where i use a AT fireteam of 4 member against any armor except vodniks, where quite high percentage of them survive the encounter.

[CarlGustaffa 4]

Good to me as well. Waiting for the next beta now ;)

Guess your wish was granted :p Not sure if that is in yet though.

[fabrizio_t 58]

Hello,

i just posted a new ticket here:

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

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

Please can anybody run the repro and check if problem is reproduceable ? Thanks.

[maddogx 13]

Those are 400 seconds in real time, no speeding up.

[fabrizio_t 58]

Those are 400 seconds in real time, no speeding up.

I guess that's a confirmation, even if "DCDeadBody" != body count for some reason.

However the longer you run the mission the more the gap between CAN FIRE count and (real) body count is noticeable.

[Beagle 684]

The fact that vodniks are not attacks by AT has to be fixed asap...this fact is exploited to the extreme in MP these days. And it also seems that MBts also dont use Cammon at Vodniks but only MG.

I was able to beat 2 M1s with Vodnik HMG lately.

[Muahaha 10]

This is my result

[fabrizio_t 58]

Ticket updated with repro including explicit "body count" counter for better evaluation.

Thanks to people (MadDogX, Muahaha) who already helped and to anybody who'll care to test.

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

[froggyluv 2130]

Really great find fellas - vote this one up folks! This could be a huge improvement to AI response especially in cqb.

[suma 8]

I guess that's a confirmation, even if "DCDeadBody" != body count for some reason.

However the longer you run the mission the more the gap between CAN FIRE count and (real) body count is noticeable.

It does not necessarily be equal. The event is triggered when a unit sees either a kill, or a dead body. It is triggered only once in each group, but it can be triggered multiple times if multiple groups see the dead body. On the other hand, it does not have to be triggered when nobody discovered the body.

The primary reason why this "danger cause" exists is to provide some reaction when safe units encounter a dead body without seeing the shooting, which is typical in stealth scenarios.

[fabrizio_t 58]

It does not necessarily be equal. The event is triggered when a unit sees either a kill, or a dead body. It is triggered only once in each group, but it can be triggered multiple times if multiple groups see the dead body. On the other hand, it does not have to be triggered when nobody discovered the body.

The primary reason why this "danger cause" exists is to provide some reaction when safe units encounter a dead body without seeing the shOooting, which is typical in stealth scenarios.

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?

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.

Edited July 29, 2011 by fabrizio_T

[KeyCat 131]

The primary reason why this "danger cause" exists is to provide some reaction when safe units encounter a dead body without seeing the shooting, which is typical in stealth scenarios.

Yes, this is - as you say - very much needed in sneakier type of missions and hope to see it implemented.

/KC

[fabrizio_t 58]

Yes, this is - as you say - very much needed in sneakier type of missions and hope to see it implemented.

/KC

I would say it's already working at least to some extent, the only suspicious thing with "DCDeadBody" it's how it's counted/detected, to me.

I hope Suma will better clarify the expected behaviour for all .fsm triggered events. It would make testing easier.