HETMAN - Artificial Leader

[Rydygier 1309]

1. Shouldn't be a problem IMO (if groups, then ExcludedG, I assume?), but not 100% sure. Just try, if there will be a problem, it will leave a trace in RPT logs;

2. 

 

Quote

RydHQ_NObj – initially equal to 1. It is positive integer of range 1 to 5. Indicates, which objective is currently a target. 5 means, that all objectives are taken;

 

It may decrease, if objective once taken is lost. Also currently taken objective triggers should be held here: takenObjectives = (group LeaderHQ) getVariable ["RydHQ_Taken",[]]; (it's internal variable)

 

On the side note, Big Boss mode is different story, above will not indicate properly BB objectives progress, but I assume, you don't use BB. 

 

3. Well, additional stuff to do (drawing and showing markers) has to have some impact on CPU load. How big? Don't know. I guesstimate it's negligible. BTW HAL tolerates well SQF execution delays due to overloaded CPU schedule, timing is not crucial here, just orders and status checks will be more delayed. 

 

 

[b3lx 161]

I have a problem that happened three times already which is some armoured group moves out and ends up on [0,0,0]. Any clue?

 

Have another question. Is there a way to get a spawned group to be instantly recognised by HAL?

[Rydygier 1309]

Quote

Any clue?

 

Data needed. RPT log, vanilla repro mission... In general [0,0,0] is characteristic output of the code, that tries to obtain a position of a non-existent (anymore) object (objNull). Question is, why and what is null/not existing. Unless the reason is different in this case. 

 

Quote

Is there a way to get a spawned group to be instantly recognised by HAL?

 

What means recognized? If "sent with some orders", the no, not instantly. In default control mode (and in limited mode if group put into Included array), with the next HAL's cycle group will be taken into account. You can only try to shorten cycle interval, but see description:

 

Quote

RydHQ_CommDelay =1 - this is the multiplier of the pause between the end of one cycle and the start of a new one for the given Leader. I advise caution with values smaller than 1; the flow of information can possibly be significantly perturbed by low values. Values higher than 1 are for realism fans who would like the delivery of orders to take as much time as it would in reality.

 

[b3lx 161]

20 minutes ago, Rydygier said:

with the next HAL's cycle group will be taken into account.

That's enough for me. I have a reinforcements script so units will wait until they are called in by HAL.

 

21 minutes ago, Rydygier said:

Data needed. RPT log, vanilla repro mission...

 

I'm testing a faction mod I'm making (already made a RHQarray for it ),  so I really just wanted to know if there was any known issue that could put me in the right track. I'll see if it happens in vanilla as well. Thanks

 

 

[redarmy 422]

@Rydygier Is the leader supposed to skip REC sometimes,and go directly for a CAP?

Im seeing this alot,also noticing the leader is sending out groups to CAP OBJ2 ,before OBJ1 has been taken or assaulted.

The first OBJ (OBJ1) gets REC asigned to it and it works as i expect,but it seems after enemy contact is known,CAP orders are issued to the next objectives(REC also is being ordered at same time strangely)

 

Also,when groups have finished REC of first OBJ(It has no enemy,i use it as a "staging area") the leader (genius) sends ALL groups on his side(10) to CAP,leaving no units in reserve save for one spec ops team at Leaders position.

 

Is here anyway to reduce the amount of groups moving to CAP an OBJ? It gets extremely cluttered and destroys mission pacing,chance for flanking by leader,and worst of all,frame rate.I cannot use the variables on individual groups for example to keep in reserve as he groups are respawning,thus losing the group name,so variable would be useless.

 

These are my config variables at present,with the leader in question being "RydHQ_"

 

Quote

RydHQ_ChatDebug=  true;

RydHQB_Excluded  =  [ei200,ei1044,ei233,ei234,ei206,ei2049,ei203,ei2039];

RydHQ_ExInfo=  true;

RydHQB_ExInfo=  true;

RydHQ_GroupMarks=[0,resistance,0];

RydHQ_SAmmo=  true;

RydHQ_SRep=  true;

RydHQ_Flare  =  true;

RydHQB_Flare  =  true;

RydHQ_KnowTL=  true;

RydxHQ_AIChatDensity  =  10; 

RydHQ_Rush  =  true; 

RydHQ_Flee  =  false;

RydHQB_Flee  =  false;
 
RydHQ_Wait  =  100;

RydHQ_Debug = true;

RydHQB_Berserk  =  true; 

RydHQB_AAO  =  true; 

RydHQ_CaptLimit  =  10;

RydHQB_CaptLimit  =  10;

RydHQ_UnlimitedCapt=  false;

RydHQB_UnlimitedCapt=  false;

RydHQ_MAtt  =  true;

RydHQB_MAtt  =  true;

RydHQ_ObjRadius1  =  600; 

RydHQB_ObjRadius1  =  600;

RydHQ_Personality="GENIUS";

RydHQB_Personality="GENIUS";

 

Would appreciate some tips,i have gone over the PDF alot and have not found a solution to mentioned issues.

I understand HAL can be very dynamic in nature,but thought i should make sure and ask.

Cheers

[Rydygier 1309]

Not sure, if this is desired, depends. Skipping recon stage usually is very rare by design, but from what I see in the code, it may be often with AAO enabled (try to disable AAO and compare) and some enemies known. Perhaps something to correct in the future, not sure, need to analyze this code closely first. 

[redarmy 422]

8 minutes ago, Rydygier said:

Not sure, if this is desired, depends. Skipping recon stage usually is very rare by design, but from what I see in the code, it may be often with AAO enabled (try to disable AAO and compare) and some enemies known. Perhaps something to correct in the future, not sure, need to analyze this code closely first. 

AAO was on the other leader,sorry for confusion.

 

And i just had a thought 

 

"

RydHQ_CaptLimit =10"  in PDF it states this is UNITS,not groups.

 

I just started using ZBE cache system,it caches all units but group leader,it may be whats causing the vast amount of groups to all move to one OBJ.Counting an actual 8 man group as 1 unit for example.Il check,also il turn off AAO for other leader too.

 

cheers

 

[Rydygier 1309]

Well, I can only add, according to HQOrders.sqf logic indeed capturing may/will occur even without/along with rec, if enemy is known. That however doesn't explain, why it reaches more, than one objective at once without AAO, and why amount of groups is unexpected. Hetman's logic is complex enough to get me lost too, as I didn't work with it long time. Also some specific scenario setting may trigger not expected course of actions. Mods possibly too, although ZBE caching was intended to work with HAL, and IIRC, it doesn't delete anything, just hide/freeze.One day I'll probably review HAL's code again, not sure when it happen though. 

[redarmy 422]

12 minutes ago, Rydygier said:

Well, I can only add, according to HQOrders.sqf logic indeed capturing may/will occur even without/along with rec, if enemy is known. That however doesn't explain, why it reaches more, than one objective at once without AAO, and why amount of groups is unexpected. Hetman's logic is complex enough to get me lost too, as I didn't work with it long time. Also some specific scenario setting may trigger not expected course of actions. Mods possibly too, although ZBE caching was intended to work with HAL, and IIRC, it doesn't delete anything, just hide/freeze.One day I'll probably review HAL's code again, not sure when it happen though. 

Quote

Also some specific scenario setting may trigger not expected course of actions. Mods possibly too, although ZBE caching was intended to work with HAL,

Specific scenario settings,yep,it can be a nightmare to trouble shoot..However i just ran a test with this

 

Quote

RydHQ_CaptLimit  =  1;

And hay presto! HAL sent an appropriate amount of groups again to capture (3 + me,or 4 groups) 

 

More importantly,(i failed to mention before,HAL was always sending armour,vehicles etc in first,and i dont think thats normal behaviour?) However now it is INF and vehicles holding back in idle(mainly armour composition) quite strange,il do more testing.If i find anything significant il let you know.

 

EDIT : Can you confirm AAO setting is to be applied to EACH leader HQ or is it universal?

[Rydygier 1309]

Quote

And hay presto! HAL sent an appropriate amount of groups again to capture (3 + me,or 4 groups) 

 

With captlimit 1? Odd, but OK then. :)

 

If HAL sends first infantry or armored/soft vehicles may vary depending on kind of enemy, available, not occupied/reserved forces, distance, chance etc., so all is possible here and factors are many. 

 

AAO works per Leader, not universal. 

[redarmy 422]

13 minutes ago, Rydygier said:

 

With captlimit 1? Odd, but OK then. :)

 

If HAL sends first infantry or armored/soft vehicles may vary depending on kind of enemy, available, not occupied/reserved forces, distance, chance etc., so all is possible here and factors are many. 

 

AAO works per Leader, not universal. 

So something is amiss here...but i see an interesting pattern....so my final results of testing this...

 

When i put 

RydHQ_CaptLimit  =  10; originally,i had the issue that leader sent ALL almost of my groups(over 10)

 

i changed it to 

RydHQ_CaptLimit  =  1;  and it sent 4 groups...

 

i completely removed 

RydHQ_CaptLimit  =   variable from init.sqf,and it sent  3 :) And three was always default amount with HETMAN as far as i recall.

 

So.....it seems like these variables in my init.sqf were "stacking" ,for what reason i do not know. Through debug i can also see REC showing up twice the amount.Where usually theres one REC position,another appears rite next to it(causing 6 groups to recon). 

 

 

 

[delta99 34]

On 2018-10-18 at 3:20 AM, redarmy said:

MCC has always been adding new features,possibly something in a new update broke compatibility.

I had no modules down what so ever.

 

Possibly but typically not. If you load MCC but don't actually use anything it doesn't do much if anything to a mission. Sure there are some mods its not compatible with but those are usually ones that are watching for mods like MCC and disabling them.

[redarmy 422]

On 10/30/2018 at 3:41 AM, delta99 said:

 

Possibly but typically not. If you load MCC but don't actually use anything it doesn't do much if anything to a mission. Sure there are some mods its not compatible with but those are usually ones that are watching for mods like MCC and disabling them.

I dont know,iv had trouble with MCC and other stuff before...for example when running MCC and using the BIS high command module,after a few minutes the high command group icons you get to see(and that of spotted enemies) dissapear,sometimes re appear and dissapear  again. So just to be safe i run without it.

 

Its extremely hard to narrow down issues,and testing is so time consuming so in order to use HETMAN i heavily removed as many mods as i can,MCC had to go.

 

@Rydygier I was debugging a few things and noticed that units still withdraw (with debug mark black triangle,with letter A,beside it) even when i have this variable included

 

Quote

RydHQ_Withdraw  =  0;

Am i missing something? Im attempting to have units/groups not withdraw as they are respawning and i would prefer a group with one man left to outright die than retreat so the whole group can respawn.

 

I even have

 

Quote

RydHQ_Flee  =  false;    and  
RydHQ_Berserk  =  true;

 

both in the init.sqf. Its possible its a conflict on my end,if so il figure it out i just need to know if the variables above should indeed stop units from withdraw/rest missions.

 

cheers

[Rydygier 1309]

RydHQ_Withdraw controls probability of withdrawal of groups facing overwhelming enemy forces. Same kind of order, "resting", marked by same black triangle, is issued also for groups considered as combat ineffective due to wounds/losses, low amount of ammo or fuel. This second case is not dependent on RydHQ_Withdraw setting. 

 

In fact, there's no variable to limit withdrawal of combat ineffective groups. You can try to fool Hetman by giving to each group such code: someGroupName setVariable [("Resting" + (str someGroupName)),true]; but if you do, may occur weird side effects depending, if and how logic is reffering to group having resting status. Not sure, but not recommended. For example tagged as "resting" groups may be excluded from all other activities IIRC. 

 

I suppose, you would need to run parallel code, that would monitor group losses, and if too high, artificially kill/delete/clear the rest, best as part of respawn loop. Or perhaps better do so for each group with said someGroupName getVariable [("Resting" + (str someGroupName)),false]; returning true - prefferably AFTER adding this group-to-be-deleted to excluded groups array and applying someGroupName setVariable ["RydHQ_MIA",true]; to make sure, you do not deleting group in the middle of its task. 

[b3lx 161]

About an issue a few posts ago: I've been using HAL with VCOM, and having AI PATHING disabled in VCOM options seems to make it work fine together.

 

I'm not a fan of having one guy occupying his own group after the rest were killed, so I use a script that checks for single unit groups and groups each one of them to the nearest group. Would that create some problem with HAL? So far I've seen nothing wrong.

[Rydygier 1309]

Shouldn't do any harm (probably). In fact, under certain circumstancies, at each "reset", HAL also may combine decimated foot infantry groups, if resting close enough together. 

[redarmy 422]

17 hours ago, Rydygier said:

RydHQ_Withdraw controls probability of withdrawal of groups facing overwhelming enemy forces. Same kind of order, "resting", marked by same black triangle, is issued also for groups considered as combat ineffective due to wounds/losses, low amount of ammo or fuel. This second case is not dependent on RydHQ_Withdraw setting. 

 

In fact, there's no variable to limit withdrawal of combat ineffective groups. You can try to fool Hetman by giving to each group such code: someGroupName setVariable [("Resting" + (str someGroupName)),true]; but if you do, may occur weird side effects depending, if and how logic is reffering to group having resting status. Not sure, but not recommended. For example tagged as "resting" groups may be excluded from all other activities IIRC. 

 

I suppose, you would need to run parallel code, that would monitor group losses, and if too high, artificially kill/delete/clear the rest, best as part of respawn loop. Or perhaps better do so for each group with said someGroupName getVariable [("Resting" + (str someGroupName)),false]; returning true - prefferably AFTER adding this group-to-be-deleted to excluded groups array and applying someGroupName setVariable ["RydHQ_MIA",true]; to make sure, you do not deleting group in the middle of its task. 

Thanks Ryd , i cannot fool Hetman by using someGroupName setVariable [("Resting" + (str someGroupName)),true]; as groups respawn(at mission start) .

So,they loose group names.

 

It seems too much of an issue so i am going to use a work around of involving all rest units who go to certain rest areas to get them combat effective again.

 

Cheers

[Rydygier 1309]

OK. BTW code (group unitObject) stands for unit's group name, so every group anytime has a name possible to obtain. Example: (group player) returns player's group name even, if you never gave a name manually in editor. Even easier - such code (not tested) pasted into init.sqf will run in parallel and should every 30 seconds kill last remnant of every group, that contains less than two units and clear that group (may be redundant):

 

nul = [] spawn
	{
	while {true} do
		{
		sleep 30;
		
			{
			if (({alive _x} count (units _x)) < 2) then
				{
					{
					_x setDamage 1//and here _x stands for given member of that group from all of them one by one
					}
				foreach (units _x);//_x here stands for inspected group name, one of all of them
				deleteGroup _x;
				}
			}
		foreach allGroups;
		};
	};

 

Every group, so beware, if group by default, at start has one unit only, will be deleted too. Additional conditions needed to avoid that, for example this: 

 

nul = [] spawn
	{
	while {true} do
		{
		sleep 30;
		
			{
			if (_x getVariable [("Resting" + (str _x)),false]) then
				{
				if (({alive _x} count (units _x)) < 2) then
					{
						{
						_x setDamage 1//and here _x stands for given member of that group from all of them one by one
						}
					foreach (units _x);//_x here stands for inspected group name, one of all of them
					deleteGroup _x;
					}
				}
			}
		foreach allGroups;
		};
	};

Will check -> delete such 1-man groups only if also with "Resting" status. Not tested either, typos possible. 

[LDU30 5]

 You can create compatibility of the artillery system, with the Iron Front arma 3 lite mod ? thanks 

 

Great mod !

[Rydygier 1309]

I don't know current status of the arty from said mod (haven't it now, didn't used long time, something might change), but if custom artillery is compatible with vanilla artillery system/computer, then AFAIK it should be possible to set it up for HAL using present init variables as for any other custom arty. Otherwise - there's nothing, I could do. 

 

In the Ragnarok'44 scenario in fact HAL is used with IF mortars. Didn't tested that long time, but setup there should look like this for the mortars, I believe:

 

//RHQ_Mortars = ["lib_grwr34","lib_bm37"];//this one should stay disabled probably
RHQ_Static = ["lib_grwr34","lib_bm37"]; 
RHQ_Art = ["lib_grwr34","lib_bm37"];  

 

RydHQ_Add_OtherArty = 
    [
    [["lib_bm37"],["LIB_8Rnd_82mmHE_BM37","LIB_8Rnd_82mmHE_BM37",
    "LIB_8Rnd_82mmHE_BM37","",""]],

    [["lib_grwr34"],["LIB_8Rnd_81mmHE_GRWR34","LIB_8Rnd_81mmHE_GRWR34",
    "LIB_8Rnd_81mmHE_GRWR34","",""]]
    ];

 

and explanation based on another mod example:

 

 

That much I can help right now. 

[Rydygier 1309]

I'm testing now some IFA3 arty with HAL using above config method. In general it works, but there's an issue: IFA3 arty, if used manually via artillery computer, shot at given ranges with no problem. But as for scripted arty fire (doArtilleryFire), it won't shot at the same target if was close enough (arty markers on place, but no actual shelling occurs). To fix that, target need to be moved much farther. That indicates some problems with scripted arty fire ranges. Maybe that's the problem with arty commands, like inRangeOfArtillery and doArtilleryFire or maybe something is wrong with these arty pieces? There's no such problem with vanilla arty though, which suggest mod problem. So, one can construct properly working IFA arty HAL setup, but with described issue there may occur "fake salvos" when targets closer, than some unknown distance, that varies depending on type of arty.   

[Rydygier 1309]

So, here is complete init config for all IFA3 arty pieces, I found (hopefully didn't miss any). Tested each  - all shoot under HAL control (except for described issue and the fact, Russian mortar model on uneven ground tend to flip upside down :) ):

 

RHQ_Static = ["lib_grwr34","lib_grwr34_g","lib_bm37","lib_lefh18","lib_flak_36_arty","lib_nebelwerfer41","lib_nebelwerfer41_camo","lib_nebelwerfer41_gelbbraun","lib_us6_bm13_dlv","lib_m2_60"];//add here also Katyushas' classes, if they shouldn't be moved around 
RHQ_Art = ["lib_grwr34","lib_grwr34_g","lib_bm37","lib_lefh18","lib_flak_36_arty","lib_nebelwerfer41","lib_nebelwerfer41_camo","lib_nebelwerfer41_gelbbraun","lib_us6_bm13","lib_us6_bm13_dlv","lib_m2_60"];  


RydHQ_Add_OtherArty = 
	[
	[["lib_bm37"],["LIB_8Rnd_82mmHE_BM37","LIB_8Rnd_82mmHE_BM37","LIB_8Rnd_82mmHE_BM37","",""]],
	[["lib_grwr34","lib_grwr34_g"],["LIB_8Rnd_81mmHE_GRWR34","LIB_8Rnd_81mmHE_GRWR34","LIB_8Rnd_81mmHE_GRWR34","",""]],
	[["lib_lefh18"],["LIB_20x_Shell_105L28_Gr39HlC_HE","LIB_20x_Shell_105L28_Gr38_HE","",""]],
	[["lib_flak_36_arty"],["LIB_45x_SprGr_KwK36_HE","LIB_45x_SprGr_KwK36_HE","",""]],
	[["lib_nebelwerfer41","lib_nebelwerfer41_camo","lib_nebelwerfer41_gelbbraun"],["LIB_6Rnd_NbW41","LIB_6Rnd_NbW41","",""]],
	[["lib_us6_bm13","lib_us6_bm13_dlv"],["LIB_16Rnd_BM13","LIB_16Rnd_BM13","",""]],
	[["lib_m2_60"],["LIB_8Rnd_60mmHE_M2","LIB_8Rnd_60mmHE_M2","",""]]
	];

 

Note, WW2 rocket arty has huge dispersion radius. What HAL considers safe distance, isn't safe at all for Nebelwerfers and Katyushas. Accidental "Friendly fire" possible. 

[semiconductor 309]

Hey there!

 

Just stumbled upon this mod and it looks really exiting. However, it isn't clear from the first glance whether it supports multiplayer or not.

Could you please clarify that? :)

[Rydygier 1309]

Some time ago it was made MP compatible and AFAIK ppl are using HAL in MP.  Should be run server side only (HAL's code enforces that anyway). 

[Rydygier 1309]

BTW, you may be interested in this edition, currently under much more dynamic development: