HETMAN - Artificial Leader

[Rydygier 1309]

Quote

Does this mean the commander would send "more" units to take an OBJ? Or simply consider it taken?And if not enough units there,he sends more on the next cycle..

 

The more units required, the more HAL should send, with some additional number depending on circumspection and reclessness of the Leader. If not enough on place, should send more. And in total not less, than 3 (or was that 4?) groups, IIRC. 

 

Quote

Can i use this somehow to make one sides commander defend 2 or 3 areas apart from each other without have 2 or 3 commanders for that side?

 

Leader will defend an area around each of already taken objectives, this way you can point up to 4 areas, not counting area around the Leader. Quoting exemplary setup:

 

Quote

4. Exemplary config for custom, round defense:

 

//to keep Leader in defend mode

 

RydHQ_Order = "DEFEND";

 

//only, if at least 6 groups will be closest to given objective, that objective become a perimeter point

 

RydHQ_DefendObjectives = 6;

 

//to make all objectives "taken"

 

RydHQ_NObj = 5;

 

//directions of each perimeter, where objectives are placed around Leader

 

RydHQ_DefFrontL = ["N","E"];//North-East

RydHQ_DefFront1 = ["N",""];//1st perimeter facing North

RydHQ_DefFront2 = ["E",""];//2nd perimeter facing East

RydHQ_DefFront3 = ["S",""];//3rd  perimeter facing South

RydHQ_DefFront4 = ["W",""];//4th perimeter facing West

 

nul = [] execVM "RydHQInit.sqf";

 

uses this:

 

Quote

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;

 

As for facing directions, this wasn't working properly earlier, but IIRC I fixed that (?). 

 

Note, in defensive mode groups will stay rather stationary, no offensive maneuvers, except for sending defensive reinforcements, if needed. If you need to continue offensive in the same time, you need to divide your forces between two Leaders, one in defensive, and second in offensive stance. 

 

As for garrisoning, it is separate thing and may happen dynamically in Big Boss mode. Other thant that - no, IIRC. To point groups as garrisons:

 

Quote

RydHQ_Garrison= [] - array for names of groups that will become “garrison”. Recommended mostly for infantry or land vehicles;

 

Plus two more variables:

 

Quote

RydHQ_GarrR = 500 - radius in meters around a given garrisoned group team leader's initial position, within which this group should be available for attack missions;

 

RydHQ_GarrVehAb= false - if true, garrisoned motorized groups will disembark their vehicles and act as non-motorized garrison group. Otherwise motorized garrisons will only get sentry waypoint at its current position;

 

 

Details: manual, page 13, chapter 5.6.7.

[redarmy 422]

12 hours ago, Rydygier said:

 

The more units required, the more HAL should send, with some additional number depending on circumspection and reclessness of the Leader. If not enough on place, should send more. And in total not less, than 3 (or was that 4?) groups, IIRC. 

 

 

Leader will defend an area around each of already taken objectives, this way you can point up to 4 areas, not counting area around the Leader. Quoting exemplary setup:

 

 

uses this:

 

 

As for facing directions, this wasn't working properly earlier, but IIRC I fixed that (?). 

 

Note, in defensive mode groups will stay rather stationary, no offensive maneuvers, except for sending defensive reinforcements, if needed. If you need to continue offensive in the same time, you need to divide your forces between two Leaders, one in defensive, and second in offensive stance. 

 

As for garrisoning, it is separate thing and may happen dynamically in Big Boss mode. Other thant that - no, IIRC. To point groups as garrisons:

 

 

Plus two more variables:

 

 

 

Details: manual, page 13, chapter 5.6.7.

Awesome,thanks for spelling it out for me.

So many features and variables in this mod its hard to not get lost at first.

 

Iv always wanted to play a mission just taxi-ing AI around in the transport choppers by night in the heavy rain,looking down at a very alive battlefield.

 

with this mod,im often being tasked IF im in a chopper to transport/load a squad(so far for evac as i set that option) ,and drop them off.Its a lovely change of pace.

The AI transport system works quite well too with helo's being the exception,helo's pick up and drop off units ok,but they then hover until given new orders(death sentence lol).Vanilla helo behaviour has improved particularly S&D in recent updates but it still aint as good as it could be.

 

 

Oh i did have one more question,is it ok to take control of an AI group(issue it waypoints IN the mission) under the leaders control and give it some waypoints?

Im guessing HAL will regain control of that group on the next cycle,and thats fine,i just dont want to be causing anything I DO,to break the script somehow.

 

for an example as i mentioned helo's just hovering after transporting a group,i would like to give that helo a move/land WP back to base,and hopefully HAL can utilize it again at next cycle.

 

[Rydygier 1309]

Hovering issue is someting, that wasn't here earlier, but I saw similar issue with attack helos with assigned waypoint in different mission context, this may be the same case. Anyway, cargo orders are also based on waypoints, and, possibly with some rare exceptions, HAL will just wait, till task completed or till he considers it failed (for example if unit doesn't move certain amount of time, probably around 120 seconds for cargo task) before issue another order. IMO you giving own waypoints in the middle of the task should not break HAL. As long unit is moving, HAL probably will consider, the task is pending and leave the helo be. But test it to be sure. 

[redarmy 422]

Iv tested giving units wps and all seems ok. 

 

However for some reason now one of the leaders from the two opposing leaders in my scenario is not sending units to the objectives..

 

I have BLUFOR leader named LeaderHQB and his OBJs are RydHQB_Obj1 RydHQB_Obj2 RydHQB_Obj3 RydHQB_Obj4 .

 

Using four empty triggers respectively.

 

I have independant leader named LeaderHQ and his OBJs are RydHQ_Obj1....up to four aswell.

 

when mission starts after 15 seconds things boot up(iv cleared my init .sqf of all changes i tested with HAL such as enabling rush movement,info and Cargo options.

 

The independant groups get orders to move to RydHQ_Obj1(About 3 or 4 groups) all fine and normal.

But looking at Blufor groups they only have move,move,move,cycle waypoints either at their start position,or a little distance away to leaders(LeaderHQB) position.

 

I understand i think,fairley well how the script is supposed to work and i cannot see any reason why blufor are not moving to their objective.I have been testing for hours,evening removing any non HAL units/init settings,so basically following instructions to the letter to get this to work,but it will not work for blufor leader groups.

 

Have i missed something obvious?If you need more in depth info plz ask,i dont think i left anything out,and the funny thing is that things were working ok yesterday,i cannot figure out what is causing the Blufor leader to not tell groups to move to objective areas.

 

Thanks

[Rydygier 1309]

Reasons may be many, from certain weird circumstancies (not likely) to naming typos and init setup syntax errors (most often causes of such issues). I simply can't tell by verbal description. I would need vanilla (no mod requirement) repro mission to see myself. From what you said, all blufor gets just so called idle orders, so it seems, BLU Leader doesn't see any objective to take or for some reason considers all as already taken. 

[redarmy 422]

4 hours ago, Rydygier said:

Reasons may be many, from certain weird circumstancies (not likely) to naming typos and init setup syntax errors (most often causes of such issues). I simply can't tell by verbal description. I would need vanilla (no mod requirement) repro mission to see myself. From what you said, all blufor gets just so called idle orders, so it seems, BLU Leader doesn't see any objective to take or for some reason considers all as already taken. 

I sent you a P.M with the mission.sqm

 

Also forgot to mention every few minutes i am recieving errors while testing with HAL

Quote

'..._danger + ((_eCount * _eCount /_fCount) I#I/(_dst/3)))}

}

}

}

Foreach (_HQ getvariab..."

Error Zero divisor

I also noticed HAL working fine the first time i tried a few days ago,and since that time CBA got updated,possibly something.

 

EDIT: I reverted to CBA previous version,and attempted to put HAL script version in a totally new clean,scenario,the same things happening in that BLUFOR units ignore any OBJ trigger and only idle around leader,really odd.Also being met with the error above in script version test

[Rydygier 1309]

All right, I put HAL scripts inside, run it with debug on. Seems, both sides send recon at respective first objectives, as should. The only oddity I see, is that some idle orders (res) are issued at enem positions. Maybe an issue with debug markers. Are you using any init variables? If so - where are defined? Anyway, try this (pure vanilla, no CBA (but CBA update shouldn't affect IMO, it is used solely to auto-init scripts inside the pbo in addon version), no any addons, HAL in scripted version included, just run preview). Looks that way for me after a short while:

 

 

RPT is clear - no any error logs so far, the error, you get, comes from EnemyScan.sqf, cyclic code that checks per each group, if there's enough close enough enemies to put it in the "danger" state. Full RPT could tell more about the causes, seems, like _dst is 0 for some reason. Distance between given group and one of the enemies, like for some reason that group is own enemy simultanously, thus 0 dst, but that's just blind guessing... Wait a minute...

 

Oh! I have a theory. Be sure, you've set IND as enemy of BLUFOR and vice versa. If both are mutually friendly (as it is in my case here), in default control mode both Leaders try to control forces of both sides, and what we see, including that "Res" issue, is a result of chaotic fight over the control over every group on the map - each may receive orders from both Leaders.

[redarmy 422]

2 hours ago, Rydygier said:

All right, I put HAL scripts inside, run it with debug on. Seems, both sides send recon at respective first objectives, as should. The only oddity I see, is that some idle orders (res) are issued at enem positions. Maybe an issue with debug markers. Are you using any init variables? If so - where are defined? Anyway, try this (pure vanilla, no CBA (but CBA update shouldn't affect IMO, it is used solely to auto-init scripts inside the pbo in addon version), no any addons, HAL in scripted version included, just run preview). Looks that way for me after a short while:

 

 

RPT is clear - no any error logs so far, the error, you get, comes from EnemyScan.sqf, cyclic code that checks per each group, if there's enough close enough enemies to put it in the "danger" state. Full RPT could tell more about the causes, seems, like _dst is 0 for some reason. Distance between given group and one of the enemies, like for some reason that group is own enemy simultanously, thus 0 dst, but that's just blind guessing... Wait a minute...

 

Oh! I have a theory. Be sure, you've set IND as enemy of BLUFOR and vice versa. If both are mutually friendly (as it is in my case here), in default control mode both Leaders try to control forces of both sides, and what we see, including that "Res" issue, is a result of chaotic fight over the control over every group on the map - each may receive orders from both Leaders.

OK I finally sorted it...Thanks for the help man.

I tested your demo mission,everything ran fine...my own mission version still didnt work on a clean game(no mods)

I figured out it WAS  mod causing the issue,the mod in question...MCC.

 

I did remove the mod and test,HOWEVER it seems it was "baked into" my scenario(mission SQM)

So what i did was copy paste all objects/units folders etc into a new mission,and tested.....the screenshot below shows the results...HAL working flawlessly.

 

Sorry mate i had no idea a mod can become still active in your mission after you remove it and there are NO dependencie messages showing.

To confirm it was MCC,i loaded up the mission you sent me(with debug init info) and ran it HAL + MCC...the result was IND getting some REC points,but BLUFOR getting only RES positions.

 

Thanks again for the help. Its a shame i cant get MCC to work with HAL but happy this is resolved.

[Rydygier 1309]

Great (indeed, if two mods do analogous/similar thing, in most cases can't be mutually compatible. Conflict seems inavoidable in such case). Glad, I could help. Just remeber, to make IND and BLU enemies in EDEN settings or via script. :)

[redarmy 422]

12 minutes ago, Rydygier said:

Great (indeed, if two mods do analogous/similar thing, in most cases can't be mutually compatible. Conflict seems inavoidable in such case). Glad, I could help. Just remeber, to make IND and BLU enemies in EDEN settings or via script. :)

Absolutely will do,i had it set in Eden editor attributes tab i believe , to make IND hostile to BLUFR,but just to be sure i have this code running about 10 seconds before HAL starts up ;)

 

Quote

west setFriend [resistance, 0];

Quote

resistance setFriend [west, 0];

This is essential...i just got a rest and recover type WP...it was located in the other sides,leaders tent :p other side of map

[b3lx 161]

Is HAL compatible with VCOM AI with AI pathing enabled? With AI pathing  enabled VCOM sends groups to assist nearby units facing an enemy threat. I am asking because this feature can take over a group's waypoints that are are assigned via High Command so it seems it could do the same in HAL.

[redarmy 422]

7 hours ago, b3lx said:

Is HAL compatible with VCOM AI with AI pathing enabled? With AI pathing  enabled VCOM sends groups to assist nearby units facing an enemy threat. I am asking because this feature can take over a group's waypoints that are are assigned via High Command so it seems it could do the same in HAL.

They wont work so well together from a logical point of view,i beleive HAL and VCOM will be fighting over control of the groups.Performance may suffer in large scale envoirments.

 

Vcom will be more active with WPs on individual groups than HAL i think.Best bet is to use one or the other.

Or what you could do if you MUST have VCOM running with HAL is to exclude certain groups from HAL control or vice versa

 

Quote

RydHQ_Excluded  =  [mygroup1,mygroup2,mygroup3];
 

Quote

RydHQB_Excluded  =  [myenemygroup1,myenemygroup2,myenemygroup3];
 

Run from INIT.SQF . This is the best practice though i really advise to not use both mods together as conflicts may arise.

 

I am using advanced AI command to give move orders like in High command to a few groups whom i put in the excluded array,seems ok so far.

[Rydygier 1309]

Quote

I am asking because this feature can take over a group's waypoints that are are assigned via High Command so it seems it could do the same in HAL.

 

Indeed. As redarmy said. HAL, with few exceptions, avoids manipulating single unit actions to leave space for low level AI mods, focuses on group as a whole: assigning waypoints, switching combat modes, group formations and behaviors. But if given AI mod manipulates same stuff, as Hetman - yes, you logically should expect inevitable conflicts and mutual group control "hijacking". Don't expect compatibility in such cases - your intuition is right. 

[delta99 34]

I think I used to run MCC with Hetman all the time without issues. MCC wouldn't be doing anything if all you are doing is loading the MOD. Unless you placed down some MCC modules or something. I can't see MCC touching anything unless you ask it to.

[redarmy 422]

5 hours ago, delta99 said:

I think I used to run MCC with Hetman all the time without issues. MCC wouldn't be doing anything if all you are doing is loading the MOD. Unless you placed down some MCC modules or something. I can't see MCC touching anything unless you ask it to.

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

I had no modules down what so ever.

[pognivet 151]

cool mod, but extremely confusing to use. i remember using it back in arma 2.

 

i tried to use it on the map kidal and it just gets stuck at loading forever.

[Rydygier 1309]

Really that confusing? Basic use is simple: Leader unit, 4 objective objects (+ one init code line, if script version).  There's lots more of course, but all optional. 

[Rapaxlegio 1]

Does someone have units sfq configured to work with RHS and IFA  mods? If so, , would you mind sharing
Thank you.

[b3lx 161]

3 hours ago, pognivet said:

cool mod, but extremely confusing to use. i remember using it back in arma 2.

 

i tried to use it on the map kidal and it just gets stuck at loading forever.

kidal doesn't work with alive either, maybe it's related? A good thing to do is to keep HAL setups saved in compositions so it's mostly drag and drop. This is also useful with alive which is even harder to get right than HAL

[AtomicBoy 33]

2 hours ago, Rapaxlegio said:

Does someone have units sfq configured to work with RHS and IFA  mods? If so, , would you mind sharing
Thank you.

 

 FOR US ARMY RHS. Create an init.sqf file and it is added:

 

RHQ_SpecFor = ["rhsusf_socom_marsoc_teamleader",
"rhsusf_socom_marsoc_teamchief",
"rhsusf_socom_marsoc_elementleader",
"rhsusf_socom_marsoc_cso",
"rhsusf_socom_marsoc_cso_breacher",
"rhsusf_socom_marsoc_cso_mechanic",
"rhsusf_socom_marsoc_sarc",
"rhsusf_socom_marsoc_elementleader",
"rhsusf_socom_marsoc_cso",
"rhsusf_socom_marsoc_cso_breacher",
"rhsusf_socom_marsoc_cso_mechanic",
"rhsusf_socom_marsoc_sarc"];

 

RHQ_Recon = ["rhsusf_socom_marsoc_teamleader",
"rhsusf_socom_marsoc_teamchief",
"rhsusf_socom_marsoc_elementleader",
"rhsusf_socom_marsoc_cso",
"rhsusf_socom_marsoc_cso_breacher",
"rhsusf_socom_marsoc_cso_mechanic",
"rhsusf_socom_marsoc_sarc",
"rhsusf_socom_marsoc_elementleader",
"rhsusf_socom_marsoc_cso",
"rhsusf_socom_marsoc_cso_breacher",
"rhsusf_socom_marsoc_cso_mechanic",
"rhsusf_socom_marsoc_sarc",
"CUP_B_AH6X_USA",
"CUP_B_USMC_DYN_MQ9"];

 

RHQ_FO–forward = ["rhsusf_socom_marsoc_jtac"];

 

RHQ_ATInf = ["rhsusf_army_ocp_javelin"]

RHQ_Inf = ["rhsusf_socom_marsoc_teamleader",
"rhsusf_socom_marsoc_teamchief",
"rhsusf_socom_marsoc_elementleader",
"rhsusf_socom_marsoc_cso",
"rhsusf_socom_marsoc_cso_breacher",
"rhsusf_socom_marsoc_cso_mechanic",
"rhsusf_socom_marsoc_sarc",
"rhsusf_socom_marsoc_elementleader",
"rhsusf_socom_marsoc_cso",
"rhsusf_socom_marsoc_cso_breacher",
"rhsusf_socom_marsoc_cso_mechanic",
"rhsusf_socom_marsoc_sarc","rhsusf_army_ocp_squadleader",
"rhsusf_army_ocp_teamleader",
"rhsusf_army_ocp_grenadier",
"rhsusf_army_ocp_rifleman",
"rhsusf_army_ocp_teamleader",
"rhsusf_army_ocp_autorifleman",
"rhsusf_army_ocp_autorifleman",
"rhsusf_army_ocp_javelin",
"rhsusf_army_ocp_rifleman",
"rhsusf_socom_marsoc_jtac",
"CUP_B_AH6X_USA",
"CUP_B_USMC_DYN_MQ9",
"rhsusf_army_ocp_helicrew",
"rhsusf_army_ocp_helipilot",
"rhsusf_army_ocp_crewman",
"rhsusf_army_ocp_combatcrewman"];

RHQ_HArmor = ["rhsusf_m1a2sep1d_usarmy"];

 

RHQ_MArmor = ["RHS_M2A2_BUSKI","RHS_M2A3_BUSKIII"];

 

RHQ_Support = ["rhsusf_M977A4_AMMO_usarmy_d",
"rhsusf_M977A4_REPAIR_usarmy_d",
"rhsusf_M1085A1P2_B_D_Medical_fmtv_usarmy",
"rhsusf_M978A4_usarmy_d"];

 

RHQ_Cargo = ["RHS_CH_47F_10",
"RHS_CH_47F_light",
"RHS_UH60M_d","RHS_M2A2_BUSKI","RHS_M2A3_BUSKIII"]

RHQ_Med = ["rhsusf_M1085A1P2_B_D_Medical_fmtv_usarmy"];

 

RHQ_Ammo = ["rhsusf_M977A4_AMMO_usarmy_d"];

 

RHQ_Rep = ["rhsusf_M977A4_REPAIR_usarmy_d"];

 

RHQ_Fuel = ["rhsusf_M978A4_usarmy_d"];

 

RHQ_Air = ["RHS_AH64D",
"RHS_CH_47F_10",
"RHS_CH_47F_light",
"RHS_UH60M_d"]

 

RHQ_Crew = ["rhsusf_army_ocp_helicrew",
"rhsusf_army_ocp_helipilot",
"rhsusf_army_ocp_crewman",
"rhsusf_army_ocp_combatcrewman"]

 

 

Edited October 18, 2018 by AtomicBoy
correción errores

[Rapaxlegio 1]

Thank you AtomicBoy!,   Now I just need the russians.

[AtomicBoy 33]

1 hour ago, Rapaxlegio said:

Thank you AtomicBoy!,   Now I just need the russians.

 

How to create units sfq configured:

Remove the records of the units.

Put the Russian RHS units on the map
Select them all
With the right mouse button click on the units and click on record -> register class on clipboard
Paste the content into a document.

Create RHQ_ARRAYS, create the list by adding class in quotation marks and separated by commas, follow the instructions in the HETMAN PDF:

 

////////////////////////////////////////////////////////////////////////////////////////
//
// RHQ_SpecFor–special forces group. Will be used for constant guarding of HQ if idle or // chosen for it. If there is known valuable target (enemy HQ, arty or static), there is a // chance dependant on Leader’s personality (bigger at night, much lower, when target is // armored), that group(s) will be send to eliminate that target with wide flanking route; 
// RHQ_Recon-reconnaissance units; note, that all classes included here should be also // included to Inf category; 
//RHQ_FO–forward observer units; note, that all classes included here should be also included // to Inf category; 
//RHQ_Snipers-snipers, sharpshooters; note, that all classes included here should be also//  // included to Inf category; 
//RHQ_ATInf-infantry and unarmored vehicles with antitank weapons; note, that all infantry // classes included here should be also included to Inf categoryand unarmored vehicles to // RHQ_Cars; 
//RHQ_AAInf-infantry and vehicles with antiaircraft weaponry; note, that all infantry classes // included here should be also included to Inf category,unarmored vehicles to RHQ_Cars and // armored to RHQ_LArmor categories; 
// RHQ_Inf-infantry in total; 
// RHQ_Art-artillery; 
// RHQ_HArmor-tanks
// 
// RHQ_MArmor–medium armor IFVs, APCs with significant firepower or aged tanks like T-34; // note, that all classes included here should be also included respectively to LArmor or // HArmor category;
// RHQ_LArmor–all light armored vehicles, included medium armor category, APCs, etc. // (excluding self propelled artillery like MRLS). Light armor will sometimes be used for // recon; 
// RHQ_LarmorAT-as above, with weapons effective against armored vehicles (such as mounted // ATGM 
// launchers); note, that all classes included here should be also included to LArmor // category; 
// RHQ_Cars-vehicles without armor; 
// RHQ_Air–all helicopters and planes; 
// RHQ_NCAir–all unarmed helicopters and planes; note, that all classes included here should // be also included to Air category; 
// RHQ_BAir–bombers.Note, that all classes included here should be also included to Air // category. This category is empty by default, because some units are effective both as // fighter and bomber CAS, so with this array mission maker may choose which generic or non-// generic planes should behave as bombers. Planes added to this category will receive precise // “destroy” waypoint attached to the target group’s team leader or team leader’s vehicle // instead of usual “SAD” waypoint. However, this will not make the given unit drop bombs // attarget, for this additional external code is needed. Without such external code (which // perhapswill be provided someday in HAL’s BIS Forum thread…) such planes will use only guns // or rockets, as non-bombing CAS; 
// RHQ_RAir–recon aerial units, mostly for unmanned UAVs (generic UAVs added); therecon of // first choice; note, that all classes included here should be also included to Air category;
// RHQ_Naval -boats; 
// RHQ_Static-static weapons including MG nests; 
// RHQ_StaticAA-as above, anti-aircraft;note, that all classes included here should be also // included to Static category;
// RHQ_StaticAT-as above, anti-tank; note, that all classes included here should be also // included to Static category;
// RHQ_Support-logistics and medical support units; 
// RHQ_Med = []–medevac support vehicles;note, that all classes included here should be also // included to support category;
// RHQ_Ammo = []–reammo support vehicles; note, that all classes included here should be also // included to support category;
// RHQ_Fuel = []–refuel support vehicles; note, that all classes included here should be also // included to support category;
// RHQ_Rep = []–repair support vehicles; note, that all classes included here should be also // included to support category;
// RHQ_Cargo-all vehicles, armored and not,able to carry passengers;; note, that classes of // unarmed vehicles included here should be also included to Cars category, and armored to // LArmor;
// RHQ_NCCargo-as above, unarmed; 
// RHQ_Crew-only pilots and designated vehicle crew members; note, that all classes included // here should be also included to Inf category;
// RHQ_SPMortars–custom self-propelled artillery vehicles, that should be controlled by // internal arty handler; 
// RHQ_Mortars = [];-as above, for custom variants of mortars;
// 
// RHQ_RocketArty–ditto, for custom rocket artillery (MLRS). 
// Each Leader shares same RHQ arrays set, so only RHQ_ are needed, and no RHQB_ and // subsequent are needed. All categories of non-generic “vanilla” Arma 2 (from user-made // addons, official DLC’s, expansions, etc.), both units and vehicles, present on the map // should be included in RHQ arrays, regardless of faction, that uses the given unit/vehicle, // unless missiondesigner wants to make a given Leader not able to recognize & control units // of selected classes. The necessary class names may be found in given addon’s readme, on BIS // Forums, or on DevHeaven. Alternatively they may easily be determined by an in-editormethod: // add following code to init field of any unit whose class name you want to know: diag_log  // (typeOf this);and check RPT file after “preview”, or hint (typeOf this);and watch the on // screen message. 
//
//////////////////////////////////////////////////////////////////////////////////////////////

 

Edited October 18, 2018 by AtomicBoy
actualizando el texto, VIVA ESPAÑA!!!!!!!!!!!!!!!!!!!!

[Rapaxlegio 1]

I did not know that!, thanks for your full explanation , I'll try it ASAP.

[AtomicBoy 33]

14 hours ago, Rapaxlegio said:

I did not know that!, thanks for your full explanation , I'll try it ASAP.

 

Remember that you can add the Russian units to the US ARMY RHS list, follow the instructions from the HETMAN PDF

 

Br.

 

AtomicBoy

[redarmy 422]

@Rydygier I had a few more general questions i wanted to ask about HETMAN that i cannot find in the PDF.

 

First is...if i use "RydHQ_Excluded " array and add, say 10 groups,but each of those groups have a 50/50 chance to spawn at mission start,will anything get messed up if say "myAAteam1" do not spawn,but they were included in the array?I ask because it throws variable errors up in editor preview(normal). I just wana be sure it wont cause the general actions of HAL or reading of rest of init.sqf to be affected.

 

Second question... Is there anything i can put on a trigger condition to check if an OBJ has been captured?I want to set up some custom sounds to play on captures and losses of OBJ areas.

 

And third,do any of the debugging variables placed in init.sqf cause performance to run slower?I think generally debugging can increase CPU usage,so im just curious about how it may affect HAL.

 

Cheers