HETMAN - Artificial Commander

[delta99 34]

Is there an official HETMAN Arma3 thread? If not probably best to start one so that the latest version etc. can be posted in the original thread with discussion of the A3 version there rather than mixing the two here.

[Rydygier 1309]

For now there is no official "HAC for A3" development/porting work in progress, so no reason for such thread yet. There will be one in proper time. Meanwhile any current work on porting HAC to A3 is unofficial, so there can be created only unofficial thread - if someone want to do that, I have nothing against.

[mjolnir66 48]

Could you post this so we can test it for ourselves?

[mrcash2009 0]

For now there is no official "HAC for A3" development/porting work in progress, so no reason for such thread yet.

Could you post this so we can test it for ourselves?

How can we test for ourselves something that is not?

[Rydygier 1309]

@Mjolnir66

If you want to test HAC under A3 you can use it as is, was reported, that in general HAC is working in A3. However, there is some stuff, that will not work there, most important would be HAC's artillery handler (not so crucial for now, as there are only mortars in alpha, and these somehow are functional by itself) and code basing on MP Framework (tasks, some HQ comm, both in multiplayer), also some other dependent on certain classnames minor stuff (flares, smoke, ammo drop...). Check first post to see repositiory of zorrobyte, who tries to do something about unofficially.

Edited April 14, 2013 by Rydygier

[delta99 34]

Will the demo versions work with the scripted version? I took the first simple demo and added all the scripting files to the mission and then added the appropriate line to init.sqf and nothing happened. I didn't see any errors in the Rpt file either I don't think. Just nothing happened. I then just loaded the mod version and things worked fine but hoping to get the script version working.

[Rydygier 1309]

Yes, every demo should work also with script version, if only all files are on place and [] execVM "RydHQInit.sqf" is executed, so something must be done wrong, if it is not working. Addon version basically contains same scripts, that are auto-launched thanks to CBA. Perhaps RPT file contains some answers.

[TugeX 1]

I'm getting a bunch of Errors in RPT while testing MP mission by hosting it myself. However these errors did NOT happen while testing only in the editor. Basically I have 3 leaders (LeaderHQ,LeaderHQB,LeaderHQC) and correspondive Front area triggers named properly. In case 1 HQA initialized correctly but the other 2 did not. In case 2 not even the HQA did initialize.

Case 1: This happened when there was no enemy to the AI, only me as an civilian observer.

"Commander A (OTHER) - Recklessness: 1 Consistency: 1 Activity: 1 Reflex: 1 Circumspection: 0.2 Fineness: 0.5"
"Morale A (OTHER): 0 - losses: 0 percent (0)"
"Commander A (OTHER) - Recklessness: 1 Consistency: 1 Activity: 1 Reflex: 1 Circumspection: 0.2 Fineness: 0.5"
Error in expression <QB_CInitial = RydHQB_CInitial + (count (units _x))
}
foreach RydHQB_Friends + [R>
 Error position: <units _x))
}
foreach RydHQB_Friends + [R>
 Error units: Type String, expected Object,Group
"Commander A (OTHER) - Recklessness: 1 Consistency: 1 Activity: 1 Reflex: 1 Circumspection: 0.2 Fineness: 0.5"
Error in expression <(RydHQB_KnowTL) then 
{
{
if (isPlayer (leader _x)) then {_players = _players + >
 Error position: <leader _x)) then {_players = _players + >
 Error leader: Type String, expected Object,Group,Team member

Case 2: I was on the AI's enemy side

"Commander A (OTHER) - Recklessness: 1 Consistency: 1 Activity: 1 Reflex: 1 Circumspection: 0.2 Fineness: 0.5"
Error in expression <hicle ((units _x) select _a);
{
if ((_x knowsAbout _enemyU) >= 0.05) exitwith 
{>
 Error position: <knowsAbout _enemyU) >= 0.05) exitwith 
{>
 Error knowsabout: Type String, expected Object,Side,Group

There was also error of deleting waypoints of the groups, but I just commented the script part out since I spawn in fresh groups which don't have any.

All errors seem to be "Error X: Type String, expected Object,Side,Group".

[Rydygier 1309]

With that info I can only say, that for some reason instead of group name a string is passed to the code. Of course I have no idea, how or why. As usual I need repro - troublemaking mission itself (best without any addon dependency, so I could run it) to see, if anything more can be said here.

[TugeX 1]

My bad, I was defining groups to be excluded/included like this:

//RydHQC_Included = [];
//{if (!isNil _x) then {RydHQC_Included = RydHQC_Included + [_x]};} forEach ["HQCgrpSF1","HQCgrpSF2","HQCgrpSF3","HQCgrp1",...];

which was obviously wrong, but

RydHQC_Included = [];
{if (!isNull _x) then {RydHQC_Included = RydHQC_Included + [_x]};} forEach [HQCgrpSF1,HQCgrpSF2,HQCgrpSF3,HQCgrp1,..];

does not work the way I want to. Any ideas what to change or some other method how to add groups to the array if they exist?

[delta99 34]

Yes, every demo should work also with script version, if only all files are on place and [] execVM "RydHQInit.sqf" is executed, so something must be done wrong, if it is not working. Addon version basically contains same scripts, that are auto-launched thanks to CBA. Perhaps RPT file contains some answers.

I will try this again at some point. Maybe I screwed something up. Also, I have nothing in the init.sqf other than the RydHQinit call. Should I put a bit of a delay in or something?

---------- Post added at 22:02 ---------- Previous post was at 21:52 ----------

Thought I would point out a bug that I think I noticed as well. A group called for an ammo resupply and while the ammo truck was on its way the groups vehicle was destroyed. The ammo truck then arrived a little while later and hung around. The units that survived the destroyed vehicle just stood there. I suspect it was the vehicle they were looking to resupply. I can't remember now if the ammo truck drove away after a while but I don't think so. The unit never left and the resupply debug marker never went away. My guess is that because the vehicle was destroyed at some point the resupply was never able to happen and therefore it never ended properly either. That is, it should probably cancel itself.

Also I thought I read somewhere that there is code that can potentially catch groups that have not moved in a long while and get them moving. Those units that were waiting for resupply never moved for the rest of the mission. This could be again because do the screwup with the resupply.

[Rydygier 1309]

RydHQC_Included = [];
{if (!isNull _x) then {RydHQC_Included = RydHQC_Included + [_x]};} forEach [HQCgrpSF1,HQCgrpSF2,HQCgrpSF3,HQCgrp1,..];

does not work the way I want to. Any ideas what to change or some other method how to add groups to the array if they exist?

Code by itself looks good (syntax side). All depends, what exactly you want to achieve, how and when this code is used and what is the effect.

---------- Post added at 10:47 ---------- Previous post was at 10:21 ----------

I will try this again at some point. Maybe I screwed something up.

I think so - I tested, just to be sure - it is working.

Should I put a bit of a delay in or something?

I sometimes do, but in fact this shouldn't be necessary.

My guess is that because the vehicle was destroyed at some point the resupply was never able to happen and therefore it never ended properly either. That is, it should probably cancel itself.

Well, thanks for reporting, but is not a bug. In fact, from the moment, when supply vehicle first time obtain target position, further fate of supported vehicle is not important for supporting routine. Supply will go there, will simply wait a bit (resupplying itself is based purely on vanilla A2 code, so HAC ensures only needed circumstancies - resupply vehicle close enough to the vehicle, that needs supplies), then will go here and there in the area in case, if supported vehicle was stuck or drove too far away or there is someone else in need, then supply truck will be often temporarily left there, closer to the current battle area, and waiting for further orders, later relocated somewhere between leader and current objective positions. Marker however should be deleted anyway after some time, unless you haven't wait long enough, but this is minor thing.

Those units that were waiting for resupply never moved for the rest of the mission.

Anyway this is not because of supplying, as supply routine code doesn't manipulate target group movements anyhow unless this is about ammo drop from air unit for infantry. There are several possible reasons of such idling.

For example:

If there was in debug mode green triangle at their position - then this was resting order - group is withdrawn from action until become effective again. As there is no chance for that - vehicle lost - resting is endless, group stay unused to the end of the battle (not quite sure, if destroyed vehicle becomes unassigned from the group, there is no reason for resting, and group becomes effective infantry. Still another cause of resting could be crew's wounds or lack of ammo, or simply fact, that group is crew type only - that type is not used in combat as infantry). Not sure, perhaps there was issued such order, but for some reason group was stuck and not follow towards its waypoint but such stuck is something outside HAC. In such case, if group with movement order is not moving long enough, waypoint is repositioned at current group's position and task is considered as completed. This way HAC handles "group is stuck" cases, when group for any reason do not follow HAC's waypoint orders. Also perhaps that group was simply in HAC's plans not needed anymore on battlefield. Possibilities are many.

Edited April 15, 2013 by Rydygier

[TugeX 1]

Code by itself looks good (syntax side). All depends, what exactly you want to achieve, how and when this code is used and what is the effect.

First I check the amount of players, then spawn in base amount of AI groups and depending on the number of players some additional AI groups are spawned. After that I define config variables for HAC and assing correct groups to LeaderHQ's.

RydHQC_Included = [];
{if (!isNull _x) then {RydHQC_Included = RydHQC_Included + [_x]};} forEach [HQCgrpSF1,HQCgrpSF2,HQCgrpSF3,HQCgrp1,..];

The code gives errors of _x not defined, which, I believe means it still tries to add groups that don't exist to the RydHQ_Included array. !isNull check was supposed to ignore groups that were not spawned.

I spawn the groups like this:

HQBgrpSF4 = [getMarkerPos "Bsf4", east, ["RUS_Soldier_TL","RUS_Soldier_GL","RUS_Soldier_GL","RUS_Soldier1","RUS_Soldier1"]] call BIS_fnc_spawnGroup;

Edited April 15, 2013 by TugeX

[Rydygier 1309]

First, you can try one of two:

1. Define at start all possible group names as grpNull;

2. Replace not isNull group check with not isNil "group", as this way is tested, if group is defined at all.

Another, I think better, way would be to add given group to Included just after spawning in such manner:

HQBgrpSF4 = [getMarkerPos "Bsf4", east, ["RUS_Soldier_TL","RUS_Soldier_GL","RUS_Soldier_GL","RUS_Soldier1","RUS_Soldier1"]] call BIS_fnc_spawnGroup;
RydHQC_Included = RydHQC_Included + [HQBgrpSF4];

or just:

_group = [getMarkerPos "Bsf4", east, ["RUS_Soldier_TL","RUS_Soldier_GL","RUS_Soldier_GL","RUS_Soldier1","RUS_Soldier1"]] call BIS_fnc_spawnGroup;
RydHQC_Included = RydHQC_Included + [_group];

(unless you need somewhere else specific group name)

[TugeX 1]

Thank you, grpNull did the trick and it suits my needs the best. However {_x=grpNull} forEach [grp1,grp2,...] did not work (_x undefined) and I have now defined each group separately as grpNull (~80 groups). There must be a more simple(=short) way to do that.

[Rydygier 1309]

80? As for me best solution is as described previously - including after each spawn. For sure not doing it line by line 80 times... If you for some reason want grpNull method however, there may be no other way here. Unless changing approach somewhere else, so grpNull method would be not necessary any more. Only guessing of course, do not see yours code, so can only guess blindly. Anyway, with good script editor even that way code can be made quite quick, so it is not so important, rather aesthetic issue. Well. Good luck.

[mjolnir66 48]

Is there any released scripts which combine HAC with a spawning script, or some idiots guide of how to use DAC to do it, because I haven't managed to do it.

[Rydygier 1309]

I think, that script is not needed. If you want spawn - just spawn. HAC by default will control everything, that he find on map, that is of Leader's side. No additional coding necessary. If used limited control - just make spawned group controlled by HAC, method depends of used control mode. If you want to spawn forces before HAC init - wait with HAC init until spawn is done.

You see, problem is, that in general solution depends highly on desired effect, and there are many possible combinations of spawning and control. Simple and complex. First spawn, next control; spawn and control simultanously; conditional spawn, conditional control, spawn dependent on achievements in control (eg when BB's objective taken, etc, etc.). So rather there is no overall, universal solution. Only certain cases and needs.

Somewhere in this thread there are described attempts of using HAC with DAC. Use thread search function with "DAC" key word to reveal them.

[delta99 34]

I will try this again at some point. Maybe I screwed something up. Also, I have nothing in the init.sqf other than the RydHQinit call. Should I put a bit of a delay in or something?

In the end I ended up getting this to work so I must have screwed up the first time around.

---------- Post added at 19:09 ---------- Previous post was at 19:02 ----------

I was wondering how one can make a Leader to attack more forcefully. What I did was take the Defense_Demo.Chernarus mission and I wanted to put the OPFOR forces under HAC command with a leader or number of leaders. The mission comes with OPFOR getting regular waypoints for all the groups and is NOT under HAC command.

When I put the OPFOR under HAC command they of course attack eventually but at a much slower/deliberate pace than default Arma2. This is understandable but I also then tried setting a bunch of options that one would think would make them attack more straight forward and deliberate but doesn't seem to make that much of a difference. They still take a very very long time and sometimes slow routes to attack.

This is what I've put in:

RydHQB_UnlimitedCapt = true;

RydHQB_SubAll = true;

RydHQB_LRelocating = true;

RydHQB_IdleOrd = false;

RydHQB_Rush = true;

RydHQB_RapidCapture = 40;

RydHQB_Berserk = true;

RydHQB_Withdraw = 0.5;

RydHQB_MARatio = [1,1,1,1];

for LeaderB which controls all the OPFOR forces. Is there something I am doing wrong here or something better I should be setting for a deliberate attack.

Also, I'd like to make the objective of the mission to kill the BLUFOR commander. Is there a way to set this for HAC? If there is, I haven't seen it.

[Jockywillson 10]

looks good

[Rydygier 1309]

I was wondering how one can make a Leader to attack more forcefully.

There are possible some tricks. Even with default setting, if only recon is turned off (this seems to be yours main problem), you can get quite intense attacks, if you divide OPFOR between several leaders, all with their objectives on the same position. The more leaders, them more intense attacks, because each will send indepedently fixed amount of groups against each spotted enemy and towards his objectives. Also increasing CaptLimit should help, as then Leader will send for taking objective more troops.

If this is still not sufficient...

MARatio is also interesting help here, worth of using.

Important may be to use along with it RydHQ_AttackReserve variable set to 0, so Leader will not keep anything in reserve. This is internal variable, so not listed in the manual if I'm not mistaken, but can be used as regular init variable too (another one is RydHQ_ReconReserve, as recon units have separate reserve, but this is not important now, as we turned of recon anyway). So, if AttackReserve is equal to 0, no reserve is set. Otherwise it is a multiplier of overall number of groups, by default calculated basing on Circumspection - aspect of Leader's personality.

Still some idle groups may be left behind, if not needed for objective taking or engaging enemy (MARatio set to 1,1,1,1 however should assure sending all non-reserve, not busy and combat effective groups against first spotted enemy). If you don't want that, you can force even idle groups to move towards chosen spot (eg enemy lines). To do so use IdleDecoy elliptic empty trigger, similar to objectives, described in chapter 3 of the manual.

Also, here is some init config made for HAC sending "mindless waves" that may bring some interesting ideas:

RydHQ_Rush = true;//Crucial. Disable walking
RydHQ_Wait = 2;

RydHQ_SubAll = false;//limited control on...
RydHQ_SubSynchro = true;//...by syncing
RydHQ_MAtt = true;//manual personality
RydHQ_Personality = "BRUTE";//brute Leader. Not so important with this settings, but...
RydHQ_Debug = true;//to see, what is going on...
RydHQ_DebugII = true;///... even better
RydHQ_NoRec = 10000;//Crucial. No recon
RydHQ_RapidCapt = 10000;//Crucial. Capture despite situation
RydHQ_ResetTime = 600;//Optional. Every reset idle position is recalculated though
RydHQ_UnlimitedCapt = true;//Crucial. Endless capturing (unlimited "capacity" of objective)
RydHQ_Withdraw = 0;//no withdrawal
RydHQ_Berserk = true;//no defend stance
RydHQ_Flee = false;//no low morale effects
RydHQ_CommDelay = 1;//with this can be set quicker cycles, but if not "Fast" mode, then the furter Leader, the less frequently will get cycle chance
//RydHQ_Fast = true;//Leaders will not wait with new cycle for comrades - can do CPU choking, disable, if so
RydHQ_DynForm = true;//not change much here, when rush is on, but does not harm
RydHQ_AttackReserve = 0;//no reserve.
RydHQ_CaptLimit = 1000;//In 1.42 probably changes nothing here. In 1.43 - will do: units per wave with capturing mission. Optional, thanks to IdleDecoys all units will run towards objective anyway, but with slightly different bahaviour. 

Also, I'd like to make the objective of the mission to kill the BLUFOR commander. Is there a way to set this for HAC?

Directly - there is no such option inside HAC. But:

1. You can simply set for OPFOR Leader objectives on BLUFOR leader position;

2. More exotic - you can try make BLUFOR Leader itself an objective object for OPFOR instead of empty trigger (RydHQB_Obj1 = LeaderHQ;). But then OPFOR will have always knwoledge about actual BLUFOR leader's position (as Leader always knows, where is his objective);

3. If you have some specfor groups - these guys may be sometimes used for direct wide-flanking attakcs on enemy HQ itself, if it is known (can be made known for the while within visibility range eg by reveal scripting command).

Only third way, if player is TL of specfor group (note, that thanks to RHQ method in fact any class of unit can be made a specfor if needed), give you regular task entry of such mission, but nothing is guaranteed here, HAC is simply not designed for babysitting manual control over it, in HAC nearly always this is about probability of occurence, not certainty. If such task is needed reliably, always and in 100% repeatable manner - HAC will not provide that, so create such task externally in such case. Also specfors are used only for such tasks (precise attacks on valuable targets from behind), otherwise they will guard own HQ all the time.

Edited May 2, 2013 by Rydygier

[delta99 34]

Rydygier, thanks for your detailed response. With this info I will try some additional things. Lots of ideas there.

And in case I didn't mention this already, you have a total masterpiece here. Really great system.

[delta99 34]

Rydgier, I gave your suggestions on a config for "attack" but didn't seem to make that much of a difference. A little bit perhaps but I still see a lot of groups moving pretty slowly. Mech and armor units are moving in pretty quickly however and they aren't waiting for infantry either.

I did have one variable "RydHQ_RapidCapt" defined incorrectly as "RydHQ_RapidCapture" but that probably wasn't the issue really. Plus it is correct in the last test using your config.

Besides that I am still a bit confused on the "RydHQ_ResetTime". I have set mine to 180 (3 minutes). The documentation says to refer to "reset" above in the documentation but I don't see that. I'm assuming this is the time between when HQ re-evaluates the battlefield and gives new orders but I could be wrong. This and cycle time I am confused about.

[Rydygier 1309]

A little bit perhaps but I still see a lot of groups moving pretty slowly.

To make all infantry run instead of walking should help RydHQ_Rush = true;

This is variable common to all Leaders (affects all at once).

Rest of ideas is rather for increasing number of groups send to attack and rate of attacks.

Sadly, there is no such thing in HAC like armored - infantry time coordination of attack between groups. There is only some experimental and troublemaking sometimes RydxHQ_SynchroAttack = true; that is supposed to cause, that groups sent against given enemy group after reaching flanking position should wait with attack at enemy position itself until rest of groups dispatched for this attack arrive on their flanking positions. You can try that, if any intentional coordination is needed.

Cycles & resets - Every Leader thinks in cycles. Every cycle he does everything, what is described in chapter 4 of manual. Except for introduced in 1.43 and apperently forgotten to update in manual fact, that now there is independent, quicker check for capturing objectives as part of capturing routine itself. Also morale change is calculated, checked opportunities for specfor missions etc.

Resets, which by default occur less frequntly than cycles, are moments for some additional checks for:

- loosing taken objectives;

- merging decimated and near groups if proper mode is activated (rare);

- some other internal checks amongst other code used to determine, if there is enemy lines dangerously close to the own HQ, what can cause bigger tendency for risky orders ("desperado" mode);

and, mainly, some things are reseted:

- improvised (5% chance for ordered) defense;

- reserve deployment;

- 5% chance for garrisons redeployment;

- recon again desired;

- progress status for HQ relocating.

Edited May 4, 2013 by Rydygier

[delta99 34]

To make all infantry run instead of walking should help RydHQ_Rush = true;

This is variable common to all Leaders (affects all at once).

Yeah, sort of works. They still don't move nearly as fast as default Arma2 waypoints so I'm not sure what is going on.

Rest of ideas is rather for increasing number of groups send to attack and rate of attacks.

Sadly, there is no such thing in HAC like armored - infantry time coordination of attack between groups. There is only some experimental and troublemaking sometimes RydxHQ_SynchroAttack = true; that is supposed to cause, that groups sent against given enemy group after reaching flanking position should wait with attack at enemy position itself until rest of groups dispatched for this attack arrive on their flanking positions. You can try that, if any intentional coordination is needed.

I don't need that. What I was saying is that armor was rushing ahead in before everything else but I guess that makes sense with the settings we are using. I guess if we didn't have RydHQ_Rush on and other settings messing with the attacking force then it would behave like I've seen it before and like is stated in the manual about armor not going in if it is known that there is potential AA assets.

Cycles & resets - Every Leader thinks in cycles. Every cycle he does everything, what is described in chapter 4 of manual. Except for introduced in 1.43 and apperently forgotten to update in manual fact, that now there is independent, quicker check for capturing objectives as part of capturing routine itself. Also morale change is calculated, checked opportunities for specfor missions etc.

Resets, which by default occur less frequntly than cycles, are moments for some additional checks for:

- loosing taken objectives;

- merging decimated and near groups if proper mode is activated (rare);

- some other internal checks amongst other code used to determine, if there is enemy lines dangerously close to the own HQ, what can cause bigger tendency for risky orders ("desperado" mode);

and, mainly, some things are reseted:

- improvised (5% chance for ordered) defense;

- reserve deployment;

- 5% chance for garrisons redeployment;

- recon again desired;

- progress status for HQ relocating.

Ok, I think I am understanding this better. What I was worried about was that new orders and such happened at the reset time. I should have noticed that new orders were happening quicker but then again I've always set the reset time pretty low.

Couple additional questions:

1. If the objective markers are moved during the mission will HQ re-evaluate?

2. If it does evaluate how does this work? For example, lets say HQ takes Objective #1 and are on there way to Objective #2 or have then taken Objective #2 and at some point I move Objective #2 to an empty area? What happens then?