HETMAN - Artificial Leader

[Rydygier 1309]

Hm. Interesting question. Depends, what exactly means "de-simmed", didn't studied that so far. If this new system actually deletes units - that's a casaulty for HAL. If only suspends unit's visibilty and simulation, then IMO HAL will perceive them as untouched. But Hetman will still try to give them orders of course, which, if I understand correctly, de-simmed groups will ignore/not follow, as temporarily "stuck". That's why most of caching ways aren't HAL-friendly, because HAL works on big areas, far beyond normal caching distancies. Also beyond the horizon HAL's battle is conducted. 

[acoustic 82]

Did the garrison feature ever get fixed? Had weird results way back when. 

[Rydygier 1309]

It is about that report, so they don't attack near hostiles? If so, that looks to me as something out of HAL, since HAL doesn't control low level AI in general. Garrisoned troops are just positioned at certain house positions, and what they are doing there - that's up to vanilla AI or used low level AI mods. AI inside buildings AFAIK certainly may have troubles with engaging hostiles outside buildings. For example they tend to go prone, so even, if the're at window, they lost LOS. That kind of stuff. 

 

No time for now, but in any case I'll check, how garrisoning works, when time appear, meanwhile more details on garrisoning issue would be helpful. 

[acoustic 82]

I'll take a look and see.

 

I just got back into Arma. On that note, I actually did because of your return. This is by far the best AI command mod out there. The tactics used are so advanced. The AI Pathway feature (where it analyzes terrain on its way to the target), the synch attack, and the overall communication have spoiled me too much to use anything else.

 

Quick questions:

 

Does this still work with ZBE caching?

 

And, is there anyway to make HAL persistent between missions? Similar to ALiVE?

[Rydygier 1309]

Quote

Does this still work with ZBE caching?

 

I don't know frankly. From my end IMO I did nothing, that could make it not working. 

 

Quote

And, is there anyway to make HAL persistent between missions? Similar to ALiVE?

 

Frankly, I'm not familiar with ALiVE persistency nature. What exactly would be involved here, what and what way should be persistent? There's a bit of inter-session persistency in HWS scenario (which offer to save battle results in kind of quasi campaign), that kind of stuff is possible, but with additional scripting out of HAL, just like in HWS.  

[Tuntematon 3]

2 hours ago, acoustic said:

Does this still work with ZBE caching?

 

Just tested that in my mission. HAL did order groups to do stuff even when group was cached. So didint see any promblems.

 

 

Same time i tested HC.

i run HAL on server and spawned AI on HC. Everything worked fine.

[Rydygier 1309]

Quote

Everything worked fine.

 

That's great. Everybody heard? HAL supports HC. I'm so good, I adressed that request without writing anything! By willpower alone. :)

 

Quote

Just tested that in my mission. HAL did order groups to do stuff even when group was cached. So didint see any promblems.

 

Good. But the real question is, are groups actually doing ordered stuff, while being cached?

 

 

[Tuntematon 3]

27 minutes ago, Rydygier said:

 

That's great. Everybody heard? HAL supports HC. I'm so good, I adressed that request without writing anything! By willpower alone. :)

 

 

Good. But the real question is, are groups actually doing ordered stuff, while being cached?

 

 

Praise the lord Rydygier!

 

 

Well they are moving. Because nature of the mission. Only unit what are cached have mostly Res. orders.

I think that UAV recon dont work if unit is cached. Did not test that.

[Rydygier 1309]

Quote

Well they are moving. 

 

So there's some "move-when-cashed" supported or at receiving movement order they are uncached. Either way apparently BI's dynamic simulation is more fancy/cool, I thought. I have to study it closer one day. But it's weird actually, because:

 

https://community.bistudio.com/wiki/Arma_3_Dynamic_Simulation

 

Quote

No support for moving entities; entities will stop moving when disabled.

 

And the only described wake-up trigger seems a proximity of another entity. Did something change since this documentation was written?

[sixt 26]

In my test zbe caching doesn't work. It sends out forces. But it uses way lesser groups to capture objectives and becomes way more passive than without so we don't use zbe caching in our group. Also in my tests you have the hal script run both on server and on the headless client (not the addon), and the leader units have to be local to the server before it works.

Sendt fra min SM-G925F med Tapatalk

[Rydygier 1309]

Quote

 Also in my tests you have the hal script run both on server and on the headless client

 

So either in fact there are two sets of groups, divided by their locality, each controlled by own, local HAL instance (server's and HC's), which is in the result not the same as single HAL Leader controlling all groups, or both HALs are interferring, which is very bad. 

[sixt 26]

My group have an youtube channel with video from our sessions. We primarely uses hal or upsmon, mostly hal in our missions. So if you are curiuos to se hal in an dedicated enviroment then look up nzdk gaming group on youtube. We are an danish group so we speak danish. But think you can get the general idea on how hal works anyway :)

Sendt fra min SM-G925F med Tapatalk

[sixt 26]

5 hours ago, Rydygier said:

 

So either in fact there are two sets of groups, divided by their locality, each controlled by own, local HAL instance (server's and HC's), which is in the result not the same as single HAL Leader controlling all groups, or both HALs are interferring, which is very bad. 

Yeah that is correct, i thougt so also, it was some time ago i tested in on headless, and i cant remember how i did it to get it to work. 

I couldn't get to work with units local to the headless client. As i remember it i was running with RydHQ_SubSynchro = true; and needed the units to get synced to the leader and it didn't work somehow with the headless. I know it ended working normally i could see it in debug mode, that HAL only runned once. But i can see another person have got it working on headless, with it only local to the server, so just ignore the reply with the headless thing ;-)

 

But im pretty sure that HAL doesn't work good with ZBE caching.

 

[kremator 1065]

Hmmm will have to try with ZBE Caching, but it should effect the gameplay.  As soon as groups are <1km from eachother they expand to their original size. 

[target_practice 163]

Although I've had HAL sitting on my PC for ages I haven't tried making serious use of it until recently, and I gotta say, this is one hell of an impressive addon you've crafted!

I have however had some problems with unclear instructions in the manual. To start with on page 5, the manual mentions:

Quote

If the mission designer wants less than four objectives, then simply place the unneeded objectives at same position as the ultimate objective.

See the chapter “Config Variables” for info about an easier way to achieve that.

 

After looking in that chapter I find no mentions of such (though of course I could just be a bit dense).

 

Further on in section 5.10, the instructions for the name-based control mode says:

Quote

By naming chosen team leaders: "Ryd(Side letter)" + number (1-100 default, the maximum number can be changed. For example "Ryd10" or, for B side, "RydB35")

There are a number of things about this that confuse me. Firstly does the Side letter refer to a letter corresponding to one of the 4 sides, or does it refer to the alphabetical designation of leaders? (which would explain you giving an example without a letter).

Secondly, does it have to be the team leaders and not the groups that are named? Does that mean that in order for a group that has had its leader killed to remain under HAL control, relevant subordinates must also be given a unique designation?

Thirdly, not so much a confusion over instructions as it is of the technical side of the system, why is the maximum number of designations per leader a made a variable? Why not just hard code it 9999 or something?

 

[Rydygier 1309]

Quote

After looking in that chapter I find no mentions of such (though of course I could just be a bit dense).

 

To be honest I have no idea, what I had in mind when I was writing that. Weird. :) There's another way indeed however - you can set a single trigger, named RydHQ_Obj1, set its condition to true, and activation code: 

 

RydHQ_Obj2 =  RydHQ_Obj1; RydHQ_Obj3 =  RydHQ_Obj1; RydHQ_Obj4 =  RydHQ_Obj1;

 

Simple trick. 

 

Quote

Firstly does the Side letter refer to a letter corresponding to one of the 4 sides, or does it refer to the alphabetical designation of leaders?

 

Leaders' letters (none for A, as usual, or B to H). 

 

Quote

why is the maximum number of designations per leader a made a variable?

 

Yes, the maximum can be changed, 100 is by default:

 

Quote

RydHQ_NameLimit= 100 - maximum number of names used in "subNamed" method;

Why not hardcoded at some super high value? Well. Each cycle HAL will iterate through each number from 1 to that value looking for units with given name. Difference may be neglectible, unless number really high, still - why not allow to limit the number to necessary value only, if user wants? There wasn't any important consideration besides that however. 

 

Quote

 

Secondly, does it have to be the team leaders and not the groups that are named? Does that mean that in order for a group that has had its leader killed to remain under HAL control, relevant subordinates must also be given a unique designation?

 

 

 

 

Yes, team leaders (when it was designed, there was no as easy way to name a group from editor level, as it was for a unit, it came with Eden IIRC), and indeed, a valid point about unique names also for the rest of the group members (unless you want taking a group from Leader's control after TL is dead). BTW this consequence was simply overlooked. I feel, I need to explain one thing here. Hetman was a second 100% done by me mod project and the first the major. When I was writing first version, I had like 10% my current knowledge about scripting, barely knowing, what I'm doing, but with "big" plans/ambitions. Many things, I written back then was clumsy, awkward, not efficient or wrong and I was learning new things every day of creating the code. With years I fixed/improved most of such things, but some was either too rooted to eradicate/change, either was left for backward compatibility or just forgotten. This way of limited control setting is such case - truly ancient part of Hetman. Back then I had no idea, how to achieve this better way. In time I learned how, thus now we have tree ways to add a group under Leader's control in the limited mode. I wouldn't recommend this one, is probably the worst, still left in case, someone prefers it. IMO the best is Included array, some may prefer synchronization way. 

[monyetswa808 13]

Updated RPTs from more testing.

 

Below happens when I turn off Debug I and II for the enemy, but keep it on for my LeaderHQ

Error Undefined variable in expression: ryd_ws_artymarks
Error position: <RYD_WS_ArtyMarks};if (_Debug) then {>

Error Undefined variable in expression: _debug
Error position: <_Debug) then {_posM1 = getposATL (vehi>

lots and lots and lots (like 50 per second) of: 

Destroy waypoint not linked to a target: Near target acquisition is slow and may even select friendly unit.

Not displayed in game, just RPT. 

 

And finally:

Error Undefined variable in expression: _gar
Error position: <_gar) then {_alive = false};not (_alive>

 

I've been playing around with new config variables.  

At RydHQD_DefRange = 0.1; my leader D makes his Def Center on himself, and his groups stay very close together, but he always sends them off to the nearest reverse slope (Abdera on Altis) about 500m away from the Def Center.  Enemy sent in 1 mortar round and that was the end of his morale.

 

RydHQ_ReconDistance = 0.1; RydHQ_AttInfDistance = 0.1; RydHQ_AttArmDistance = 0.1; RydHQ_CaptureDistance = 0.1;

Very fun and useful for making them come into towns. Thanks for these!

[delta99 34]

On 2017-03-13 at 0:11 PM, spyderblack723 said:

 

Not necessarily. In most cases, there is sufficient idle CPU and memory to do this without issues. Often, people even report better performance compared to a single instance of Arma 3 handling everything. Give it a whirl.

 

Agreed. I usually run missions this way without issues and better performance. Mind you, smaller missions with just a few connected clients but still.

[ArmaMan360 94]

Helo Rydy..

 

I am elated to see you are working on HAL... As much as I am excited to test it, I am also equally involved with my job and other freelance work. I wish to fire up my HAL missions again asap :D

 

Thank you..

[target_practice 163]

Quick question, will HAL 1.22 be able to recognize the functions of groups and units added in Apex or will they need to be manually defined?

 

EDIT: Oh and another question, if I was to set up a BB-directed battle with multiple leaders on each side, will the individual leaders support each other (Ie with transport and artillery etc) or only their own units?

[Rydygier 1309]

Quote

will HAL 1.22 be able to recognize the functions of groups and units added in Apex or will they need to be manually defined?

 

You mean - would RHQ autofill function work properly for APEX stuff? I didn't tested this, but I think so.

 

Quote

 will the individual leaders support each other (Ie with transport and artillery etc) or only their own units?

 

No, Leaders wouldn't "lend" trasportation or support vehicles to other Leaders. Nor the arty. But as for the arty support, there's a trick possible, since Leader may decide to assign fire mission on any known enemy:

 

1. Put all groups controlled by other allied Leaders into given Leader's RydHQ_ExcludedG (for example for LeaderB define RydHQB_ExcludedG with all the groups controlled by Leaders A, C, D, E, F, G, H, (whichever are allied with B) and analogously do for the rest for allied Leaders);

 

2. Define for all these allied Leaders as true this variable:

 

Quote

RydHQ_ExInfo = false - if true - Leader receives information about the enemy also from excluded units;

 

It wasn't tested, but I think, in the result all the allied Leaders should get intel about enemy contacts from all groups controlled by all allied Leaders. And if so, if conditions are met, each Leader may direct arty fire upon every of such contacts. This way should be possible at least shared arty support. 

 

Apart from that, BB code has included some BB-level combat support, which should make one Leader temporarily turn his forces towards allied Leader's part of the front (if they seem threatened enough). That's the idea, but frankly I'm not sure, if I saw this happening at least once. It's rare circumstance, if works, which isn't sure. 

[hoizen 18]

Although it has already been discussed both here and in FFE, I still cannot for the life of me get any RHS artillery (and any third-party artillery for that matter) working with HAL. 

 

My current test mission defines:

	//includes
	RHQ_Art = ["rhs_D30_msv","rhs_D30_at_msv","rhs_2b14_82mm_msv","rhs_2s3_tv","RHS_BM21_MSV_01"];
	RHQ_SPMortars = ["rhs_2s3_tv","RHS_BM21_MSV_01"];
	RHQ_Mortars = ["rhs_D30_msv","rhs_D30_at_msv","rhs_2b14_82mm_msv"];
	RHQ_RocketArty = ["RHS_BM21_MSV_01"];

	//excludes
	RHQs_Cars = ["RHS_BM21_MSV_01"];
	RHQs_HArmor = ["rhs_2s3_tv"];

 

Debug console watch for RydHQ_SPMortar_A3, RydHQ_Mortar_A3, and RydHQ_Rocket_A3 (and subsequently RydHQ_AllArty) all include their appropriate RHS classnames.

HAL is initialized after these arrays are defined.

Test results in "All batteries are busy." on any fire mission requests.

However, the moment I place down a vanilla artillery piece, it works perfectly. 

 

EDIT:
I have also tried at various distances :P 

[Rydygier 1309]

I don't know about other possible reasons, but I see at least one here: class name have to be lowercase only. Some are, some aren't in your arrays. 

 

Sadly, picture tells me nothing valuable. Maybe in some free time I look into it, but I need to download RHS first (I personally tend to not use wip mods). 

[Rydygier 1309]

Well, I tested this issue for Podnos VDV mortar. Some custom arty pieces doesn't respond on A3 artillery commands, eg IF's mortars, so checked that first, but not the case - RHS arty work fine with doArtilleryFire command. 

 

So I went through the arty handler code, and found a reason. The reason is - lacking info in the HAL manual. :) Custom arty, that utilizes also custom, not vanilla, ammunition, require additional config. It is possible in HAL in a way analogous to FFE, but there's no info about that in the HAL manual. In this additional config you inform code, which class of custom ammo does what (HE, smoke...). FFE manual:

 

Quote

RydFFE_Add_Other([]) – here you can list classnames of other custom artillery units(lowercase only!), that should be controlled by “FFE”, if are using custom magazines (classes added here shouldn’t be added to any other “add” array). Format:

[[[list of arty pieces classnames (lowercase)],[list of magazines for these classes in order: primary (HE), rare (WP, Cluster…),secondary (used instead of HE – guided, laser…),smoke, illum]], …];

 

Example:

 

RydFFE_Add_Other =

      [

[["rds_d30_fia","rds_d30_aaf","rds_d30_csat"],["RDS_30Rnd_122mmHE_D30","RDS_30Rnd_122mmWP_D30","RDS_30Rnd_122mmLASER_D30","RDS_30Rnd_122mmSMOKE_D30","RDS_30Rnd_122mmILLUM_D30"]],

[["rds_m119_aaf"],["RDS_30Rnd_105mmHE_M119","RDS_30Rnd_105mmWP_M119","RDS_30Rnd_105mmLASER_M119","RDS_30Rnd_105mmSMOKE_M119","RDS_30Rnd_105mmILLUM_M119"]]

      ];

 

Same magazine class my by used for primary, rare and secondary ammunition. If some category isn’t or shouldn’t be used use "" (empty string) instead of classname.

 

In HAL this is RydHQ_Add_OtherArty, which should be used instead of RHQ_Mortars (RHQ_Mortars is for mortars, also custom, but only those using vanilla ammunition). Rest works same way. 

 

I prepared simplistic demo mission including HAL 122 scripts:

 

Custom arty demo

 

Setup may be not accurate (didn't tested, which ammo is smoke or illum, and as for the rest I put HE everywhere). Tested, works fine now (run it in editor, observe a tank ahead, open map, watch debug markers, at SPLASH close map to see booms around the tank).

 

Here's init config:

 

RydHQ_Wait = 2;

RydHQ_Debug = true;
RydHQ_DebugII = true;
RydHQ_ChatDebug = true;
RydHQ_GroupMarks = [west,east,resistance,civilian];

RHQ_Art = ["rhs_2b14_82mm_vdv"];

/*[[[list of arty pieces classnames (lowercase)],[list of magazines for these classes in order: primary (HE), rare (WP, Cluster…),secondary (used instead of HE – guided, laser…),smoke, illum]], …];
Same magazine class my by used for primary, rare and secondary ammunition. If some category isn’t or shouldn’t be used use "" (empty string) instead of classname.*/

RydHQ_Add_OtherArty = [[["rhs_2b14_82mm_vdv"],["rhs_mag_3vo18_10","rhs_mag_3vo18_10","rhs_mag_3vo18_10","",""]]];

nul = [] execVM "RydHQInit.sqf";

Note, it's single version of Podnos mortar config. Analogously you have to add all the rest artillery with proper ammunition lists to this array. And remember, arty piece classes has to be all lowercase. 

[hoizen 18]

Wonderful work, Rydygier. That did the trick.

 

Thanks for your help. For anyone else who may also have this struggle, my BM-21s and Podnos were working with:

RydHQ_Add_OtherArty = [
    [["rhs_2b14_82mm_vdv"],["rhs_mag_3vo18_10","rhs_mag_3vo18_10","rhs_mag_3vo18_10","",""]],
    [["rhs_bm21_msv_01"],["rhs_mag_40Rnd_122mm_rockets","rhs_mag_40Rnd_122mm_rockets","rhs_mag_40Rnd_122mm_rockets","",""]]
];