Rydygier

So, here is wip5 version. This one should be the last of wips. Includes all features from “To Do†list with several tweaks and fixes, excluding Big Boss, which is currently “work in progress†(and there is progress in work :) ), guerilla mode, which will wait for next version, and new manual content. When BB and manual will be ready – should be officially release next HAC version, probably with beta status however. In wip5 we have large amount of reworked and new code, co there is good chance for brand new bugs as well, so meanwhile I’ll be grateful for tests and bug reporting (including RPT, if any errors here, info about other addons/mods/DLCs in use, and perhaps even repro mission, if reasonable). NOTE: this is first version not compatible with Arma 2 1.11 alone. Needs 1.60 or better because of some commands introduced with OA/CO, that I was forced to use for fix of some problems. Probably not complete list of changes: - NEW: cyclical comparing forces routine during fight and withdrawing when to big enemy advantage; Added new value for each group – a “danger factor†based on number of nearby known enemy and ally units and distances. If factor become big enough, there is a chance for withdrawal in same manner, as is for combat ineffective units (towards same area regardless of distance); - NEW: for impatient: init config variable RydHQ_Rush (default: false). If true, in any circumstancies, when groups are usually moving slowly (limited speed or safe behavior), speed is set to normal, and behavior to aware. No longer very looong walks if not desired; - IMPROVED: deeply reworked code for defensive stance. Now you can set line of defense of chosen kind including “in siege†like round defense. To achieve that set objective objects in places, that should become a defense centers along with Leader’s position. Next you need to use some new init variables for initialization, and customization: RydHQ_Order = "DEFEND"; (to keep Leader in defence mode) RydHQ_DefendObjectives = 4; (default 4. Must be greater, than 0 for activation of new defense pattern. Integer value tells HAC, when should use given objective position as defense center. This number means, how many of groups on map must be placed closest to this objective for that. Each group will take position in the area of closest objective, so this prevents situations, where eg. only one or too few for efficient defense groups is placed in given area, what is not reasonable. Unless you set this value to 1 of course.) RydHQ_NObj = 5; (so Leader will consider all objectives as taken. Only taken objectives will be used for this defense pattern. If you set this 1, none will be used, for value 2 – first of them and so on. This is internal global variable used in offensive mode to control, which objectives are taken, and which aren't yet. So should be not manualy defined in offensive mode) RydHQ_DefFrontL = ["N","E"]; RydHQ_DefFront1 = ["N","W"]; RydHQ_DefFront2 = ["W",""]; RydHQ_DefFront3 = ["S",""]; RydHQ_DefFront4 = ["E",""]; (these are optional. If defined, as array of two strings, will force given direction of defence perimeter (in which direction is front of Leader’s point and each of four objective points perimeter). Rules: first string may be one of: N, S, W, E. This is “primary directionâ€. For N and S you can set secondary direction: E or W if needed. Otherwise put there an empty string. If not defined, direction towards last known enemy positions will be chosen. If there is no known enemy positions – direction will be randomized for each defense point separately). Once taken defensive positions will be keeped as long, as there is defensive mode on, no longer chaos generating reshuffles after reset. Also there is used new reinforcement support in defensive mode, based on mentioned “danger factorâ€. It is dynamic, so reinforcements can be every minute redirected on the fly, if needed more somewhere else, but if group is already sent – there will be usually needed more serious threat for redirection, than reason of initial reinforce order. As most important threat will be considered usually known enemy closer to Leader, than average distance of all allied groups is (enemy on flanks!). Now also in defensive mode will be used smoke grenades, also 40mm for withdrawal consealing, and, new, artillery smoke screen. After sunset and before sunrise defending groups will use both 40mm flares (not so efficient though because shooters has tendency to shoot flare with too low trajectory, so often it will lamp area only for few seconds) or, optionally, will call for arty illumination if will know about enemy close enough. For “night detection†there is used small piece of code found in TPW’s charming lights addon, originally made by Carl Gustaffa. - IMPROVED: well… slightly – withdrawal goes now sometimes a bit better, also because arty smoke (not so great, as is usually too quick dispersed). AllowFleeing not helped. Will test this further while working on guerilla mode. - IMPROVED: old, broken surrendering behavior replaced with new code, bounded with panic system, that gives chance for surrender each group separatelly. It is untested and experimental, so RydHQ_Surr is still false by default. Probably captives still will be shot on sight :(. - NEW: as mentioned – decided to implement own HAC’s artillery handling. HE/SADARM will be still handled externally, but usage of smoke and illumination, as it needs strict coordination dependent on certain situation, is now optionally moved into Leader’s control. It is based on artillery module, and needs only vanilla howitzers (smoke, illum) or mortars (illum) on map, where each group consist only one kind of arty piece. This, I hope, will not interrupt work of external AI artillery handler. To activate define with value greater, than 0, this init variable: RydHQ_ArtyShells = 120; (default 120 – amount of shells of both types available per battery (arty group)). Smoke, in mentioned situations, will be placed by 9 shells, that should to envelope withdrawing group, between that group and nearest known enemy, with some randomization and dispersion. 3 shells on left, 3 on right, 3 in middle. Illum fire mission means single shell deployed above closest known enemy position); - NEW: morale drop (-10 – (random 10)) when current Leader unit dies; - NEW: additional pause (60 + (random 60) seconds) before next cycle, if new Leader is replacing killed previous one; - NEW: distinction between aerial and land medevac vehicles for choosing apriopriate kind depending on distance and kind of wound; - NEW: in debug mode silent hint info about Leader's staff death (when HAC's control ends); - IMPROVED: HAC uses now placed temporarily “laser target†object to convince bombers (planes of types included in RHQ_BAir, by default none of the planes are used as bombers) to use their bombs. Not always, but often this works; - IMPROVED: new garrison handling. Each garrisoned group will: to fill up static defenses, to take positions in enterable buildings. Rest (at least team leader) will patrol area including building’s interior checks (route is randomized once, initially). This feature comes with one init variable: RydHQ_GarrVehAb = true; (false by default). If true, garrisoned groups with assigned vehicle will disembark and act as not motorized (crew stays at the vehicle). Otherwise garrisoned groups with vehicle will only get sentry waypoint at its current position. - reworked architecture of main attack decision-making code, introduced numerous functions, reduced redundancy, fixed some small issues and code problems. Fixed problem with emptied enemy vehicles, that was considered as enemy during objective state checks (was blocking objective capturing). Now empty vehicles are not counted. PS. There is message about missing "surr.sqf". (that's why changes after last tests aren't good idea). You can just ignore it, or go to VarInit.sqf and comment out or remove 70 line.

Hmm. Never tested HAC with big, custom groups. If mix is "exotic" (not recommended), eg. A chopper grouped with the tank and sniper, then HAC will consider such group as simultanously sniper, armor and air capable (quite rightly isn't :) ). Now you can imagine problems, when HAC will send such "mix" with, eg air attack mission... But this is BTW. Generally HAC will consider given group as of each type of its units. So if group consist infantry, AT infantry, AA infantry, a tank and humvee, this "mixed group" will be considered as : infantry, at infantry, aa infantry, armored and motorized group. So any task considered by HAC as proper for any of this types may be issued to that group. Or should. One thing: HAC uses some special ways of distinction type of group based on assumption, that there are set default group types. So if this is complex, custom group, HAC may sometimes misunderstand kind of such group. Not sure, but possible sometimes. For example - a MTVR truck should be considered as non-combat cargo and not used in fight, right? And a rifleman should be considered as infantry, and his group used in fight, yes? Not so simply, cause truck is driven by rifleman, no crewman... So additional distinction is needed here, based on eg number of riflemen in group and their role in vehicle, to distinct empty truck with driver from truck full of troops. Anyway, if possible, I recommend rather to use eg . 5 groups of 5 men, each with vehicle, than one group of 25 men with 5 vehicles. If things will go, as are going now, shortly should be ready wip5 with partially deeply redesigned code, some problems removed and most of "to do" features implemented. There is good progress in big boss too, so next should be official new version release.

@kiberkiller If you are interested - I have at hand, in my private "stock" some tiny addon called Simply Weather Dynamizer. Including userconfig, where you can set weather tendencies and weather dynamics. This is test version, so proper functioning is not guaranteed, still this may be a handy replacer for infinitely more advanced and sophisticated RUBE's great module, if someone just want to have simply calculated, but reasonable semi-randomized, dynamic weather. There is no any special effects as post processing, particles and such. Just continous juggling with four basic weather settings: overcast, rain, fog and wind. So, if you want to have rainy and generally heavy overcast, then before Arma launch raise overcast and rain settings in userconfig init values, eg to 10 or so and play with this addon. SWD will, maybe after some delay, start to "stir" in the weather.

Should be possible in many ways. One of them could be: Delete "this" from trigger's condition field and replace it by something like that: ({_x in vehicle1} count [unit1,unit2,unit3]) == 0 If all of listed units will be outside vehicle1 - trigger will be activated.

No, not a translation problem. This is CEMS stuff - summoner is a battlemage. CEMS means Combat Effective Magick System (aka Rincewinder). This brings "magic" into battlefield, and part of spells are summoning-something spells. :) Particullary quoted function is used for summon an "earth elemental".

Hmm. I just set up empty SCUD, independent and BLUFOR groups - there wasn't any shooting at SCUD. Empty vehicles was/are of civilian side, as dead bodies, and are marked on map with civilian colour. Do not know, if this will help, but when working on CEMS I noted one thing, when implemented "summoned" creatures. For example I'm using there spawned empty APC, that is next filled with spawned crew. So, until I use this syntax for crew spawn: createUnit_array Regardless of group's side, units will retain its default side, what made this syntax useless in that case, as spawned such way manned vehicle should be always of side of its "summoner" (initially empty vehicle will become side of its current crew, and probably will stay with this side after crew removal, so maybe this is BTW a way to switch vehicle's side also in-game, unless will back to civilian, initial side, not sure, no time for tests). To achieve this is needed this syntax: createUnit In this method group's side will overwrite default unit's side, so this way seems to be possible to have any spawned unit or manned vehicle of any side. A practical example (CEMS' function):

I'm glad then. Yep.

So it have not problem with string, but strictly with object name, but we cannot use string here. And even "synchronized" method fails? http://www33.zippyshare.com/v/20991924/file.html

Hrmm... So I'm forced to give up. Haven't idea, why yours Arma has problem with 12 line of init.sqf, when mine haven't. Wondering, if someone else will have such problems too. I assume, that RPT reports are similar?

OK. So we now something. I have empty RPT. Such error I can reproduce only, when change name of player unit placed on map, but even then units are spawned. Except official DLCs the only important difference is undead mod. Maybe this mod changes somehow for some reason name of player unit or use name unit1 for something else (re-define it and makes it nil then)? My suggestions: 1. Try my demo without undead mod (helped? yes/no); 2. Try with undead, but change in line 12 of init.sqf and player's unit name in editor from unit1 to SomeVeryUniqueName1254 :) (yes/no); 3. Try with undead, but change in line 12 of init.sqf unit1 to player (yes/no); If none will help, there are other ways to define CLN_playable_units array, without using their names in code, eg by synchronizing such units with some logic and usage of: CLN_playable_units = synchronizedObjects SomeLogicName;

So this is working for me and not working for you. Really strange. Haven't idea, what may be a cause here. Are there any errors reported in yours RPT file? Any addons/mods active?

I don't know, why. This version is working for me. Units are spawned and removed, when should be. See this demo: http://www45.zippyshare.com/v/15747832/file.html (go forward into trigger area) Used NAPA units - haven't zombies. One thing: there is "position player" used. Not acceptable for MP. Maybe position _trigger instead will be sufficient? Or better closest to trigger (or any/random/first) element of mentioned trigger's thislist array (containing all, what makes it currently active). See also: list EDIT: eg instead of _pos = position player use: _actArr = list _trigger; _pos = position (_actArr select (floor (random (count _actArr)))); So center position for zombie spawn will be a position of randomly selected BLUFOR unit inside trigger area (if condition set on "BLUFOR present"). Tested with above demo, works. I suggest also to add some sleep, eg 30 seconds, before waitUntil, so zombie will be not in any circumstance removed just after spawning, but at least 30+5 seconds later:

As for MP scripting - lets better someone else will help here, I not know much about "how to make script MP compatibile". If you will be able to prepare an array containing all player's (playable) characters, eg as CLN_playable_units global array, you can do this distance check for every of them: _trigger = _this select 0; _triggerRadius = _this select 1; _classArray = [ "CHN_UNDEAD_Doctor", "CHN_UNDEAD_Policeman", "CHN_UNDEAD_Rocker2", "CHN_UNDEAD_HouseWife5", "CHN_UNDEAD_Damsel4", "CHN_UNDEAD_Citizen3", "CHN_UNDEAD_Priest", "CHN_UNDEAD_Profiteer4", "CHN_UNDEAD_Hooker2", "CHN_UNDEAD_Secretary3", "CHN_UNDEAD_Functionary2", "CHN_UNDEAD_Madam3", "CHN_UNDEAD_USMC_Soldier_Base", "CHN_ZOMBIE_Doctor", "CHN_ZOMBIE_Policeman", "CHN_ZOMBIE_Rocker2", "CHN_ZOMBIE_Rocker3", "CHN_ZOMBIE_Worker4", "CHN_ZOMBIE_Citizen3", "CHN_ZOMBIE_Priest", "CHN_ZOMBIE_Profiteer4", "CHN_ZOMBIE_Villager2", "CHN_ZOMBIE_Villager3", "CHN_ZOMBIE_Functionary2", "CHN_ZOMBIE_Worker1", "CHN_ZOMBIE_USMC_Soldier_Base", "CHN_UNDEAD_Doctor", "CHN_UNDEAD_Policeman", "CHN_UNDEAD_Rocker2", "CHN_UNDEAD_HouseWife5", "CHN_UNDEAD_Damsel4", "CHN_UNDEAD_Citizen3", "CHN_UNDEAD_Priest", "CHN_UNDEAD_Profiteer4", "CHN_UNDEAD_Hooker2", "CHN_UNDEAD_Secretary3", "CHN_UNDEAD_Functionary2", "CHN_UNDEAD_Madam3", "CHN_UNDEAD_USMC_Soldier_Base", "CHN_ZOMBIE_Doctor", "CHN_ZOMBIE_Policeman", "CHN_ZOMBIE_Rocker2", "CHN_ZOMBIE_Rocker3", "CHN_ZOMBIE_Worker4", "CHN_ZOMBIE_Citizen3", "CHN_ZOMBIE_Priest", "CHN_ZOMBIE_Profiteer4", "CHN_ZOMBIE_Villager2", "CHN_ZOMBIE_Villager3", "CHN_ZOMBIE_Functionary2", "CHN_ZOMBIE_Worker1", "CHN_ZOMBIE_USMC_Soldier_Base" ]; _HQ = createCenter resistance;//if there is no any unit of resistance side placed on map in editor _grp = createGroup resistance; _pos = position player; { _u1 = _grp createUnit [_x, _pos, [], 100, "FORM"] } foreach _classArray; { [_x,_trigger,_triggerRadius] spawn { _zombie = _this select 0; _trigger = _this select 1; _triggerRadius = _this select 2; _toDelete = false; waitUntil { sleep 5; _nE = _zombie findNearestEnemy _zombie; if (isNull _nE) then { _toDelete = true } else { if ((_nE distance _zombie) > 500) then { _toDelete = true } }; _tooClose = false; { if ((_x distance _trigger) < _triggerRadius) exitwith {_tooClose = true} } foreach CLN_playable_units; (not (_tooClose) and (_toDelete)) }; deleteVehicle _zombie } } foreach (units _grp); Note some other changes. Now code is more universal - can be used for any trigger, and should be executed such or similar way: nul = [NameOfThisTrigger,RadiusOfThisTrigger] execVM "spawn.sqf"; If this is only for MP, probably manually defined at init CLN_playable_units array can be replaced by simply playableUnits command in spawn.sqf. If you plan to use such code many times with many triggers (trying to make own DayZ, eh? :) ) then you may consider to initially preprocess and compile this code, and then only spawn it for better performance. Same array of zombie classes can be defined only once, on init, as global. If so, then yours init code will contain something like: CLN_ZombieClassArray = [ "CHN_UNDEAD_Doctor", "CHN_UNDEAD_Policeman", "CHN_UNDEAD_Rocker2", "CHN_UNDEAD_HouseWife5", "CHN_UNDEAD_Damsel4", "CHN_UNDEAD_Citizen3", "CHN_UNDEAD_Priest", "CHN_UNDEAD_Profiteer4", "CHN_UNDEAD_Hooker2", "CHN_UNDEAD_Secretary3", "CHN_UNDEAD_Functionary2", "CHN_UNDEAD_Madam3", "CHN_UNDEAD_USMC_Soldier_Base", "CHN_ZOMBIE_Doctor", "CHN_ZOMBIE_Policeman", "CHN_ZOMBIE_Rocker2", "CHN_ZOMBIE_Rocker3", "CHN_ZOMBIE_Worker4", "CHN_ZOMBIE_Citizen3", "CHN_ZOMBIE_Priest", "CHN_ZOMBIE_Profiteer4", "CHN_ZOMBIE_Villager2", "CHN_ZOMBIE_Villager3", "CHN_ZOMBIE_Functionary2", "CHN_ZOMBIE_Worker1", "CHN_ZOMBIE_USMC_Soldier_Base", "CHN_UNDEAD_Doctor", "CHN_UNDEAD_Policeman", "CHN_UNDEAD_Rocker2", "CHN_UNDEAD_HouseWife5", "CHN_UNDEAD_Damsel4", "CHN_UNDEAD_Citizen3", "CHN_UNDEAD_Priest", "CHN_UNDEAD_Profiteer4", "CHN_UNDEAD_Hooker2", "CHN_UNDEAD_Secretary3", "CHN_UNDEAD_Functionary2", "CHN_UNDEAD_Madam3", "CHN_UNDEAD_USMC_Soldier_Base", "CHN_ZOMBIE_Doctor", "CHN_ZOMBIE_Policeman", "CHN_ZOMBIE_Rocker2", "CHN_ZOMBIE_Rocker3", "CHN_ZOMBIE_Worker4", "CHN_ZOMBIE_Citizen3", "CHN_ZOMBIE_Priest", "CHN_ZOMBIE_Profiteer4", "CHN_ZOMBIE_Villager2", "CHN_ZOMBIE_Villager3", "CHN_ZOMBIE_Functionary2", "CHN_ZOMBIE_Worker1", "CHN_ZOMBIE_USMC_Soldier_Base" ]; ZombiesEverywhere = compile preprocessFile "spawn.sqf"; _HQ = createCenter resistance;//if there is no any unit of resistance side placed on map in editor spawn.sqf then: _trigger = _this select 0; _triggerRadius = _this select 1; _grp = createGroup resistance; _pos = position player; { _u1 = _grp createUnit [_x, _pos, [], 100, "FORM"] } foreach CLN_ZombieClassArray; { [_x,_trigger,_triggerRadius] spawn { _zombie = _this select 0; _trigger = _this select 1; _triggerRadius = _this select 2; _toDelete = false; waitUntil { sleep 5; _nE = _zombie findNearestEnemy _zombie; if (isNull _nE) then { _toDelete = true } else { if ((_nE distance _zombie) > 500) then { _toDelete = true } }; _tooClose = false; { if ((_x distance _trigger) < _triggerRadius) exitwith {_tooClose = true} } foreach CLN_playable_units; (not (_tooClose) and (_toDelete)) }; deleteVehicle _zombie } } foreach (units _grp); and trigger's Act execution: nul = [NameOfThisTrigger,RadiusOfThisTrigger] spawn ZombiesEverywhere; As for second part - no time for tests now, if some here is appropriate but you may try: enableSentences enableRadio fadeRadio Not sure, if this fit here, but via Description.ext file you can also mess with disabling certain chat channels: disableChannels EDIT: Oh, if you want to silence only zombies, then you can make each of them a separate group. This will need some changes in spawn.sqf, eg, for last mentioned version: _trigger = _this select 0; _triggerRadius = _this select 1; _pos = position player; { _grp = createGroup resistance; _u1 = _grp createUnit [_x, _pos, [], 100, "FORM"]; [_u1,_trigger,_triggerRadius] spawn { _zombie = _this select 0; _trigger = _this select 1; _triggerRadius = _this select 2; _toDelete = false; waitUntil { sleep 5; _nE = _zombie findNearestEnemy _zombie; if (isNull _nE) then { _toDelete = true } else { if ((_nE distance _zombie) > 500) then { _toDelete = true } }; _tooClose = false; { if ((_x distance _trigger) < _triggerRadius) exitwith {_tooClose = true} } foreach CLN_playable_units; (not (_tooClose) and (_toDelete)) }; deleteVehicle _zombie } } foreach CLN_ZombieClassArray;

Shouldn't be such problems there. If I'm not mistaken BIS patrol just adds couple of random waypoints with cycle wp at end, and then exits. HAC, at init part of any "Go" script (movement order execution code) removes all previously assigned to the group waypoints, same should be with WPs added via BIS patrol function.

My untested proposition: leave onDeAct empty, and as Act-executed code use something like: _classArray = [ "CHN_UNDEAD_Doctor", "CHN_UNDEAD_Policeman", "CHN_UNDEAD_Rocker2", "CHN_UNDEAD_HouseWife5", "CHN_UNDEAD_Damsel4", "CHN_UNDEAD_Citizen3", "CHN_UNDEAD_Priest", "CHN_UNDEAD_Profiteer4", "CHN_UNDEAD_Hooker2", "CHN_UNDEAD_Secretary3", "CHN_UNDEAD_Functionary2", "CHN_UNDEAD_Madam3", "CHN_UNDEAD_USMC_Soldier_Base", "CHN_ZOMBIE_Doctor", "CHN_ZOMBIE_Policeman", "CHN_ZOMBIE_Rocker2", "CHN_ZOMBIE_Rocker3", "CHN_ZOMBIE_Worker4", "CHN_ZOMBIE_Citizen3", "CHN_ZOMBIE_Priest", "CHN_ZOMBIE_Profiteer4", "CHN_ZOMBIE_Villager2", "CHN_ZOMBIE_Villager3", "CHN_ZOMBIE_Functionary2", "CHN_ZOMBIE_Worker1", "CHN_ZOMBIE_USMC_Soldier_Base", "CHN_UNDEAD_Doctor", "CHN_UNDEAD_Policeman", "CHN_UNDEAD_Rocker2", "CHN_UNDEAD_HouseWife5", "CHN_UNDEAD_Damsel4", "CHN_UNDEAD_Citizen3", "CHN_UNDEAD_Priest", "CHN_UNDEAD_Profiteer4", "CHN_UNDEAD_Hooker2", "CHN_UNDEAD_Secretary3", "CHN_UNDEAD_Functionary2", "CHN_UNDEAD_Madam3", "CHN_UNDEAD_USMC_Soldier_Base", "CHN_ZOMBIE_Doctor", "CHN_ZOMBIE_Policeman", "CHN_ZOMBIE_Rocker2", "CHN_ZOMBIE_Rocker3", "CHN_ZOMBIE_Worker4", "CHN_ZOMBIE_Citizen3", "CHN_ZOMBIE_Priest", "CHN_ZOMBIE_Profiteer4", "CHN_ZOMBIE_Villager2", "CHN_ZOMBIE_Villager3", "CHN_ZOMBIE_Functionary2", "CHN_ZOMBIE_Worker1", "CHN_ZOMBIE_USMC_Soldier_Base" ]; _HQ = createCenter resistance;//if there is no any unit of resistance side placed on map in editor _grp = createGroup resistance; _pos = position player; { _u1 = _grp createUnit [_x, _pos, [], 100, "FORM"] } foreach _classArray; { [_x] spawn { _zombie = _this select 0; _triggerRadius = 200;//only example value of course _toDelete = false; waitUntil { sleep 5; _nE = _zombie findNearestEnemy _zombie; if (isNull _nE) then { _toDelete = true } else { if ((_nE distance _zombie) > 500) then { _toDelete = true } }; (((player distance trigger1) > _triggerRadius) and (_toDelete)) }; deleteVehicle _zombie } } foreach (units _grp); In this example deleted will be each zombie, that do not know about any enemy (player) or is farer than 500 meters, but only when distance between player and trigger named here trigger1 is bigger than 200 meters (conditions checked every 5 seconds, if this is for MP, "player" command shouldn't be used and so distance condition will look different, also because there will be more, than one player).

Yep, I'm thinking about some kind of garrison handling for BB. Something like: objective captured? So we leave here as "garrisoned" eg. 5% non garrisoned yet groups (rounded down, so if force contain less than 20 gropus in this example, there will, be no garrison assigned, so no all forces should be spent on garrisons). Or something similar... Still garrison service, if no enemy nearby, will be very monotonous. :) The problem with HAC as a gaming tool is fact, that it tries to simulate in some degree real war course, and in real war, I think, most time is spent on sitting, waiting or marching very far, very slow. Only minority on killing and dying. Not so playable for guys, that want action, action and more action, still this depends on mission setup... BTW My current long-term plan looks as follows: to finish BB (in August perhaps? We will see) plus some minor things from to do list and slight code refreshment, then new HAC release. Next stage would be attempt to implement guerilla AI, but this still needs some thinking, so meanwhile will concentrate on some of my other projects/ideas (promised to some people Arma-chess, 2 or 3 SP missions on Chernaruss and Lingor, CEMS)... All dependent on my eagerness, which is changeable, and time. Well, I think, that when I finish with all stuff, I have in mind, no one will use it, as Arma3 will be released till then. :)

This will be an optional addition, not replacement. A new feature. Currently objectives for each Leader are manually chosen by mission maker. BB will do this automatically and, hopefully, reasonable. Will also change objectives dynamically during gameplay until all points on map considered by him as strategic will be taken or when his forces will lose combat effectiveness. And for this purpose should use all "task forces" of given to him Leaders in coordinated manner. That is the plan - BB is the higher level HQ of a more general look over the whole battlefield, commanding the Leaders.

Wow, great! Must test this right away.

That's right. I not used WOO (damn, when finally I'll have time to try this?), but I see, that WOO is kind of very special, RTS gameplay mode. Hetman is field commander-level (soon, hopefully, also higher) AI behavior enchancement. HAC is a smart "waypoint giver" for groups put under his control (as his "army" or "task force"), where his goal is to take all chosen for him objectives on map and to destroy all known enemies, all this in organized and sophisticated way. So he is using for that purpose flanking, reserves, logistics, transport handling and more. If there are any similarities, it can be only in the behavior of AI used in WOO. (CO)WarMod is, if I'm not mistaken, big pack of chosen addons matched and optimized to work fine together. So as long there is no included in this compilation any addon, that will mess with group's waypoints (ask Gunter about that) - all pack should be fully compatibile with HAC. There is no need to merge/combine them, just play with both if you want.

Not sure, if acceptable here, but you can use such init for stopping (version for tracked): this allowCrewInImmobile true;{this setHit [_x, 1]} foreach ["PAS_P","PAS_L"];

Great. However noticed, what SaOk said in nearby thread - indeed, good idea to make crows to fly in from somewhere. So added such thing into my version, in my way: each crow will be spawned at some distance (800-1400 meters) in random direction and will fly towards area with body (this will take additional seconds of course). Next - same: will circle as long, as body exist, when body is removed - all crows, this time together, as flock, will fly away towards randomly chosen "somewhere", and will be removed at 1000 meters. C&F In my opinion final effect is very nice and looks natural: crows gather progressively over the body.

selectBestPlaces

If I understood correctly explanations from here: setWind Then permanent, medium wind from east to west can be set by: setWind [-5,0, true]; eg in init field of any unit on map. Seems, that first number is for N-S axis, where positive values mean "from south to north", and vice versa, same way second number is for E-W axis, where positive is "from west to east". As for scripts, in some my simply weather "dynamizer" I used such code for reasonable wind randomization: [] spawn { private ["_wind","_wind1","_wind2","_forcer"]; while {(true)} do { _wind = ((wind select 0) + (wind select 1))/2; _wind1 = 0; _wind2 = 0; if ((random 100) > 20) then { _wind1 = _wind + ((random 2.5) - (random 2.5)); _wind2 = _wind + ((random 2.5) - (random 2.5)) } else { if ((random 100) <= 30) exitwith {}; if ((random 100) > 10) then { _wind1 = _wind + ((random 4.5) - (random 4.5)); _wind2 = _wind + ((random 4.5) - (random 4.5)) } else { _wind1 = _wind + ((random 6.5) - (random 6.5)); _wind2 = _wind + ((random 6.5) - (random 6.5)) } }; if (_wind1 < -10) then {_wind1 = -10}; if (_wind1 > 10) then {_wind1 = 10}; if (_wind2 < -10) then {_wind2 = -10}; if (_wind2 > 10) then {_wind2 = 10}; setWind [_wind1,_wind2,true]; _forcer = 0; waituntil { sleep (300 + (random 30)); if (_forcer <= 90) then {_forcer = _forcer + 5}; ((random 100) > 95 - _forcer) } } };

See my post 15:17, second link - this is my demo. In this demo crows just fly away. Best would be in my opinion to combine both solutions - flock is flying away, and then removed... I do not know, if time will allow me, if so, then may try to mess a little with crows function as kind of FSM coding practice. ---------- Post added at 22:05 ---------- Previous post was at 20:57 ---------- OK. Check this: C&F This contains modified by me BIS crow function (heh, my first FSM editing, hope that I did not broke anything). Seems, that works fine. Now flock will fly away and every crow will be deleted at distance more than 1000 meters from body. Also added new flies source every 30 minutes up to 8 times after four houres. So now probably only time before flies and crows appearing need to be adjusted. And perhaps minimum distance between flocks and flies swarms. Now is set 150 meters for crows and 20 for flies (if within this radius already exists flock/swarm, new one will be not created over given body). EDIT: still must do some tests for this minimum distance check, seems to be not optimal. EDIT2: So made some adjustments: distances are now 100 and 10 and should be checked more reliable, crows are flying a bit higher...

Do not know much about MP scripting, but I would try to use custom crow spawner instead of BIS' if deletion is necessary, simpliest - same code, but modified. Also know little about fsms, but maybe is needed only small change: some possibility of breaking re-spawn loop on demand or automatically, when body object passed into such modified function become null (disappear).