HETMAN - Artificial Leader

[LDU30 5]

ok thanks...another question, how many units can handle each commander? there is a limit?.

[Rydygier 1309]

No limit in HAL. Your PC's harware efficiency is the limit here. IIRC there is also limit in Arma 3 itself - 144 groups per side. Not sure though. But it's unlikely, any PC can handle such number of groups without caching. 

[LDU30 5]

Oh men! now HAL artillery system works perfect ok!!..but with VAINILLA arty units xD.....i was using RHS units, podnos,d30,grad etc and for that reason i does not work for me ...i got crazy hahaha!

 

You can make compatible RHS arty units with HAL system? if times allows it, of course :rolleyes:

 

Thanks!

 

Note:i using beta dev and Eden 3d editor

[Rydygier 1309]

IIRC (it as really long time since I tested this last time), HAL should use any arty units compatibile with A3 arty commands, vanilla or not vanilla. Same, as FFE.

 

If some modded arty doesn't work with these commands - well, pity, but nothing to do with that on my end. If aren't recognized due to exotic config though - well, although it may be possible to make cod ecompatibile with them, question is, if I want to track compatibility with other mods out there - rather not. If anything is to improve on my end - I'm planning to push forward HAL's development at some point in the future. Not sure, when. 

 

Also you may try, if you wish, to add class names of these not working artillery to the proper RHQ arrays manually (read manual, chapter 7.1, especially end of page 35, begin of page 36.). There is also explained, how to get on your own class names of the vehicles. 

[LDU30 5]

OK with RHQ_Mortars now RHS arty units works! Thanks Rydygier.

[ArmaMan360 94]

​Hello Rydy. Hope you are keeping well. :)

 

I am making a SP mission with perpetual objectives and want to have more than 1 HALs per side with limited control.

To make the mission perpetual I will be using the in-built Spawn AI module to spawn AI over and over.​

 

How can I link the different HALs to particular Spawn AI modules so that they control only the AI spawned via those modules?

 

Regards :)

[Rydygier 1309]

I'm not familiar with those modules, so I can answer only in general: you have to grab somehow spawned group and add it under control of given Leader by usual limited control ways, like put it into IncludedG variable. Don't know, if possible with these modules without a bit of scripting. Most convenient would be spawning solely via script, then you can do that inside your own spawning code. Otherwise you have to somehow detect new group appearance and eg. basing on spawning position decide, to which Leader assign spawned group. Method of detection depends on, what given spawning mechanism gives in this regard. If it returns somehwere, what it spawned, you can grab it there. Otherwise you need most costly and least effective way - constant allGroups checks for new groups or something like that. 

[SavageCDN 231]

Hi Rydygier!  This is more directed to anyone who uses HAL - does anyone have a working mission using DAC to spawn units then handing them over to HAL?

[monyetswa808 13]

For you guys looking for using HAL with spawn systems,  you might want to check out EBSS; its for ArmA 2 Operation Arrowhead.  It worked well with HAC (A2 version) and perhaps the scripts can be working with HAL too. If not maybe you can reverse-engineer it to see how it collected spawned units to give to HAL LeaderHQs.

[monyetswa808 13]

Just a quick request for next version:

Can you make the "Garrison" function - search for house position part have a variable radius?   I think the default is 300m radius.

I want to garrison certain groups not so far from the leaders starting pos. 

Thanks, and great work  B)

[Rydygier 1309]

 

 

Can you make the "Garrison" function - search for house position part have a variable radius? 

 

I see no problem. :)

[ArmaMan360 94]

I'm not familiar with those modules, so I can answer only in general: you have to grab somehow spawned group and add it under control of given Leader by usual limited control ways, like put it into IncludedG variable. Don't know, if possible with these modules without a bit of scripting. Most convenient would be spawning solely via script, then you can do that inside your own spawning code. Otherwise you have to somehow detect new group appearance and eg. basing on spawning position decide, to which Leader assign spawned group. Method of detection depends on, what given spawning mechanism gives in this regard. If it returns somehwere, what it spawned, you can grab it there. Otherwise you need most costly and least effective way - constant allGroups checks for new groups or something like that. 

Thank you very much. I believe position based unit collection will be best. That will totally solve my issue. Lets say I put up ellipse triggers at positions where units will spawn. With this trigger set to presence of a particular side, and set to repeatedly run, I believe one of the following two approaches can be applied in the trigger's init:

 

1. If units of this side exist, detect all the groups present, add them in RydHQ_Included = [], or,

2. If units of this side exist, detect the number of group leader's present, then add them in RydHQ_Included = [].

 

I personally believe the latter approach may be easier? However any other approach as you deem fit Rydy. I dont want to bug you too much but please help in this man. :)

I want to make this insurgency mode based off HAL and send it to you for posting in your original thread.

 

 

Hi Rydygier!  This is more directed to anyone who uses HAL - does anyone have a working mission using DAC to spawn units then handing them over to HAL?

 

Savage, I am sure that starting from DAC's generate units 'on-the-fly' option will be the right path. What needs to be done is that spawn units via this line,

_units = [.....] spawnDACzone; // I am not 100% of the word spawnDACzone. Used it way back

then lets wait till a solution to my previous reply to Rydy which will add spawned units to RydHQ_Included = [].

Sometimes the lack of advanced scripting hurts :'(

 

 

P.S.: Rydy you have created the monstrous HAL, I am sure you have made a similar monstrous mission out of it :P

Please share if you have. Would be more than happy to play it :)

[Rydygier 1309]

 

 

Sometimes the lack of advanced scripting hurts :'(

 

Indeed, I honestly recommend to learn it, if you have ambition to make complex game modes etc. Seriously. I did exactly that having the same ambition after long period of futile frustration. 

 

The code isn't tested, so may miss something, but I hope, it's OK. 

//run what's below before HAL starts. Note: it's assumed singleplayer. no idea, how it will work in MP, but if kept server side (same, as HAL), should be OK likely. Just be sure, you spawn groups of relevant Leader's side at given marker :)

RydHQ_Included = [];
RydHQ_IncludedB = [];
RydHQ_IncludedC = [];
RydHQ_IncludedD = [];
RydHQ_IncludedE = [];
RydHQ_IncludedF = [];
RydHQ_IncludedG = [];
RydHQ_IncludedH = [];//if you have already (earlier in the code!) defined these variables with some groups inside - scratch those lines. Or instead, define them here. 
	
_presentGroups = +allGroups;//we'll cyclically check, if any new group appeared. to do so, we need to save preplaced in editor groups to sift them off. Once detected new grups will be added to this array to avoid detecting them more, than once
	
[_presentGroups] spawn //we need to run in parallel permanent loop for cyclical checks, thus we spawn parallel thread
	{
	_presentGroups = _this select 0;//we passed local array of present groups inside new thread
	
	_mySpawnmarks = //place markers on the map, one per each array above (one per Leader used). Gather their names here. 
		[
		"smarkA",
		"smarkB",
		"smarkC",
		"smarkD",
		"smarkE",
		"smarkF",
		"smarkG",
		"smarkH"
		];	
		
	while {true} do//here our permanent loop begin. It will continue till the end of scenario
		{
		sleep 5;//checks every 5 seconds - the shorter pause, the more intense code is for CPU. If too long though - spawned group may go too far from spawning mark to be detected 
		
		_newGroups = allGroups - _presentGroups;//let's obtain all new groups on the map. Just below we we'll run some code per each
		
			{
			_gp = _x;//inside foreach loop an _x means a single subsequent group from the _newGroups array. We bound it with _gp variable
			_lPos = position (leader _gp);//We obtain a position of it's TL
			//now we need to find, if _lpos is close enough to one of the markers to determine, for whom we will assign the group. It's assumed, group will not go to far during 5 secs. Instead we could check for the closest marker, but that's more complex code. 
			
				{
				_mPos = markerPos _x;//it's another foreach loop, inside which _x means subsequent single marker in the _mySpawnmarks array, that's why we introduced _gp, to use it inside here to mark a group, while outside this _x still means a group
				
				if ((_mPos distance _lPos) < 50) exitWith//we abandon the loop as soon we find close marker, thus exitWith. Don't place markers closer to each other, than used here treshold distance value or reduce value. 
					{
					switch (_x) do//depending on what marker is the close one, we assign the group for given Leader
						{
						case ("smarkA") :
							{
							RydHQ_Included pushBack _gp
							};
							
						case ("smarkB") :
							{
							RydHQ_IncludedB pushBack _gp
							};
							
						case ("smarkC") :
							{
							RydHQ_IncludedC pushBack _gp
							};
							
						case ("smarkD") :
							{
							RydHQ_IncludedD pushBack _gp
							};
							
						case ("smarkE") :
							{
							RydHQ_IncludedE pushBack _gp
							};
							
						case ("smarkF") :
							{
							RydHQ_IncludedF pushBack _gp
							};
							
						case ("smarkG") :
							{
							RydHQ_IncludedG pushBack _gp
							};
							
						case ("smarkH") :
							{
							RydHQ_IncludedH pushBack _gp
							};
						}
					}
				}
			foreach _mySpawnmarks;
			
			_presentGroups pushBack _gp//at the end let's add this group to all already checked, that will b excluded next check. 
			}
		foreach _newGroups;
		
		_presentGroups = _presentGroups - [grpNull];//just in case (to make caclulations of subtractng arrays lighter) let's clear checked groups array from already deleted groups (groups without any units may stay existing as empty, unless something chaged since I checked that, thus group will be not null until deleted via deleteGroup)
		}
	};

As for DAC - I remember from A2 times, Orcinus worked on boundig it with Hetman and the main and only problem there was, DAC not only spawned groups, but then assumed some control over them, assigning waypoints etc and whole difficulty was to prevent that before you give the group for Hetman control. Otherwise DAC and Hetman issued own orders to the same group in  parallel - chaos. Don't know, what changed in this regard in A3 DAC though. 

 

 

 

Rydy you have created the monstrous HAL, I am sure you have made a similar monstrous mission out of it

 

Haha, only released HWS, nothing more. Seriously. It's an irony - I started making Hetman because I badly wanted to play such kind of missions, but when I made it, I realized, I don't want to play anymore, creation of Hetman was much more rewarding and I prefered to continue development of new stuff than actually playing it. So at the end I rarely even use scripts, I made for fun, mainly run them for testing and for Hetman I have nothing more, than bunch of technbical testing scenarios, not fun-to-play at all. 

[ArmaMan360 94]

Indeed, I honestly recommend to learn it, if you have ambition to make complex game modes etc. Seriously. I did exactly that having the same ambition after long period of futile frustration. 

 

The code isn't tested, so may miss something, but I hope, it's OK. 

 

You are a legend. What a code wow. O.O 

I'll check it first thing at home tonight, in sha Allah O.O

 

And yes I am a totally Single player man. I am delighted at your SP code. :D

 

MP for me is only brief wasteland/king of the hill sessions :P

 

 

It's an irony - I started making Hetman because I badly wanted to play such kind of missions, but when I made it, I realized, I don't want to play anymore, creation of Hetman was much more rewarding and I prefered to continue development of new stuff than actually playing it. So at the end I rarely even use scripts, I made for fun, mainly run them for testing...

hahaha Its like I am reading about myself. I rarely play my mission "Al Inteqam" even after months of making it. Just want to keep updating it and making it better and better. :D

 

But what's greatly satisfying is that people actually enjoy what you did and thank you for it. Beats all the personal gratification to play it yourself ;)

[monyetswa808 13]

Maybe another thing to look into before the next update could be the cargo system.  As I understood, HAL will assign far away waypoints to an infantry group, and the infantry group will decide to take an empty vehicle, or will board an occupied vehicle with empty spaces, move with it to the waypoint and disembark.

 

It seems I can't get that action.  My infantry groups (vanilla AAF) will walk by foot to waypoints 4-5 km away, when there are all kinds of empty and occupied vehicles available nearby (within the "search" raidus).  In debug, i can see the group's path marked with several short waypoints (this is with the default PathFinding variable).  Maybe this makes him think he doesnt need a vehicle, but with PathFinding =0; = 100; = 5000; I get the same result.

 

Any ideas?

[virtualvikingx 19]

Again thanks for this outstanding add on!

At mission start the HETMAN script states that the script has started (Hetman 1.22 is here). This is always relayed from "Independent:"

Sometimes I see this start message twice.

Does it matter which faction starts the script? Is the double message an indication of an error/problem?

Sent from my iPhone using Tapatalk

[Rydygier 1309]

Faction doesn't matter, message should always be displayed only once (occurs once in the code, that is run once). Aren't you by a chance run simultanously both versions, addon and script? If so - don't, that would duplicate Hetman's code. If not - no idea, what reason may be unless you somehow run the script twice. 

[twistking 204]

hello rydgier,

 

first of all i want to thank you for your awesome work. i couldn't imagine that such a complex ai-mod would be pssible with scripting alone. i think it is brilliant and really demonstrates what arma is all about. i especially like your concept of trying not to mess with low level ai and you focus on compatibilty. for example i messed around with the zeus real-time-editor spawning units and it all worked fawlessly. nice!

 

unfortunately i didn't have enough time to really try every aspect of hetman, but i still had fun just messing around with it.

 

however i found some minor problems:

 

transport helicopters who finished a recon mission without new orders tend to stay hovering on their last waypoint not moving even when under heavy (!) fire. default arma behaviour for transport helis under fire would be to flee, so i think this could be a problem with hetman modifying low-level-ai in some ways for helis.

the only way to solve this was to exclude transport helis from recon and attack missions, since transport missions always seem to end with heli returning to home-base.

 

in defend-mode hetman reacts very passive. i think it would be cool, if he would retreat further back when threatened enough, but he seems to always make his last stand on the objective he chooses to defend and will fight to the last man without ever retreating.

 

in attack however hetman seemed to be a bit to aggressive even when set to have more careful personaility. hetman would often loose transport helis and support vehicles, because it sent them to far to the front. this could however have something to do with view-distance, since greater view distance mean longer AI spotting capabilities.

also i could not configure hetman to be more passive. when building smaller scenarios hetman would alsways use all forces to attack. only on very large scenarios hetman would make use of unit reserve.

 

also when playtesting only me and two of my buddies always killed the enemy commander when he had advanced to a checkpoint, but did not retreat back. i guess because, he didn't recognise our small 3-player-team as dangerous enough. i could not find a variable to make the commander retreat back earlier. perhaps he didn't consider his last checkpoint to be lost, because there were not enough of our forces (as said: three human players). there weren't enemy hetman forces either, so the commander should have retreated, i guess.

 

most other problem where probably low-level-ai related. problem with pathfinding etc....

 

**********

if you one day decide to further improve hetman i would improve on the core concept. for example give hetman understading of combined arms. tanks covering advance of lighter units and so on. i don't know if this would be too difficult to archive, but it surely would be great. probably low-level-ai would also need to get better to make hetmans battles this real.

 

**********

some questions of mine. (probably more to come, when i find soem time for actual mission building;)

 

- is the spawn point of enemy commander relevant, when commander is set to advance? would it be possible for commander to retreat back from first objective to his initial spawn? when commander is static, the spawn obviously acts as "main base". but when commander is set to advance should one construct the main base near commander spawn or near first objevtiv?

 

- with the new 3eden-editor there are now FIA units accesible for independent and opfor also (from old editor you could only use FIA units from blufor). will hetman work with these units?

 

 

*******

thanls again!

over and out!

 

********

ps: does anybody know a verly sleek, lightweight, multiplayer-friendly ambient-civilian-addon that could run alongside hetman without much of a performance impact. something like the old bis-module. just spawning some civillian relative to number of houses...

[Rydygier 1309]

Hi, thanks for the input. Will be considered, when I'll start with Hetman update. 

 

As for offensive aggresiveness/defensive passiveness, it's always hard to optimize. Either too risky either too passive. And all depends on particular situation which may be impossible to recognize via script. There was also opinions, so Hetman is too passive in offensive stance. Also code is fit to work with certain state of AI, while it was done long time ago and vanilla AI changed since. But I would like to review whole Hetman when updating and apply new knowledge, I possessed since I touched some parts last time to make it generally improved and more advance if possible. That's the intent. The reality for next months is still busy with RL work and no mind power to touch any Arma projects (not mentioning new ideas, while some appeared lately). 

 

Also as for sticking at objectives, this one may help a bit:

 

RydHQ_DefendObjectives = 4 – In “DEFEND†mode this variable controls, how many groups should have already taken objective as closest, to consider it as additional defense perimeter. If set to 0, only Leader’s position is considered as perimeter center/reference point. This variable allows to avoid situations, when alone group or too few of them are defending given perimeter;

 

Try to set it higher or even 0. 

Helis hovering under fire - don't know, but saw sometimes also out of Hetman. May have something to do with SAD or other waypoint misbehavior, as apart from assigning waypoints/combat modes/behaviors Hetman really avoids low-level AI changes except few narrow exceptions like placing smoke or flares at night. There isn't any change in heli low level behavior, I could remember, except making it land. 

 

As for Leader topic, there are such variables:

 

 

RydHQ_LRelocating = false – if true, Leader will be relocated to last captured objective (and will retreat if this objective become “lostâ€. See earlier section about objectives); 
RydBB_LRelocating = true – BB uses own HQs relocating routine. If this is set to false – that routine will be turned off and subordinated Leader’s group will stay on place, not touched by BB. Changing this value is not recommended, especially for scenarios on big maps;

 

 

 

- is the spawn point of enemy commander relevant, when commander is set to advance?

 

In what meaning relevant? As for retreating, see above variable. 

 

 

 with the new 3eden-editor there are now FIA units accesible for independent and opfor also (from old editor you could only use FIA units from blufor). will hetman work with these units?

 

Hetman will use any properly configured armed units of the Leader's side. In the newer versions should also recongnize/categorize automatically new classes, if any was added, which means RHQ arrays are now optional only. 

[twistking 204]

Thanks for the reply. you are the best!

 

i did some more playtesting with my friends last night and you are right. aggressivness just needs some fiddling around with. i further tweaked the personalities (RydHQ_Recklessness) and increased RydHQ_RapidCapt and it hit the sweet spot. hetman was less aggressive and when we pushed to his HQ he surprised us with some mechanized infantry reserves, which killed us. a second try played differently, but still hetman was less aggressive and more deliberate..., i'm really impressed :)

 

if bohemia now would improve the pathfinding, it would be perfect. ;)

 

by the way. your were right with the helis. i checked it and the heli transport is definately a vanilla low-level problem. must have been introduced in one of the latest patches. luckily excluding transport helis from recon and attack is a good workaround.

 

one last question.

in my scenario theres a blufor (hq) and a redfor hetman (hqb).

 

but blufor being the coop/player-team has way less troops. often the player squad is the main capturing force.

so i put "RydHQ_CaptLimit = 3" to allow points being captured by small blufor teams.

 

now, if i but "RydHQB_CaptLimit = 20" would HQB opfor still understand that an object is lost, if it is "only" captured by 3 blufor units. i mean for the HQ (blufor) 3 units are enough to capture, but HQB (opfor) needs 20 units to capture.

 

or in other words: does "RydHQ_CaptLimit" have any effect on loosing an objective or only on capturing? if not, how many (known?) enemy troops are needed for an objective to be lost?

 

hope that makes sense:)

 

*edit* argh. i meant "CaptLimit" not "RapidCapt" sorry. corrected now. that is why i suck at scripting. always mixing things up :-\

[Rydygier 1309]

You mean RydHQ_CaptLimit, right? It matters only for capturing. At least that number of units has to be 300 meters or closer to the objective while no more, than:

 

(RydHQ_Recklessness/(0.5 + RydHQ_Consistency))*10

 

enemies in 500 meters radius to capture the objective. 

 

To lose the objective, there need to be more enemies in 300 meters radius around taken objective, than allies in 500 meters radius while HAL checks the status of the taken objectives (each "reset"). Also check chapter 5.7 of the manual. 

[twistking 204]

sorry, i meant "CaptLimit". i always mix up these abstract terms and names. that's why i'll never be good at scripting/programming.

 

but still you answered my question;)

 

so theoretically with "RydHQcaptlimit = 5" a single soldier could still "liberate" an objective from the enemy by killing every enemy in certain radius, but could not capture for his own side, since he would need 4 more guys for captlimit = 5.

 

all i need to know. thanks again.

 

****

just one bug report.

sometimes, but not often i got a script error like:

'...isoned" | (str (group _unit)));
if not (|#|_gar then {_alive = false};
if not (_alive....'
Error undefined variable in expression: _gar

i'm pretty sure, i got this, the moment an enemy was shot, which belonged to a garrisoned unit (would make sense), but i believe i once got a similar error (something containing _alive = false) when a regular hal-controlled tank was hit by a rocket. can't remember if crew died.

however everything still seemed to run fine afterwards. so nothing gamebreaking.

[sixt 26]

Hi im having some problems getting big boss to work in the 3d editor, it just dont start, i can see big boss start in the corner but the fronts isn't assigned and the ai leaders just stand still not moving at all. Im the only one who can't getting to work? i use the script version.

 

The addon version doesn't work either in 3d editor.

 

Sixt

 

Ps there are no indicators in the rpt that the big boss shouldn't work 

[bumgie 49]

https://forums.bistudio.com/topic/189479-ai-suppress-command/

 

 

rev 135205

added commands commandSuppressiveFire and doSuppressiveFire

 

I hope rydygier considers using these commands to enhance HAL tactics.

 

Also, since I read something about you having a go at enhancing HAL. Here are some feature requests for you to consider:

 

 

Someway to change aspects of AI artillery support, other than ammo count. Especially the time it takes for AI to aim their mortars after they are given a target. Also, artillery accuracy and spread is something I would like to be able to get my hands on.

Also the distinct leader types such as a guerilla type leader or a soviet steamroller type AIs, these would bring so much variety to HAL .

 

Whatever you decide to do or not to do, I would like you to know that your work is topnotch and your attitude has always been great.

[Rydygier 1309]

For sure I'll try to make best use of any such sweet new commands, but we need to remember, HAL avoids messing with low-level AI (although doubtful, if I'll be alble to resist the temptation in this particular case :) ).

 

 

 

Also the distinct leader types such as a guerilla type leader or a soviet steamroller type AIs

 

Yes, not new idea in fact, but so far was blocked by quite fundamental obstacle: such thing is not really improving HAL, it is (requires) in fact writing new sub-HAL within existing HAL, because current code can't be adapted to handle things like eastern doctrine or guerilla warfare. But if doable, the only problem is time for this... We'll see. For sure I would like to enhance HAL also in this way. Bah. I wonder, If I would be able to grasp and implement anyhow effective self-learning algorithms (currently no idea, how) and some kind of "passive military advisor" module, but such things, if possible, are rather for Hetman 2 :), which would be written most likely from the scratch to free it at last from the flaws of HAL's basic design - it was my first major project, started, when I had no idea about many important things, while I was deciding about shape of the code fundaments, which affects and limits HAL till now.

 

 

 

Someway to change aspects of AI artillery support, other than ammo count. Especially the time it takes for AI to aim their mortars after they are given a target. Also, artillery accuracy and spread is something I would like to be able to get my hands on.

 

Since HAL's artillery handler is strictly based on FFE script, where some of these things are customizable, some of this should be doable. In fact, IIRC I didn't removed FFE's variables from the code, so let's say RydART_Acc = 0.2; in the init.sqf should improve whole salvo accuracy x10 (reducing max salvo drift from intendent impact position 10 times, it's equal 2 by default). But globally - all the arty of all the sides affected same way. As for each single shot in the salvo spread - IIRC in A3 it's handled by some vanilla, internal calculations and I can't adjust that (I did in A2's Fire At Will, FFE ancestor). Targeting time however is hard to ommit, as it's not just artificial delay, this time is used to calculate real movement vector of the target, the shorter this time, the less accurate prediction, so shortening this targeting delay may have a harsh price.