HETMAN - Artificial Commander

[euly 0]

I realize that vehicular accidents are mostly due to the game (as they've always been, even back in OFP days), but what I'm talking about is the formations and mode of travel. Even if I spread the groups out to keep them away from vehicles, they tend to run into each other in the process of moving to waypoints, which is why I picked-up on SLX because one of it's features is having the AI walk along the side of the road(?). I'm fairly certain that HAC could attempt to separate vehicle paths (not to extreme levels though), so tracked armor wouldn't have the high probability of vehicular manslaughter every time they drive by a squad walking down the road. I don't know, I'm fishing for ideas here on how to solve a problem I see way too often. If HAC can do things like avoid sending tanks into wooded areas, couldn't it avoid heavily trafficked roads?

I'm using the standalone SLX because Gunter hasn't put COSLX or CoWarMOD on Six Updater yet. I know I sound like a total noob with this stuff, but I've just been doing it too long without getting deeper into writing code. I didn't take the time to learn more scripting in my early 20's (with OFP), so now I'm paying the price.

[Rydygier 1330]

If HAC can do things like avoid sending tanks into wooded areas, couldn't it avoid heavily trafficked roads?

Method, that makes possible first thing (choosing target point in area of given topography/terrain) will not make possible the second one (pathfinding with traffic factor, route forcing etc). Such thing, interesting however, will need, I suppose, quite heavy scripting (constatly active "crowd" searcher or something). Sorry, if I disappoint, but not see, how this may be done in reasonable way. Also this is really not HAC's focus, such things. HAC will not to replace/fix vanilla AI behaviour, it is not an unofficial patch, that will repair everything and change Arma in something perfect. HAC is "only" a "waypoint giver", and how groups will fulfill own waypoint orders - this is another story. A fundamental HAC principle... And he gives only target waypoints (with one exception), so also pathfinding between start and end point isn't his concern. HAC assumes, that groups will act reasonable, and gives them orders with this assumption - it simulates commander of trained troops, not a babysitter for mindless idiots, that must be hand-holding, step by step... And if troops in Arma, especially drivers, often acts like drunk idiots... well, pity&shame. If I will try to do such AI driving/pathfinding fixes someday, then this will be separate addon, especially, that issues, that we are talking about, can be with every new patch changed/reduced/removed, which will make all made fixing work futile.

In other words: yes, technically, probably is possible, via combat mode, to make, that HAC will sent vehicles off-road, through "bushes and briars", so they will not kill foot troops on roads, or probably can same way make, that only vehicles will use roads, but this is unrealistic. Army will use roads for distant movements. Will not spread out and wade through the scrub and hills all the way, but only in battle, exactly in combat mode. Setting all in combat mode all the time, where roads are mostly ignored, is possible, but not good. Also will slow down greatly any movement because of combat mode specificity.

Edited July 4, 2012 by Rydygier

[orcinus 121]

In other words: yes, technically, probably is possible via combat mode to make, that HAC will sent vehicles off-road, through "bushes and briars", so they will not kill foot troops on roads, or probably can same way make, that only vehicles will use roads, but this is unrealistic. Army will use roads for distant movements. Will not spread out and wade through the scrub and hills all the way, but only in battle, exactly in combat mode. Setting all in combat mode all the time, where roads are mostly ignored, is possible, but not good.

And if you did it anyway, as soon as the grunts spread out on & off the roads in combat, the imbecile AI drivers would squish them anyway.

@lucidity: it's a problem in the game engine; a real solution will have to wait for BIS. Ryd is correct about patches breaking mods that address engine issues. Very much to the point, read the thread on SakuraChan's SakuDrive.

Also: COSLX is a major improvement on the original, with many bugs fixed. Not that big a download, & worth every byte :)

[jiltedjock 10]

hi, been playing this a lot over the last few days - one of those mods that makes you want to spend a lot of time trying things out (-:

One thing I have noticed is that I haven't yet seen HAC Garrison groups making any use of buildings (Takistan is where I have been doing most of my testing. The groups are properly named and they are showing as garrisoned in debug mode. But it seems they would rather occupy the areas outside.) My workaround is to use GL4 and have as much of it disabled as possible, then synchronize the GL4 Defend module with the groups that I want to occupy buildings defensively - GL4 is very good at getting units into buildings.

Looking at snkman's garrison function, the buildingpos searching etc in his code looks pretty extensive. I wonder if you could make use of any of his techniques to make the AI use buildings a bit more?

[Rydygier 1330]

Because of some code specificity, currently only "groups", that contain only one member will go inside buildings. Rest will man near static weaponry and will stay outside. Probably HAC's garrison routine can be better, and if can, then probably someday will be. :)

[jiltedjock 10]

Ah, ok, thanks for the answer (-:

[orcinus 121]

Ah, ok, thanks for the answer (-:

Have you tried using the latest asr_ai? - units enter buildings, snipe from rooftops, fire from windows, etc.; as well as some great improvements to stance & firing mode, especially for MG/AR & snipers.

[euly 0]

hi, been playing this a lot over the last few days - one of those mods that makes you want to spend a lot of time trying things out (-:

One thing I have noticed is that I haven't yet seen HAC Garrison groups making any use of buildings (Takistan is where I have been doing most of my testing. The groups are properly named and they are showing as garrisoned in debug mode. But it seems they would rather occupy the areas outside.) My workaround is to use GL4 and have as much of it disabled as possible, then synchronize the GL4 Defend module with the groups that I want to occupy buildings defensively - GL4 is very good at getting units into buildings.

Looking at snkman's garrison function, the buildingpos searching etc in his code looks pretty extensive. I wonder if you could make use of any of his techniques to make the AI use buildings a bit more?

I've noticed this as well. Placing guards/lookouts near towers tends to result in a high probability that they'll do what garrisoned units are supposed to do, but I think they overall general behavior is affected by the timing of HAC. Sometimes the units climb the towers and stay there; other times they don't climb the towers at all, and sometimes, they climb the towers, then climb back down and stay down.

I agree, GL4 does it effectively. Units climb buildings like ants, no matter how many are in the group, but I don't like blending HAC and GL4, so I just tend to not use guard towers with HAC. One thing I haven't tried yet is setting the units on top of the towers/buildings in the mission editor. I'm willing to bet they would climb down though, so I just stick to vehicle garrisons pointed in the direction I want them to face. I've also yet to see garrisoned units take missions.

[Rydygier 1330]

I've looked at GL4 garrisoning method. Seems to be nice, based on doMove - doStop, while HAC's method is based on setWaypointHousePosition. Because waypoints works with whole groups, so here is limitation for only one-member groups (otherwise, I think, all group will crowd around a single position...). Well. Probably should be possible replacing this method with more flexible doMove-doStop as one of future improvements, despite, that this is micro-AI level :P .

[jiltedjock 10]

Yes I use ASR AI too. The trouble is that it doesn't kick in until they are in combat mode.

What GL4 is good at is affecting the behaviour of units that are not in combat mode yet, which is more immersive if, say, you are observing them at a distance through binoculars. So in the case of the GL4 Defend module, distant enemies are likely to already be occupying buildings etc.

The biggest immersion killer in Arma for me is when you look at distant enemies and they are standing stock still in wedge formation.

Of course the issue with GL4 is that it can be a bit heavy on the FPS, even if you are only running the bits that you want. Robalo's code for the search nearby and the house search is nice and lightweight, it would be great if he did a Defend Module based on that, or created a new Defend variable within the ASR AI that could have an array of groups in it, where the AI would take up nearby buildingpos and stay there.

---------- Post added at 10:47 AM ---------- Previous post was at 10:37 AM ----------

Or if HAC garrisoning was going to be changed, perhaps if the code:

searched for nearest building <200 metres that had 50% or more buildingpos in its index than units in the group, then 50% of the group moved to a random selection of the buildingpos array (I am no coder, as you might have guessed :) ). Robalo does something a little like this in his searchhouse function.

Edited July 10, 2012 by jiltedjock

[wolffy.au 9]

FYI - Rydygier's Big Boss of HETMAN Artificial Commander

http://www.ausarma.org/blog/4/entry-29-rydygiers-big-boss-of-hetman-artificial-commander/

[BasileyOne 10]

q: sorry for stupid question, but how HETMAN was compared to WOO ? :)

confused because partial similarity:-)

q: is there any chances to HETMAN become co-operate/join with/to A2Warmod ? :-)

[kremator 1065]

WOO puts the player in charge of all forces, HETMAN puts AI in charge of force deployment.

Shame that WOO wasn't further developed but I think Mondkalb said there were problems with stupid AI.

[Rydygier 1330]

That's right. I not used WOO (damn, when finally I'll have time to try this?), but I see, that WOO is kind of very special, RTS gameplay mode. Hetman is field commander-level (soon, hopefully, also higher) AI behavior enchancement. HAC is a smart "waypoint giver" for groups put under his control (as his "army" or "task force"), where his goal is to take all chosen for him objectives on map and to destroy all known enemies, all this in organized and sophisticated way. So he is using for that purpose flanking, reserves, logistics, transport handling and more. If there are any similarities, it can be only in the behavior of AI used in WOO.

(CO)WarMod is, if I'm not mistaken, big pack of chosen addons matched and optimized to work fine together. So as long there is no included in this compilation any addon, that will mess with group's waypoints (ask Gunter about that) - all pack should be fully compatibile with HAC. There is no need to merge/combine them, just play with both if you want.

Edited July 29, 2012 by Rydygier

[BasileyOne 10]

ok, tnx.

Warmod also include some WOO-alike portions/feats.

would be nice to see it in action together on Warfare maps ;)

about A2W, as i get it, after reading their frontpage [http://warmod.webs.com/]

A2Warmod comes in five-seven different flavors/builds/forks:

A1

A2

A2 with ACE

A2CO

A2CO with ACE

A2CO with Invasion 1944

both with or without SLX

some others i didn't uderstand properly

Edited July 29, 2012 by BasileyOne

[subroc 4]

Released Epic Battlefield System Scripted version and included support for HAC:

http://forums.bistudio.com/showthread.php?137963-EBSS-Epic-Battlefield-System-Scripted-version&p=2197300#post2197300

[euly 0]

Will Big Boss replace the HAC system (will I be able to simply replace the HAC files), or will it need to be set up?

[orcinus 121]

(CO)WarMod is, if I'm not mistaken, big pack of chosen addons matched and optimized to work fine together. So as long there is no included in this compilation any addon, that will mess with group's waypoints (ask Gunter about that) - all pack should be fully compatibile with HAC. There is no need to merge/combine them, just play with both if you want.

Correct, though I'm not sure how Zeus will interact with HAC (I don't use Zeus any more).

[Rydygier 1330]

Will Big Boss replace the HAC system

This will be an optional addition, not replacement. A new feature. Currently objectives for each Leader are manually chosen by mission maker. BB will do this automatically and, hopefully, reasonable. Will also change objectives dynamically during gameplay until all points on map considered by him as strategic will be taken or when his forces will lose combat effectiveness. And for this purpose should use all "task forces" of given to him Leaders in coordinated manner. That is the plan - BB is the higher level HQ of a more general look over the whole battlefield, commanding the Leaders.

Edited July 31, 2012 by Rydygier

[euly 0]

This will be an optional addition, not replacement. A new feature. Currently objectives for each Leader are manually chosen by mission maker. BB will do this automatically and, hopefully, reasonable. Will also change objectives dynamically during gameplay until all points on map considered by him as strategic will be taken or when his forces will lose combat effectiveness. And for this purpose should use all "task forces" of given to him Leaders in coordinated manner. That is the plan - BB is the higher level HQ of a more general look over the whole battlefield, commanding the Leaders.

Sounds awesome. Though, I still enjoy having a unit on the map that represents a general or commander.

Is there any chance that some objectives could be reinforced by some simple means of garrisons? I ask because I've been using the CWR2 maps lately, specifically Kolgujev, which have lots of bases with guard towers. I'm hoping they could treat some objectives as bases by reinforcing them with look-outs, scouts, or patrols. I know this occurs on a nominal level currently, but the AI tends to be spread out and reammo, resupply, and refuel are way out in the middle of nowhere.

Maybe I'm all wrong, but it seems like the objectives are treated with little importance once they are captured. The commander does seem to try, but as I've played many hours of HAC in groups (not the leader), I've noticed that the problem tends to be forces are unable to move into position fast enough. Once forces enter the area, they simply park in whatever position is convenient. I enjoy playing a lower ranking unit in a large group, so what happens often is our group will be on foot patrol somewhere when we receive a capture order 2000+ meters away. If a chopper shows up for us and we're flown in, then timing is not a problem, else, we're stuck walking at-ease until the commander realizes we'll be there in an hour. If we are flown in, we just exit the helicopter and run into an open position and wait for new orders. I'm sure Orcinus will rip up my argument to make me sound like an idiot, but I don't know, it just feels like something better can be done once the AI captures objectives.

Also, remember to address the issue of non-destroyed enemy vehicles in the proximity of objectives. Even if the crew of the vehicle are dead, if the engine is running, the friendly AI seems to consider the vehicle enemy, but not a threat.

[Rydygier 1330]

Yep, I'm thinking about some kind of garrison handling for BB. Something like: objective captured? So we leave here as "garrisoned" eg. 5% non garrisoned yet groups (rounded down, so if force contain less than 20 gropus in this example, there will, be no garrison assigned, so no all forces should be spent on garrisons). Or something similar... Still garrison service, if no enemy nearby, will be very monotonous. :) The problem with HAC as a gaming tool is fact, that it tries to simulate in some degree real war course, and in real war, I think, most time is spent on sitting, waiting or marching very far, very slow. Only minority on killing and dying. Not so playable for guys, that want action, action and more action, still this depends on mission setup...

BTW

My current long-term plan looks as follows: to finish BB (in August perhaps? We will see) plus some minor things from to do list and slight code refreshment, then new HAC release. Next stage would be attempt to implement guerilla AI, but this still needs some thinking, so meanwhile will concentrate on some of my other projects/ideas (promised to some people Arma-chess, 2 or 3 SP missions on Chernaruss and Lingor, CEMS)... All dependent on my eagerness, which is changeable, and time. Well, I think, that when I finish with all stuff, I have in mind, no one will use it, as Arma3 will be released till then. :)

[euly 0]

Yep, I'm thinking about some kind of garrison handling for BB. Something like: objective captured? So we leave here as "garrisoned" eg. 5% non garrisoned yet groups (rounded down, so if force contain less than 20 gropus in this example, there will, be no garrison assigned, so no all forces should be spent on garrisons). Or something similar... Still garrison service, if no enemy nearby, will be very monotonous. :) The problem with HAC as a gaming tool is fact, that it tries to simulate in some degree real war course, and in real war, I think, most time is spent on sitting, waiting or marching very far, very slow. Only minority on killing and dying. Not so playable for guys, that want action, action and more action, still this depends on mission setup...

BTW

My current long-term plan looks as follows: to finish BB (in August perhaps? We will see) plus some minor things from to do list and slight code refreshment, then new HAC release. Next stage would be attempt to implement guerilla AI, but this still needs some thinking, so meanwhile will concentrate on some of my other projects/ideas (promised to some people Arma-chess, 2 or 3 SP missions on Chernaruss and Lingor, CEMS)... All dependent on my eagerness, which is changeable, and time. Well, I think, that when I finish with all stuff, I have in mind, no one will use it, as Arma3 will be released till then. :)

I'm sure porting HAC to ArmA 3 will be easy as the code will at least be legacy and, at that point, will need to be updated with new commands ArmA 3 introduces.

[instagoat 133]

I am wondering if there´s a way to handle large mixed-class units. For example, in one of my missions, I am running a company assault where the platoons are actually single units (so about 40 Units + 5 vehicles of different types in one group.)

Right now, the AI commander seems very reluctant to use these units, instead resorting to little 5 man SOF squads or units with few or no vehicles at all, or non-mixed vehicle units. So the bulk of the force gets left behind or LMCU´d while the recon squads do all capturing and fighting. I am currently trying to make a workaround by forcing the units trough the init.sqs with the RHQ_firsttofight thing to actually be used.

Have to say, I love this mod. Probably the greatest addition to Arma in ages for me.

[Rydygier 1330]

so about 40 Units + 5 vehicles of different types in one group.

Hmm. Never tested HAC with big, custom groups. If mix is "exotic" (not recommended), eg. A chopper grouped with the tank and sniper, then HAC will consider such group as simultanously sniper, armor and air capable (quite rightly isn't :) ). Now you can imagine problems, when HAC will send such "mix" with, eg air attack mission... But this is BTW. Generally HAC will consider given group as of each type of its units. So if group consist infantry, AT infantry, AA infantry, a tank and humvee, this "mixed group" will be considered as : infantry, at infantry, aa infantry, armored and motorized group. So any task considered by HAC as proper for any of this types may be issued to that group. Or should. One thing: HAC uses some special ways of distinction type of group based on assumption, that there are set default group types. So if this is complex, custom group, HAC may sometimes misunderstand kind of such group. Not sure, but possible sometimes. For example - a MTVR truck should be considered as non-combat cargo and not used in fight, right? And a rifleman should be considered as infantry, and his group used in fight, yes? Not so simply, cause truck is driven by rifleman, no crewman... So additional distinction is needed here, based on eg number of riflemen in group and their role in vehicle, to distinct empty truck with driver from truck full of troops. Anyway, if possible, I recommend rather to use eg . 5 groups of 5 men, each with vehicle, than one group of 25 men with 5 vehicles.

If things will go, as are going now, shortly should be ready wip5 with partially deeply redesigned code, some problems removed and most of "to do" features implemented. There is good progress in big boss too, so next should be official new version release.

[Rydygier 1330]

So, here is wip5 version. This one should be the last of wips. Includes all features from “To Do†list with several tweaks and fixes, excluding Big Boss, which is currently “work in progress†(and there is progress in work :) ), guerilla mode, which will wait for next version, and new manual content. When BB and manual will be ready – should be officially release next HAC version, probably with beta status however.

In wip5 we have large amount of reworked and new code, co there is good chance for brand new bugs as well, so meanwhile I’ll be grateful for tests and bug reporting (including RPT, if any errors here, info about other addons/mods/DLCs in use, and perhaps even repro mission, if reasonable).

NOTE: this is first version not compatible with Arma 2 1.11 alone. Needs 1.60 or better because of some commands introduced with OA/CO, that I was forced to use for fix of some problems.

Probably not complete list of changes:

- NEW: cyclical comparing forces routine during fight and withdrawing when to big enemy advantage;

Added new value for each group – a “danger factor†based on number of nearby known enemy and ally units and distances. If factor become big enough, there is a chance for withdrawal in same manner, as is for combat ineffective units (towards same area regardless of distance);

- NEW: for impatient: init config variable RydHQ_Rush (default: false). If true, in any circumstancies, when groups are usually moving slowly (limited speed or safe behavior), speed is set to normal, and behavior to aware. No longer very looong walks if not desired;

- IMPROVED: deeply reworked code for defensive stance. Now you can set line of defense of chosen kind including “in siege†like round defense. To achieve that set objective objects in places, that should become a defense centers along with Leader’s position. Next you need to use some new init variables for initialization, and customization:

RydHQ_Order = "DEFEND";

(to keep Leader in defence mode)

RydHQ_DefendObjectives = 4;

(default 4. Must be greater, than 0 for activation of new defense pattern. Integer value tells HAC, when should use given objective position as defense center. This number means, how many of groups on map must be placed closest to this objective for that. Each group will take position in the area of closest objective, so this prevents situations, where eg. only one or too few for efficient defense groups is placed in given area, what is not reasonable. Unless you set this value to 1 of course.)

RydHQ_NObj = 5;

(so Leader will consider all objectives as taken. Only taken objectives will be used for this defense pattern. If you set this 1, none will be used, for value 2 – first of them and so on. This is internal global variable used in offensive mode to control, which objectives are taken, and which aren't yet. So should be not manualy defined in offensive mode)

RydHQ_DefFrontL = ["N","E"];

RydHQ_DefFront1 = ["N","W"];

RydHQ_DefFront2 = ["W",""];

RydHQ_DefFront3 = ["S",""];

RydHQ_DefFront4 = ["E",""];

(these are optional. If defined, as array of two strings, will force given direction of defence perimeter (in which direction is front of Leader’s point and each of four objective points perimeter). Rules: first string may be one of: N, S, W, E. This is “primary directionâ€. For N and S you can set secondary direction: E or W if needed. Otherwise put there an empty string. If not defined, direction towards last known enemy positions will be chosen. If there is no known enemy positions – direction will be randomized for each defense point separately).

Once taken defensive positions will be keeped as long, as there is defensive mode on, no longer chaos generating reshuffles after reset.

Also there is used new reinforcement support in defensive mode, based on mentioned “danger factorâ€. It is dynamic, so reinforcements can be every minute redirected on the fly, if needed more somewhere else, but if group is already sent – there will be usually needed more serious threat for redirection, than reason of initial reinforce order. As most important threat will be considered usually known enemy closer to Leader, than average distance of all allied groups is (enemy on flanks!).

Now also in defensive mode will be used smoke grenades, also 40mm for withdrawal consealing, and, new, artillery smoke screen. After sunset and before sunrise defending groups will use both 40mm flares (not so efficient though because shooters has tendency to shoot flare with too low trajectory, so often it will lamp area only for few seconds) or, optionally, will call for arty illumination if will know about enemy close enough. For “night detection†there is used small piece of code found in TPW’s charming lights addon, originally made by Carl Gustaffa.

- IMPROVED: well… slightly – withdrawal goes now sometimes a bit better, also because arty smoke (not so great, as is usually too quick dispersed). AllowFleeing not helped. Will test this further while working on guerilla mode.

- IMPROVED: old, broken surrendering behavior replaced with new code, bounded with panic system, that gives chance for surrender each group separatelly. It is untested and experimental, so RydHQ_Surr is still false by default. Probably captives still will be shot on sight :(.

- NEW: as mentioned – decided to implement own HAC’s artillery handling. HE/SADARM will be still handled externally, but usage of smoke and illumination, as it needs strict coordination dependent on certain situation, is now optionally moved into Leader’s control. It is based on artillery module, and needs only vanilla howitzers (smoke, illum) or mortars (illum) on map, where each group consist only one kind of arty piece. This, I hope, will not interrupt work of external AI artillery handler. To activate define with value greater, than 0, this init variable:

RydHQ_ArtyShells = 120;

(default 120 – amount of shells of both types available per battery (arty group)). Smoke, in mentioned situations, will be placed by 9 shells, that should to envelope withdrawing group, between that group and nearest known enemy, with some randomization and dispersion. 3 shells on left, 3 on right, 3 in middle. Illum fire mission means single shell deployed above closest known enemy position);

- NEW: morale drop (-10 – (random 10)) when current Leader unit dies;

- NEW: additional pause (60 + (random 60) seconds) before next cycle, if new Leader is replacing killed previous one;

- NEW: distinction between aerial and land medevac vehicles for choosing apriopriate kind depending on distance and kind of wound;

- NEW: in debug mode silent hint info about Leader's staff death (when HAC's control ends);

- IMPROVED: HAC uses now placed temporarily “laser target†object to convince bombers (planes of types included in RHQ_BAir, by default none of the planes are used as bombers) to use their bombs. Not always, but often this works;

- IMPROVED: new garrison handling. Each garrisoned group will: to fill up static defenses, to take positions in enterable buildings. Rest (at least team leader) will patrol area including building’s interior checks (route is randomized once, initially). This feature comes with one init variable:

RydHQ_GarrVehAb = true;

(false by default). If true, garrisoned groups with assigned vehicle will disembark and act as not motorized (crew stays at the vehicle). Otherwise garrisoned groups with vehicle will only get sentry waypoint at its current position.

- reworked architecture of main attack decision-making code, introduced numerous functions, reduced redundancy, fixed some small issues and code problems. Fixed problem with emptied enemy vehicles, that was considered as enemy during objective state checks (was blocking objective capturing). Now empty vehicles are not counted.

PS. There is message about missing "surr.sqf". (that's why changes after last tests aren't good idea). You can just ignore it, or go to VarInit.sqf and comment out or remove 70 line.

Edited August 14, 2012 by Rydygier