HETMAN - Artificial Commander

[Rydygier 1309]

Yeah, that always was though nut to crack. How to have a big scale battle without lagging. Simple fact is, that many AI on move and under fight means lag. HAC indeed doesn't tolerate caching. And excluding such way part of forces is anyway against whole idea of having all units under control as one army. Also hard to limit plans, when BB is exactly for that purpose - for leading many units across whole map. We can even say, that I anticipated era by creating Big Boss, as it is made for hardware, that does not exist yet... on the common market anyway. :) I wonder, how this will look for A3.

You can use DAC or other script (perhaps even better, as DAC tries next to control spawned groups, these must be released from DAC's control, which however, if I remember correctly, isn't 100% reliable... ) as spawner, and HAC as controler. It is imperfect, but near only idea at the moment in my head. This can be justified as kind of reinforcements from some outer pool.

Also just a thought, you can play with really low viewdistance, this may help as AI doesn't see enemy out of view distance range. This of course will affect all fighting, but this is the point. And consider give up ALICE. Ambient is nice, but not when all is lagged. Additionally you can disable HAC's idle orders, so idle groups will stand still instead patrolling around.

[Georilla 6]

Right now I'm trying to experiment with the middle-road between the two. I'm deploying several regional DAC zones, spawning Takistani Army troops. Which means they will just cache when xxxx metres far away, also several Takistani Militia DAC zones like that in the mountains.

And now the experimenting part, I'm deploying a core Takistani Army, which is smaller in size than having entire Takistani Army being HAC controlled, because I now have several random "regional" Takistani Army troops with DAC. This core army is HAC and has several objectives. I won't need to make it as big anymore, but I will still have the feeling of an army fighting for the map and several other regional forces fighting in the DAC zones.

In short, DAC controls the "regional" troops, and HAC controls the always existing main troops. Maybe this will work better.

Edited June 30, 2013 by Georilla

[orcinus 121]

HAC indeed doesn't tolerate caching.

Wasn't there one caching system that was supposed to work with HAC? - for MP IIRC. Can't find the link though.

Hmm - as HAC only tracks the group leader (I think) could groups not near enemy have all but the leader cached? - though I have no idea how or even if that might be possible.

... as I'm technically cut off from downloading big data, so must wait for box version with all data on DVD only activated on the Steam (BTW games' Steam dependency, because of my poor, limited net connection become more and more my personal plague, when comes to gaming).

Heh, try mobile BB. To download 20 GB would cost me GBP 300. No way will I give any 3rd party control over my bandwidth use. I'll only be able to play Arma3 if it is only the initial activation the Steam is needed for. Still, enough OT ranting :)

---------- Post added at 12:53 PM ---------- Previous post was at 12:37 PM ----------

Right now I'm trying to experiment with the middle-road between the two. I'm deploying several regional DAC zones, spawning Takistani Army troops. Which means they will just cache when xxxx metres far away, also several Takistani Militia DAC zones like that in the mountains.

And now the experimenting part, I'm deploying a core Takistani Army, which is smaller in size than having entire Takistani Army being HAC controlled, because I now have several random "regional" Takistani Army troops with DAC. This core army is HAC and has several objectives. I won't need to make it as big anymore, but I will still have the feeling of an army fighting for the map and several other regional forces fighting in the DAC zones.

In short, DAC controls the "regional" troops, and HAC controls the always existing main troops. Maybe this will work better.

You can do this. However DAC & HAC will fight over control unless you are careful to specify which DAC-created units are or are not available to HAC. Easiest way is to spawn DAC groups into named arrays. Enter the names into the HAC-excluded array,. Also, since you're using DAC anyway, you could use DAC to spawn groups for HAC adding in a release script. I've done both. Note that stock DAC causes some issues with choppers when you try to release them from DAC - for now best to use other methods to spawn helis for HAC, or use editor-placed machines.

Any editor-placed vehicles &/or statics you do not want DAC to take over should have "this setVariable ["DAC_Excluded",true]; in their init lines.

Edited June 30, 2013 by Orcinus

[Rydygier 1309]

HAC only tracks the group leader

But also HAC checks all squad for determining group's category and losses. That's always was a problem, cause from HAC perspective caching a group is equal to massive losses. And vice versa. There are some very time-consuming and extensive ideas, frankly I'm not willing to struggle with that. Too much work, too many things to check and change. All usual calcualtions must be coupled and synced with cached groups state calculations. Distant firefights will drain FPS anyway unless there will be only simulated firefights between cached groups (too weird and unreliable for me). Similar with arty fire. Tons of problems. A2 HAC development is closed anyway. We will see, what become possible/needed under A3.

Heh, try mobile BB.

Part of my problem is literal lack of any alternative except satellite net (far too expensive, perhaps I should move to Pitcairn Island, there is a rumor, that UK government founds satellite net for everyone there. And they need immigrants :) ). Mobiles are out of range here. This is because of terrain shape - river valley slope. Many woods around. Many hills blocking the signal. Few people. Few signal emitters. No real town in 30 km radius.

[Georilla 6]

You can do this. However DAC & HAC will fight over control unless you are careful to specify which DAC-created units are or are not available to HAC. Easiest way is to spawn DAC groups into named arrays. Enter the names into the HAC-excluded array,. Also, since you're using DAC anyway, you could use DAC to spawn groups for HAC adding in a release script. I've done both. Note that stock DAC causes some issues with choppers when you try to release them from DAC - for now best to use other methods to spawn helis for HAC, or use editor-placed machines.

Any editor-placed vehicles &/or statics you do not want DAC to take over should have "this setVariable ["DAC_Excluded",true]; in their init lines.

I've been doing the following: synchronize units to specific LeaderHQ's for HAC control (and edit init.sqf SubSynchro etc. settings). Which means HAC only controls the units it's synched to. All these units are editor placed.

I don't think DAC controls any editor placed units in the default setings? Only the ones it spawn. Which should work, HAC just controlling the synched to LeaderHQ's units. And DAC just the ones it's spawns from DAC zones.

[orcinus 121]

But also HAC checks all squad for determining group's category and losses. That's always was a problem, cause from HAC perspective caching a group is equal to massive losses. And vice versa. There are some very time-consuming and extensive ideas, frankly I'm not willing to struggle with that.

Heh, I suppose you've already considered setting a variable on units when they're cached (& of course removing it when un-cached) then something like count (live units) = count (_liveunits) plus count (_cachedunits)?

I used to know someone who did a stint in the British Council as a lawyer. From what he said, I suspect you wouldn't enjoy living on Pitcairn!

---------- Post added at 06:07 PM ---------- Previous post was at 05:59 PM ----------

I've been doing the following: synchronize units to specific LeaderHQ's for HAC control (and edit init.sqf SubSynchro etc. settings). Which means HAC only controls the units it's synched to. All these units are editor placed.

I don't think DAC controls any editor placed units in the default setings? Only the ones it spawn. Which should work, HAC just controlling the synched to LeaderHQ's units. And DAC just the ones it's spawns from DAC zones.

Ah OK, that should work though I haven't tried that way of setting it up (since I'm releasing some but not all DAC-spawned groups to HAC).

Correct, DAC will not try to control editor-placed groups unless they are deliberately included (as per the manual). However, depending on the settings in, IIRC, DAC_Config_Behaviour, DAC will place units into empty statics, etc. For example that might mean DAC preventing HAC from properly exploiting artillery. DAC & HAC's view of the battlefield may be quite different & DAC will not have any data on HAC's objectives. I have seen DAC troops commandeer an editor-placed vehicle as well - "Oi! That was my truck, you bastards!".

[Rydygier 1309]

setting a variable on units when they're cached (& of course removing it when un-cached) then something like count (live units) = count (_liveunits) plus count (_cachedunits)?

Yep, that's the way. Looong way. Setting a variable to the group is easy part. Then you must dig through entire HAC code and add in many dozens of places all needed code, that will take into account these variables properly, without issues. Not only units. Weaponry, health state... Theoretically simplier and more reliable would be, if each group have own "specification file", means some kind of central database of each group, refreshed separatelly from HAC containing all data, that HAC can need for each group. Database handles all this cached/uncached synchro stuff to keep thinks valid and up to date, and HAC no longer obtains needed data from groups itself, but instead for each group opens relevant database entry and read needed data about that group. Still whole HAC code must be changed for that, and database system must be written. And caching system too. Whole idea also isn't without weaknesess of course. Eg. currently HAC refreshes data exactly before are needed, so such database must be refreshed very often. And still we have problem with distant firefights between groups or arty fire against cached groups. And what with groups on the move, cargo system... Complications, complications. I doubt, if this is even a half of all problems. If such thing will be implemented - for sure not soon.

Why it is so bad on Pitcairn? They have own web page and it looks interesting - few people, all resources imported like in captain's Cook times from the ships throught the boats... Looks like intriguing and very unique place. Of course, seriously, I'm not such a desperate hardcore... :)

[best2nd 10]

Ok... So, after fiddling around with HETMAN on dedicated server I noticed that my RPT was spammed a lot. Instead of bitching about it, I decided to actually provide the server RPT.

https://dl.dropboxusercontent.com/u/100396463/rpt.sqf

NOTE: HAC works fine, it's just that the RPT spam is not healthy for the server.

[Rydygier 1309]

Which exactly Arma version was used? Part of the things are not related with HAC (ACE, ACRE), but most is of same kind - undefined variable. I heard something related for 1.63 beta patches (like not tolerating not defined variables or something, not sure, what exactly is the problem), never used them, on 1.62 RPT is clear. If this is the case, I was planned to check that as soon, as 1.63 will be official released, changing the code because of problems with not finished yet patch is poor idea.

Meanwhile you can try some workaround here...

1. Try on 1.62, if this is the case of using 1.63 Beta.

2. You can try at least to reduce RPT spamming by defining some of these variables:

- Set "front" for as described in manual, that covers whole map: rectangular/square trigger named HET_FA. If I'm right, this should solve a problem with undefined FrontA.

- Set as false in init RydHQ_DebugII, RydHQB_DebugII etc for each leader used.

However IMHO best fix could be to play for now on 1.62, not 1.63 betas. Unless this wasn't 1.63, then I do not know frankly.

BTW thanks to yours report located some issue, where all Leaders uses FrontA area if front trigger established, but each should use own. Something to fix then, it can affect Big Boss - so new version is coming, I think. BTW I'll try to deal with these listed "undefined variables" somehow. Thanks.

[best2nd 10]

Hey, thanks for quick reply!

I'm using 1.62.107882 beta patch (I'm in no position to revert).

These undefined variables appear only on dedicated server, they don't actually harm HAC functionality, however they increase the I\O load causing server issues.

I will try out your #2 suggestion and report my findings.

[Rydygier 1309]

Yes. This suggestion should reduce amount of RPT messages by removing most frequently repeated error logs, if I'm right. BTW I predict, that 1.63 patch will be kind of small RPT-quake beacause such problems affecting many addons, mods and scripts, just like HAC, ACE and ACRE from the above RPT. Seems, that something, that wasn't considered as a error to log (using of undefined variable), in 1.63 become such error.

[best2nd 10]

Fixed almost all...

Now I get this:

2013/09/01,  6:56:28 Error in expression < (isNil ("RydHQB_Support")) and ((count RydHQB_Support) > 0) and (RydHQB_Cycleco>
2013/09/01,  6:56:28   Error position: <RydHQB_Support) > 0) and (RydHQB_Cycleco>
2013/09/01,  6:56:28   Error Undefined variable in expression: rydhqb_support
2013/09/01,  6:56:29 Error in expression < (isNil ("RydHQB_Support")) and ((count RydHQB_Support) > 0) and (RydHQB_Cycleco>
2013/09/01,  6:56:29   Error position: <RydHQB_Support) > 0) and (RydHQB_Cycleco>
2013/09/01,  6:56:29   Error Undefined variable in expression: rydhqb_support
2013/09/01,  6:56:29 Error in expression < (isNil ("RydHQB_Support")) and ((count RydHQB_Support) > 0) and (RydHQB_Cycleco>
2013/09/01,  6:56:29   Error position: <RydHQB_Support) > 0) and (RydHQB_Cycleco>
2013/09/01,  6:56:29   Error Undefined variable in expression: rydhqb_support
2013/09/01,  6:56:34 Error in expression < (isNil ("RydHQC_Support")) and ((count RydHQC_Support) > 0) and (RydHQC_Cycleco>
2013/09/01,  6:56:34   Error position: <RydHQC_Support) > 0) and (RydHQC_Cycleco>
2013/09/01,  6:56:34   Error Undefined variable in expression: rydhqc_support
2013/09/01,  6:56:34 Error in expression < (isNil ("RydHQC_Support")) and ((count RydHQC_Support) > 0) and (RydHQC_Cycleco>
2013/09/01,  6:56:34   Error position: <RydHQC_Support) > 0) and (RydHQC_Cycleco>
2013/09/01,  6:56:34   Error Undefined variable in expression: rydhqc_support
2013/09/01,  6:56:34 Error in expression < (isNil ("RydHQC_Support")) and ((count RydHQC_Support) > 0) and (RydHQC_Cycleco>
2013/09/01,  6:56:34   Error position: <RydHQC_Support) > 0) and (RydHQC_Cycleco>
2013/09/01,  6:56:34   Error Undefined variable in expression: rydhqc_support

[Rydygier 1309]

Good. These, I believe, also can be removed. Try in the init define for each used Leader RydHQ_Support (RydHQB_... RydHQC_... etc) variable as empty array (RydHQ_Support = []; ). Should help, I think and will do no any harm.

[Rydygier 1309]

According to last reports released new HAC version - 1.44.

Changelog:

- numerous fixes to avoid flooding RPT with "undefined variable" logs by newest beta patches;

- fixed issue with "Fronts" feature, that could affect also Big Boss;

- small fixes for debug mode;

- minor manual update;

- various code fixes.

Possibly still in some rare situations beta patch can produce RPT message related with HAC activity. I'll be grateful for reporting any such cases...

[Guest]

Thanks a lot for the headsup about the new version mate :cool:

New version frontpaged on the Armaholic homepage.

HETMAN - Artificial Commander v1.44



Community Base Addons

===================================================

We have also "connected" these pages to your account on Armaholic.

This means in the future you will be able to maintain these pages yourself if you wish to do so. Once this new feature is ready we will contact you about it and explain how things work and what options you have.

When you have any questions already feel free to PM or email me!

[Rydygier 1309]

Thanks. :)

[SabotAndHeat 10]

Has anyone created an A3 Beta unit array already?

[the_blitz6794 10]

can someone point to some missions that use this?

[Rydygier 1309]

Most people, as far, as I know, use HAC for quick to set dynamic battles unique each play, still organized, not just random. Bunch of groups per side, objectives in chosen spots, perhaps some initial customization and go. A few more recipes for such kind of missions with HAC are described in the manual. Heard about some more complex projects, but nothing about finished ones. In effect in the first post of this thread in missions section you'll find only one, small example mission provided by me. Also MSO contains HAC.

[best2nd 10]

No RPT errors... Now to ACE and ACRE...

[cadmium77 16]

God bless you my boy; this is the kind of thinking I love to see here.

[MadM0nkey 1]

firstly, thanks for making this it's very impressive scripting.

I am having a small issue that I can't quite figure out.

I am using norrins AI respawn patrol script that uses Kronzky's UPS script basically a default "armed civillians" spawn marker is placed for the ai patrols to respawn at, and a destination radious marker where the ai patrol will head towards and patrol.

my issue is when I am using your Hac script specifically BigBoss_simpleDemo.Chernarus it moves norrins patrol destination markers off the map.

I want to set a radius marker for Armed Civillians/Guerrillas to patrol in towns & citys but they are moved off the map..

and so the ai patrols all slowly walk towards the placement off the map.. way off the map and not where I originally placed them.

any idea why? and or how to fix this?

<edit>

ok so I tested this originally on Bukovina an ACR Lite cout-out of cherns island

I copied it all over to utes and it didn't have any issues, the markers stayed in place.. very odd.

Edited September 18, 2013 by MadM0nkey

[Rydygier 1309]

Odd indeed. I see no reason, why HAC should move any markers except own debug markers. HAC simply doesn't do such things. On the other hand I can't tell, what could do other scripts you use. I do not know well norrins AI respawn nor UPS, so can't tell if there could be any interferences between it and HAC. Possibly, if HAC controls same groups, as other script that issues waypoints (avoid that), but this would be related to waypoints, not markers. Are you shure HAC is causing that? Tried same scenario without HAC? Any other adons are used?

If you want, you may upload yours troublemaking mission here, if possible I'll try to check, what is going on in some free time.

[MadM0nkey 1]

I spoke too soon.. the problem still exists it just took a couple mins to load.

It moves the markers & takes place just after the message HAC is here.

the test I did on utes moved them far away off screen, at first I was thinking it just removed the markers from visibility. but no.

if you want to maybe test it and try to recreate the issue you can get the ai patrol script demo from here:

Group respawning AI that patrol an area using Kronzky's UPS

OFPec maybe offline? I got the demo from Topic: http://www.ofpec.com/forum/index.php?topic=33732.0

if the site is down try Google for the filename: aiRespawnUPS.Chernarus.rar

Thanks for your help =)

Edited September 18, 2013 by MadM0nkey

[Rydygier 1309]

Hmm. First link is not opening, second returns error 404.