HETMAN - Artificial Commander

[Rydygier 1302]

Thanks for report. Which Leader it was? B? RPT was clear? What was approximate time interval between these cyclic lags? Will try to find reason of this (perhaps just it is not scripted enough situation, when Leader is dead and surrendering off (and this always should be off for Leaders from C to H)). However haven't time for this now and I'm not sure, when I will have.

Edited March 1, 2012 by Rydygier

[taro8 806]

It was OPFOR leader. I think it was B as I only had one commander per side. I cant say exactly the span between lags, but it was very frequent, about 10s or so. I have so many mods that my RTP is fucked up, with makes it hard to find anything unless you knwo what you are looking for. Also I deleted it so Arma would create new cleaner one when I was testing my arty script..

Edited March 4, 2012 by Taro8

[pd3 25]

Looks like I've jumped into this discussion late, as this has probably (and currently is) being discussed.

Respawning reinforcements for dummies?

In other words: Areas wherein reinforcements are spawned, the AI commander goes: "Oh, hey, look, more cannon fodder", and appropriates them accordingly.

I'm currently fiddling around with DAC and perhaps its just something I'm not doing correctly, but it seems like DAC has its own AI direction nonsense that it seems to prefer and I can't get the HAC and DAC to play nice.

It seems to me that DAC's spawn zones must have waypoints, which can only exist within the maximum limits of the defined zone, which means AI can spawn anywhere within an area they could technically walk to.

Which means if you ever want to see two opposing forces fight, you technically have to give them the ability to spawn right next to each other...

And while that might make for an interesting "instant action", battle, its pretty lame when you're trying to create a mission in which two AI commanders direct assets against one another.

Simply put, I've been testing it, and I've been given no indication that HAC will "assume control" of AI spawned with DAC.

Has anyone created a mission with the HAC suite that has spawning reinforcements that it can actually send to secure objectives?

If so, could you please perhaps make a tutorial or submit your map for others?

[orcinus 121]

Simply put, I've been testing it, and I've been given no indication that HAC will "assume control" of AI spawned with DAC.

Has anyone created a mission with the HAC suite that has spawning reinforcements that it can actually send to secure objectives?

If so, could you please perhaps make a tutorial or submit your map for others?

I've been using spawning with DAC in HAC games for some time, though hardly at all since HAC v1.1 was released as I've been snowed under with RL stuff. Note there is no way to predict what the DAC-spawned groups will be called, so one thing you should do is spawn the DAC zones before starting HAC, & use SubAll for HAC (which is the simplest to set up anyway).

The handover from DAC to HAC seems different in HAC v1.1 to earlier versions, & I have some issues with late-activated zones in HAC v1.1 that I'm trying to resolve; however DAC zones initiated at the start seem to hand over the units quite satisfactorily. I'll put together a basic 2-leader HAC [script] plus 2 camps/2waypoint DAC [script] zone mission & upload it somewhere around the end of this week - pretty busy for the next few days. It will be set on Chernarus. I'll post some notes here about things I've found that do & don't work.

Note that I haven't yet set up fronts with spawning, though I think it should be possible to have DAC spawning into the separate HAC zones (rather than the primary A & B leaders grabbing all the units). One of the things I have planned for next weekend.

By the way, you do not need to have opposing DAC zones adjacent to or overlapping with each other to get a battle - there are 2, maybe 3 tutorial missions in the DAC pack which demonstrate that. Look at those & read the manual, plus there's a lot of useful information in the main DAC thread and JTDMarkwick's excellent DAC tutorial thread.

BR

Orcinus

[pd3 25]

I've been using spawning with DAC in HAC games for some time, though hardly at all since HAC v1.1 was released as I've been snowed under with RL stuff. Note there is no way to predict what the DAC-spawned groups will be called, so one thing you should do is spawn the DAC zones before starting HAC, & use SubAll for HAC (which is the simplest to set up anyway).

The handover from DAC to HAC seems different in HAC v1.1 to earlier versions, & I have some issues with late-activated zones in HAC v1.1 that I'm trying to resolve; however DAC zones initiated at the start seem to hand over the units quite satisfactorily. I'll put together a basic 2-leader HAC [script] plus 2 camps/2waypoint DAC [script] zone mission & upload it somewhere around the end of this week - pretty busy for the next few days. It will be set on Chernarus. I'll post some notes here about things I've found that do & don't work.

Note that I haven't yet set up fronts with spawning, though I think it should be possible to have DAC spawning into the separate HAC zones (rather than the primary A & B leaders grabbing all the units). One of the things I have planned for next weekend.

By the way, you do not need to have opposing DAC zones adjacent to or overlapping with each other to get a battle - there are 2, maybe 3 tutorial missions in the DAC pack which demonstrate that. Look at those & read the manual, plus there's a lot of useful information in the main DAC thread and JTDMarkwick's excellent DAC tutorial thread.

BR

Orcinus

That would be great, and I know what you mean by RL issues monpolizing one's free time.

I've only just gotten into either of them, so it will require some reading, however I'm finding, as usual, that practical examples usually help provide context a lot better especially when chewing through technical stuff I'm not familiar with.

I was aware that you can use waypoints with DAC, and I'm assuming that's what you're referring to, I believe there's an example mission utilizing them. I'll get around to reading a bit more and trying to get the most out of both as I can, but yeah, if you can post any practical examples of something similar to what I'm trying to accomplish, I'd appreciate it.

[orcinus 121]

That would be great, and I know what you mean by RL issues monpolizing one's free time.

I've only just gotten into either of them, so it will require some reading, however I'm finding, as usual, that practical examples usually help provide context a lot better especially when chewing through technical stuff I'm not familiar with.

I was aware that you can use waypoints with DAC, and I'm assuming that's what you're referring to, I believe there's an example mission utilizing them. I'll get around to reading a bit more and trying to get the most out of both as I can, but yeah, if you can post any practical examples of something similar to what I'm trying to accomplish, I'd appreciate it.

Yes, you can add user waypoints into DAC but you don't need to. Have a look at the demo "enemy contact" - it uses linked zones to get the opposing sides to engage. Make a copy then port it to somewhere bigger than Utes, move the Blufor zones further away from Opfor &/or resize them & you'll see what I mean.

I started out doing just that on Podagorsk, then adding in a team for myself + more statics & fortifications, etc. Large-scale assaults on towns (offense & defense) plus pitched battles in the countryside - all quite easy to set up once you've done one, it's just a question of how & where you set up the zones. I have 6 roughed-out missions that someday might appear as a campaign when I've got HAC working with DAC the way I hope (no HAC in those missions yet, they pre-date HAC release). They're quite tough - well, at least for me 'cos I'm still rubbish :)

BR

Orcinus

[Rydygier 1302]

I may have found a problem with HAC. I set up small infantry only battle around Electozavodsk (or something). I snuck behind enemy lines and found enemy commander, called artillery strike (once again thanks for help) and killed him. Then something weird happened: Arma started lagging as hell and everything turned into slide show. It was very cyclic so Im pretty sure its script trying to do something, but failing, due to dead enemy commander.

Yesterday got couple of free houres, so did some test and some thinking as well. Simply tried few times to run HAC and to kill leaderHQ unit. There was no lags observed by me, but (now I will bore you :) ):

(Technical details below, may be skipped, if someone is not interested, how HAC doing some things)

Flow of the HAC code looks like here, so that is the main loop, called a cycle (with two internal branches, for offensive or defensive stance, but this is BTW). At its end code checks, whether the RydHQ variable still corresponding to leader's group (means is not null. If group is gone (all memebers are dead), then RydHQ becomes null). If RydHQ is null, then code will permanently exit main loop (also if surrender routine occured for given leader, but this should be rather turned off). However. At start only HAC's code spawns some secondary, small loops, like support checks, garrison control etc. These loops are working constantly, simultanously and indepedently of the main loop. Also every cycle main loop (and some secondary loops too) spawns some sub-routines responsible for orders execution (waypoint assigning and such, mostly sqfs with "Go" in its names), all of them simultanous and independent (however some of them will "communicate" between each other or will spawn some sub-sub-routines, as terrain scans, orders notifications or cargo calls). This sub-routines aren't loops, but often their execution takes many minutes, because they are full of "waituntils" - they simply waits, until given group finishes first part of its job, and then they give to that group next waypoint, order, whatever is needed next.

So. Even, if due to leaderHQ's death main loop will exit at end of its current cycle, these secondary loops and sub-routines are still running. And, especially these sub-routines, often refer to leaderHQ, mainly it's position. So what happens, when leaderHQ is killed? Should happen nothing special, leaderHQ is still there, but is not alive, only its side, as all dead units, is changed to civilian, but still has own position and same name. But not always... I think, that when unit is, due to massive damage or some other addon feature, dismembered (artillery shell's explosions is a good reason), unit object ceases to exist, is replaced by new objects, which represent pieces/remains... Question is, what Arma engine doing, when script is trying to reffer to position or other attribute (as side) of object or object itself, that not longer exist? Frankly, I don't know, but maybe here is possibility of lags.

Now what can I do with that? I affraid, not much. First, there is script command "terminate" to immediately terminating of runnig script, but:

1. It needs, that each spawned script routine had assigned so called "scripthandle", means kind of variable, that reffers to given running code (eg _somescripthandle = [] spawn something). This means the necessity of naming with unique "scripthandle" each time each launched subroutine, and I don't know, how achieve that;

2. Even very often checks, if leaderHQ still exist will not guarantee, that some code will not to try to reffer to no longer existing object between these checks;

3. Consequences of "premature" termination of running sub-routine may be worse, than these lags.

Second, there perhaps is also other method - to add special check, if leaderHQ exist, before each reffering to that unit. It is possible and this will not be done in close future due to amount of work, that this needs (there are about 1000 such references...).

Third, only, I can do, is to check, if some of these secondary loops may cause this lags and input such check here. It is possible, because lags are cyclic (five of this loops have cycle short enough, below minute: four support scanners (25 sec.) and "revealer" for sharing knowledge about known units - 20 seconds). However can't check, if this helps until manage to reproduce problem with lags under controlled circumstances. Will see, when I will have more time for this.

Question: If you still remember, Taro8, there was any support vehicles on map for side, that lost its leader in this mission?

EDIT: just maded further tests - this time I removed leaderHQ from map completely, by "deleteVehicle" when HAC was running. Still no "luck" - no lags spotted. Currently haven't other theory, maybe this occurs only in rare circumstancies, or maybe this was something else, not HAC... Will keep this in mind anyway.

Edited March 24, 2012 by Rydygier

[subroc 4]

Rydygier, iv´e testet the übersniping problem and it most likely comes from some of the addons im using. so no fault on your scipts.

[orcinus 121]

Rydygier, iv´e testet the übersniping problem and it most likely comes from some of the addons im using. so no fault on your scipts.

If by "übersniping problem" you mean the AI blowing you away with headshots almost as soon as you are detected, that is a problem introduced in 1.60 when BIS removed the precision setting from the config. The only way in vanilla to lower enemy precision is to reduce enemy skill, which makes the AI somewhat moronic. You can use either Robalo's asr_ai (you'll need to enter the appropriate unit classes into the config.hpp) or use Jedra's skills slider. You can use both ofc, but don't load the JED config addon since asr_ai changes the game config as well. Both are excellent addons.

HTH

Orcinus

[Rydygier 1302]

Perhaps it is time for some news here...

Got a few free days, so I started to deal with some partisan tactics AI code. I can't guarantee, that I will manage to complete this project, but first steps are done...

I suppose that this addition will provide not so much an intense fights, as regular HAC Leaders do, but rather kind of background for missions in the form of acts of sabotage, placing mines on roads, ambushes and occasional brief skirmishes from time to time here and there. In brief - asimetric, guerilla warfare, not regular battles. All this, as usual, dynamic, based only on resources currently present on map and, hopefully, unpredictable. I think, that all this will work best on big maps, like Chernaruss. We will see... :)

I started with what I consider to be the biggest challenge. I call this "prophetic procedure". Purpose of this is to predict, where will be given moving unit after given, long time (10-30 minutes) without any "supernatural" knowledge about unit's target. For dynamicaly setting of ambushes, if opportunity will meet with possibility. This should be one of important partisan Leader activities. Something similar is used in AI FO scripts, but here problem is more complex. Determination of the move vector is only first step. Main problem here is to determine unit's destination basing on this vector, road network and most probable destinations (based on map locations and some crowd finder). There will be no miracles here. Such thing is mostly guessing work and lottery even for human intelligence. Still I hope, that I managed to make, that AI will to guess not much worse than human. Of course sometimes AI decisions will be completely stupid, which makes clear, that AI only pretends thinking :). Had two concepts, and was unable to choose one of them, so decided to implement both. :) Currently procedure returns 1 to 10 (five per method) suitable for ambush spots, in good covered terrain, preferably elevated, near, but not too near of road recognized, as most probably route of enemy.

Method 1

- Some minutes for determining vector of unit's movement;

- because roads are rarely straight, such vector rarely corresponds exactly to the true direction towards destination point. So around predicted vector's end point is calculated elliptic area of size dependent of distance from current unit position;

- AI collects info about all potentially interesting locations in this area (including places, where many units are present close toghether);

- three of this locations are selected, usualy closest to unit, but sometimes also randomly.

- along line, that links unit with chosen location are choosed some points (dozen or so);

- now for each point is finded nearest road segment;

- surrounding of each segment is topographically scanned with some randomness;

- best five spots are chosen;

- one of them is randomly chosen.

Method 2

- Some minutes for determining vector of unit's movement;

- now is gathered info about some interesting locations (mostly towns and villages) within some wide angle and within certain, but randomized distance ahead of unit;

- one of them is randomly selected as expected destination of unit;

- is determined complete road route from unit to this location (usualy similar to optimal, but not exactly);

- some of this route's roads segments are scanned to choose spot with best terrain for ambush;

- five best spots are selected;

- one of them is selected randomly.

Both methods are used simultanously. Above scheme assumes, that the target will keep the roads.

Calculating all this can take from dozen seconds to more than two minutes and can produce light lags (few (1-3) FPS drop is expected), because code contains some CPU-heavy loops without sleeps (with even minimal sleeps this will take far too long)...

When spots are choosed, AI should to check, if there is enough available units close enough, to send them there with ambush mission. I suppose, that sometimes, or even often, ambushes will be prepared at wrong routes, but it is not so bad - they will wait some time, maybe also this route will be used by enemy in the future?

These are my ideas, but maybe someone has own, better/different? I will be grateful for any suggestions here. Is also considered introduction factor of "friendly natives", providing average reliable information on the enemy targets and destinations...

This is all for now, work will be continued, as time will allow me.

Edited April 14, 2012 by Rydygier

[subroc 4]

wow, that seems promising. I would say that the friendly natives is best left up to the missionmakers decision (the standard ask civ for targets is pretty good for this). But the idea to have a insurgent commander is really nice. One thing that i miss in HAC1.1 is a better defensive system. I would like to have my leaderHQ defending obj1-obj4, not only area around leaderHQ. Setting up obj1 in town 1, obj2 in town 2 etc. or putting the objectives in a row forming a frontline.

[Rydygier 1302]

Yes, I agree, defensive behavior can be better, so probably some day will be :). Good idea with front of defence created such way. Will think about.

Best to do with HAC 1.1 is for now:

RydHQ_LRelocating – if set to true, Leader will be relocated (will move slowly) to last captured objective (and will retreat (fast fall back) if this objective become “lostâ€).

This way at least defesive perimeter will be set at lately captured objective (Leader will try to defend, what he conquered already).

[SavageCDN 231]

(With DAC) ....if you ever want to see two opposing forces fight, you technically have to give them the ability to spawn right next to each other...

And while that might make for an interesting "instant action", battle, its pretty lame when you're trying to create a mission in which two AI commanders direct assets against one another.

There are a few ways to accomplish your first point in DAC - Orcinus mentioned one.. linked zones. The problem with using linked zones is that the units will continue to use the waypoints from the 'spawn' zone as well as the linked one, which may not be ideal if you are trying to simulate a 'front'. A better way is to move the DAC zone after DAC has initialized by adding a few lines to the end of your init.sqf (or some other method).

**I am doing this at work so not sure if I have it exactly right.. this code was pulled from the main DAC thread (a response by shiloa)**

// Move DAC Unit zones
waituntil{DAC_Basic_Value > 0};

if(isServer) then
{
[zone1,(position zone3),[],0,0,0] call DAC_fChangeZone;
sleep 1;
waituntil{DAC_NewZone == 0};
[zone2,(position zone3),[],0,0,0] call DAC_fChangeZone;
};

This will move both zone1 and zone2 to zone3's position after DAC has completed initialization. The units created in zone1 and zone2 will be assigned new waypoints. If zone3 is 'linked' to the other zones then the units will have a waypoint pool consisting of all three zones. If you only have one zone to move, get rid of these three lines:

sleep 1;
waituntil{DAC_NewZone == 0};
[zone2,(position zone3),[],0,0,0] call DAC_fChangeZone;

So for a 'front' you would create a DAC spawn zone (no units just camp) in the rear-area, then separate unit spawn zones where you want the units to appear at mission start, then move the DAC unit zones to where you want the units to 'attack'. Units that are killed will respawn at the rear-area DAC spawn zone and move to their 'new' zone waypoints.

Simply put, I've been testing it, and I've been given no indication that HAC will "assume control" of AI spawned with DAC.

I'm not too sure as I've never tried DAC and HAC together (but will do so now!!), but I would assume you need to release the units from DAC after they are created. Howto is probably in the DAC manual somewhere. Not sure about re-spawning DAC units and then releasing them... but I'm sure it's possible :o

edit: I just re-read my post... hopefully it makes sense my coffee intake is lower than usual today

Edited April 16, 2012 by SavageCDN

[orcinus 121]

The problem with using linked zones is that the units will continue to use the waypoints from the 'spawn' zone as well as the linked one, which may not be ideal if you are trying to simulate a 'front'

It's not an issue if you set DAC to spawn all units into an array; an entry from a mission.sqm looks like:

class Sensors
{
	items=14;
	class Item0
	{
		position[]={5024.0376,15.860807,1550.2985};
		a=150;
		b=200;
		rectangular=1;
		activationBy="LOGIC";
		repeating=1;
		age="UNKNOWN";
		name="z1";
		expCond="time > 1";
		expActiv="fun=[""z1"",[1,0,0],[10,3,40,2,""inf_group_z1""],[3,3,40,2,""La_group_z1""],[3,1,40,2,""arm_group_z1""],[],[1,1,1,7]] spawn DAC_Zone;";
		class Effects
		{
		};
	};

I assign 2 waypoints from the pool, if you allocate only one you may find an error about 'inability to cycle between waypoints'. Also good to have a decent excess of waypoints, it reduces collisions & strawberry jam incidents.

When DAC has finished spawning, you can release them, so,after the DAC spawn is finished you run lines like these from the init:

waitUntil {DAC_Release_Action == 0};

//release groups from DAC

if(isServer) then
{
       {[_x] spawn DAC_fReleaseGroup}foreach inf_group_z1;
       {[_x] spawn DAC_fReleaseGroup}foreach arm_group_z1;
       {[_x] spawn DAC_fReleaseGroup}foreach La_group_z1;
       {[_x] spawn DAC_fReleaseGroup}foreach inf_group_z2;
       {[_x] spawn DAC_fReleaseGroup}foreach La_group_z2;
       {[_x] spawn DAC_fReleaseGroup}foreach arm_group_z2;
       {[_x] spawn DAC_fReleaseGroup}foreach Hel_group_z2;
};

waitUntil {DAC_Release_Action == 0};
// the HAC lines follow

It is very important to have the waitUntil statement before & after the DAC_fReleaseGoup lines (with thanks to MadRussian for that gem; one of several similar points missing from the manual).

So for a 'front' you would create a DAC spawn zone (no units just camp) in the rear-area, then separate unit spawn zones where you want the units to appear at mission start, then move the DAC unit zones to where you want the units to 'attack'. Units that are killed will respawn at the rear-area DAC spawn zone and move to their 'new' zone waypoints.

You can do that, but it somewhat defeats the idea of having HAC run things (well, for the most part - I'm playing around with randomly spawning Chedaki &/or NAPA at randomly-chosen points from a predefined list behind enemy lines & leaving them under DAC control, giving independent irregulars which throw unpredictable spanners in the works - one-off spawns of grunts & technicals at minimal camps, it will work with just a flagpole or so).

About to test spawning specific DAC zones to supply troops to specific fronts.

I'm not too sure as I've never tried DAC and HAC together (but will do so now!!), but I would assume you need to release the units from DAC after they are created. Howto is probably in the DAC manual somewhere. Not sure about re-spawning DAC units and then releasing them... but I'm sure it's possible :o

Oh, definitely have a go! Even a basic mission is a lot of fun (so much so that testing often turns into an extended play session instead, oops!).

How to release from DAC is not properly documented in the manual. The code above comes mostly from a post Silola made here:

http://forums.bistudio.com/showpost.php?p=1654904&postcount=230

with the added waiUntil lines as recommended by MadRussian.

One point about released groups - they will not be respawned. I'm finishing a script that will check the count of released groups in specific arrays; when the count in an array falls to a threshhold value, the spawn zone will be recreated & the newly spawned groups released as before. For this I'm modifying my design to spawn grunts, armour & helis in separate zones - a good idea anyway, helis can spawn in ideal spots away from trees & powerlines, & the grunts don't get squished by the armour before they get a chance to move out. The only drawback is the slightly longer delay while all the zones are initialised. The total number of these 'zone respawns' can be limited to any value desired by the designer.

Note that if f you spawn camp units into arrays which are not released and are listed as excluded in the init, they will guard the camps under DAC control & respawn as necessary. The spawn parameters allow you to define how far they will patrol. This is crucial because if the camp is destroyed, all its spawn zones will be inactivated. Never let HAC grab the forces defending the camps.

I meant to have a demo version released a while ago but both RL stuff & trying to make my first addon (player / teammates throwing mags to each other rather than rearming at backpacks or crates) means I'm running late.

Your point about moving DAC zones is intriguing, I had not considered that. I've been planning an ebb-and-flow scenario where if a leader's base is threatened with capture, he can retreat to a new zone, the old zone being left to be taken (i.e., the camp destroyed) by the advancing enemy. If that leader succeeds in recapturing this original base, the original camp is recreated. Do you think that moving the zone is more realistic? It might be fun of all the associated vehicles & grunts 'flee' to the moved zone - I haven't figured out how to achieve that in the 'create new zone' scenario.

BR

Orcinus

[SavageCDN 231]

Your point about moving DAC zones is intriguing, I had not considered that.

You know what's funny? After posting yesterday I thought 'you know what? he's going to reply with stuff I've never tried or considered before' ... especially since (as you mentioned) there are a bunch of undocumented features missing from the manual.. and that's exactly what happened :p

It's not an issue if you set DAC to spawn all units into an array....When DAC has finished spawning, you can release them

I tried that once and couldn't make it work properly (due to my lack of coding/scripting skills I'm sure). Now I have homework to do... in addition to re-reading the DAC thread.

You can do that, but it somewhat defeats the idea of having HAC run things

Of course you are correct... this is my method when just using DAC and trying to create a 'front'

Oh, definitely have a go! Even a basic mission is a lot of fun (so much so that testing often turns into an extended play session instead, oops!).

Well I'm sure that would NEVER happen to me.... I will try it out this weekend. Have you used GL4 as well in conjunction with DAC/HAC?

Note that if you spawn camp units into arrays which are not released and are listed as excluded in the init, they will guard the camps under DAC control & respawn as necessary. The spawn parameters allow you to define how far they will patrol. This is crucial because if the camp is destroyed, all its spawn zones will be inactivated. Never let HAC grab the forces defending the camps.

You lost me here a bit.. are you referring to the group that spawns with the camp and defends it in a set radius? So if HAC takes command of this defending group it kills the camp?

If that leader succeeds in recapturing this original base, the original camp is recreated. Do you think that moving the zone is more realistic? It might be fun of all the associated vehicles & grunts 'flee' to the moved zone - I haven't figured out how to achieve that in the 'create new zone' scenario.

I would say it would be more realistic yes, as the units are not deleted and re-created (which if I remember correctly is what happens when you delete a DAC zone... or are your units released from DAC by then?) rather they are just assigned new waypoints... and as such will 'flee' to the new zone :p

[orcinus 121]

You know what's funny? After posting yesterday I thought 'you know what? he's going to reply with stuff I've never tried or considered before' ... especially since (as you mentioned) there are a bunch of undocumented features missing from the manual.. and that's exactly what happened :p

LOL! Well, my thanks to you for posting something I hadn't considered :)

Well I'm sure that would NEVER happen to me.... I will try it out this weekend. Have you used GL4 as well in conjunction with DAC/HAC?

Nope, still too busy getting HAC & DAC to work together the way I want, plus attempting to make my first addon. Not sure how GL4 would integrate with HAC, though of course the DAC release function was specifically to allow DAC to work well with GL4.

You lost me here a bit.. are you referring to the group that spawns with the camp and defends it in a set radius? So if HAC takes command of this defending group it kills the camp?

No, I meant that HAC cannot take into account the special role of the DAC camps, apologies for being unclear.

Leaving the groups spawned in the camps out of HAC means the camp will be defended against marauding enemies. Because those units are not released they will get respawned if & when they get killed off, maintaining a camp-specific defensive zone. The composition of the defence force & size of the patrol zone is controlled by the configs. The camps should be well back from the front line in any event, though the spawn zones can be anywhere.

I would say it would be more realistic yes, as the units are not deleted and re-created (which if I remember correctly is what happens when you delete a DAC zone... or are your units released from DAC by then?) rather they are just assigned new waypoints... and as such will 'flee' to the new zone :p

Cool, I'll try that out soon. All except the units in the camps are released from DAC. It occurs to me that the units at the camp could be released just before the camp is deleted, but your idea of moving the zone(s) sounds very much better than the approach I've taken. Cheers for that :)

[SavageCDN 231]

Nope, still too busy getting HAC & DAC to work together the way I want, plus attempting to make my first addon. Not sure how GL4 would integrate with HAC, though of course the DAC release function was specifically to allow DAC to work well with GL4.

If groups can be excluded from HAC (which you mentioned before), then GL4 might be useful in a situation where you require a group or set of groups to defend a specific location or objective, and call in reinforcements outside of HAC control (ie: a reinforcing group set to support ONLY one specific group) There are probably other uses as well but I'll need to get more familiar with HAC first.

No, I meant that HAC cannot take into account the special role of the DAC camps, apologies for being unclear.

Leaving the groups spawned in the camps out of HAC means the camp will be defended against marauding enemies. Because those units are not released they will get respawned if & when they get killed off, maintaining a camp-specific defensive zone. The composition of the defence force & size of the patrol zone is controlled by the configs. The camps should be well back from the front line in any event, though the spawn zones can be anywhere.

OK I get it now... thanks. That actually sounds like a good thing!!

Cool, I'll try that out soon. All except the units in the camps are released from DAC. It occurs to me that the units at the camp could be released just before the camp is deleted, but your idea of moving the zone(s) sounds very much better than the approach I've taken. Cheers for that :)

Now that I've thought about it a bit more I don't think I've ever tried to move a DAC zone that included a camp.. I've only tried it on zones that spawn units and/or waypoints. I'm not sure what would happen to the camp itself after the zone is moved.. old camp 'disappears' and new one is created in new zone? With units it's easy as they are just assigned new waypoints and move off accordingly.

[orcinus 121]

Hi

I noticed that if you have, e.g., RydHQB_AirCargo = false and you spawn helis with cargo (troop) space, they get stuck. The reason seems to be that at least some of the grunts will get into the choppers before the release from DAC is completed, and then ignore the team leaders' orders to disembark. The only solution I have found is to limit the heli spawn to types which have no cargo space, as DAC does not allow one to generate helis without generating grunt teams as well. Alternatively, set AirCargo = true.

Depends on the scenario which option the mission designer might use. However, the first option - no AirCargo = true - does not preclude using choppers to fly in reinforcements later; one could set up an inactive DAC zone to spawn, e.g., MH-60s; then when needed (trigger or scripted) use a script to reset Aircargo = true before activating the DAC zone, waiting for the zone to complete spawning, & releasing the units. HAC should then route them to where they are needed.

Secondly - HAC has a very irritating habit of ordering squad formation changes which override my own, sometimes to dire effect. Moving along a narrow space between a cliff & a road in file formation, while I was checking the map HAC ordered "wedge". Before I could exit the map & reset the formation, two of my squad got squished by a 'friendly' tank. Even more unhelpful - HAC ordered a formation change when I was sneaking along in file behind a low wall to avoid a BTR90 - which, by Sod's Law, spotted us almost instantly as some of my squad went over the wall; & it then chewed us up badly. On yet another occasion, the order to assume wedge formation was virtually simultaneous with my ordering the squad to get in a truck I was driving. My #2 refused to get in, & then the option to order him in disappeared. Only way to get him in was to get out & let him drive <groan, weep, gnash teeth, scream abuse, etc.>

@Ryd: would it be possible to exclude the player's squad from formation, hold fire, & other squad orders?

BR

Orcinus

[Rydygier 1302]

Yes, I know this problem. Was reported eariler. It occurs when defensive or idle routine is ongoing. Source is setFormation command, which must be used in this two cases instead of usual setWaypointFormation, which has no such effect for human leaded groups. And this is resolved already, but for HAC 1.11, that is not released yet. I wouldn't want to announce official release of new version only for this and very few other small fixes, so instead here you go, very unofficial newest WIP version. Is stable, as far, as I know, just do not contains all planned features. Only this, what you can find in first post in this thread as green text in TO DO section:

HAC 1.11wip

[orcinus 121]

Yes, I know this problem. Was reported eariler. It occurs when defensive or idle routine is ongoing. Source is setFormation command, which must be used in this two cases instead of usual setWaypointFormation, which has no such effect for human leaded groups. And this is resolved already, but for HAC 1.11, that is not released yet. I wouldn't want to announce official release of new version only for this and very few other small fixes, so instead here you go, very unofficial newest WIP version. Is stable, as far, as I know, just do not contains all planned features. Only this, what you can find in first post in this thread as green text in TO DO section:

HAC 1.11wip

Hi, my friend. Hee, I logged on just 1 minute after your post :D

having just been blown away twice in a row partly due to that, erm, feature.

Not sure if this has been reported, but intermittently I get the error

Error in expression <rale + 20};
_lost = ObjNull;
{
_AllV2 = nearestObjects [_x, ["AllVehicles"], Ryd>
 Error position: <nearestObjects [_x, ["AllVehicles"], Ryd>
 Error 0 elements provided, 3 expected

It seems to happen when carnage is high so I'm guessing it might be HAC issuing an order or setting a waypoint to a group or unit that has just ceased to exist.

Thanks very much for the WIP version, will be trying that tomorrow. I've almost completed a HAC-DAC demo on Chernarus, just tuning it to avoid to slow a frame rate & to get the chopper zone respawning to occcur reasonably early, & tracking down why the first time it starts only some of the 7 DAC zones initialise. I may activate all but the first from the init so I can modify the zone initialisation & timing & sequence more easily.

I'll complete that with the current v1.1 stable, though. Haven't decided whether or not to add in fronts and/or some spanner-in-the-works random creation of Chedaki/NAPA DAC zones behind enemy lines. I'll probably put those up as a separate demo.

Cheers

Orcinus

[Rydygier 1302]

Not sure if this has been reported, but intermittently I get the error

It is something new, I think. Must to check this part of code... Thanks.

EDIT:

Here is all involved piece of code (part of reset procedure responsible for monitoring lost objectives):

	_lost = ObjNull;
	{
	_AllV2 = nearestObjects [_x, ["AllVehicles"], RydHQ_ObjRadius1];
	_Civs2 = nearestObjects [_x, ["Civilian"], RydHQ_ObjRadius1];
	_AllV2 = _AllV2 - _Civs2;
	_NearEnemies = leaderHQ countenemy _AllV2;
	_AllV = nearestObjects [_trg, ["AllVehicles"], RydHQ_ObjRadius2];
	_Civs = nearestObjects [_trg, ["Civilian"], RydHQ_ObjRadius2];
	_AllV = _AllV - _Civs;
	_NearAllies = leaderHQ countfriendly _AllV;
	if (_NearEnemies > _NearAllies) exitwith {_lost = _x};
	}
foreach [RydHQ_Obj1,RydHQ_Obj2,RydHQ_Obj3,RydHQ_Obj4];

I see only one reason, that would explain such error message: lack of one of objective objects on map (usual empty triggers, RydHQ_Obj1, RydHQ_Obj2, RydHQ_Obj3 or RydHQ_Obj4 for A side), or name is wrong for one of them. Can you check this?

Edited April 18, 2012 by Rydygier

[orcinus 121]

I see only one reason, that would explain such error message: lack of one of objective objects on map (usual empty triggers, RydHQ_Obj1, RydHQ_Obj2, RydHQ_Obj3 or RydHQ_Obj4 for A side), or name is wrong for one of them. Can you check this?

Ahh.. I see that when I deleted an OPFOR zone & some associated editor-placed units, I also deleted the trigger for Obj4 & forgot to replace it, duh!

Thanks for checking. It should be useful to know what that error message flags when testing missions.

Another dumb thing I did when editing a mission was to switch the leader to SubAll = true but left my group in the RydHQ_Included array. HAC issued me two different orders in quick succession & then the waypoint routine seemed to break (none appeared on the map, no chevrons in the FOV) & no further orders were given; all goups stopped except a few that presumably had waypoints assigned before my mistake broke things. I think that is most easily addressed by a cautionary edit of the manual for the next version.

Re the big boss - will that deal with allocating reinforcements to a front under heavy attack? - if so I won't carry on with some coding I've been thinking about.

There's an issue I encountered when generating helis with DAC if you have AirCargo = False for any leader. When the helis have cargo carrying capability (e.g., Mi-8, MH-60) some at least will have loaded some or all grunts before the release is completed (as DAC will not allow helis to be spawned without grunts). The helis then get stuck because the on-board grunts ignore their squad leaders' orders to disembark. Simplest workaround is to create a user-defined DAC_Config_Units that lists only helis with no cargo space (e.g. AH1Z, AH64 etc.). The grunts will set off on foot; if the zone is well behind the lines, placing some empty trucks in the editor might be a good idea.

Another thing I observed (testing with HAC & DAC debugs on, ofc) was that when a leader (at Balota) had AirCargo = true & a heli zone way up at Berezino spawning M-8s and grunts, sometimes 1 or 2 groups of grunts could been seen marching towards Berezino. I had the findCargo range set to 100. Only explanations I could think of was that either HAC decided this was a good spot to keep reserves (ugh!) or that there were free slots in the choppers. I'll test the latter by setting HAC to spawn exactly the number of grunts needed to fill the choppers.

That should be done anyway - if a cargo-carrying vehicle is only part-filled, under DAC it will not depart until full; not sure about HAC but there's no reason not to fill choppers by default. Motorised infantry groups are trickier as the cargo size varies with vehicle type, but as these spawn nearer the front HAC would presumably deal with filling them without problems.

BR

Orcinus

[Rydygier 1302]

Re the big boss - will that deal with allocating reinforcements to a front under heavy attack? - if so I won't carry on with some coding I've been thinking about.

Should. But, honestly, can't tell, when bigboss will be implemented... My free time is about to end for now.

Another dumb thing I did when editing a mission was to switch the leader to SubAll = true but left my group in the RydHQ_Included array. HAC issued me two different orders in quick succession & then the waypoint routine seemed to break (none appeared on the map, no chevrons in the FOV) & no further orders were given; all goups stopped except a few that presumably had waypoints assigned before my mistake broke things. I think that is most easily addressed by a cautionary edit of the manual for the next version.

I was thinking (!) a while, if this can be a reason. Thought, that no, however now I suppose, that indeed - group name added to overall "groups under control" array twice may to give such effect. There is one circumstance also, when radio message about new order is send, but map target marker aren't placed right away. It is when external cargo for your's group is allocated. In such circumstance human-led team should just wait. Markers will appear when cargo arrives.

For now can't help with all this HAC vs DAC brawl, cause do not know much about DAC, amongst other, about DAC's "release" routine.

Edited April 19, 2012 by Rydygier

[SavageCDN 231]

There's an issue I encountered when generating helis with DAC if you have AirCargo = False for any leader. When the helis have cargo carrying capability (e.g., Mi-8, MH-60) some at least will have loaded some or all grunts before the release is completed (as DAC will not allow helis to be spawned without grunts). The helis then get stuck because the on-board grunts ignore their squad leaders' orders to disembark. Simplest workaround is to create a user-defined DAC_Config_Units that lists only helis with no cargo space (e.g. AH1Z, AH64 etc.). The grunts will set off on foot; if the zone is well behind the lines, placing some empty trucks in the editor might be a good idea.

Orcinus

Perhaps I'm not understanding the problem but would you not be able to spawn heli groups with only 2 units in the group (pilot, copilot/gunner) so that regardless of chopper type there are only 2 "DAC units" per chopper? So your Config_creator say has group size 1 = [2,2] and you set the heli spawns in zone to [4,1,12].. spawning 4 choppers with 2 units per chopper and 12 waypoints.

Or perhaps a way to either delay the release of heli groups or have the heli groups spawn already inside the choppers?

Or am I completely missing the problem? Are the 'grunts' you are referring to part of the DAC heli group or their own group (ie DAC inf or editor-placed units)?

[orcinus 121]

For now can't help with all this HAC vs DAC brawl, cause do not know much about DAC, amongst other, about DAC's "release" routine.

No worries mate, there's nothing to do on that wrt HAC. It's a combination of DAC & the game engine. I reckon that if you want to use air transport for reinforcements when AirCargo = false, you just set up a DAC zone to spawn the helis & grunts with user-defined waypoints to direct them to the main DAC camp for the HAC leader with waypoint order for grunts to disembark on arrival & move away from the choppers, then release the array.

Perhaps I'm not understanding the problem but would you not be able to spawn heli groups with only 2 units in the group (pilot, copilot/gunner) so that regardless of chopper type there are only 2 "DAC units" per chopper? So your Config_creator say has group size 1 = [2,2] and you set the heli spawns in zone to [4,1,12].. spawning 4 choppers with 2 units per chopper and 12 waypoints.

The problem is that when AirCargo is set to False, Helis will not take off if there are any grunts in cargo; but they will not obey orders to disembark. Heli crews automatically spawn with the choppers (but not inside them, they don't get in until ordered by DAC or HAC). However, DAC will *not* allow you to spawn helis without also spawning some grunts (even for spawning AH64s); this allows airborne troop groups to be formed.

Or perhaps a way to either delay the release of heli groups or have the heli groups spawn already inside the choppers?

The release occurs whenever you want. Delaying it would make matters worse as perhaps then all the choppers would contain stuck grunts. You can't spawn the units in the choppers using DAC, but again that would make them stuck.