Rydygier

Nope currently there is no such variable for speed setting. Will think about, however will be some work with this because changes will be needed in numerous code lines for that purpose. BTW I suppose, that during WWII there was some other tactics, blitzkrieg itp. HAC may be anachronistic a bit here... or maybe not? Anyway - who cares? :)

Yes, UAV has it's limitations. But maybe this way is more realistic? I don't know. And yes, it has tendency to crash. Maybe this will help with poor spotting: setSkill_array for example try to add this to UAV's init field: this setskill ["spotDistance",1];this setskill ["spotTime",1] maybe plus set overall skill to maximum... BTW, about this: { if ((UAV_1 knowsAbout _CheckedUnit) >= 0.01) then {_x reveal _CheckedUnit} } foreach units group Player1; It will work, but all group members share the same knowledge, so there is no need to reveal for all of them, in fact revealing only for group as a whole, or only for group leader will be sufficient. So, if this is about only one group, then foreach loop is uneccessary. Try this instead: if ((UAV_1 knowsAbout _CheckedUnit) >= 0.01) then {Player1 reveal _CheckedUnit}; should be same effect with this: if ((UAV_1 knowsAbout _CheckedUnit) >= 0.01) then {(group Player1) reveal _CheckedUnit}; and this :) if ((UAV_1 knowsAbout _CheckedUnit) >= 0.01) then {leader (group Player1) reveal _CheckedUnit};

Needed effect may be achieved for example with one of such scripts (executed once, usual way, as .sqf with suitable name): //version compatibile with pure A2 1.10. Level of minimum UAV knowledge (here set as 0.05) may be adjusted if needed //ArrayOfUnitsToSpot while {(true)} do { for [{_a = 0},{_a < (count ArrayOfUnitsToSpot)},{_a = _a + 1}] do { _CheckedUnit = ArrayOfUnitsToSpot select _a; { if ((UAV_1 knowsAbout _CheckedUnit) >= 0.05) then {_x reveal _CheckedUnit} } foreach ArrayOfNamesOfGroupsThatShouldReceiveInfo }; sleep 15 } or //probably better version, but not tested, so effect unknown, for OA 1.60 while {(true)} do { for [{_a = 0},{_a < (count ArrayOfUnitsToSpot)},{_a = _a + 1}] do { _CheckedUnit = ArrayOfUnitsToSpot select _a; _UAVKnowledge = UAV_1 knowsAbout _CheckedUnit; { _x reveal [_CheckedUnit,_UAVKnowledge]; } foreach ArrayOfNamesOfGroupsThatShouldReceiveInfo }; sleep 15 } See for details: Reveal knowsAbout UAV_1 is example name of spotting unit/vehicle. If UAV unit should to report info about all units present on map, if are known to this unit, then ArrayOfUnitsToSpot may be simply replaced by allUnits. This should work with any spotter, so UAV_1 may be also a FO infantry, tank, civilian etc. If there will be any problem with revealing units inside vehicles, means with revealing vehicle itself (shouldn't, but I'm not quite sure that), then line: _CheckedUnit = ArrayOfUnitsToSpot select _a; may be replaced with this one: _CheckedUnit = vehicle (ArrayOfUnitsToSpot select _a); This is way to direct transmission of knowledge value (probably not exact in first version). If there is needed reports in other form, it is also possible with this code after some changes (eg some chat message with name/kind/position of spotted target or marker placed on map instead of reveal...).

HAC, to track progress, uses this variable: RydHQ_NObj (form for "A" side, for "B" and following as usual, RHQB_NObj and so on). If it's value is equal 1, means, that currently goal is a first objective. Value equal 2 means, that first objective is captured, and second is target, 3 - first and second are captured, 4 - also third is captured. This value may be changed every reset (when objective checking occurs, default every 10 minutes). However there is no value for all objectives captured (not needed for HAC (hmm... something to think about), possible values are 1,2,3,4). So you may to use this variable in some condition for spawning trigger/script. Just remember, that objectives may be also lost (with all subsequent) and retaken theoretically indefinitely (and this variable's value will change accordingly)... There is also second variable, used for Leader's unit relocation routine, named RydHQ_Progress. Usually is equal 0, but if after last reset some objective(s) was captured, then at current reset becomes equal to 1 until next reset. If some objectives was lost lately, then at next reset will become -1 until subsequent reset (for this purpose HAC always compares the state of progress at the previous reset to the state at the current reset). This may be useful too.

Lately haven't much time, but will try to check this thread as often, as possible (and will keep releasing new versions if ready of course)... @Jingle I think it is some easy way to achieve, that Chinook (and any other cargo vehicle of course) will receive only cargo missions (or stop to receive attack orders at least). Try to add it's class name to RHQ_NCAir and perhaps also RHQ_NCCargo (but this shouldn't be neccessary). These are arrays for unarmed vehicles (No Combat) and HAC will treat such vehicle as an unarmed unit, therefore, excluded from an attack missions (but still if needed such unit will use it's weapon of course). In fact putting given classname in: RHQ_NCAir + RHQ_Air + RHQ_Cargo (+ RHQ_NCCargo ?) should be equal to RHQ_Air + hypothetical RHQ_AIRTRANSPORT.

OK. I see, that you use SubSynchro control mode, and, I assume, you synchronized chosen groups with each Leader... One important thing is missing: Enabling SubSynchro is not enough, it is also needed to turn off unlimited control: RydHQ_SubAll = false; RydHQB_SubAll = false; Try with this. This "Rec B" marker was brown?

@subroc Can I see all yours HAC init config? Is proper set limit control for both Leaders? If not, this will be simpliest answer. Checked code, and looks fine - for leader "B" code refers to leaderHQB position, and "B" side objective, as should be. ---------- Post added at 21:08 ---------- Previous post was at 21:04 ---------- Throw this awful job. :) And where is the longed-for retirement?

@Orcinus So here is, some kind of experimental counter with silent hint infoscreen. Behind each number is hidden a global variable, that may be used in any way (hint may be easly turned off or deleted if not needed). Counted are: current forces for west, east and resistance, total losses and total enemy kills ("friendly" kills aren't counted). It is based on "killed" EH, so will be very interefere with any script, that uses this kind of event handler... Is HAC compatibile but may be used without HAC as well. All three files goes into mission folder. Init, as usual: nul = [] execVM "KCInit.sqf"; KC @subroc I will check defend code right away.

But such condition will never become true. Value can't be in the same moment bigger than 18 AND smaller than 6. Use this instead: if ((daytime > 18) OR (daytime < 6)) then {skipTime 1};

Implementing kill counter for each side should be possible as long, as it will be not a part of Leader's knowledge (because may be very hard to determine (and heavy to calculate), about which kills Leader should to know, and about which not, also because it is unnecessary - Leader's morale is calculated in other way, by comparing own and known enemy forces and with losses factors - general and current), but some external value available for mission maker. But if so, equally well may be this resolved by external script. Still, I afraid, that here may be needed some heavy iterations and maybe even event handlers (for example EH "killed" for all units, checked often beacuse of spawning during play). Must to think about such script.

@Orcinus This should help: //to init: nul = [Center point of checked for allies perimeter (object or position array),radius of this perimeter, any unit of side for which threat is checked] execVM "ThreatMon.sqf"; _center = _this select 0; _radius = _this select 1; _unit = _this select 2; _unitG = group _unit; while {(true)} do // refreshed every 30 seconds { if (isNil ("RydHQ_ThreatValue")) then {RydHQ_ThreatValue = 0}; // this global variable will contain final threat value. _NearAllyG = []; _EG = []; _threat = 0; { if (((side _x) getFriend (side _unitG) >= 0.6) and not (_x in _NearAllyG) and (((vehicle (leader _x)) distance _center) <= _radius)) then {_NearAllyG = _NearAllyG + [_x]}; } foreach Allgroups; // getting ally groups in given radius around given center point { _countE = 0; _Eveh = []; _mobileFactor = 1; _armorFactor = 1; _airFactor = 1; _Kn = 0; _LU = leader _x; _ne = _LU findNearestEnemy (vehicle _LU); //getting nearest known enemy for each ally group in radius if ((isNull _ne) or (((group _ne) in _EG))) then //selecting only present enemies not counted yet { _countE = 0; _mobileFactor = 1; _armorFactor = 1; _airFactor = 1; _Kn = 0; } else // setting formula multipiers { _EG = _EG + [(group _ne)]; _Eunits = units (group _ne); _countE = count _Eunits; { if (not ((vehicle _x) == _x) and not ((vehicle _x) in _Eveh)) then {_Eveh = _Eveh + [(vehicle _x)]}; } foreach _Eunits; _mobileFactor = _mobileFactor + ((count _Eveh)/10); { if (_x isKindOf "tank") then { _armorFactor = _armorFactor + 0.5 } else { if (_x isKindOf "Wheeled_APC") then { _armorFactor = _armorFactor + 0.25 } else { if (_x isKindOf "Air") then { _airFactor = _airFactor + 1; } } } } foreach _Eveh; _Kn = (leader _x) knowsAbout _ne; _threat = _threat + (_countE * _mobileFactor * _armorFactor * _airFactor * _Kn); // main threat value formula } } foreach _NearAllyG; if not (_threat == RydHQ_ThreatValue) then {RydHQ_ThreatValue = _threat}; // threat value becomes a global variable value if changed //hint (str RydHQ_ThreatValue); sleep 30; } Note: this is for single case (generating single variable). To make this work for all groups simultanously there will be needed some changes (just ask, if needed, I will think about this then :) ). It is not HAC dependant and may be used anywhere. As more dangerous are considered enemy groups with own vehicles, especially armored or air. Final value may be of course processed further. May be added comparing factor that takes into account number and weaponry of allied and known enemy forces in area... Also note, that this gives higher threat value when enemy is better known, but takes into consideration only Kn value for first checked ally group, and this value may be not highest amongst Kn values of all checked allied groups. Also is not taking into account enemies, that aren't nearest to any ally group in area. For this purpose there may be useful NearTargets command. Use hint (str RydHQ_ThreatValue); just above sleep 30; command to on screen control of this value. Hmm. Such code my be sueful also for HAC improving... But there is in A2 default retreat behaviour when group feels overwhelmed, so maybe this is not neccessary.

@ Jingle It is possible, just now I saw these threads: http://forums.bistudio.com/showthread.php?131362-Armor-Targetting-engagement-in-1-60 http://forums.bistudio.com/showthread.php?131173-Targeting-in-tanks ---------- Post added at 10:56 ---------- Previous post was at 10:40 ---------- Well. KAM shows Kn value for nearest enemy, and given enemy may be nearest for several groups at once, so this value may for many groups refer to same enemy unit, so if you simply add these values from each group, then you receive strongly exaggerated threat value. Still it is possible to make, that given enemy is counted only once and knowledge about him also. There is even possible to make some "value" gradation, so more dangerous enemy will have more "danger" value, in some free time will try to prepare some code. HAC counts casaulties for each controlled group every cycle, but note, that HAC considers group strenght as nominal in moment, when is taking control over this group. So if group lost some men earier, then HAC will not consider such losses. Kills aren't counted.

It is takistan, so can't test (really - only A2 here :) ). Config looks fine. But here is my own demo on Utes (HAC script and config included): Medevac test Maybe check, if this will work for you (for me worked). You are injured soldier here, so just wait and check map for medevac marker. One note: first medevac missions are issued after about 160 seconds, so maybe just this was a problem - maybe you did not wait long enough? BTW AI was suprised me here. I tested support range earlier on Duala and there was 500 meters, but here, if injured is not player and alone, then will go towards ambulanse placed much futher. But as subordinate in group, will not receive from TL heal order until ambulance is in radius. Interesting. ---------- Post added at 23:56 ---------- Previous post was at 23:44 ---------- Wow. Thanks. Must check this. ---------- Post added at 00:39 ---------- Previous post was at 23:56 ---------- For interested another, similar debug tool. This one shows on the map in the same way as KAM combat mode and behaviour for current waypoint ("NONE" if there is no any waypoint or "" if there is only initial waypoint always placed at start at unit's position) plus kind of team leader's vehicle. WPMon has same limitations as KAM. _CWi = 1; _CW = []; _CMode = "NONE"; _CBeh = "NONE"; _in = ""; _i = ""; { _LU = leader _x; if ((count (waypoints _x)) > 0) then { _CWi = currentWaypoint _x; _CW = [_x,_CWi]; _CMode = waypointCombatMode _CW; _CBeh = waypointBehaviour _CW; } else { _CW = [_x,1]; _CMode = "NONE"; _CBeh = "NONE"; }; _in = "markKWP" + str (_x); _i = createMarker [_in,position (vehicle _LU)]; _i setMarkerColor "ColorBlack"; _i setMarkerShape "ICON"; _i setMarkerSize [0.1,0.1]; _i setMarkerType "DOT"; _i setMarkerText ((typeof (vehicle _LU)) + " - " + (str _CMode) + " - " + (str _CBeh)); } foreach AllGroups; while {(true)} do { sleep 1; { _LU = leader _x; if ((count (waypoints _x)) > 0) then { _CWi = currentWaypoint _x; _CW = [_x,_CWi]; _CMode = waypointCombatMode _CW; _CBeh = waypointBehaviour _CW; } else { _CW = [_x,1]; _CMode = "NONE"; _CBeh = "NONE"; }; _i = "markKWP" + str (_x); _i setMarkerPos (position (vehicle _LU)); _i setMarkerText ((typeof (vehicle _LU)) + " - " + (str _CMode) + " - " + (str _CBeh)); } foreach AllGroups; } ---------- Post added at 01:02 ---------- Previous post was at 00:39 ---------- Some short tests was done with this test mission for A2 1.10: In "blue" mode groups will not fire at enemy even when under fire. In "green" mode however groups are firing at enemy on sight. Maybe distance is here important... But more tests needed to be sure.

@abdel Hmm. ACE shouldn't make a trouble as long as RHQ arrays are proper set for ACE units (maybe some typo in classname? Tried with generic A2 USMC ambulance in the same mission?) ."Res" is idle order. Can you upload this or similar mission? If A2 1.10 + ACE is sufficient to launch it, then I test this, otherwise at least will check configs itp. @ Jingle Thanks for that info and testing.

If this is usable for you, then I'm glad. If there is needed only certain number of enemies in certain radius, then trigger is easiest way, but if there is needed given sum of knowledge about hostiles, then method will be a bit more tricky. My script gives Kn value only for one, closest enemy per group (and this may be same hostile unit for many allies), I'm not sure, if this is sufficient data. BTW I'm curious about effect of some tests, that I will make right away - what if to place close each other two enemy groups, all with manually set blue or green mode... Theroretically shouldn't open fire at all... Also I wonder if there is some difference between A2 1.10 and OA 1.60 in this case...

Is not used SendSimplyCommand "cease fire". "Blue" (never fire) waypoint mode is set only for support missions; also in Arma 1.10 I tested blue mode for withdrawing infantry and they still was shooting at enemy, only not so willingly. More often is used green mode (defend only - should not fire first, but should fire back; in withdrawing, non-combat recon, rest, main flanking maneuver before last stage...). HOLD waypoint is used only once, for AI Leader's unit to prevent changing position.

It is strange issue reporting by some HAC users. Quote Jingle: Like something blinded some units...

Maybe this will help a bit with to slow bomb falling and its horizontal orientation problem: _bomb = createVehicle ["Bo_GBU12_LGB", [((position T1) select 0),((position T1) select 1),100], [], 0, "NONE"]; //create a bomb 100 meters above object named T1 _bomb setVectorUp [0,-1,-0.001]; // make the bomb vertical oriented (point downward) _vel = -50; //initial velocity at spawning height while {((getpos _bomb) select 2) > 1} do // loop for keeping growing (or constant, if acceleration = 0) velocity until bomb is at least 1 meter above terrain { _vel = _vel - 0.05; //acceleration per cycle _bomb setVelocity [0, 0, _vel]; //adjusting velocity }; Tested this as sqf executed by radio trigger and with various values of _vel, acceleration, initial height and so on with good results.

Also, if someone want to investigate more deeply, here is some small and handy debug tool, that I just wrote for this purpose: _KA = 0; _en = objNull; _in = ""; _i = ""; { _LU = leader _x; _ne = _LU findNearestEnemy (vehicle _LU); if not (isNull _ne) then {_KA = _LU knowsAbout _ne} else {_KA = 0}; _in = "markKA" + str (_x); _i = createMarker [_in,position (vehicle _LU)]; _i setMarkerColor "ColorBlack"; _i setMarkerShape "ICON"; _i setMarkerSize [0.1,0.1]; _i setMarkerType "DOT"; _i setMarkerText (" - " + (str _KA)); } foreach AllGroups; while {(true)} do { sleep 1; { _LU = leader _x; _ne = _LU findNearestEnemy (vehicle _LU); if not (isNull _ne) then {_KA = _LU knowsAbout _ne} else {_KA = 0}; _i = "markKA" + str (_x); _i setMarkerPos (position (vehicle _LU)); _i setMarkerText (" - " + (str _KA)); } foreach AllGroups; } This shows on map refreshed every second markers, that indicates "knowledge" value about nearest known enemy for each group (0 is uknown, 4 is max value). To use this, make above code a sqf file, eg KAM.sqf, put that file into mission folder and execute same way as HAC script version, by nul = [] execVM "KAM.sqf"; in init.sqf or some init field. I'm curios, what values will show this for "blinded" groups... Of course this tool may be used for any other purpose too, but KAM (KnowsAbout Monitor) is only makeshift tool, so will not delete markers of destroyed groups and will not generate markers for groups spawned after executing of this script.

Good news - already reported and fixed for next release. :) ---------- Post added at 13:50 ---------- Previous post was at 13:32 ---------- About this annoying blindness issue: Very long shot, still there was changes in this in 1.60, so someone can test it: There is some reveal script, that provides Leader's knowledge about known enemy and friendly positions to all team leaders. For this purpose is used reveal command. Who knows, maybe this sets knowsAbout parameter to low for 1.60? Can't test this, so you, guys, must to test it for me. :) So. First, there is variable RydHQ_KnowTL. Adding RydHQ_KnowTL = false tu HAC config will turn off revealing, but only for human controlled Team leaders, so probably not help. To disable this for all you need to do as follows: 1. for testing use script version. 2. In this version's files find "Rev" sqf for used Leader(s) 3. Open this file in some editor or notepad. Code looks like this: if (isNil ("RydHQ_KnowTL")) then {RydHQ_KnowTL = true}; while {(true)} do { waituntil {sleep 1; not (isNil ("RydHQ_KnEnemies"))}; sleep 20; _players = []; if (RydHQ_KnowTL) then { { if (isPlayer (leader _x)) then {_players = _players + [_x]}; } foreach RydHQ_Friends; }; for [{_z = 0},{_z < (count RydHQ_KnEnemies)},{_z = _z + 1}] do { _KnU = RydHQ_KnEnemies select _z; { if ((_x knowsAbout _KnU) >= 0.01) then {{_x reveal _KnU} foreach ([RydHQ] + _players)} } foreach RydHQ_Friends }; for [{_z = 0},{_z < (count RydHQ_Friends)},{_z = _z + 1}] do { _KnU = RydHQ_Friends select _z; { {_x reveal (vehicle (leader _KnU))} foreach ([RydHQ] + _players) } foreach RydHQ_Friends } }; Replace this code with this one (copy and paste over current code): if (isNil ("RydHQ_KnowTL")) then {RydHQ_KnowTL = true}; /* while {(true)} do { waituntil {sleep 1; not (isNil ("RydHQ_KnEnemies"))}; sleep 20; _players = []; if (RydHQ_KnowTL) then { { if (isPlayer (leader _x)) then {_players = _players + [_x]}; } foreach RydHQ_Friends; }; for [{_z = 0},{_z < (count RydHQ_KnEnemies)},{_z = _z + 1}] do { _KnU = RydHQ_KnEnemies select _z; { if ((_x knowsAbout _KnU) >= 0.01) then {{_x reveal _KnU} foreach ([RydHQ] + _players)} } foreach RydHQ_Friends }; for [{_z = 0},{_z < (count RydHQ_Friends)},{_z = _z + 1}] do { _KnU = RydHQ_Friends select _z; { {_x reveal (vehicle (leader _KnU))} foreach ([RydHQ] + _players) } foreach RydHQ_Friends } }; */ This will turn off all reveal routine. 4. Play with so prepared script version and see, if blindness is still present, or maybe disappeared... But this affects only Leader's and players knowledge... Also must to analyze this code, seems, like there is some mistake (redundant and useless last foreach).

Not good. So I assume, that this problem not appears without HAC? Everyone have this problem? And appears while regular combat mission is issued by HAC? Can anyone test if this will appear when playing on pure Arma 2 1.10? Hmm. As I said, it is not appears to me at all, so can't hunt'em down, I move blindly here. Disabling different formations and waypoint behaviours will remove one of the most requested feature for HAC - exactly that: different formations and behaviours depending on situation. It would be a big regress. AI, as far as I know, will not change formation or behaviour on its own depending on situation, so in this case all troops should be all the time in default, aware mode, exactly as in first HAC version. And this is not true solution, means not cure for the problem, only removing troublemaking HAC feature, if really this is troublemaking here (if so, then same problem should occurs without HAC, when waypoint with different behaviours are set manually in editor, so I'm not convinced here). Micromanagement, if I understeand this word correctly here, is limited to minimum and only to specific situations (disableAI target and autotarget for cargo vehicles when on cargo missions (but cargo system is off by default, so can be easily tested without), smoke placing when withdrawing (also may be turned off), setting direction of watching on defensive position, turning off engine for idle vehicles... its all, I think). I see no way, in which this may affect regular combat behaviour, but I already said that before. HAC not deals with micro AI in any other way that by choosing default implemented in Arma waypoints modes (if this modes are crippled, then this is Arma issue, not HAC's). So, simply, do not know, what to do with this. I have no where to start, an idea, nothing. :( In the future I plan to improve code effectiveness, if I'm able to, but this means probably writing nearly all HAC code in different way (and for know I do not know, in which way), this means lot of work and lot of time needed for this, and time is currently luxury, that I haven't to much. And I see, that before this I will need to buy newest game version, because obviously my pure Arma do not share such problems with new OA/CO, and this will not happened soon, I afraid. Also there was said, that this kind of code do not overloads CPU, because is low priority. And in fact, there is no any FPS impact because of HAC for me, I have low-end computer, regardless, if there is one Leader or all of them, that means eight. Only difference is, that issuing orders take more time for each Leader (probably their scripts share always same amount of CPU resource, but in first place, beacuse cycles aren't executed simultanousy, but alternately). Hmm. Perhaps someone have a time and possibility to prepare short youtube presentation, how exactly this blindness looks like? This may help a bit too... PS Shortly: while haven't OA, CO and so on, I can't do anything about that until you, guys, provide to me a repro mission with this issue present and pointed, based on pure Arma 2 1.10 (and without any other mods/addons). I can not fix the problem, which I know only from the description of the other players, when these descriptions aren't and can't be sufficient to understand, what exactly is going wrong, and which I am not able to see and diagnose in my own gameplay, with some useful tools, in fully controlled by me environment etc. Sorry...

Hmm. Currently there is no such comparing with engaged enemy after issuing order, only before HAC considering, which group, if any, will be best to engage given enemy. Withdrawn are only groups considered as combat ineffective due to lack of ammo, health status, damage and casaulties (and this is happening, if enemy is to tough). Maybe it is possible, maybe to complicated... must to think about this. Its funny. I tried really hard to convince withrawning groups to stop firing at enemy and even to stop pay attention on him. Yes, I tried to achieve exactly this blindness, what happens as this issue to you, guys, but without effect. I suppose, there was maded some changes in AI after Arma 2 1.10, that gives this strange effect. Can't reproduce this issue so can't determine, what is its source. I think, that using of numerous and/or heavy scripts may cause such effects like not reacting AI only, if routines responsible for AI's default actions (FSMs?) such as firing at spotted enemy, have the same or lower priority in access to CPU resources as these scripts (HAC, DAC and so on). I do not know what's true, but I doubt it. Of course, if this effect apperars only when HAC is active, then situation is clear, but if it appears also without HAC, then what can I do? Yes, saw this thread. However for now I not even to launch Arma, so can't try this, only for quick HAC testing, because also my secondary, old videocard starts to make troubles and I think, that this junk will die soon. Fortunately there is a chance that in a month I will finally have a better one, but it is anything for sure. ---------- Post added at 22:57 ---------- Previous post was at 22:32 ---------- Reason may be as follows: - was not injuried seriously enough (they call for ambulance when there is such support in 500 meters radius (and even not necessary to know about, this is default Arma AI behaviour) and when damage is > 0.5 or when soldier can not stand (legs damage 1.0); so also only for this or greater damage ambulance will be sent. This is most probably here, try to add this code to init field of given unit: this setdamage 0.6 and check then; - was injuried enough, but ambulance was busy in other area; - some time passes before support mission is issued... ---------- Post added at 23:14 ---------- Previous post was at 22:57 ---------- Oh. There is no need to add into RHQs classnames of units, that are generic in pure Arma 2 1.10, only others (OA, CO, BAF, user maded and so on). This should make no difference however.

Well. In fact there is implemented such routine. Amongst other factors, when vehicle is damaged more than 0.5, then group is considered as "exhausted" in next Leader's cycle and receive "rest" order (look for green triangles on map in debug mode, good method to see, which side suffered greater losses), which means withdrawal to point, where often support units are gathering, if enemy nearby also with smoke usage if available (and this works - as tank commander I received such order when was damaged). Also such group will not receive further attack orders until its condition improve enough. But between receive order and obey order there is often big difference especially, when currently group is in fight.

:) Great. Something for me.

:) But this was that easiest part. Real troubles may appear during implementation. First is not much time for this in near future... However if it succeeds the effect may be very interesting. Classic HAC tactics against guerilla warfare...