HETMAN - Artificial Leader

[acoustic 82]

Hi. Iv started using HETMAN - Artificial Leader and it is fantastic. Im having some difficulties with with garrison and defence. Not sure if I am using the commands correctly. So I have created a script in the mission folder, which is activated as soon as mission starts. Im trying to make six small groups defend and garrison a small cluster of buildings and the command group is present here also. I have placed all for 'objective triggers' on this building cluster. But the groups dont garrison any of the buildings, instead they spread out in a radius of 500m or so in a defensive formation (admittedly a pretty good idea, but not what im looking for). Below is the script I am using along with .pbo version of the addon. Looking at some earlier posts, I can see that defence positioning variable can be edited in .sqf files. How do I edit these in the .pbo version of the addon? (this is the only way I could download from steam).

RydHQ_Debug = true;

RydHQ_Activity = 0.5;

RydHQ_Fineness = 0;

RydHQ_Order = "Defend";

RydHQ_Garrison = [g1,g2,g3,g4,g5,g6];

RydHQ_GarrR = 300

RydHQ_NObj = 5;

RydHQ_ROnly = [g1,g2,g3,g4,g5,g6];

Regards,

Rob501t

Garrison is acting really weird and probably needs an update. Ryd is pretty limited with time to work on the project, so I would suggest not using it for now. Unless Ryd can give some better input to the situation.

[Rydygier 1302]

But the groups dont garrison any of the buildings, instead they spread out in a radius of 500m or so in a defensive formation (admittedly a pretty good idea, but not what im looking for).

By intention all groups in RydHQ_Garrison should be excluded from any other tasks, including defense, so here is something wrong - if all your groups are garrisoned, setting Leader in the defensive mode should make no difference in their behaviour, they should anyway act like garrisons and that's it. Also garrR does nothing in defensive IIRC. The more, you have lacking semicolon after RydHQ_GarrR = 300 what makes whole setting invalid and not working.

BTW, if you want to change personality of the Leader, you have to activate RydHQ_MAtt = true; - manual settings. Otherwise it will be randomized anyway. Also "Defend" should be "DEFEND" (all caps) to work so not sure, if you got defensive bahaviour at all.

How do I edit these in the .pbo version of the addon? (this is the only way I could download from steam).

My advice - download full package from Armaholic (see first post for links) and use script version, if you need HQOrdersDef.sqf update, you mentioned. To edit pbo you need to to have and know to use tool for that and know, how to re-pack it properly. Don't bother IMO. Pbo is mostly for very beginners and lazy :) , for easy start.

Or even better use script version included in this reference demo, where I set up for you all according to what I wrote above:

HAL_Garrisoning_test

Init.sqf:

RydHQ_Wait = 2;

RydHQ_Debug = true;
RydHQ_DebugII = true;

RydHQ_MAtt = true;
RydHQ_Activity = 0.5;
RydHQ_Fineness = 0;//minimal chance to keep any group in reserve, still possible
RydHQ_Order = "DEFEND";
//RydHQ_Garrison = [g1,g2,g3,g4,g5,g6];
RydHQ_Garrison = [g1,g2];

RydHQ_NObj = 5;
RydHQ_Taken = [RydHQ_Obj1,RydHQ_Obj2,RydHQ_Obj3,RydHQ_Obj4];//required along with NObj after last updates to make all objectives "taken"

RydHQ_DefRange = 0.5;//how far from def center search for suitable positions - multiplier.  1 for default spread. Best use values >=0.1.

RydHQ_DefendObjectives = 1;//one group closest to given objective is enough to establish defend perimeter around

RydHQ_DefFrontL = ["N","E"];//North-East
RydHQ_DefFront1 = ["N",""];//1st perimeter facing North
RydHQ_DefFront2 = ["E",""];//2nd perimeter facing East
RydHQ_DefFront3 = ["S",""];//3rd perimeter facing South
RydHQ_DefFront4 = ["W",""];//4th perimeter facing West

nul = [] execVM "RydHQInit.sqf";

You have Leader group, you as separate group, 4 fire teams (G3 to G6) and two rifle squads (G1 and G2). G1 and G2 are set as garrisons, while rest will be used to man defense perimeters around closest objectives (you for fifth, Leader's perimeter). There is small chance, some perimeter will be not man, as Leader may wish to keep some group as def reserve (reinforcements). If you would keep all 6 groups as garrisons, no one will man perimeters (garrisoning and defending are exclusive each other). Debug is active, so all should be shown on the map (+ some markers to show, where perimeters are in the mission).

Now this version contain newest HQOrdersDef.sqf, which combines DefRange variable with fixed defense directions for the groups (both things was added separately earlier and seems, version containing one fix was without the other, kinda fail - fixed here).

As for me, garrisoning is developing just fine - most of each group is spread across random house positions in the area, rest of the group is constantly patrolling between these houses. Not tested, how it works in combat, Acoustic reported some problems there.

I really need review whole code - there is room for improvements, and prepare official Hetman update. Still not sure, when.

Edited July 17, 2015 by Rydygier

[1212PDMCDMPPM 200]

Hi Rydygier,

Thx for sharing HETMAN with us !! :)

I noticed something and don't know if it's a bug or a normal behaviour:

with Subball, LeaderHQ is ordering all friendly units, not restricted to his side.

I created a sample mission to test GAIA and HETMAN as foe. I put BLUFOR units controlled by GAIA and OPFOR controlled by HETMAN.

I added a single INDEP unit (the player ie me), specifying that INDEP were friendly to everybody.

Few seconds after HETMAN kicked in, I started receiving orders from HETMAN.

Shouldn't HETMANN stick giving orders to his own side ?

Thx !

[Rydygier 1302]

Indeed, Hetman under subAll will control all firendly factions/sides except factions defined as "civilian". One way to exclude player's faction when friendly with the Leader set such way would be something like:

RydHQ_CivF = [faction player,"CIV_F"];

Or make the player civilian.

It's interesting to test two AI mods fighting... who win? :)

[1212PDMCDMPPM 200]

Thx for such a quick answer !!

It's interesting to test two AI mods fighting... who win? :)

Hehehe, hard to tell because GAIA and HETMAN don't try to do the same thing:

- GAIA's goal is to maintain patrol (ie some kind of control) on specified areas without consideration for losses

- HETMAN's goal is gain control of areas then, if too many losses are taken, fall back to defend the leader

In my ultra simple setup, I setup some forces on two side of the map and define a GAIA zone and an HETMAN objective in the same area.

Forces were composed of 5 inf squad, 2 HMG vehicles and one ART.

I used Zeus and the Ares mod to add all units to Zeus and be able to check waypoints...etc

GAIA rushed to the zone while HETMAN was more cautious. Because I was too near the area, my own unit saw the GAIA motorized units thus starting artillery barrage and rush of motorized HETMAN units. After few minutes (playing in the editor and speeding time by x4 is your friend) the GAIA inf took control of the zone and started to be harassed by HETMAN inf.

After 5 to 10 minutes of fighting (in x4), the GAIA inf were slaugthered while HETMAN took more than 50% casualties, thus making the leader deciding it was high time to fall back.

In the end, the objective was in control of the last 2 GAIA inf with about 15 - 20 HETMAN inf having taken defensive position, mid point between the objective and the leader.

At no time GAIA used its artillery (in the first part of the fight it was rushed to the front and destroyed).

These are really interesting results because, as a mission maker, I need to understand how the AI brain is working to be able to use it at max potential in my missions.

For example, the safeguard mechanism of HETMAN is something that surprised me, falling back when detected superiority was 10 to 1.

On the flip side, GAIA sending its troops without any effect on moral seemed kind unreallistic (or fanatical).

You can find my sample (and ultra simple) mission here:

https://www.dropbox.com/s/g5e2db4ppcfkb5c/GAIA%2520vs%2520HETMAN.Altis.zip?dl=0

You don't need any addon to run it (so no MCC and no HETMAN addon), just 100% script on Altis with vanilla units.

EDIT: I forgot to mention that killing all the units in the HETMAN leader group is generating an error in the script.

[-lordsoth- 15]

that is some really interesting stuff there 1212, good work. Would never have though to put GAIA and HETMAN head to head like that.

[Rydygier 1302]

Thanks for this story. Very interesting. :) And thanks for bug reporting.

[1212PDMCDMPPM 200]

that is some really interesting stuff there 1212, good work. Would never have though to put GAIA and HETMAN head to head like that.

I'm always looking to provide a realistic behaviour for ennemies in our coop mission. That's how I stumbled by luck on HETMAN and decided to test both of them as foes. Sadly, GAIA and HETMAN are the only high level AI I'm aware of.

Remember also that this first test doesn't include air assets or transportation.

My first feeling is that GAIA is fine for missions with low number of players (15-) or many small engagements and HETMAN should shine with 20+.

With a small number of players, quick reaction is key to provide opposition and GAIA is really fast at ordering flanking maneuvers.

On the opposite, with more players, the overall strategy is propbably more important than flanking this one small squad that was just detected. This is why HETMAN was designed, as far as I understand it.

To put it in a different way, I would say that ASR AI or bcombat are low level AIs, GAIA is mid level AI and HETMAN highlevel AI.

Both GAIA and HETMAN are sharing common "extra" features (mainly transportation and artillery support) but there're three significant differences between them:

- quick reaction (in favor of GAIA - waypoints are given instantly when ennemies are detected)

- understanding of the whole battlefield (HETMAN)

- significance of human life (fanatical for GAIA, conservative for HETMAN with default settings)

Now I'm trying to find ways to combine GAIA and HETMAN (ie controlling the same side :) )

[rob501st4 10]

Rydygier,

Thank you for all the info. Very helpful in assisting me to understand how to use your addon. I will use your script and play around with it over next few evenings and will download and install the script version.

Thank you

Rob

[kremator 1064]

I'm always looking to provide a realistic behaviour for ennemies in our coop mission. That's how I stumbled by luck on HETMAN and decided to test both of them as foes. Sadly, GAIA and HETMAN are the only high level AI I'm aware of.

Remember also that this first test doesn't include air assets or transportation.

My first feeling is that GAIA is fine for missions with low number of players (15-) or many small engagements and HETMAN should shine with 20+.

With a small number of players, quick reaction is key to provide opposition and GAIA is really fast at ordering flanking maneuvers.

On the opposite, with more players, the overall strategy is propbably more important than flanking this one small squad that was just detected. This is why HETMAN was designed, as far as I understand it.

To put it in a different way, I would say that ASR AI or bcombat are low level AIs, GAIA is mid level AI and HETMAN highlevel AI.

Both GAIA and HETMAN are sharing common "extra" features (mainly transportation and artillery support) but there're three significant differences between them:

- quick reaction (in favor of GAIA - waypoints are given instantly when ennemies are detected)

- understanding of the whole battlefield (HETMAN)

- significance of human life (fanatical for GAIA, conservative for HETMAN with default settings)

Now I'm trying to find ways to combine GAIA and HETMAN (ie controlling the same side :) )

Very interesting results! Have played mission about 5 times so far. HETMAN is very tactical but does get beaten with offensive GAIA. Looking forward to updates.

[linx77 15]

I am trying to use this:

RydHQ_FirstToFight = []

 

But I don't know how to give group a name or something, so that Hetman will recognize it with FirstToFight command.

Any help would be much appreicated. :)

 

 

Also, is there a way to disable Rest and Regroup orders for player units?

[Rydygier 1302]

1. To name a group put into init field of any of its member this:

 

myGroupName = group this;

 

Now you can refer to this group via myGroupName.

 

If you spawn a group via script: 

 

myGroupName = createGroup _side;

 

does same thing. 

 

2. Quoting manual: RydHQ_Withdraw = 1 – multiplier of needed “danger level†(indicated in “debugII†mode as number at group’s position) for tactical withdrawal overwhelmed groups. The higher value, the bigger danger is needed for withdrawing. If set to 0 – withdrawal is turned off;

 

Set this to 0 to disable rest & regroup for groups considered as outnumbered/outgunned by close enemy. Still R&R will be issued for combat ineffective groups. Eliminating also this possibility requires direct HAL code editing, to be exact lines 892-906 of HQOrders.sqf:

	{
	_recvar = str _x;
	_resting = false;
	_resting = _x getvariable ("Resting" + _recvar);
	if (isNil ("_resting")) then {_resting = false};
	if not (_resting) then 
		{
		if not (_x in (_HQ getVariable ["RydHQ_Garrison",[]])) then
			{
			//[_x,_HQ] spawn HAL_GoRest
			[[_x,_HQ],HAL_GoRest] call RYD_Spawn;
			}
		}
	}
foreach ((_HQ getVariable ["RydHQ_Exhausted",[]]) - ((_HQ getVariable ["RydHQ_AirG",[]]) + (_HQ getVariable ["RydHQ_StaticG",[]]) + (_HQ getVariable ["RydHQ_ArtG",[]]) + (_HQ getVariable ["RydHQ_NavalG",[]])));

Has to deactivated/commented out. At minimum this one: [[_x,_HQ],HAL_GoRest] call RYD_Spawn;

 

Same for the lines 443-454. 

 

To make exception for groups consisting player units you has to properly edit above code, that of course requires some scripting knowledge. Like this:

	{
	_recvar = str _x;
	_resting = false;
	_resting = _x getvariable ("Resting" + _recvar);
	if (isNil ("_resting")) then {_resting = false};
	if not (_resting) then 
		{
		if not (_x in (_HQ getVariable ["RydHQ_Garrison",[]])) then
			{
			//[_x,_HQ] spawn HAL_GoRest
			if not (({isPlayer _x} count (units _x)) > 0) then
				{
				[[_x,_HQ],HAL_GoRest] call RYD_Spawn;
				}
			}
		}
	}
foreach ((_HQ getVariable ["RydHQ_Exhausted",[]]) - ((_HQ getVariable ["RydHQ_AirG",[]]) + (_HQ getVariable ["RydHQ_StaticG",[]]) + (_HQ getVariable ["RydHQ_ArtG",[]]) + (_HQ getVariable ["RydHQ_NavalG",[]])));

in both places (not tested). 

 

Similar exceptions has to be made in the code if you want only players not to be withdrawn in outnumbered group case: line 199, same file. 

[linx77 15]

Thank your for this detailed response and the great mod! :)

[thelegendarykhan 15]

Really I and MP does not like nor understand each other very much...

I am so emotional right now, got tears in my eyes. Where were you till now bro :')

 

Btw, HETMAN is a amazing mod. But the thing about spawning units in editor just takes away the suspense of what to expect as you know how many units the enemy has :(

Anyway to spawn random number (specified by the mission maker somewhere and not totally random) of HAC controlled enemy units?

 

This will be huge for me considering the fact that I too am unaware of the bird called MP. :P

[Rydygier 1302]

 

 

Anyway to spawn random number (specified by the mission maker somewhere and not totally random) of HAC controlled enemy units?

 

Look for one of existing spawning scripts (not sure about exact possibilities as for today) or try to write own. Best execute spawning before HAL initialization, although HAL will assume control over every newly spawned group smoothly. HWS mision, you found, works that way (user chooses settings in the GUI, then spawning groups/setting up the battle is conducted, after that Hetman awakes...), although there spawning part is kinda complicated for some reasons. 

[thelegendarykhan 15]

Look for one of existing spawning scripts (not sure about exact possibilities as for today) or try to write own. Best execute spawning before HAL initialization, although HAL will assume control over every newly spawned group smoothly. HWS mision, you found, works that way (user chooses settings in the GUI, then spawning groups/setting up the battle is conducted, after that Hetman awakes...), although there spawning part is kinda complicated for some reasons. 

Thank you for the prompt response.

1. Say if I use DAC which doesnt need anything in the init.sqf, how can I delay its execution before HAL? btw,  DAC uses triggers to initiate.

2. Also, EOS is another option I use often, that does have an entry which needs to be made in init.sqf.

3. If the unit assigned as HAL is killed, will the script stop functioning? Or do I have to set the HAL unit as "this setdamage false" also?

 

Please be patient and tell me a little in layman's terms for point 1 and 2. 3rd should be simple :D

 

Thank you and I love your addon. Its unbelievable. For me it deserved the MANW by all means :D

[Rydygier 1302]

What you need to know, if spawning script done his work, depends on that script. As said, I do not know/have no experience with spawning scripts around here, so don't know, what exactly indicates finished work for them. 

 

Specific for given script flag/indicator is usually optimal way. But if you don't know such way, or there isn't any for used script, general workarounds are possible. One promising way is to check, if count of groups on the map is no longer rising. Something like this before HAL init in init.sqf:

sleep 10;

waitUntil
	{
	_gCnt = count allGroups;
	sleep 5;
	not (_gCnt < (count allGroups))
	};

will pass the code further only, if amount of groups didn't raised last 5 seconds. There is made an assumption, so spawning will begin in the first 10 seconds, which should be typically safe enough. 

 

If spawning code is called/executed completely before HAL, it's not necessary. It's required, if such spawner was run in parallel, via execVM or spawn commands, or via trigger, so init.sqf doesn't wait for their finish before will go further. 

 

However maybe EOS/DAC users could share with better, dedicated for them indicator of finished task. 

 

From what I remember about DAC (Arma 2 times however, not sure, if this still applies) - it's not only spawner, but also controller. To avoid two scripts (eg DAC and HAL) fighting for control over same groups with contradictory, simultaneously issued orders, before you give green light for HAL be sure, none of spawned groups is under DAC control. 

[thelegendarykhan 15]

What you need to know, if spawning script done his work, depends on that script. As said, I do not know/have no experience with spawning scripts around here, so don't know, what exactly indicates finished work for them. 

 

Specific for given script flag/indicator is usually optimal way. But if you don't know such way, or there isn't any for used script, general workarounds are possible. One promising way is to check, if count of groups on the map is no longer rising. Something like this before HAL init in init.sqf:

sleep 10;

waitUntil
	{
	_gCnt = count allGroups;
	sleep 5;
	not (_gCnt < (count allGroups))
	};

will pass the code further only, if amount of groups didn't raised last 5 seconds. There is made an assumption, so spawning will begin in the first 10 seconds, which should be typically safe enough. 

 

If spawning code is called/executed completely before HAL, it's not necessary. It's required, if such spawner was run in parallel, via execVM or spawn commands, or via trigger, so init.sqf doesn't wait for their finish before will go further. 

 

However maybe EOS/DAC users could share with better, dedicated for them indicator of finished task. 

 

From what I remeber about DAC (Arma 2 times however, not sure, if this still applies) - it's not only spawner, but also controller. To avoid two scripts (DAC and HAL) fingting for control over groups with contradictory, simultaneously issued orders, before you give green light for HAL be sure, none of spawned groups is under DAC control. 

Yeah that is an amazing idea. Funny how people like you make scripting look piece of cake :D I will copy paste your provided code exactly before HAL's init line.

 

But a little catch. DAC's last array determines the side of spawned units, their behaviour along with any camps present, "[1,1,1,1]". This example means it will spawn NATO with behaviour "case 1", and 1 camp. I cant re-call what the last "1" means.

 

Maybe some DAC cum HAL players can shed light on this. I cannot leave the behaviour value as 0 like [1,0,1,1] as even 0 refers to a Behaviour preset in DAC. Maybe I can choose a number like 4 or 5 which is not having any preset to avoid conflicts between HAL and DAC. Only case 1, case 2, and case 3 are included in DAC behaviour sqf. :)

 

1. Can I execute HAL through a Radio trigger? That I believe would solve all issues as I can freely run it once everything else is in place :D

2. Secondly, it appears Zorro's caching script needs you to put an entry in the unit's init space. If I use DAC or even EOS, no units need to be manually placed in editor. Does his caching script has the ability to automatically determine spawned units like your wonder script does?

 

I am sorry for bombarding you with questions but I am at office. Cant really go for trial and error right now. And honestly, i've been playing around with ALive since 2-3 days but inability to save SP has seriously put me off now.

[Rydygier 1302]

 

 

1. Can I execute HAL through a Radio trigger? That I believe would solve all issues as I can freely run it once everything else is in place 

Sure. If you're OK with such way, it will work - HAL will begin on your command. Just put final HAL init line into exec field of radio trigger: nul = [] execVM "RydHQInit.sqf"; 

Rest of the optional HAL init may be done earlier, eg in the init.sqf or paste all into this trigger - no difference.

 

 

 

2. Secondly, it appears Zorro's caching script needs you to put an entry in the unit's init space. If I use DAC or even EOS, no units need to be manually placed in editor. Does his caching script has the ability to automatically determine spawned units like your wonder script does?

 

Frankly, I don't know. That init field code may be optional setting. I would expect/guess, it can pick whatever is present on the map. Just try. :)

 

 

 

I am sorry for bombarding you with questions but I am at office. Cant really go for trial and error right now. And honestly, i've been playing around with ALive since 2-3 days but inability to save SP has seriously put me off now.

 

No problem. I'm glad, as much I can help. Yes, ALiVE looks amazing, but it is focused on persistent MP AFAIK. No idea, for what reason they blocked saving, maybe it's just inevtable side effect of the persistency. 

[thelegendarykhan 15]

Sure. If you're OK with such way, it will work - HAL will begin on your command. Just put final HAL init line into exec field of radio trigger: nul = [] execVM "RydHQInit.sqf"; 

Rest of the optional HAL init may be done earlier, eg in the init.sqf or paste all into this trigger - no difference.

 

 

Frankly, I don't know. That init field code may be optional setting. I would expect/guess, it can pick whatever is present on the map. Just try. :)

 

 

No problem. I'm glad, as much I can help. Yes, ALiVE looks amazing, but it is focused on persistent MP AFAIK. No idea, for what reason they blocked saving, maybe it's just inevtable side effect of the persistency. 

Sir, allow me to buy you a cup of coffee. :D

[thelegendarykhan 15]

There is a new update to the BeCTI mission here. That is like a "CTI" version of war stories and with a economy system. One important thing missing from it is for the AI to use nearby vehicles and dismount at a safe distance before reaching destination. Your mod does that also. :D

 

How to incorporate HAL's nearby vehicle feature in this CTI mission, without conflicts ofcourse?

 

Thank you.

[Rydygier 1302]

You can't just like that pick a single feature and inject it anywhere. Whole transportation in Hetman works in tight symbiosis with the rest of HAL's code. Probably best, you can do, is asking BeCTI creator for such feature.

[thelegendarykhan 15]

You can't just like that pick a single feature and inject it anywhere. Whole transportation in Hetman works in tight symbiosis with the rest of HAL's code. Probably best, you can do, is asking BeCTI creator for such feature.

Ok thanks. Ill stick with War Stories anyway :)

[piter306 16]

As for the older issue, I think troops controlled by GAIA win with units HAL, because it often sets the unit on the defensive on an empty field where they have no cover. Is it possible to order the unit were waiting for orders "to hide"? It's fun though frequently used buildings, forest lines, bunkers etc. And an attack could better connect foot, transporters and tanks. Even so, HAL and Hetman: War Stories are one of the best additions to Arma3. Cheers :)

[1212PDMCDMPPM 200]

@piter306: I don't consider this an issue (ie the fact that GAIA is "winning" vs HETMAN), it's just a different way to wage war.

 

@Kremator: sorry, I was away from my main computer and missed your reply. Do you have other tests in mind we could try pitting those 2 AI mods against each other ? :)