HETMAN - Artificial Commander

[Rydygier 1309]

Found this thread about this strange helo behavior when under fire. Hmm. Seems that combination of "allowdamage false" and "never fire" combat mode do the trick. Of course allowdamage false is not an option, but maybe this info will help someone come up with an alternative way? How can we make pilot did not pay attention to the increasing damage to the helicopter? For now, I'll test just "never fire." BTW I've solved mentioned problem with crashing helo after cargo unload. Thanks for additional waypoint idea. Now after unload helo first increases its height and only then proceed to the next waypoint.

---------- Post added at 13:23 ---------- Previous post was at 11:42 ----------

More about:

when an inactive DAC zone is turned on, it generates units but although the HAC unit counter increases, no orders appear to be given to them

Just tested HAC with some self-prepared random groups spawner, so i can confirm, that HAC will take control under units spawned during the game. However, this conclusion makes quoted issue with units spawned by DAC more mysterious...

[orcinus 121]

I think the easiest way to deal with DAC created units is to make a list for HAC, in with PHRASES can be put like "inf_group_" or "HAC_". HAC will take control of those units as long as phrase is in leader name.

Hi Taro8

The lines I posted here

http://forums.bistudio.com/showpost.php?p=2085113&postcount=248

work fine, as long as the DAC zone is initialised at the start.

One can also add lines to the init to exclude such named-array groups from HAC, that works equally well (I've seen a need for this - HAC grabs the defending troops from DAC camps, other than those on any artillery or other statics, which isn't ideal IMHO).

As far as DAC zones initialised at the start are concerned, the two systems work seamlessly using these simple commands; so if it ain't broke, don't fix it :)

The issue I'm finding - & will be testing further today with HAC v1.1 - is that for any zone which is activated later, HAC recognises the new troops (you can watch the unit count jump if you activate the counter.sqf) but doesn't appear to utilise the new forces even when activation also includes releasing the units from DAC.

BR

Orcinus

---------- Post added at 12:36 PM ---------- Previous post was at 12:25 PM ----------

Similar option is in testing now. In this optional mode HAC will take control only over groups, which leaders are named "Ryd" (or "RydB", maybe will change this to "HAC" and "HACB") plus number from 1 to 100 (default) or to other, manually set maximum value. Eg "Ryd12" or "RydB98" for B side.

At the moment I have no idea how to make HAC looking for a specific phrase in their names instead of whole specific names. As far as I know, "string" variables can only be added to each other. Do not know method for so, that code be looking for shared part of given names.

Hi Rydygier

I'm not clear what you mean - currently HAC takes over the DAC-spawned units in arrays like "inf_group_z1" and as far as I can tell from watching the map with both DAC markers & HAC debug turned on, also takes over all respawned units.

In the case of HAC combined with DAC, I see no need to change anything as far as this aspect is concerned, if only for DAC zones initialised from the start.

BR

Orcinus

I'm not even sure if it's necessary to have the release-from-DAC lines in the init, but they don't hurt so I'm leaving them in.

[Rydygier 1309]

This optional mode is for general use, not only DAC dedicated. It gives possibility of highlight groups which, unlike the other, goes under HAC control. So this is inverse of RydHQ_Excluded array option. Regardless of this option of selection groups that should be included under HAC control, will also can to select them by synchronizing group leaders with leaderHQ and by placing groups names in RydHQ_Included array.

Therefore can be placed under tHAC control, for example, only units with a specific whole name (eg Ryd1). However I do not know, how to bring under HAC control groups, whose name only contains a specific phrase, but otherwise can be any. For example: HAC_1, HAC_Something or Blahblah_HAC_Anything.

EDIT: above refers to this:

I think the easiest way to deal with DAC units is created to make a list for HAC, in with PHRASES can be put like "inf_group_" or "HAC_". HAC will take control of Those units as long as phrase is leader in name.

But maybe, because of my poor English, did not understand properly, and there comes about preparation of such option in DAC configuration. If so, I'm sorry.

Edited January 7, 2012 by Rydygier

[_William 0]

Found this thread about this strange helo behavior when under fire. Hmm. Seems that combination of "allowdamage false" and "never fire" combat mode do the trick. Of course allowdamage false is not an option, but maybe this info will help someone come up with an alternative way? How can we make pilot did not pay attention to the increasing damage to the helicopter? For now, I'll test just "never fire."

The following works for me (and is what I include in all my automatically generated missions):

1. fly ingress on combatMode YELLOW, combat STEALTH. Yellow to avoid detours, STEALTH to fly without landing lights.

2. just prior to reaching the landing zone: disableAI "TARGET" and disableAI "AUTOTARGET", to prevent the helicopter moving to engage threats instead of landing. Note that door gunners will continue to fire at threats.

3. during the landing, run a script that continues to issue LAND commands until the heli is empty. This script includes some behavior to allow a group of heli's to land together.

comment "Force the helicopter to land, even under fire, until all passengers have disembarked.";

comment "William van der Sterren, www.plannedassault.com, 2010";

private ["_script", "_aircraft", "_landing_mode", "_update_delay", "_debug"];

_aircraft = _this select 0;

_script = 'rotary_wing\land_vehicle_under_any_condition.sqf';

_landing_mode = "GET OUT";

_update_delay = 0.5;

_debug = 0;

if (_debug == 1) then { diag_log (format ["time: %1 [%2] exec '%3' - started", time, _aircraft, _script]); };

comment "identify and track the passengers";

private ["_passengers", "_aircraft_group"];

_aircraft_group = group _aircraft;

_passengers = [];

{

if ( (group _x) != _aircraft_group ) then { _passengers = _passengers + [_x]; };

} forEach (crew _aircraft);

if (_debug == 1) then { diag_log (format ["time: %1 %2 passengers are: '%3'", time, _aircraft, _passengers]); };

comment "order aircraft to land, repeatedly if necessary until all passengers have disembarked";

_aircraft land _landing_mode;

private ["_empty"];

_empty = 0;

while { ((landResult _aircraft) != "NotFound") and (_empty == 0) } do

{

sleep _update_delay;

comment "remove dead and disembarked passengers";

private ["_disembarked"];

_disembarked = [];

if ( (count _passengers) == 0 ) then { _empty = 1; };

{

if ( (!alive _x) || (_x == (vehicle _x)) ) then { _disembarked = _disembarked + [_x]; };

} forEach _passengers;

if ( (_debug == 1) && ((count _disembarked) > 0) ) then { diag_log (format ["time %1: '%3' disembarked from aircraft %2", time, _aircraft, _disembarked]); };

_passengers = _passengers - _disembarked;

comment "determine whether we're empty, and abort any landing if we are";

if ( (count _passengers) == 0 ) then

{

_empty = 1;

_aircraft land "NONE";

if (_debug == 1) then { diag_log (format ["time %1: %2 completed disembarking", time, _aircraft]); };

}

else

{

comment "reissue the land command unless we're moving or a group vehicle is close and underneath us";

if ( unitReady _aircraft ) then

{

comment "check if any of this groups' aircraft is near and lower";

private ["_group_aircraft", "_above_aircraft"];

_group_aircraft = [];

{ if (((vehicle _x) != _aircraft) && (_x != (vehicle _x)) && (_x == driver (vehicle _x))) then { _group_aircraft = _group_aircraft + [vehicle _x]; }; } forEach (units _aircraft_group);

_above_aircraft = 0;

{

if ( ((getPos _aircraft select 2) > (getPos _x select 2)) and ((_x distance _aircraft) < 10.0) ) then { _above_aircraft = 1; };

} forEach _group_aircraft;

if ( 0 == _above_aircraft ) then

{

_aircraft land _landing_mode;

};

};

};

};

if (_debug == 1) then { diag_log (format ["time: %1 [%2] exec '%3' - exited", time, _aircraft, _script]); };

true

This

shows proof (and the dangers of Arma2 heli landings in general)

[Rydygier 1309]

HAC recognises the new troops (you can watch the unit count jump if you activate the counter.sqf)

Counter is mostly separate tool, it simpy counts units and vehicles on map, therefore it does not mean that HAC is aware of these units. While in brackets counterU.sqs indicates the number of units of given side known to the opposite side, and this information comes from HAC.

@William - thanks, will try.

[mikey74 169]

Orcinus:

fun=["z1",[1,0,0],[10,3,50,1,"inf_group_z1"],[],[3,1,10,1,"arm_group_z1"],[],[1,1,1,7]] spawn DAC_Zone;

Give the units only 1 way point. Seems to work a bit better on my end, but depends on what you are shooting for.

[Rydygier 1309]

Funny, just now I learned that MH60S chopper is MEDEVAC and has heal ability. :) Must do change in support category...

---------- Post added at 17:43 ---------- Previous post was at 15:54 ----------

@ William

1. fly ingress on combatMode YELLOW, combat STEALTH. Yellow to avoid detours, STEALTH to fly without landing lights.

2. just prior to reaching the landing zone: disableAI "TARGET" and disableAI "AUTOTARGET", to prevent the helicopter moving to engage threats instead of landing. Note that door gunners will continue to fire at threats.

3. during the landing, run a script that continues to issue LAND commands until the heli is empty. This script includes some behavior to allow a group of heli's to land together.

I think, that now is better. Thanks a lot. Helos not engage enemy. It happens, however, that the helicopter at the sight of the enemy, especially an enemy helicopter, without abandoning designated waypoint fly somewhere far away, in a completely different direction, there waits a few minutes and then comes back and either unloads group, as it should, or fly somewhere again...

[orcinus 121]

Counter is mostly separate tool, it simpy counts units and vehicles on map, therefore it does not mean that HAC is aware of these units. While in brackets counterU.sqs indicates the number of units of given side known to the opposite side, and this information comes from HAC.

Thanks, that helped a lot. Modified original code to:

#loop1

_unitsumW = (west countSide vehicles) + (west countSide allunits)

_unitsumE = (east countSide vehicles) + (east countSide allunits)

~5

hintsilent format ["West %1 (Kn: %4) - East %2 (Kn: %3)",_unitsumW,_unitsumE,count RydHQ_KnEnemies,count RydHQB_KnEnemies]

~10

goto "loop1"

and added a second counter script to list controlled groups:

#loop1

_unitsumW = (RydHQ_Friends)

_unitsumE = (RydHQ_Enemies)

~5

hintsilent format ["West %1 (Kn: %4) - East %2 (Kn: %3)",_unitsumW,_unitsumE]

~10

goto "loop1"

Each activated by radio triggers (if the first is activated too early, RPT file gets filled with errors about one Kn value undefined &/or division by zero).

The hint text alternates between a list of units/groups that (I assume) are under the control of the 2 commanders (the new script), and stats on all known units plus tally of killed on each side.

I simplified my mission - however while the newly-spawned groups from both "t=o" intitialised DAC zones & those activated by trigger appear in the second listing as named groups (e.g., B 1-1-C), something still is borked; the respawn counts for the camps behave in odd ways, & in both full test runs, LeaderHQ surrendered despite having 7 respawns left in the main DAC zone; in the first trial the displayed count from counter.sqf was 0 units for HQ which was seemingly incorrect (my own team totalled 13, and all still alive; & I could see other HQ groups on the map).

Have my counter code changes screwed it up? - especially as there were no respawns left in the main E (HGB) DAC zone.

On activating either or both of the reinforcement DAC zones (delayed intitiation), the new groups appear in the controlled groups list as well as boosting the unit counts from counter.sqf.

Will test some more tomorrow, after switching the test mission to HAC1.1 & then upload it for anyone interested (please feel free to criticise my attempts - I'll learn faster that way).

BR

Orcinus

---------- Post added at 09:15 PM ---------- Previous post was at 09:08 PM ----------

@Rydygier

Funny, just now I learned that MH60S chopper is MEDEVAC and has heal ability. :) Must do change in support category...

FYI, at least one of the OA Stryker units also has healing abilities - balances with the Vodkik ambulance for OPFOR.

BR

Orcinus

---------- Post added at 09:17 PM ---------- Previous post was at 09:15 PM ----------

Orcinus: Give the units only 1 way point. Seems to work a bit better on my end, but depends on what you are shooting for.

Cheers, I'll try that tomorrow. Time for dinner now, me hungry

BR

Orcinus

Edited January 7, 2012 by Orcinus
Additional information

[Rydygier 1309]

I guess I'll have a closer look at the DAC and do various tests to see exactly what is happening with those respawns, before will understand what is going on, because now I know too little about DAC - so far I had no occasion to use it, although I downloaded DAC for myself (for a few months practically no playing, only scripting here).

[fabrizio_t 58]

Similar option is in testing now. In this optional mode HAC will take control only over groups, which leaders are named "Ryd" (or "RydB", maybe will change this to "HAC" and "HACB") plus number from 1 to 100 (default) or to other, manually set maximum value. Eg "Ryd12" or "RydB98" for B side.

At the moment I have no idea how to make HAC looking for a specific phrase in their names instead of whole specific names. As far as I know, "string" variables can only be added to each other. Do not know method for so, that code be looking for shared part of given names.

I bet this custom functions library may help:

http://www.kronzky.info/snippets/strings/index.htm

See "InStr".

By the way, i've looked a bit into the code.

Just a minor suggestion: by using SQF functions you may be able to cut some repetition / redundancy, improve maintanability and achieve even better performance.

SQF Functions are pretty straightforward to use, see here for reference: http://community.bistudio.com/wiki/Function

Edited January 7, 2012 by fabrizio_T

[Rydygier 1309]

Thanks.

I intentionally avoided use of functions, because I do not have any experience with them and wanted to avoid additional complications associated with learning their usage, when I wanted to focus on HAC merits. As I read, they also have its limitations: when containing a lot of code, may slow down, rather than accelerate. I have no experience to say, how large parts of code is worth pack up into function, and when it is no longer profitable. For example, a secondary scripts, that I run through execVM, are quite large. I would not want also, that main script wait for their completion.

In other words - to take advantage of functions and avoid their drawbacks, first I need to learn more about them, work out... So it is the song of the future.

[taro8 806]

About that MV-22 problem: ospray keeps missing LZ due to high speed, but if you set up your waypoints right you can limit the tendency to shoot deep into enemy territory. I did quite a bit of testing, but no good solution was found, only small fix making use of AI turning right in aircraft when told to stop.

Here is the legend:

1. Normal speed

2. Limited speed, timeout 10s

3. Transport unload

Pink dotted line - how MV-22 flies (more or less)

Red symbol - where I get out

That sharp tun at the end is done in VTOL mode, its rather slow so its unfit for combat insertions. Still, its better then overshooting whole Utes island.

[Rydygier 1309]

Thanks, Taro8.

More about this strange problem with initially not active DAC spawn zones:

I'm not sure I understood the essence of the problem, at least have prepared a small testing ground, based on how I understood problem, for DAC addon (newest alpha 1 HAC files with init.sqf included). There is "internal" DAC logic in use.

DAC&HAC

I placed two inactive at the beginning zones, one per side and placed west leaderHQ with objective. Zones are activated by radio channel Juliet - this should be done after start of HAC. 15 seconds after activation of zones will run also HC module, which allows via CTRL + SPACE to keep track of units movements on map. I conclude that HAC sets waypoints for units that were spawned by a zones activated only during the game as much as usual, and these units follow to their target as should be. Occasionally there are some realted to DAC files RPT errors, also it seems, that DAC sometimes gives initial waypoints far on the sea. So it does not explain directly reported by Orcinus problems with such spawning zones, but anyone, who has mentioned problem with his own DAC config, can now try and compare used configs and maybe look for causes of problems in the differences between these configurations.

By the occasion of these tests have found and removed a small bug in the main flanking maneuver routine (lack of removing previously added waypoints)...

Edited January 8, 2012 by Rydygier

[orcinus 121]

Thanks, Taro8.

More about this strange problem with initially not active DAC spawn zones:

I'm not sure I understood the essence of the problem, at least have prepared a small testing ground, based on how I understood problem, for DAC addon (newest alpha 1 HAC files with init.sqf included). There is "internal" DAC logic in use.

DAC&HAC

Thanks, I'll try this out.

Occasionally there are some realted to DAC files RPT errors, also it seems, that DAC sometimes gives initial waypoints far on the sea. between these configurations.

I noticed that as well, though I'm not sure which script set is placing the waypoints. However, if you watch the map for a little while, those weird waypoints are deleted.

By the occasion of these tests have found and removed a small bug in the main flanking maneuver routine (lack of removing previously added waypoints)...

Ahh, maybe that's it? - might relate to Mikey74's observation that setting only 1 waypoint per group in the DAC is better (haven't had time to test yet). I noticed as well (HAC 1.0 & HAC 1.1alpha) that when I set HQ to defend, my unit was sent from just north of Protvino to a spot ~1km away SE on a little peninsula just S of Devil's Peak - I ignored the command :eek:

I'll retest with the modifed flanking script.

Rydygier, many thanks once more for all your continuing efforts on HAC.

BR

Orcinus

[Rydygier 1309]

I'll retest with the modifed flanking script.

That will be next alpha, which I upload when support handling will be done. Soon, I hope.

my unit was sent from just north of Protvino to a spot ~1km away SE on a little peninsula just S of Devil's Peak - I ignored the command

:) Yes, defense perimeter has leght of about 1000 meters in HAC. Utes is in fact to small for HETMAN.

[Rydygier 1309]

A few comments on the medevac support, on which I work now:

I noticed, that there is implemented in Arma doubled generic system:

- first step - if an ambulance is in sight, nearby team leaders sends his injuried units to heal, and ambulance goes to meet them and waits for termination of treatment. This makes any attempt of prior exportation wounded from the battlefield vain, because wounded near the medevac unit will automatically take the treatment.

- second step - SUPPORT waypoint - If you designate a waypoint of this type to ambulance, it will automatically receive calls for healing assistance (yellow sidechat) from the battlefield and went to the wounded, then waits for end of treatment and then go to the next injured.

EDIT: This system also includes handling of medical support calls by the player, which is one of points from "to do".

So, I think, the only thing that will do HAC will be sending an adequate number of ambulances in given area, taking into account number of wounded, with "SUPPORT" waypoint. After end of support vehicle will not return to the starting point, and remain near the battle lines for further disposal.

It was also postulated that soldiers injured in the legs were separated from their groups and then alone retreated toward the medevac units to avoid slowing rest of the group. I have serious doubts whether this should be happening. Does team shall in such a way to leave a wounded colleague to their fate? Is that it happens on a real battlefield? Instead, perhaps better, that such injuries were treated primarily and until that moment guarded by team mates. The above described generic system works well, units are treated fairly smoothly thus crawling wounded should not slow down squad too long.

Edited January 8, 2012 by Rydygier

[wolffy.au 9]

I haven't been focused on this mod as much as I'd like to, but just a word on the SUPPORT waypoint, in that it only works when local to the AI or players i.e., if on a dedicated server I have an ambulance with a support waypoint, and I as a player request support, I will be told there is none available.

AI running on the dedicated server will be granted support, as they are local to the unit with the SUPPORT waypoint. Not sure how it impacts your plans, if at all - but be aware. If I ever work out where the code is that executes this "call for help", I work on making it MP compatible. :D

I know there is talk of getting HAC as a module in MSO, so I will keep following this and one day get to have a play around in it.

[Rydygier 1309]

Hmm. Thanks for this information. I do not know if I can do something about it, but I will think about. In the end, still there is this first option, which operates within a radius of 500 meters from the ambulance. It seems that both operate simultaneously. Unless this option also works only locally...

EDIT: In fact, with SUPPORT waypoint is also this problem, that probably there is no distance limitations, which threatens that ambulance will be driving all over the map, which I would rather avoid. Still can prove, that I do not use this type of waypoint for this reason. HAC med-support script is adapted more to that other option of medevac calls, limited to 500 meters.

Edited January 9, 2012 by Rydygier

[kremator 1065]

Hey Rydygier,

Have you seen that Domz has included HAC into his high command extension stuff? Really good!

http://forums.bistudio.com/showpost.php?p=2086225&postcount=32

[Rydygier 1309]

Yes, he asked me about permission. That's great. Will try this, when I'll have some time for playing, that is, when I finish HAC 1.1. :)

[orcinus 121]

Hi

Been rather busy with unexpected work project so haven't had much time, however I did notice one thing:

I have a player group set up in my Chernarus test where I pre-assigned (in the editor) half the units to team Red. If I team-switch away (I put a couple of civ observers at the delayed-initiation DAC sites), when I switch back the team assignments have gone and the team menu is grayed out, so the player can't split the group into teams again. The group wasn't split into teams at this point.

Will be testing the Utes HAC-DAC demo this evening.

BR

Orcinus

[Rydygier 1309]

And without HAC this effect does not occur?

Now about reammo issues.

As some know, there is no command "getVehicleAmmo" that returns value obtained by the command "setVehicleAmmo". I just tried two different, but similar workarounds, but both are inaccurate and based on the amount of ammunition in the currently loaded magazine ("ammo" command), and therefore give a false result if the vehicle has a spare magazines for given weapon (also there is no command, that allows sum up bullets of all magazines of given weapon only, the command "magazines" gives a list of all magazines for all weapons. Maybe you can try to match names of these magazines to the appropriate weapon and multiply maximal magazine capacity value only by number of its appriopriate kind in the "magazines" array minus one, and sum with bullets in current loaded magazine, but even, if this is possible, this will make whole calculation far too long, I think).

So, unfortunately, reammo vehicle will depart with the delivery only when particular vehicle shoots all possessed ammunition in the main weapon. I'm not particularly happy with this, but I see no other way...

Edited January 10, 2012 by Rydygier

[taro8 806]

I assume that you dont want ammo truck to drive to every vehicle that shoot out all ammo.

You can do something like this: you order ammo truck to move somewhere and once it arrives to the spot you give it "disableAi move". Now in next cycle HAC check if vehicle is out of ammo, if it is HAC tell that vehicle to move to position where ammo truck is. AI will rearm by themselves, then it can be sent back to action in next cycle. If other supply vehicles would be used that way (creating something like Forward resupply base) AI will use them as well.

While not perfect, this solution is pretty decent and elegant.

[Rydygier 1309]

Something like that I want to do. Now this "somewhere" point I set currently near one of the units without ammunition/wounded/without fuel/damaged to make sure that HAC does not send support to a place where it is unnecessary. This support unit will stay there until it will be sent to another unit need of support. I take into account also, that would not send more than one support unit in the same area (currently up to one support of given kind in 125-250 meters radius, but it will be probably more extended) and if there are some known enemies in area (in 500 meters radius from target point and same radius from a halfway point to avoid passing a nearby enemy), support will not be sent. Of course I can simply deploy support trucks evenly behind front line too.

Edited January 10, 2012 by Rydygier

[orcinus 121]

Something like that I want to do. Now this "somewhere" point I set currently near one of the units without ammunition/wounded/without fuel/damaged to make sure that HAC does not send support to a place where it is unnecessary. This support unit will stay there until it will be sent to another unit need of support. I take into account also, that would not send more than one support unit in the same area (currently up to one support of given kind in 125-250 meters radius, but it will be probably more extended) and if there are some known enemies in area (in 500 meters radius from target point and same radius from a halfway point to avoid passing a nearby enemy), support will not be sent. Of course I can simply deploy support trucks evenly behind front line too.

Hi

Don't know if you've ever tried it, but Demonized has a really excellent script for automating medics in the player's team, Automedic:

http://forums.bistudio.com/showthread.php?t=122083

which has various changeable parameters for how the medics should behave, distance limits, prioritisation re level of injury (read 'damage'), & setting fallback positions. Once initiated, just one medic (I've placed uip to 3 medics in a large group) attends an injured team-mate quite without player intervention.

Demonized comes over as very helpful as well as highly competent; maybe asked nicely he might even agree to his code being modifed or some of it incorporated into HAC. I use the script a lot in missions for myself.

Another potential source is SLX - part of the script set (now it's been tweaked by Gunter Severloh) correctly checks for allies near wounded units & depending on threat level, sends them to give first aid (even enemy units will sometimes heal a wounded unit, taking them prisoner thereafter). SLX is now freely available to the community for modification, etc., as sadly Solus seems to have quit.

In principle, the routines in those scripts for detecting injured grunts & sending support should be adaptable to detecting damaged, immobilized vehicles, or for weapons platforms running low on ammo or fuel to detect allied support vehicles & travel to them for rearming automatically.

Re your DAC&HAC mission: I've run through it twice, & there were no errors. Likely it is some newbie cock-up I've made somewhere (though the DAC inits are fine) so I'll try & troubleshoot those.

Cheers

Orcinus