AI Discussion (dev branch)

[seba1976 98]

Yeah, but would things still go fubar if the AI FSM could detect that it is going fubar?

Well, detection of failure is usually easier than preventing it.

[2nd ranger 282]

Is it intentional that AI vehicle gunners slow the frequency of their bursts as their ammunition depletes? I think it's a good thing, just never noticed it. Infantry units should probably do the same thing.

Also, a random obsvervation: a guy using a TRG will fire single shots if a target is within approximately 50m, but beyond that he will switch to burst. Should it be the other way around?

[KeyCat 131]

Is it intentional that AI vehicle gunners slow the frequency of their bursts as their ammunition depletes? I think it's a good thing, just never noticed it. Infantry units should probably do the same thing.

Never noticed that, need to pay more attention I guess, cool if it's intentional

/KC

[rübe 127]

Never noticed that, ...

Yeah, me neither...

cool if it's intentional

I wouldn't be too sure about that, since this seems to be rather situational.

What if my guys have plenty of ammo (maybe in a box) right next to them? Still pleased to see them go slow on their shots?

What if my support vehicle (on ground or in air) is supposd to go in fast, deplete all its ammo to return to the base and reammo? Hanging around for longer, preserving ammo by not shooting too quickly could easily lead to disaster. :p

IMHO such stuff needs to be configurable in one way or the other.

[SaOk 112]

Is there any changes to get the pathfinding less demanding for performance? Have noticed from ArmA2 that especially planes bring FPS much down when those fly over towns. Would think there is some unneeded stuff running for planes then. Just throwing thoughts, else AI additions have been great. ;)

[2nd ranger 282]

What if my guys have plenty of ammo (maybe in a box) right next to them? Still pleased to see them go slow on their shots?

Well, that's moot since AI can't rearm by themselves. I wouldn't expect them to replenish their ammo in that situation anyway. However, if the AI could rearm themselves, then there wouldn't be an issue.

What if my support vehicle (on ground or in air) is supposd to go in fast, deplete all its ammo to return to the base and reammo? Hanging around for longer, preserving ammo by not shooting too quickly could easily lead to disaster. :p

True, that could be an issue. I haven't looked too deeply into it so I don't know if the behaviour can be prevented or if it applies to every type of vehicle. A remedy to that could be a functioning Suppress command.

I hope this isn't a bug though because I have recently found it useful to control a vehicle's burst rate for cosmetic purposes in a mission (continually resetting an armed offroad's ammo to a certain level so it will fire bursts at an interval I like, while retaining normal target acquisition ability). I'd like to see a command or subskill for controlling AI ROF, since as far as I know there isn't any non-hacky way of influencing it. In Arma 2, using a low value for the "aimingShake" subskill, or setUnitAbility, which I think did the same thing, would slow their ROF because they couldn't line up a shot. As far as I can tell in Arma 3, "aimingShake" doesn't do anything and setUnitAbility is obsolete. The only thing that really affects ROF now is setSuppression.

[oukej 2911]

subskill for controlling AI ROF

reloadSpeed

if the AI could rearm themselves, then there wouldn't be an issue.

It is currently bugged - http://feedback.arma3.com/view.php?id=22452

[2nd ranger 282]

Is there some specific set of criteria for using reloadSpeed, because I just tested it and it didn't do anything. At least, it didn't alter an AI rifleman's ROF at all. Or a Hunter.

[froggyluv 2136]

Also - I don't think the sometimes mentioned "force-move" action would be a good-enough solution, solid and universal. The default state should be a cautious AI that values its life, but not an AI that's lagging behind or even getting stuck.

Force move as a qualifier would be great though such as 'Cntrl-f2' meaning be expedient. We need this and the AI need it as well as shown in video below -yeah its a little long winded but didnt feel like editing on a Sunday

[rübe 127]

We need this and the AI need it as well as shown in video below -yeah its a little long winded but didnt feel like editing on a Sunday

That was a nice video/scenario and I think it drives your point home rather nicely: a group needs to have at least a very rudimental idea of the situation... and then a plan - which basic AI groups currently are lacking if surprised/under attack in the open.

And I think the solution you're hinting at would be already good enough: awareness of forces/feasibility/survival-chances and a toggle between defensive and offensive mode. The firmer goes for safety and cover (running(!) for cover, digging in, garrison buildings, ...), while the latter involves steady movement (towards some objective, with bounding box dance and that kind of thing).

Question: do any of the current main-modes (or combinations thereof) allow to model defensive and offensive behaviour? If not, where are the problems? What's lacking (just that "haul your ass already!"-command? Btw. your own guys arrived in/garrisoned that building just about fine, eh)? Would an additional (tactical/ROE/something) mode make sense? Because... certainly you wouldn't want some group go garrison buildings, if they're supposed to move (flee to?) somewhere else (i.e. this could be a bigger showstopper than the danger dance, if just applied to any group).

Hence, I'm not sure how much of such "clever" behaviour should be implemented/active by default for a group, and if it wouldn't be wiser to plug-in custom FSM per group (and as needed) to do that kind of thing. On the other hand, a human leader most certainly could need such an official "garrison that building" command, which brings me to your next point:

The second point you make is another thing for which the time might have finally come: better indoor behaviour!

IMHO the current thing with the building positions and paths is okay to go in, search and clear a building. But that's where it stops, and again we end up with an "offensive" mode only, completely lacking the "defensive" counterpart. Currently it's next to impossible to efficiently garrison (and defend) a building with AI: those building positions might be nice to hang around, but most are not suitable fighting positions (maybe with the exception of a bunch of dedicated watchtowers).

I know, I know, bipods and weapon resting are not ment/designed for AI. Fine. But I have to wonder if this new functionality (i.e. the detection of suitable walls/geometry to rest your weapon on) couldn't be (at least) leveraged to offer exactly these "defensive"/"fighting" positions in buildings (or any structure in general)?

From what I understand, such suitable places are detected dynamically? Wouldn't it be easy to calculate them before packing a pbo (in addition to hardcoded building positions) and bake them into the buildings once? Then make them available ingame, which might allow for an effective "garrison building" command?

In order to implement proper "defensiv" behaviour, shouldn't AI have access to all positions that'd be suitable for weapon resting? Not for the bonus of having the weapon rested, but for the cover exactly these positions offer, while still being able to return fire, or see/observe stuff in the first place.

[oukej 2911]

... meaning be expedient.

We are considering similar approaches (modifiers, modes...). In a way that we preserve an AI that is cautious and values its life but make the AI more soldier-like when following orders at the same time. That being said - executing orders correctly and promptly has a higher priority. On the other hand we face couple of limitations in how far we can go with the changes (e.g. radio protocol).

And - nice video!

It also shows an issue with the behavior (formation) FSM, which - admittedly - has some of it routines severely bugged (AI falls behind, has problems finding a good cover, gets stuck in a cover). Fixing and improving it is currently a priority job.

[Variable 322]

We are considering similar approaches (modifiers, modes...). In a way that we preserve an AI that is cautious and values its life but make the AI more soldier-like when following orders at the same time. That being said - executing orders correctly and promptly has a higher priority. On the other hand we face couple of limitations in how far we can go with the changes (e.g. radio protocol).

And - nice video!

It also shows an issue with the behavior (formation) FSM, which - admittedly - has some of it routines severely bugged (AI falls behind, has problems finding a good cover, gets stuck in a cover). Fixing and improving it is currently a priority job.

Encouraging news! Thanks for keeping us posted Oukej.

[froggyluv 2136]

Btw. your own guys arrived in/garrisoned that building just about fine, eh)? Would an additional (tactical/ROE/something) mode make sense? Because... certainly you wouldn't want some group go garrison buildings, if they're supposed to move (flee to?) somewhere else (i.e. this could be a bigger showstopper than the danger dance, if just applied to any group).

Hence, I'm not sure how much of such "clever" behaviour should be implemented/active by default for a group, and if it wouldn't be wiser to plug-in custom FSM per group (and as needed) to do that kind of thing. On the other hand, a human leader most certainly could need such an official "garrison that building" command, which brings me to your next point:

The second point you make is another thing for which the time might have finally come: better indoor behaviour!

IMHO the current thing with the building positions and paths is okay to go in, search and clear a building. But that's where it stops, and again we end up with an "offensive" mode only, completely lacking the "defensive" counterpart. Currently it's next to impossible to efficiently garrison (and defend) a building with AI: those building positions might be nice to hang around, but most are not suitable fighting positions (maybe with the exception of a bunch of dedicated watchtowers).

The AI moved suprisingly fast to that building and actually leave pretty quickly as well - no stuck units etc after many tests even with the large group. AI should also be able to have a chance at identifying a large enough structure to send their units for quick defense, fortify etc.. Sure we might get some wonky behavior for a while, but doesn't even wonky attempted fleeing behavior trump the current 'dance and die'? I'd much rather see the AI attempt such a maneuver than basically just take it up the A** like they do now. Buildings might be easier then giving them an awareness out in nature, such as what constitutes The Woods and such.

Ive always been on board the indoor behavior needing an overhaul but right now even if we can just get them indoors quickly would be nice. Maybe give them a 'crouch' order by default while under imminent threat as they did sometimes get tank blasted thru the windows while they had their backs to the windows. Hopefully in Expansion all windows and doors have a building position as there's little reason not too and maybe fallback positions as well 'offensive/defensive'.

We are considering similar approaches (modifiers, modes...). In a way that we preserve an AI that is cautious and values its life but make the AI more soldier-like when following orders at the same time. That being said - executing orders correctly and promptly has a higher priority. On the other hand we face couple of limitations in how far we can go with the changes (e.g. radio protocol).

And - nice video!

It also shows an issue with the behavior (formation) FSM, which - admittedly - has some of it routines severely bugged (AI falls behind, has problems finding a good cover, gets stuck in a cover). Fixing and improving it is currently a priority job.

Staying in good cover is also needed though I'm sure that gets messy with all the formation stuff. You guys really need to start a new Underground Dev Branch in which you just get downright nasty and nuts with testing new AI functionality. Too much qq and tears when progress meets setbacks by too many people with current Dev model -like they expect forward progress all the time...Im sure many here would be more than ready and willing for a 'Dirty Nasty Dev Branch' for the sake of AI.

[old_painless 182]

Right, a black ops dev branch only with Ai changes !

[froggyluv 2136]

Right, a black ops dev branch only with Ai changes !

1st rule of AI Fight Club - there is no AI Fight Club..

[old_painless 182]

Hehe, good quotes (from great movies) aside, froggyluv's suggestion is really clever: given that BI apparently prioritizes AI improvements, a good way to isolate the effect of those changes from anything else happening on dev branch would be to branch out from the dev branch and only change AI routines (and whatever else follows as necessary).

There would be plenty of testers available, given the subject, and if - at a future point in time - the AI is seen as better or satisfactory, BI then has an available changeset that can be carefully merged back into the "main" dev branch.

[Guest]

Imo, scripting commands that provide control over certain potential new behavior types of the Ai would have significant value. Especially when it comes to any kind of universal integrated behavior that does things like sends units into nearby buildings - I see clearly big issues with missions being made where the mission maker is trying to get a group of units (or a unit) to move to a position within a base or town due to certain conditions (or to stay at position), and instead the units end up inside buildings due to combat conditions with no control over it. The take cover stuff would be nice to have a script command to turn it on or off as well for groups. The more ai stuff that is integrated without a method of control, the more out of control the Ai becomes when one needs that control to create missions that sometimes require a level of control over certain Ai units during various scenarios that often involve scripted actions. In my experience it's always easier to include on/off switches in code during the implementation of various content than to attempt to come back later and do it.

Edited May 27, 2015 by Guest

[das attorney 858]

I need a bit of clarification here guys as I'm unsure on the current state of play.

If I need AI to not waver in their task and run off, I would set their "courage" to maximum

{
_x setSkill ["courage",1]
} forEach _someGuys;

But if I do this, am I also inadvertently saying that I don't want them to be suppressed?

Basically, I would like AI to not run off but also be suppressed when shot at. I am already setting _grp allowFleeing 0 as well, so I'm not sure how many other ways I can communicate to them the same information.

I seem to remember the devs tying courage into suppression resistance. Am I wrong in thinking that?

Thx in advance

[rübe 127]

I am already setting _grp allowFleeing 0 as well, ...

Wait, ...and that does not do the trick? :(

And now I'm wondering... is allowFleeing just syntactical sugar for setSkill courage? Or is this supposed to do something completely different (that might have gotten broken at some point along the way...)?

[fn_Quiksilver 1636]

What is the behaviour like currently which needs tweaking?

unit addEventHandler ['Hit',{_this select 0 setSuppression ...}];

[oukej 2911]

Courage sub-skill affects fleeing and morale in combat (incl. resistance to the suppression). AllowFleeing is just about the fleeing.

[das attorney 858]

Thx for checking, so it would sound like I need courage = 0 and allowFleeing 0 so they get suppressed but don't flee.

I'll keep an eye on them though to check courage 0 doesn't override allowFleeing 0 and make them want to flee (which is undesirable for what I need from them).

[h - 169]

oukej, does rain affect the vision/spotting abilities of AI with NVG?

Because a human player at pitch black night with NVG and full overcast+rain (well, rain above like 0.6) can't really see much but the AI seems to spot targets as it was pure daylight w/o NVG....

[Guest]

Does this mean that Courage set to 1 effectively disables any sort of take cover/garrison building reaction to combat for AI?

[das attorney 858]

I'm not noticing any suppressive effects for any units I'm testing.

I can stand in front of them unloading rounds at their feet and they continue to fire back at me with no change.

Here is the skillFinal printout of the units I'm checking:

 6:22:08 "horde_fnc_enemyUnitSkills" - unit skills: O Alpha 1-2:1"
6:22:08 "horde_fnc_enemyUnitSkills" - aimingAccuracy: 0.09125"
6:22:08 "horde_fnc_enemyUnitSkills" - aimingShake: 0.09125"
6:22:08 "horde_fnc_enemyUnitSkills" - aimingSpeed: 0.92"
6:22:08 "horde_fnc_enemyUnitSkills" - commanding: 0.92"
6:22:08 "horde_fnc_enemyUnitSkills" - courage: 0.014"
6:22:08 "horde_fnc_enemyUnitSkills" - endurance: 0.92"
6:22:08 "horde_fnc_enemyUnitSkills" - general: 0.014"
6:22:08 "horde_fnc_enemyUnitSkills" - reloadSpeed: 0.92"
6:22:08 "horde_fnc_enemyUnitSkills" - spotDistance: 0.52"
6:22:08 "horde_fnc_enemyUnitSkills" - spotTime: 0.52"
6:22:08 "----"

And here is a printout of this units getSuppressed value as I'm shooting at him:

 6:25:23 "bloke O Alpha 1-2:1, supp 1.11324"
6:25:24 "bloke O Alpha 1-2:1, supp 0.989661"
6:25:24 "bloke O Alpha 1-2:1, supp 0.993921"
6:25:25 "bloke O Alpha 1-2:1, supp 0.996402"
6:25:25 "bloke O Alpha 1-2:1, supp 0.997932"
6:25:26 "bloke O Alpha 1-2:1, supp 1.11417"
6:25:26 "bloke O Alpha 1-2:1, supp 0.989744"
6:25:27 "bloke O Alpha 1-2:1, supp 0.994748"
6:25:27 "bloke O Alpha 1-2:1, supp 0.997932"

But as I mentioned, it doesn't alter his fire rate/accuracy etc. Is anyone else finding similar things?

edit:

Also, I read this:

New danger cause DCBulletClose in danger FSM.

And then checked the danger.fsm, but I can't see it as a danger cause anywhere. They seem to be only 0-8 and DCBulletClose is listed as 9 but I don't see any mention of it save for a comment:

/*
comment "0  DCEnemyDetected";
comment "1  DCFire";
comment "2  DCHit";
comment "3  DCEnemyNear";
comment "4  DCExplosion";
comment "5  DCDeadBodyGroup";
comment "6  DCDeadBody";
comment "7  DCScream";
comment "8  DCCanFire";
comment "9  DCBulletClose";
*/

Edited May 30, 2015 by Das Attorney