Jump to content
madrussian

Disabling “AUTOCOMBAT” for AI-only groups (Issues & Solutions)

Recommended Posts

I’m happy BIS introduced the ability to disable AI component “AUTOCOMBAT” a while back (via disableAI command).  It’s quite useful in getting the AI moving and avoiding getting bogged down in COMBAT, but apparently only in very specific circumstances for AI-only groups.  Like getting the AI to run somewhere fast (as in flee) and while not stopping to shoot back at any enemies.  Old Painless has an excellent formula for exactly this case that he detailed over on the Dev Branch AI thread.  It really works great in my tests!

 

My dream is a little different, but seems like it should be doable:

You know how as a player (leading our AI group), we can move around and our AI will keep up formation and shoot at the enemy, scooting along and shooting as they go?  That is, until they sense a certain level of danger and all go into COMBAT?  Even before we had ability to disable “AUTOCOMBAT”, this has always been possible for player-led groups.  For lack of better terminology, I’ll call it AWARE scooting with shooting.

 

Seems like this same thing ought to be possible with an AI as group leader (especially now that we can disable “AUTOCOMBAT”).  Here’s what happens when I try it.

 

First, I disable “AUTOCOMBAT”, like this:

{
  _x disableAI “AUTOCOMBAT”;
} foreach (units _group);

Good to go so far, give that AI-only group a WP and they happily move toward it.  When they discover an enemy, they (sometimes some, sometimes all) stop, turn and fire, as expected.  And here’s where the trouble starts.  When the enemy is neutralized (or teleported away), the stopped AI don’t start moving again.  Often, they don’t start moving again ever.  It doesn’t matter what code I run on them to try and get them moving again.  I tried all this:

{
  _x doWatch objNull;
  _x forceSpeed -1;
  _x stop false;
  _x disableAI "TARGET";
  _x disableAI "AUTOTARGET";
  _x disableAI "COVER";
  _x disableAI "SUPPRESSION";
  _x enableAttack false;
  _x doFollow (leader _group);
} foreach (units _group);

(in various combinations / orders)

 

They start moving again for a moment and then stop again.  (which makes me think maybe the AI group leader is ordering them to stop again repeatedly).

 

I tried disabling various AI components of all subordinates before they ever find an enemy to begin with.

I tried disabling various components of specifically the group leader’s AI, including “ALL”.

I tried using a game logic as the leader of the group.

 

[I did notice that the stuck guys do "Return to Formation", if the group leader comes close to them at some point in the future.  (Obviously, this isn't a practical solution though for real-world missions.)]

 

Eventually, I used marks to track the expectedDestination (composed of [position, planningMode, forceReplan]) on each of the units, and noticed that all the units (including the stuck guys) are where their expectedDestination wants them to be at (which makes me think maybe the group leader is ordering them to those locations).  I also noticed the stuck guys are in their own formation, distinct from the moving guys formation (even though they are all in the same group).  [I’m using an automatic marker system to view and track all this.]

 

I experimented with using FSMs to modify their expectedDestination, and those stuck AIs stayed stuck.

 

For the life of me though, I can’t get those stuck guys moving again!

 

The one thing that works is to disable their native FSMs via:

_x disableAI “FSM”;

But then they only move, and don’t turn or stop to shoot at enemy.  (Which turns out to be similar to Old-Painless’s cocktail from the AI dev thread mentioned above, useful but not what we’re looking for here.)  I don’t want to write a full-blown FSM to do targeting, cover, etc  (although it would really just be targeting and moving, as cover seems to apply only to Combat mode).  I want to piggy-back off the native solider combat and formation FSMs, and let those do the stopping / shooting, but unfortunately those FSMs don’t seem to account for an AI-only group with “AUTOCOMBAT” disabled.

 

Steps To Repeat:

  1. Create an AI-only group in the editor
  2. Disable “AUTOCOMBAT” on all units in the group (via disableAI)
  3. Give group a waypoint semi-far away
  4. Give group a temporary threat, ideally small threat that AI-only group will shoot at but which won’t shoot back (I was using myself as the different-side player with allowDamage false, teleporting in, getting them shooting at me, then teleporting out).
  5. Fire up mission.
  6. Observe, AI-only group moving towards WP normally
  7. Have AI-only group run into temp threat, observe AI-only group stop and shoot at enemy.
  8. Observe AI-only group remains in AWARE mode and does not enter COMBAT mode, as expected.
  9. Have threat be eliminated (or disappear or get teleported away, etc).
  10. Observe stuck AI-only group units (whoever stopped to fire when threat was present)
  11. Experiment with dozens or even hundreds of commands (in various combinations) to try and get stuck AI to “Return to Formation” and resume movement quickly

 

This type of Ai-only Aware-only scoot-and-shoot would allow AI to cover ground more quickly (much like the player can) and would be awesome for all sorts of missions!  I feel like we were let down a bit, regarding the (implied) promise of disabling “AUTOCOMBAT”, as it doesn’t seem to work out-of-the-box with AI-only groups.  (Best outcome - I'm not sure whether this is really a bug per say, but maybe BIS can provide a quick fix?)

 

I know it’s a long shot, but has anyone got anything like this Ai-only Aware-only scoot-and-shoot working?  Any ideas?

(P.S. I’d be very happy for now with a way to simply get the stuck guys to “Return to Formation”.  Thanks!)

Share this post


Link to post
Share on other sites

1. Make a simple demo mission and submit to the A3 feedback tracker

2. Did you play around with activating AUTOCOMBAT again (on and off and on and off)?

Share this post


Link to post
Share on other sites

[KJU, I’d love to write something up, provided I can gather enough info about what exactly is going on, and simplify the repro enough so that it’s useful.]

 

OK, I’ve refined the experiment, run dozens more iterations, and learned several new things.

 

First off, I’m running these exact lines every time now to prep the group (8-man group on foot, given a distant WP).  As written, these two lines are perfect for pinpointing the issue:

{
  _x disableAI "AUTOCOMBAT";
  _x enableAttack false;
} foreach (units _group);

 

The enableAttack false line is key, because it eliminates the AI leader ordering his men into the vicinity of the perceived threat.  Based on my testing, AI leaders will issue these move orders even in Aware-only mode (with “AUTOCOMBAT” disabled from the beginning and throughout).

 

I learned that the “stuck” guys I was referring to above are really not getting permanently stuck.  They are, however, upon detecting a threat and picking out a target to fire on… waiting an extraordinarily long time!  They are waiting a random amount of time, sometimes 370 seconds and longer, whether there is anyone to shoot at or not.  That’s fully over SIX MINUTES, and here the kicker:  This seems to be the exact maximum amount of targeting wait time as for units in COMBAT mode.

 

Only these units are not in combat (AUTOCOMBAT==false), and thus they are not doing anything interesting (like taking cover, etc), so it looks very strange and gives the perception of them being stuck and broken.  Imo, this max targeting wait time for units in AWARE mode needs to be more like 5-10 seconds.

 

[Side note – I verified the max targeting wait time is not based on knowsabout of the target.  They had knowsabout of the target (me, who teleported away) of 4, long after they timed out and returned to formation.]

 

Whoever in the group perceives the threat stops, turns, and starts shooting.  Sometimes that includes the group leader and sometimes it doesn’t.  When the group leader stops, no one is moving on to the WP for up to 6 minutes (whether there are any enemies present or not).

 

When some subordinates stop but the group leader keeps going, the group gets split up, and the subordinates are left behind in one or more subformations.  Each man (that initially detected a threat) waits his full random 6 minutes (regardless of enemy presence), and one by one, they time out, move on, and form up on their correct man… who is often long gone by this time.

 

[KJU, here’s where I did experiment with turning AUTOCOMBAT on and off (and thanks for that tip btw).  I learned this seems to have absolutely no effect on the lengthy 6 minute max targeting delay.  Let me repeat that.  Units in COMBAT incur a random max stopped delay of 6 minutes.  This is the same as for such units held in AWARE mode via disabling auto-combat.  Also, that delay didn’t seem to increase or decrease when I turned on and off AUTOCOMBAT on-the-fly.  I did notice one difference with combat mode though:  Units in combat mode that are not in “max six minute delay” leave their subformation and rejoin the main group.  Units in aware-only mode that are not in “max six minute delay” line up in their subformation.]

 

Again, I would expect an AI-only group in AWARE mode (with auto-combat disabled) to behave more like a player group in AWARE mode, and not have part or all of the group get bogged down as if they were in full COMBAT mode.

 

In short, as it stands:  Placing an AI-only group in AWARE-only mode (via auto-combat disabled) removes the “Go, I’ll cover” and cover mechanics, as expected.  However, sadly this (disabling auto-combat) does nothing to address the lengthy combat-like bog-down targeting delay from the native FSM(s)  [formation and/or danger FSMs].

 

Seems like there might be a quick fix for this:  If in AWARE mode + AUTOCOMBAT disabled + AI leader, reduce stopped targeting time significantly, to something more like 5-10 seconds.  This would be a fix to the native FSMs, would really get these AI-only groups moving, and be a great asset for mission creators!

 

(Best case, BIS provides us control of the min and max length of AI stopped targeting time, under various conditions (aware, combat, player-led, ai-led, etc).  This would make for some amazing new mission possibilities!)

 

If anyone is interested, I can snap some screenshots of what’s going on, to further illuminate the problem.

Share this post


Link to post
Share on other sites

My assumption would be, if I understood you correctly, that you run into a case in the AI fsm that is either not reached at all usually or only very rarely (or not obvious for other reasons).

Now that cases seems to have an exit condition that is not getting met, and thus they are stuck until the threshold (said 6 minutes) is reached and then the FSM is exited.

Share this post


Link to post
Share on other sites

I understand what you're saying (I think), and that's certainly possible.  Looking inside those FSMs, it appears the danger ones do a single pass through (and end), and the formation ones loop.  Inside "characters_f.pbo", I was able to dePBO native civilian formation and danger FSMs, and native soldier danger FSM and have a look.  The most frustrating part seems to be:

 

The native soldier formation config, instead of a path to a file-based FSM like the others, it looks like this:

fsmFormation = "Formation";

Which seems to point to:

CfgFSMs >> “Formation”

That config entry appears to simply list the relevant functions, which I assume are hard-coded.  Thus it appears we can’t see the code inside the (arguably) most important FSM!

 

Regarding that 6 min targeting delay, I should stress that that’s a maximum.  I've seen guys return to formation in as little as 35 seconds up to 370 seconds and everywhere in between.  So it didn't necessarily seem like it was a constant 6 minute timeout thing.  More like possibly an intentional random delay with 6 minutes as the max value.  (In any event, it certainly could be hitting a timeout somewhere in there as well.)

 

It occurs to me, considering that the 6 minute max targeting time delay applies using both normal COMBAT mode and AWARE-only mode, that perhaps this targeting delay was designed with COMBAT mode in mind (where there’s a lot more going on like taking cover, etc), and the delay simply doesn't really carry over well to AWARE-only (combat-mode disabled) mode.

 

My other thought is that the native soldier formation FSM might be checking whether a group is player-led, and if so treating the group differently (via different delays, etc).  Wish I could see the code inside that FSM (see above) to know for sure.

Share this post


Link to post
Share on other sites

Not all AI "FSM" are exposed to FSM format from what i understand. There is still lot of behavior code written in c++ (but at least partially also of FSM design).

  • Like 1

Share this post


Link to post
Share on other sites

That makes sense that much of the AI is hard-coded in c++.  There's actually not a whole lot going on inside those "characters_f.pbo" fsm files, certainly not enough to explain much of the AI's behavior!

 

  • Like 1

Share this post


Link to post
Share on other sites

Hey @madrussian, thanks for taking this on and documenting it thoroughly.  Please do send it to the A3 feedback tracker.  This problem has plagued us all forever.  In my Property of Mabunga mission, I set up the East and West rescue teams to search the swamp area via sending them to a series of marker positions (if the team was not lead by a player).  It pissed me off that they would be so slow after first combat contact.  I ended up making my own script to disableAI FSM and send them in 100m increments towards next marker.  I would send group leader first, and then calculate positions around him to send the remaining group members (this could be extended to mimic formation positions BTW).  They would then wait 30 seconds or so at each movepoint, before sending them to the next one.  This worked pretty well, but has the disadvantage of units not turning and firing properly while FSM is disabled. But they will engage enemies ahead of them.  And they would engage somewhat during their 30 second pauses.  Once their search pattern put them within 150 meters of an enemy pirate camp, I would stop the movement script, reenableAI FSM, and give them a Move waypoint at the pirate camp.  Their normal combat behaviour was then active for the assault on the camp.

 

I wonder if you toggle DisableAI FSM periodically you can get a better result.  When not in Combat mode, you disableai FSM to get them moving.  When contact occurs, re-eanable FSM until NearEnemies is zero.  Once skirmish is over (nearEnemies zero), disableAI FSM again so they move to next wp.  Its sad we have to go to these lengths though, so I hope BIS can fix it.

 

If your analysis revealed there is a timer on "waiting time before safe to move again", then maybe it could be an easy fix for BIS.

 

  • Like 1

Share this post


Link to post
Share on other sites

hi madrussian, just wanted to add that you seem to work from what I found out back then:

 

  1. You first have to stop the commander of the team from (constantly) sending new targets to his subordinates
  2. then disable the individual units from acquiring targets on their own, including the commander

Once these two things are covered, the units should be able to move freely. Which they would not otherwise do, since they would constantly get or acquire a target and thus enter combat mode. My sequence of commands was this:

 

{
  _x commandWatch objNull;
  _x disableAI "AUTOTARGET";
  _x disableAI "TARGET";
  _x disableAI "SUPPRESSION";
  _x disableAI "AUTOCOMBAT";

} forEach units group wz_g1;

It matters if the commands are in this exact sequence - for some reason eg. switching two of them may lead to poor results. As far as I can tell from your posts, you may not have this exact sequence running? Note that the commander is also part of the units set that get this command, so there should not be a reason to run separate commands for him. I remember trying separate commands for the commander, but AFAIR that was not important in my case.

 

-OP

Share this post


Link to post
Share on other sites

OK, this is crazy… So I sat down to write a more concise repro mission for AI-only groups getting stuck in AUTOCOMBAT to submit to the feedback tracker (had to wait for 1.68 to download)… and low and behold seems they fixed it as of v1.68.  Please somebody confirm this is really true, seems BIS fixed the problem!!!

 

It’s funny, while 1.68 was downloading, I read through most of the changelog.  Lots of great stuff in there but I didn’t happen to see this.  In any event, if it’s really so thank you devs!

 

@Johnnyboy, I played your Property of Mabunga mission a couple months ago, very well thought out and great concept btw.  And I was wondering at the time why often the baddies weren’t turning to shoot at me.  Ha, that explains it!  Hopefully you should be able to pull out that “disable FSMs” part now.

 

Thanks again Old Painless for spearheading getting this working properly.  Can’t wait to see what mission creators are going to do with a full-blown working disable of AUTOCOMBAT.

 

Anyhow, if I’m on crack or asleep someone pinch me to wake me up from this nice dream I’m having.

  • Like 2

Share this post


Link to post
Share on other sites

I hope you're right about 1.68 fixing this.  But I just read the changelog thoroughly (and search for "combat" and "ai") and saw no reference to this fix. 

Share this post


Link to post
Share on other sites

Roger that, it's a bit perplexing.  Maybe they put it in as an Easter Egg.  Please when someone gets a few minutes to sit down and try it out, let us know how it goes... good or bad.

Share this post


Link to post
Share on other sites

I used:

{_x disableAI "AUTOCOMBAT"} forEach units _my group; {_x disableAI "COVER"} forEach units _my group; {_x disableAI "TARGET"} forEach units _my group; {_x disableAI "AUTOTARGET"} forEach units _my group;

 

it should work

Share this post


Link to post
Share on other sites

@wiki player group is different. its about non player groups

Share this post


Link to post
Share on other sites

yes, but you can replace the "_mygroup" with whatever groupname you want.

Share this post


Link to post
Share on other sites

@wiki

the bug happens only with non player groups

Share this post


Link to post
Share on other sites

Real quick, here's exactly what I was doing (seeing AI get stuck in 1.66 and everything seemingly going smoothly in 1.68).  Latest repro if you will:

 

(Of course, make sure you are running in vanilla with no mods loaded.)

 

1. Have player be single West guy.  Call this on player:

player allowDamage false;

2. Place East group in editor away from player, give them WP far away.  Call this on them:

{
    _x disableAI "AUTOCOMBAT";
    _x enableAttack false;
} foreach (units _group);

3. Write something quick to monitor units on map (loop moving markers, drawIcon or similar) so you can see what east group units do, and (optionally) where the player is.

4. Start mission.  Open map.  Keep map open, do everything from map.

5. Observe east group moving normally to WP.

6. Teleport into the middle of east group (using alt-click in editor, which appears to be built in way to teleport in SP editor).

7. Wait a second or two until guys are shooting at you, and teleport back out to somewhere they can't possibly see you.

8. Observe on map whether the guys that were shooting at you, (quickly) return to formation and continue towards WP.

 

If some of them stay in place for a very long time (up to 6 minutes), you've reproduced the problem.

If they all get back to moving pretty quickly, this particular issue is... resolved!


Disclaimer, this may only test a portion of the potential issues with disabling AUTOCOMBAT in an AI-only group.  But if this one is indeed solved, that's a very big deal indeed!

  • Like 1

Share this post


Link to post
Share on other sites

I haven't really experienced the 6 minute zombie state, thankfully -  but so much more great if that has been fixed. Perhaps your investigation attracted some attention :smile_o:

  • Like 1

Share this post


Link to post
Share on other sites

@madrussian i hope you dont mind resurrect this topic :don13:

(as i am back into AI related stuff after some years)

 

is this resolved for good as you seem to have experienced?

 

PS: what is the best resource, chat or mod/mission to learn about controlling AI well these days?

(player lead or AI lead groups, also is many single AI groups still "better" to control vs multi unit AI groups?)

  • Like 2

Share this post


Link to post
Share on other sites

@.kju  I'm glad you did!

 

So I just doubled-checked by rerunning my original test (see above).

 

Quick history for anyone catching up:

Spoiler

I was extremely excited about disableAI "AUTOCOMBAT", but upon applying it to all AIs in an AI-led group, I was getting what appeared to be completely stuck AI units.

 

Here was the simple test mission:  With one group of 8 AI east CSAT men moving towards a distant WP, I make myself (NATO man) invulnerable via allowDamage false and teleport myself in amougst them, get them firing at me, and teleport myself back out.

 

When I originally encountered this problem (March 2017), every time I ran this test (using disableAI "AUTOCOMBAT") I observed some of the guys split off into their own subgroup and basically stopped (seems like cold in their tracks as memory serves), and waited for up to 6 minutes (very bad).  Subgrouped guys would still fire at me if they saw me.  If I waited and let the main group move on a bit, I could teleport in, get them firing at me again, and then teleport back out, and another subgroup would (usually) split off (and get stuck too).

 

Then with version 1.68 of game, I observed this unwanted stopping (of subgroups) had ceased to occur!  I checked it over and over again and as far as I could tell it simply wasn't happening anymore, and thus I declared it fixed.  (Even though as mentioned there was nothing in the change log at the time about it being fixed.)

 

Fast forward to present day ...

 

EDIT: 

Yesterday, I errantly posted that this stopping problem was back.  Please see my next post for updated/correct information.

 

On 7/2/2018 at 5:24 AM, .kju said:

PS: what is the best resource, chat or mod/mission to learn about controlling AI well these days?

 

Your mileage may vary, but I know I personally wouldn't have any chance making sense of most AI related matters (especially issues like this one) without a good map-based unit/group monitoring system, that importantly draws all it's icons on the main map (for ease of use).  I developed such a system for general purpose, which I codename Marker Command.  In addition to monitoring all units/groups, you can select any group on the map (again, the main map) and add/remove/move/delete their WPs.  Then you can enable/disable group visibility & control individually per group.  And you can display groups as group icons or as unit icons with lines connected to leader (like in the editor), individually per group.  This system is central to my dynamic mission and close to release-worthy, but lol not quite there yet.  You may use it if you like (just send me a quick PM).  Anyhow, I'm sure someone has something similar and quite possibly better already released.

 

On 7/2/2018 at 5:24 AM, .kju said:

(player lead or AI lead groups, also is many single AI groups still "better" to control vs multi unit AI groups?)

 

If I understand what you're asking... Let's see, for the most part I keep AI grouped.  If I'm going to try sending them into buildings, I definitely put each guy in his own group.  In my dynamic mission, I keep each vehicle's crew in separate groups, so they have a chance of getting where they are going, given Abysmal state of AI-driving since 2016 change.  Also, when I want the AI guys in my own group to get somewhere fast, I give them move orders individually.

 

I hope some of that made sense / maybe helped. :smile_o:

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

[Anyone who may have read me saying the stopping problem had come back, please strike that, reverse it.  Apparently I had forgot the enableAttack false part (in my test), which of course is the key.]

 

Everything in-game is working as advertised (apparently since 1.68).

 

This is all it takes to get your AI-led AI-only group moving in proper scoot-and-shoot fashion:

{
    _x disableAI "AUTOCOMBAT";
    _x enableAttack false;
} foreach (units _group);

 

By default enableAttack for groups is true, which causes the AI group leader (upon contact with enemy) to order his men to move out in subgroups.  Once these subgroups get where they are going, they wait for a (often very) long time before they abandon their subgroup and follow the group leader again.  This can give the impression that they are perhaps permanently stuck, given that you'd disabled AUTOCOMBAT on all members in your AI-only group, with the intent to have them move quickly.

 

You can monitor subgroups via formLeader on each of the group's units.  So when you use enableAttack true, upon contact there will be multiple subgroups.  When you use enableAttack false, there will only ever be one subgroup.

  • Like 1

Share this post


Link to post
Share on other sites

@madrussian thanks a lot for the update, additional info and insight!

 

Some more context for enableAttack:

https://forums.bohemia.net/forums/topic/122529-a-solution-to-improving-ai-group-fighting-ability/

 

In the Blitzkrieg game mode I use single unit groups to have full control over movement, behavior, etc and to avoid any engine coded group dynamics.

With the new sqf cmds available in A3 it might be possible to get decent result with AI groups, yet for my purpose probably not worth the effort to dig into all the details again.

 

However will see about disabling autocombat and when this may entail in my context.

  • Like 2

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

×