HETMAN - Artificial Commander

[bumgie 49]

By curiosity - rest of HAC is working fine on this headless client something?

It appears so. I have made an mission with 185 Ai units under an single HAC commander. The entire HAC and those units are running under a headless client.

Server FPS is always over 45 but the Headless client has a frame rate of avg. 25 - avg. 10. Lowest momentary values are around 6-8 FPS.

First thing that needs to be done is spawn units under Headless client. That is why I was asking about the naming of the troops.

Making HAC run under headless client is rather easy. You only need to check that the entity running HAC is Headless Client in the RydHQinit.sqf (might not be the exact name of the file, cant check right now.)

I can later provide more articulate examples of scripts if someone wants them.

Overall the only problems I have faced has been the artillery issue that like you said is something I need to debug more carefully.

Second issue is that I need to run HAC script on the entity that also has the controllable units as local to it.

Example; Headless Client has 100 units local to him. Server is running HAC and does not take control of the troops (at least when not using sub all mode. Need to test this further... It might be that i need to make RydHQ_Included an public variable.)

Single player could also benefit from running headless client as an way of utilizing more unused cores on the pc.

PS. What kind of unit amounts have you guys used an single HAC commander for? What about BigBoss ?

PPS. What are ideal group sizes for HAC? Does it Benefit more from big groups or small ones ?

Edited February 28, 2013 by Bumgie
readability improvements

[Rydygier 1302]

Ad PS - In my tests it varies. Average may be 10-20. Number of groups under one Leader shouldn't affect directly HAC's code performance. Delays between cycles would be longer, but this is intended. In general there is a bit less CPU power used by HAC code, when eg 30 groups are under one Leader, than when there are 2 Leaders, each with 15 groups etc. At least I think so (more loops are running simultanously in second case). Of course the more groups in move, or especially in fight, the worse overall performance due to fsms (wonder, if not would be better in Arma, that all groups are controlled via sinle loop iterating all groups each cycle than by separate fsms for each group).

Big Boss' problem is, that its full potential can be shown with amount of groups, that in fact is too much for PC.

Add PPS - not sure, what is better for HAC performance - many small groups or few numerous. Its code will iterate each cycle through every unit anyway, so perhaps slightly better is to have fewer, but bigger groups than eg horde of single units. Overall, I can guess, the bigger group, the heavier formation.fsm execution, indeed only guessing tough. In general I recommend to use standard Arma's groups and/or single units. Not recommended are strange combinations, as eg chopper with tank in one group.

Server is running HAC and does not take control of the troops (at least when not using sub all mode.

This leads to the conclusion, that this is something about locality issue inside limited control code itself. I do not know for example, if two units, not local to each other, can be synchronized. "Included" array visible from HAC's side can be better solution here. But - tested BigBoss demo, where syncing method is used, and player, as team leader, is client side, while LeaderHQ is local to the server, and this worked fine - player and his group was properly controlled, so syncing was fine. Perhaps at least Leader must be for some reason server side (precisely - local to the machine, where HAC code is running), and his army can be client-side then?

[Rydygier 1302]

Some good news - seems, that probably found solution, how to fix spotted earlier bug, when client side human controlled TL receives task entries without destination and description if is not alone in his group. Not sure, perhaps something else still will be broken here, but in my tests that bug is gone. We will see...

So. Seems, that I'm now waiting only for more sounds and perhaps new manual language corrections...

[Vigil Vindex 64]

Some good news - seems, that probably found solution, how to fix spotted earlier bug, when client side human controlled TL receives task entries without destination and description if is not alone in his group. Not sure, perhaps something else still will be broken here, but in my tests that bug is gone. We will see...

So. Seems, that I'm now waiting only for more sounds and perhaps new manual language corrections...

Excellent news! I can help with having a look at the English manual if you want. I will also see if I can chase up some more voices :)

[Rydygier 1302]

Thanks! Someone else told, that will do manual corrections, but this was some weeks ago, and do not know, if he has time for that, so you're welcome to help me with that, if you wish. Whoever will do that - I just need manual without linguistic errors, that hinder comprehension. :) As for voices - I need minimum two more, maximal four. Of course, any addtional can be added too, if will be very good, so worthy additional MBs. Anyway - then I'll choose from these two, one for Leader's voice, another for battery voice, rest would be soldiers' voices.

Edited March 1, 2013 by Rydygier

[sidekilla09 11]

Since the release of A3 CBA I been using HAC with Arma 3 and its amazing.. Works just as fine as ArmA 2 using the Pbo version of HAC. It helps a lot when I just want to throw some units on the map :)

[Rydygier 1302]

That's great news! Some parts of HAC perhaps will anyway need tweaking for A3, besides default class set of course. Mostly because A3 may allow to do some things simplier/easier/better (eg Arty handling?), and perhaps will allow things not possible in A2 HAC version at all, and because of that never implemented/invented. Also some minor parts of HAC's code are there beacuse of A2 AI "specifity", so possible, that A3 AI differs there too, what means another changes. We will see. I'm planning to wait with any changes for A3 HAC at least to the moment of releasing A3 1.0, to be sure, that A3's shape is final&stable&reliable enough to work with it without risk, that they will change something, that will make just made code obsolete/invalid.

[euly 0]

Since the release of A3 CBA I been using HAC with Arma 3 and its amazing.. Works just as fine as ArmA 2 using the Pbo version of HAC. It helps a lot when I just want to throw some units on the map :)

Would you be willing to share your mission? I would like to see how to set up HAC with Alpha.

[sidekilla09 11]

Would you be willing to share your mission? I would like to see how to set up HAC with Alpha.

I wil galdly but how do i go by sharing this mission with you?

[Vigil Vindex 64]

I wil galdly but how do i go by sharing this mission with you?

You could upload it somewhere and share the link in this thread, there are plenty of free file hosting sites like here: http://www.filedropper.com/

[bumgie 49]

Hey rydygier.

Do you have any interest in moving your scripts HAC and FAW to arma 3?

I have enjoyed making missions with them and really appreciate your efforts.

One thing though. Could you consider commenting more in your code? I know that you encourage people to use your works and it would really help if you comented more. Especially those nested foreach and If sections can be really hard to read and comprehend.

Just maybe a single // line explaining what is happening in this segment of foreach etc.

Thanks rydygier.

[Wilsdorf 1]

Thanks Rydgier, I use your script so many times!! :)

Just one thing, I notice: I found that space between each group is too important. It's nice for motorized / mechanised group but not for infantry group.

I try to play with the "Front" variable but I see no difference.

Is there any possibility to reduce the space between group?

[Rydygier 1302]

As for A3 - see previous page. Yes, I have such interest. There is even info, that present HAC version is working under A3. Not 100%, I guess.

Commenting - almost never did that in HAC code, because simply I won't to distract when I'm during coding some concept/idea. Especially, that English isn't my native language, and such comments always need too much attention and time to me. Time, that I prefer to use for more coding. Time consuming without any warranty of intelligibility. Also, I think, I'm simply to lazy to go through all made already code and supplement it with commentaries, that would reflect code logics. Too much of that. Besides - this will make files bigger (there is many foreach segments and such)... And, as for me, commentaries more makes code messy than clear, more difficult to track the flow, when you must sift of commentaries. Not sure, perhaps some day will do that on special, separate copy of HAC's scripts set, there is some hope, just because indeed, I encourage people to use/change my code in any way they want. But, if someone is interested in some particular part of code - feel free to ask about it. Currently I'm still waiting for voices and manual corrections, so I have more time for explaining things, even if meanwhile I'm working on assymatric warfare project.

---------- Post added at 13:36 ---------- Previous post was at 13:28 ----------

@Wilsdorf

Do you mean space between groups placed on map (dependent on mission maker), or rather between group memebers in formations (dependent on formation.fsm, I think)? I'm not sure, what do you mean.

[Wilsdorf 1]

Sorry I mean between group placed on map, formation between groups part of a platoon, not between teams part of a group.

[Rydygier 1302]

Hmm. Can't you just replace groups on map in editor then to fit your needs? HAC anyway will not combine groups in platoons. Each group is treated by him separatelly. He will choose up to several groups for some tasks, eg attack, but then distancies between task waypoints of each group are adjusted to vanilla AI's spot&engage distancies to achieve as much as possible effective flanking.

[Wilsdorf 1]

So It doesn't take into account other groups and move in function of the others ?

[Rydygier 1302]

HAC will count, how many groups are sent to fulfill given task, and its waypoints around target are placed, as said, not randomly, but with effective flanking in mind, but in most cases will not check, how many groups at the moment occupies given territory (except for support missions, capturing missions and some aspects of defensive mode). Also will not control for maintaining "proper groups density" groups' paths. Such on-the-fly maintaining would be CPU heavy, and frankly - do not know, why should be done such thing. There is only experimental, turned off by default, synchro mode, where eg groups sent agains given enemy groups have synchronized flanking waypoints to achieve better cooperation (group after reaching flanking position will wait for rest before sturm), but this is troublemaking sometimes.

HAC's control is task based. He has certain amount of groups, objectives to take one by one, some core plan (simplified: recon-eliminate enemy-capture objective). Each objective or spotted enemy group etc means task to do. Appriopriate amount of best available groups will be sent with given task. So this is not anything in kind of dynamic group swarm/net movement control, where position or replacement of each group would be dependent on other groups actual position/movements. Such thing also is doable, I think, even quite interesting, but this is not a HAC, rather idea for another project (HAC development stage anyway is finished for A2 except upcoming version).

In other words - HAC will not artifically construct and maintain any kind of front line (unless you will set up HAC in defensive mode with perimeter constructed that way, but such front line will be static). As is in real - front lines can and will emerge sometimes, but only in dynamic way, as inevitable consequence of sending groups against enemy with flanking and contr-flanking goal, not as effect of direct decision of forming such line.

Edited March 10, 2013 by Rydygier

[odyseus 19]

hey guys i set up a dedicated server, but my mission never kicks in after the count down. Does anybody know what could it be? I am using the hetman script.

[Rydygier 1302]

All right people, most of you are probably anyway busy with A3 alpha, but I think, that I need to release new HAC version for A2 soon. If anybody still thinks about recordings - it is last moment to provide me the sound files for upcoming version. Otherwise of course additional voices can be added in the future, and meanwhile Leader and artillery will use same voices, as the other. I need only to update manual, so release should be matter of several days at most. As for radio comms version - I think, that beacuse of keeping package with low MB, for addon version will be available chosen by me set, same would be given for script version. Another two or more versions will be uploaded here separatelly, so users of script HAC version will be able to replace files with any other sounds version by direct overwriting the oggs in Sound folder. Same way of course they will be able to replace oggs with own voices, if wanted.

[Rydygier 1302]

HAC 1.43 Released...

Full changelog from 1.0beta to 1.43:

v1.43

- improved capturing;

- optional dynamic radio chatter background generated according to HAC activity;

- additional demo missions for certain advanced features;

- optional hiding HQ on foot inside buildings at relocating;

- optional keeping HQ in one spot for BB mode;

- optional manual setting for attack ratio;

- optional close known enemy awareness for all TL;

- several fixes and improvements.

Details:

1. Improved capturing;

In normal and BB modes now progress, if no resistance encountered, should go faster. Now only loosing objectives is checked on reset. Taking check is moved directly into capturing order code.

2. Optional dynamic radio chatter background generated according to real HAC activity;

Use RydxHQ_AIChatDensity (default: 10, shared) to set percentage chance, that given circumstance will generate radio message heard by players. This is mostly for immersion and for better situational awareness. There are some mechanisms, that will prevent flooding with chatter even with 100%, but for high values noted sometimes choking effect, when comms suffers huge delay, and then are all generated quickly one by one. Logically, the more groups of player's side, the bigger chance for situation, where chat will be generated. Each time this percentage chance is checked. Note also "x" in variable name. For some reason part of shared variables will from now contain that letter. See manual to check, which values are affected.

In the first post added link to alternative sound sets for script version.

3. additional demo missions for certain advanced features;

Demos for : Air cargo, artillery, custom defense, ammo drop, two for normal HAC, two for BB. Now all for addon version to reduce MBs.

4. optional hiding HQ on foot inside buildings at relocating;

Now RydHQ_LRelocating = false (default) turns off waypoints for HQ completely. If on - there is an option to keep HQ inside buildings, if any in 100 meters radius around relocation waypoint. Use RydHQ_GetHQInside = true. False by default.

5. optional keeping HQ in one spot for BB mode;

RydBB_LRelocating = false; (shared) for keeping all Leaders in BB on place, without relocation. Not recommended, as Leader position is key reference point for maneuver calculations. If distance between Leader and objective will be too big, army will suffer huge delays, as some groups may walk the whole map and back and will lose effectiveness. Still - was requested and can be harmless on small-medium battlefields.

6. several fixes and improvements.

Quite a few minor, some bigger. Do not remember all at the moment, one example: in many cases waypoint position will be recalculated in such way, that target spot will be not placed too close road (so groups will not block roads so often, and a bit lesser chance for "car accidents") or on object. Still, depending of group's size and formation, some group members will stay on roads sometimes, so no 100% guarantee. Another: fixed spotted lately problem with cargo, when group just after disembarking is embarking again, what cripples later part of order execution.

New config variables:

RydxHQ_GPauseActive = false – when set as true, game will be paused with on screen message each time player receive new order (was there earlier, but not documented);

RydHQ_ReconReserve = 0.3 * (0.5 + RydHQ_Circumspection) – multiplication of total number of available in given cycle recon capable groups by this value will return number of such groups, that HAC will keep as recon reserve;

RydHQ_AttackReserve = 0.5 * (0.5 + (RydHQ_Circumspection/1.5)) – multiplication of total number of available in given cycle combat effective groups by this value will return number of such groups, that HAC will keep as main reserve (part of them may be used for main flanking maneuver);

RydxHQ_AIChatDensity = 10 – shared by all leaders. Chance in %, that given event (support request, success, failure, sitrep, danger, hostile presence discovered, HQ decisions, low morale etc.) will generate appropriate to the situation radio message audible for all units of the sender’s side. Tested every event for every groups under HAC control. Recommended values are 10-30, dependent also on number of groups. Set to 0 will turn off this feature;

RydxHQ_NEAware = 0 – shared by all Leaders. When set with positive value, each group will be warned about each enemy group known to the HQ inside radius of that value in meters around group’s position. Such warned group will act like in danger. Note, that knowledge about any other unit is automatically set back to 0 outside view distance value. Values bigger than 800-1000 meters not recommended;

RydxHQ_MARatio = [-1,-1,-1,-1] – shared by all Leaders. By default HAC will send against each enemy group up to three infantry/soft, two armored, one air and two sniper groups. Each number in this array is corresponding to one of that kinds of forces in same order. Setting any of that numbers with not negative value will replace for that kind described default allocation with alternative one: total number of non-reserve and not busy groups of that kind will be multiplied by set corresponding value. Result rounded up means maximal number of groups of given kind, that HAC will try to send against one enemy group. So for example, if there are 6 infantry groups and 8 armored groups not set as reserve and currently idle, for [0.15,0.5,-1,-1] against next spotted enemy group in that cycle HAC will send up to 6 * 0.15 = 1 infantry group and 8 * 0.5 = 4 armored groups. Air and sniper groups will be allocated in default way;

RydHQ_GetHQInside = false – if true, and Leader’s group relocating is active, HAC will try to find some position inside random enterable building in 100 meters radius around relocation waypoint and will send Leader’s group there. Works only, if there is no vehicle assigned to that group;

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;

1.0-1.42:

v1.42

- code error fixed.

v1.41

- code issue in arty targeting function fixed;

- few minor code corrections.

v1.4

- FIXED: mechanized groups do not return into APC after the mission;

- FIXED: HAC's tasks overwrite pre-made briefing tasks;

- NEW: possibility of exclusion chosen empty vehicle from cargo usage;

- IMPROVED: MP compatibility. Player-HQ comm and tasks active for MP client-side (experimental);

- NEW: Ammo chute drops from chosen air support units;

- IMPROVED: new sniper mission behavior;

- NEW: SpecFor category with own mission kind: to eliminate most valuable enemies or guard own HQ if idle or chosen by user for it;

- IMPROVED: Optional temporary invisible LZ helipad for cargo choppers to help them not crash in difficult terrain;

- NEW: Included optional RHQ arrays for OA, BAF, PMC and ACR that can be used with single boolean variable;

- IMPROVED: improved capturing objectives handling, that will speed up conquering objectives;

- IMPROVED: customizable main BB cycle interval;

- NEW: "CargoOnly" and "NoCargo" arrays;

- NEW: optional repositioning for air units, that's landing area became too far from current leader's position - can be useful for BB on big maps to keep air support close of whole army;

- IMPROVED: improved defense behavior;

- CHANGED: now BB analyzes the map with load screen active, what makes all procedure much quicker;

- NEW: optional "dynamic formation" feature, that changes on the fly groups' formation and behavior if in danger (experimental);

- code tweaks and fixes.

v1.33

- addon version issue fixed;

- few minor code improvements;

- additional decoy for idle land support;

- reorganized files in script version.

v1.32

- two customizable "decoys" for idle and resting groups (see manual, chapter 3);

- time manipulating and pause before new order for human player via optional action menu options;

- weather and daytime will affect chances for air missions. More recon groups used at night;

- special debug mode for BB, that shows with arrows current forces movements, Leaders' current positions, and known enemy concetrations (BETA);

- updated manual;

- several code fixes and improvements.

v1.31

- fixed rare problems with arty missions;

- fixed morale and losses calculactions when new groups are placed under HAC control;

- improved reliability of air cargo system;

- improved choosing of positions for idle and rest orders;

- few other code fixes.

v1.3

- added: HE, WP and SADARM artillery fire missions handling (incorporated improved and adapted FAW script) with own debug;

- added: new debug indicators;

- added: possibility of customization battlefield area for BB;

- improved: optional, experimental attack coordination for land forces, not fully reliable, so turned off by default;

- improved: BB’s reserve activity;

- several tweaks and fixes.

v1.21

- fixed issues with objectives handling in BB mode

v1.2 hotfix

- fixed an issue;

v1.2

- several fixes and code improvements;

- improved morale formula;

- more optional markers;

- improved risk of attack orders calculation for armor and air groups, when hostile AT (AA) weaponry is known - now distance factor along the entire planned route is taken into account;

- changed demo for BigBoss, also added new one, simplified for BB, to facilitate understanding of the fundamentals of BB concept before studying of its advanced features.

- two new init config variables for attack-only "berserk" mode and adjusting/activating of tactical withdrawal order;

v1.2 beta 2

- several code fixes and improvements;

- additional debug markers for Big Boss.

v1.2 beta

- RHQs arrays for subtraction default classnames from given category;

- cyclical comparing forces routine during fight and withdrawing when to big enemy advantage;

- Big Boss (beta);

- optional terrain-based path finding on waypoints level for infantry (beta);

- speed of groups movement is adjustable;

- new init config variables including options for battle flow dinamisation;

- new manual content (internal variables documentation);

- "idle" orders are optional;

- better defensive behavior - usage of objectives as perimeters centers;

- improved garrison behavior;

- new morale formulas;

- lowered to 10 default number of units needed to take an objective for increasing battle dynamics;

- optional flare usage for defending troops at night;

- integrated artillery handling (coordinated usage of smoke and illum);

- morale drop when current leader unit dies;

- additional pause before next cycle, if new leader is replacing killed previous;

- distinction between aerial and land medevac vehicles for choosing appropriate kind depending on distance and kind of wound;

- optional hint info about Leader's staff death (when HAC's control ends);

- functional CAS bombing air attack;

- numerous tweaks, fixes and improvements, including partial deep code redesign.

v1.1

- Optional handling of logistic/ambulance support;

- up to eight Leaders on map;

- alternative, limited control modes;

- Up to four primary and two secondary objectives per Leader;

- optional usage of ungrouped transport vehicles;

- handling of garrisons;

- withdrawal of combat inneffective groups from the fight;

- better manner of infantry movement (varied speed, rests and formations);

- mission notifications for human controlled team leaders;

- secondary orders for idle groups;

- more diversed unit categories;

- when Leader's unit is death, another one from same group will become a new Leader, but with worsened commanding attributes;

- new ways to limit HAC control over chosen groups;

- optional "front" mode with limited to chosen area enemy groups recognition;

- many new optional/customizable parameters;

- very numerous code and behavior fixes, adjustments and improvements include code efficiency;

- new demo missions for simply and complex HAC config.

v1.0 beta 2

- fixed an error

- added demo mission

Edited March 18, 2013 by Rydygier

[Guest]

Thanks a lot for informing us about the updated version :cool:

New version frontpaged on the Armaholic homepage.

HETMAN - Artificial Commander v1.43



Community Base Addons

[Rydygier 1302]

Thanks! :)

[KeyCat 131]

Thanks for the update Rydygier!

/KC

[mrcash2009 0]

What more can be said about this, glad to see even more improvement, love it & thanks.

[kawa 14]

Been crawling through the whole 15 pages but I haven't been able to find a clear answer.

Are the human players now receiving radio message and markers when they receive orders from the BB?

Thanks for any clarification you could provide