Jump to content
Sign in to follow this  
MBot

AI unable to defend?

Recommended Posts

Test setup:

USMC player and one Russian AI rifleman are on Utes runway 200m from each other, both behind some sandbags. AI has a single waypoint (can be changed to various options). Global AI skill is 1.0, accuracy 0.5, rifleman skill is on maximum.

Mission for download:

http://cid-f33d8b1019e6f4ac.skydrive.live.com/self.aspx/Public/AI|_Defensive|_Test.utes.zip

Observations:

Giving the AI a simple move waypoint means he will immediately fire a couple rounds on mission start, then go prone and not rise again. He wont ever attempt to rise to shoot at the player. Player shooting at/over AI (or hold fire) at any point of the test has no apparent influence on AI actions.

Giving AI a search and destroy waypoint or changing move waypoint properties to engage at will, results in AI immediately fire a couple rounds on mission start, then initiates flanking maneuver (away from sandbags). Player shooting (or hold fire) at any point of the AI maneuver does not seem to have any influence on AI movements. AI will not go behind sandbags and will execute a same flanking maneuver regardless of any player fire.

Thesis:

AI is unable to fight from a defensive position. Depending on waypoint setup it will either go prone behind cover or leave cover to engage the enemy. AI has no concept of vertical cover and consciously shooting over such.

AI movement and actions are unaffected by suppressive fire. Shooting at AI has no influence on what they do. Suppression does only seem to be modeled as increasing dispersion (untested, heresy).

Would be nice if some of the more experienced editor users could have a look at that thesis. Perhaps it is a result of wrong waypoint setup for AI. Also possible custom placed objects are not recognised as cover?

Share this post


Link to post
Share on other sites
Also possible custom placed objects are not recognised as cover?

Correct.

Share this post


Link to post
Share on other sites

This evening I will search for an oppropriate spot on Utes to test it with "native" cover of the map and see if that makes any difference. But frankly I do not expect so as this behaviour matches my playing expieriences.

For a military infantry game this is a pretty big deal in my oppinion.

Share this post


Link to post
Share on other sites

Tweaking maybe? I think AI should be able to recognize sandbags as cover. And understand that you can pop up and fire and then go back to hiding.

Share this post


Link to post
Share on other sites

This does need to be fixed, or moddable. You know the thing about the warfare buildings and the AI drivers not realising they were there, does that go for cover, too? Do the AI take cover behind warfare buildings?

Share this post


Link to post
Share on other sites
This evening I will search for an oppropriate spot on Utes to test it with "native" cover of the map and see if that makes any difference. But frankly I do not expect so as this behaviour matches my playing expieriences.

For a military infantry game this is a pretty big deal in my oppinion.

It hasn't been infantry game after OFP. The mouse smoothing which causes the mouse/monitor input lag makes it impossible to play the game for any infantry player.

Share this post


Link to post
Share on other sites

Yes AI is somewhat unable to hold and/or defend properly any location.

I tried setting up many missions in which HOLD waypoint are assigned to groups.

Sadly they always ended up engaging enemy and abandoning defensive position and cover.

Setting combat mode and behaviour did not help.

Edited by fabrizio_T

Share this post


Link to post
Share on other sites
It hasn't been infantry game after OFP. The mouse smoothing which causes the mouse/monitor input lag makes it impossible to play the game for any twich player.

correction made

Share this post


Link to post
Share on other sites

if you guys dont want the AI to engage on defense, you might want to look at enableAttack.

in ARMA1, I always use this. Put this in group leader init: grp1=group this; grp1 enableAttack false;

I think thats the correct line... will try later in demo.

Share this post


Link to post
Share on other sites

You could just do "group this enableAttack false" rather than creating a variable you never use again. You might need some brackets in there but it's generally pretty good at figuring out what you're after.

Vote +1 for a few patch or expansion: smarter defensive AI.

Share this post


Link to post
Share on other sites
It hasn't been infantry game after OFP. The mouse smoothing which causes the mouse/monitor input lag makes it impossible to play the game for any infantry player.

Mouse lag gone for many with:

Windows Control Panel - Mouse - "Enhanced Mouse Pointer" = OFF

or

Triple Buffering = OFF

or

VSYNC = ON/OFF

or

Get a better PC

I dont have mouselag and my pc stinks. If i turn enhanced mouse pointer off ARMA2 works as BF2 to me. Very direct. Didnt like it though myself.

Alex

Share this post


Link to post
Share on other sites

Repeated the test with the AI behind a native map object:

http://cid-f33d8b1019e6f4ac.skydrive.live.com/self.aspx/Public/AI|_Test|_Defense2.Chernarus.zip

Test Setup

Russian AI rifleman behind stonewall has one waypoint with various properties. Player 100m away behind covered position. Global AI skill 1.0, AI accuracy 1.0, rifleman skill on max.

AI waypoint: move

AI goes prone immediately behind stone wall and stays so. No attempt to engage player

AI waypoint: move, engage at will / search and destroy

AI initiates flanking maneuver seconds after mission start. If there is cover on the flank it will try to use it while flanking.

AI waypoint: guard

AI seems to be a bit more concerned about being defensive. Often it will flank but sometimes it will constantly move along the stonewall from position to position. It does not stay at one fighting position and movement somehow seems undecided.

Some observations:

-Behavior of AI behind stonewalls is definitely different then behind sandbags which seems to support the idea that custom placed objects are not regarded as cover.

-Shooting at AI with a rifle does not seem to have effect on its movements. Shooting at AI with MG could have an effect. Sometimes AI will hold positions longer than usual, go prone behind objects or go prone when sprinting. Still ultimately MG fire will not stop AI from flanking over open ground. In the end it is difficult to achieve consistent results and you are never really sure if it is an action the AI would have done regardless. Currently I can not really say if being suppressed is simulated for AI or not (other than weapon shake). Even if it is though, it would be too weak to have any significant influence on gameplay (should perhaps be tested with lower unit skill).

-The guard waypoint seems to be able to hold the AI in place sometimes. Still it cannot stop it from frequently doing suicidal flanking maneuvers.

-The AI does a lot of unnecessary and lengthy movements. It will constantly change position and is therefore often exposed. Also it doesn't use "ducked running" which would help to reduce profile when moving behind cover.

Because the complexity of even this simple setup it is very difficult to get consistent results and draw definite conclusions. Additional input from other users would be appreciated. When just observing this single AI guy, he does a lot of unexplainable stuff, moving around a lot, going to somehow random places and back again, standing behind this wall and go prone behind the other one. Sometimes it seems he does something smart, but he moves around so much you can never know if it was just by chance. Generally speaking, from the perspective of a gamer, the AI in this scenario does not really leave an intelligent impression.

Edit:

Setting waypoint to guard and unit skill to 0 results in AI flanking each time. Even massive MG fire does not prevent that.

Edited by MBot

Share this post


Link to post
Share on other sites
correction made

Actually no, i had real mouse lag in ArmA1 and the first thing i did was tweaking my driver settings (The now commonly tweaked 'No vsync+flip queue size options) until it was gone, and from that moment on it was the best game i ever played until ArmA2 came along.

But before i fixed that the game felt absolutely horrible and i understand why people complain about it. When your gun moves literally 1 second after you moved your mouse you arent playing the game anymore, you are controlling a robot on the moon and thats just not as fun as playing virtual soldier.

Mouse lag is not a design feature, if the mouse handling doesnt feel like OFP then something is wrong on your end.

Edited by NeMeSiS

Share this post


Link to post
Share on other sites

let not make this topic, which is very well put and well orgenized into a mouse lag discussion.

Anyways, the AI in the game has the ability to use cover and even lean around corners but it seems that even though it CAN do a lot of cool things it does them rarely and in inappropriate times.

about costum objects as cover - i took the "construction yard" object from warfare buildings and covered a field of many many many of these large containers and placed 2 dozens of AIs. 12 on each side and set them to attack eachother.

i noticed AIs occasionally leaning around the edges of this custom object, which was cool, but they didnt seem to take cover often nor at appropriate times.

also, occasioanlly, the start running the opposite way and, as all of you noticed, do some un-explained stuff.

also , Mbot, u said the AI took cover behind the stone wall. do u think it was on purpose that it was behind the wall or did the AI just lie down instantly and the fact that the wall was in front of the AI is pure luck? cuz i think it's the latter.

did u try and place the AI a few feet (may 30. maybe 60) away from the stone wall and see if it goes for it?

i noticed the AI occasionally taking cover behind trees (maybe it's just luck too) but SO rarely. when it does im like :way to go, BIS" but it almost never happens.

setting the AI to:

init: this setunitpos "middle"

forces them to crouch and move at shorter distances before crouching again. i prefer this mode of movement. i hate it when the AI runs like headless chickens or goes prone - up - prone - run 2 steps - prone - crouch - prone - headless chicken maneuver - prone - etc....

an AI mod is DEFINITELY needed. the AI has the basics for doing smart stuff but choosing the right decision is still rough.

Mbot, what is the most offensive WP u found? u said GUARD is a pretty statics and defensive. what is the opposite of GUARD? what is the WP u found that makes the AI to attack the hardest?

Share this post


Link to post
Share on other sites
Actually no, i had real mouse lag in ArmA1 and the first thing i did was tweaking my driver settings (The now commonly tweaked 'No vsync+flip queue size options) until it was gone, and from that moment on it was the best game i ever played until ArmA2 came along.

But before i fixed that the game felt absolutely horrible and i understand why people complain about it. When your gun moves literally 1 second after you moved your mouse you arent playing the game anymore, you are controlling a robot on the moon and thats just not as fun as playing virtual soldier.

Mouse lag is not a design feature, if the mouse handling doesnt feel like OFP then something is wrong on your end.

You "corrected"it, so it's not impossible to play....

Ie you removed the feature effects to acceptable levels. For you (and what should be most ArmA players).

A quake player would still feel it and hate it though

Share this post


Link to post
Share on other sites
also , Mbot, u said the AI took cover behind the stone wall. do u think it was on purpose that it was behind the wall or did the AI just lie down instantly and the fact that the wall was in front of the AI is pure luck? cuz i think it's the latter.

did u try and place the AI a few feet (may 30. maybe 60) away from the stone wall and see if it goes for it?

The AI definitely sees the low stonewall as cover, as it will sometimes move crouched sideway behind the wall until it is behind the tallest portion and remain there (at least for some seconds before moving on). I will repeat the test with the AI further away from the wall but my suspicion is, that it will flank immediately and use the cover of the wall temporarly if it is on its way.

Which waypoint is the most agressive, I have the impression that 'move/engage at will', 'search and destroy' and 'guard' are all about the same (very agressive). In case of guard I had the AI with low skill almost immediately flank each time. The impression that the AI with high skill would sometimes be a bit more defensive with a guard waypoint could also have been wrong. Perhaps it just decided to change the flank multiple times, which would explain the excessive latteral movement along the wall. It would eventualy run into to open in an attemt to flank anyway.

Share this post


Link to post
Share on other sites

MBot: try to give AI 'this enableattack false' code (on init-field) and give it 'open fire, engage at will' kind behavior on waypoint. If this is same as with ArmA then he won't engage you but will remain in cover and shoot you only if opportunity rises: you expose yourself to him.

Share this post


Link to post
Share on other sites
u said GUARD is a pretty statics and defensive. what is the opposite of GUARD? what is the WP u found that makes the AI to attack the hardest?

Please note that GUARD does not do what you think it does. It doesn't do what I think it does, either. ;)

This page describes it in detail (scroll down a bit), along with all the other types. There doesn't seem to be a particular defensive waypoint type.

In short: the GUARD waypoint actually results in the AI going after any enemies detected anywhere on the map. It's intended to be used with one or more "Guarded by" triggers - AI groups set to GUARD will go to the location of the first "Guarded by" trigger which is not occupied by another group with a GUARD waypoint. They'll then wait until an enemy is detected anywhere on the map. Then they'll go and attack that enemy.

If you use it without any "Guarded by" triggers, then they seem to wait at their current location and mount attacks from there.

But they don't guard. I don't think the game has defensive "hold this position" type AI.

Share this post


Link to post
Share on other sites
I tried setting up many missions in which HOLD waypoint are assigned to groups.

Thats because a hold waypoint isn't supposed to be a defend command. It just tells the group to stay where they are untill the enemy is detected and then engage.

However you are right. the A.I. are incapable of defending a position properly. A new 'Defend' waypoint added would be a welcome addition to the list. But, as people have said 'this enableattack false' is currently the only way I'm aware of. Oh, and 'this DisableAI "move"' so that won't go anywhere.

Share this post


Link to post
Share on other sites
A new 'Defend' waypoint added would be a welcome addition to the list.

Very much agree. Not only this, a more defensive approach should also go into the basic battledrill for offensive actions. Fist achieve fire superiority over the enemy (suppressing and fixing) and only then initiate flanking or an assault. If fire superiority can not be achieved, the attack should not be pressed.

Will have a look at 'this enableattack false' this evening.

Share this post


Link to post
Share on other sites
Thats because a hold waypoint isn't supposed to be a defend command. It just tells the group to stay where they are untill the enemy is detected and then engage.

However you are right. the A.I. are incapable of defending a position properly. A new 'Defend' waypoint added would be a welcome addition to the list. But, as people have said 'this enableattack false' is currently the only way I'm aware of. Oh, and 'this DisableAI "move"' so that won't go anywhere.

Sorry, but i can't agree on what a HOLD waypoint is supposed to do.

Here is the info i have (source = wiki: http://community.bistudio.com/wiki/):

This waypoint type will cause the group will move to and stay at this position indefinitely. Only a Switch type trigger or script command will move the group from the waypoint.

So it seems AI is not supposed to leave the position at all.

On the contrary we've verified they do leave the position .

It can be a bug or a documentation issue though.

About 'this enableattack false': i may be wrong, but as far as i know this isn't a working a solution, since the instruction simply disallow group leaders from issuing "attack" (= "engage") orders to fellows.

Set if leader can issue attack commands to the soldiers in his group.

That will not prevent the leader himself to engage individually (eventually with mates in formation).

Even setting "combatmode" = YELLOW (default / open fire) for the group will not prevent the leader himself from running into enemy.

At least we have to try that out in combination with "combatmode" = GREEN, but that's a risky option ...

In short the side effect of a 'this enableattack false' instruction is that units will now fall one by one like lemmings engaging enemy, this as soon as each one of them becomes group leader (as previous leader was killed engaging) ...

All in all also disable AI 'move' is not a real option, since enemy will act flanking manoveurs putting AI units out of cover and taking them out like sitting ducks.

:(

I'd like to see a "fixed" HOLD waypoint instead of a new "DEFEND" waypoint.

The problem is that the actual AI behaviour for "HOLD" looks pretty identical to the AI behaviour for "GUARD", as long as no "guarded by" triggers are defined.

Also AI units with "COMBAT" behaviour have big problems in properly keep into cover and that should be fixed ...

Edited by fabrizio_T

Share this post


Link to post
Share on other sites

Just tested it and like fabrizio_T already explained, 'this enableattack false' wont stop my lab rat from leaving cover.

Share this post


Link to post
Share on other sites

About 'this enableattack false': i may be wrong, but as far as i know this isn't a working a solution, since the instruction simply disallow group leaders from issuing "attack" (= "engage") orders to fellows.

And for that reason in OFP and ArmA you had to issue them Combatmode "red" (in other words open fire, egage at will). Reason being that they will go into cover and wait for engage orders... Which never will come. And this applies only if they have 'engage at will' issued as during then they will seek hiding places in contact... Otherwise they just keep doing those brainless things they do.

Dunno does this work in ArmA2, i don't own ArmA2... To be honest it didn't work in ArmA very well due .FSM related reasons which required quite much scripting to overcome and BIS didn't fix it ever. In OFP it did work quite well.

Edited by Second

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×