Rydygier

More improvements: http://www8.zippyshare.com/v/92714120/file.html - spawned during mission units/vehicles are (should be) considered; - "Blood Drops" is side sensitive, set for "west" currently; - resolved problem with side of destroyed vehicles (is always civilian, so implemented some setVariable for each vehicle containing its initial side), so "KIA Sparks" also can be in this version side-sensitive, and is; - easy way to set for given side(s) - see init.sqf for each demo to know, how to initialize for chosen side or sides. This is achieved by adding a letter in quotes to array before execVM. These letters are: "W" for west, "E" for east "R" for resistance and "C" for civilian. Any combination of counted sides may be achieved this way. Order is not important, but it is (I suppose) case-sensitive. Example of init.sqf of both scripts: ["E","W"] execVM "BDStart.sqf"; ["W","E","R"] execVM "KIAStart.sqf"; and init by in-editor init field of unit/object/trigger/whatever: nul = ["W","E"] execVM "BDStart.sqf";nul = ["W","E","R"] execVM "KIAStart.sqf"; - both are slightly heavier for CPU now. Not tested with any "spawner" script, but I hope, these work fine. EDIT: And some more "real combat" Chernaruss demo, that combinig both scripts. First markers should be on map after a minute or so, when fight gets more intense. BD-KIASdemo Known issue: sometimes some blood drop may be duplicated and stay on map even, if should disappear (rare). Not sure, why, but hey, it is hard to wash off blood, is not it?

Somehow never dug into the secrets of MP scripting, so can't help. I know only, what is written here: "createMarker is global, use createMarkerLocal if you want to create a marker locally" Whether it does not mean precisely what is needed? If not, then maybe someone else can help here.

Hmm. This should be kind of compilation of these programs: monitoring of chosen process only, but with some log file output (optimal with some kind of bookmark feature) or info on-screen, like in FRAPS. Second application unfortunately doesn't work also on Vista 64-bit. I'll search something similar then.

And here is demo with no-EH workaround for vehicles. In this version only BLUFOR vehicle's deaths are marked. KIASparksVeh NOTE: all this will not work with vehicles spawned later (this refers also to units KIA markers and units counted by "Blood Drop"). For such purpose, for "KIA Sparks", all spawned on the fly vehicles should arrive with execution of such code: Ryd_AllVeh = Ryd_AllVeh + [JustSpawnedVehicle]; and spawned during gameplay units with: nul = JustSpawnedUnit addEventHandler ["Killed", {nul = _this spawn KilledMark}]; or something like that. For "Blood Drop" situation is similar: variable _AllOfThem must be everywhere in "ShowMeBlood.sqf" file changed to global (eg Ryd_AllOfThem) and for all spawned units must be executed: Ryd_AllOfThem = Ryd_AllOfThem + [JustSpawnedUnit]; (not tested however).

Just tested this. There is a problem. Looks, like "Dammaged" EH is triggered only for non-killing damage. So with this method I can to mark moment of damaging as long, as after this vehicle is still "alive". On AVIBIRD1's request prepared package with some demos. Scripts are improved and simplified. "BloodDrop1" contains Blood Drop code only for BLUFOR wounded version 1, "BloodDrop2 - same, version 2. Both are working fine. In this demos there are two groups of wounded units - west and east. May be noticed, that drop appears only for west units. "KIASparks" contains simplified code (removed redundant "spawns"), also only for BLUFOR deaths. "Blood&KIA" combines both plus KIA code for vehicles based on "Dammaged" EH. Using of "HandleDamage" considered as too complicated, because it replaces default damaging system with manually written one and triggers for each selection, that was hit. Without getHit command this makes all this coding too heavy (must be some setVariable used for each selection and so on). HandleDamage also will corrupt every other based on this EH script, like Tank Damage System. So there is needed some non-EH based workaround for vehicles' KIA monitor. For now this package: http://www46.zippyshare.com/v/3207624/file.html

Thanks guys, I'll check these soon. Of course any other ideas still very appreciated.

Do not have time to tests now, but if "Killed" EH handles also vehicles, then simply in AddKMark.sqf AllUnits should be replaced by (AllUnits + Vehicles). But if "Killed" EH, as I suppose, isn't proper for vehicles, then for them must be replaced by "Dammaged" (or, with some changes, "HandleDamage") EH. Result: 1. Init.sqf: DMark = compile preProcessFile "DMark.sqf"; KilledMark = compile preProcessFile "KilledMark.sqf"; [] execVM "AddKMark.sqf"; 2. AddKMark.sqf: { _KilledEH = _x addEventHandler ["Killed", {nul = _this spawn KilledMark}]; } foreach AllUnits; { _DEH = _x addEventHandler ["Dammaged", {nul = _this spawn DMark}]; } foreach Vehicles; 3. DMark.sqf _veh = _this select 0; _pos = getPosASL _veh; if ((damage _veh) >= 0.9) then { [_pos,_veh] spawn { _pos = _this select 0; _veh = _this select 1; _veh removeEventHandler ["Dammaged", 0]; _i = "markHD" + (str _veh); _i = createMarker [_i,_pos]; _i setMarkerColor "ColorOrange"; _i setMarkerShape "ICON"; _i setMarkerType "DOT"; _i setMarkerSize [1,1]; _alpha = 1; _size = 1; while {(_alpha > 0)} do { sleep 0.2; _i setmarkerAlpha _alpha; _i setMarkerSize [_size,_size]; _size = _size - 0.008; _alpha = _alpha - 0.01; }; deleteMarker _i; } } I hope it works...

Good point, Orcinus. Added some warning readme to a file. This is of course one of those things, that I did not plan to publish. :)

Better not to ask... :)

Well, I have two pieces of code, that do something similar, maybe this will be useful somehow. Still do not know, if these are heavy for CPU. It is possible, depends on the number of units engaged in combat. If so, the effect will be rather slow down work of this and other scripts active in the background, than the FPS drop... Prepared some simple demos for them with 525 units engaged in firefights (just watch the map). Both scripts of course may be adjusted. 1. "Blood Drops" Based on nearestObjects, looped conditional counter with marker visualisation. Tracks all unit's damage (including dead). If there is some alive unit (anyway, which side in this version) in specified in code range, then red drop will be generated on map. Its radius and intensity is proportional to sum of damage of all units in mentioned range. Its position is average of wounded units positions. Blood Drops 2. "KIA Spark" Based on "Killed" event handler "place of death visualizer". Generates temporary, orange dot on position of just killed unit. This "spark" will become more smaller and more transparent with time and finally disappears (after 20 seconds). KIA Spark

Should. But, honestly, can't tell, when bigboss will be implemented... My free time is about to end for now. 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.

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?

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

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).

Probably the easiest way to achieve such effect is to use "Dismissed" waypoint type, however radius of loitering is unlimited here, so theoretically units may to go far away with time. So perhaps some custom script, that will to allocate for each group/unit random waypoints, always in given radius from initial position plus some randomized animations from time to time may be better solution. Problematic with such animations may prove to make unit to break such animation immediately (some of them are long), when fight is started. Conditional usage of switchMove or switchAction with empty animation/move/action name may help with this problem. Maybe tommorow I will try to play with such script, effect may prove interesting, but only if I will find some free time.

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.

Ah yes, now I understand. You tried to use select for sqs style GOTO loops. I liked this loops too, but this is, I afraid, song of the past, as all sqs syntax (good as introduction into scripting for some people however). There isn't such "GOTO" loops in sqf... Well there is something somewhat similar, but it isn't exactly the same (never used by me): ScopeName breakTo breakOut still there are other, usually better methods instead to do same thing. (inside spoiler more detailed info about scopes and _this select usage, please to correct me if anyone knows something, that I do not know) So, my example of yours code now will look like this: if (fog >= 0.5) exitwith { player sidechat "Weather is Echo 1-1 aerial ressupply is a nogo." }; //this makes, that script will exit main scope (script itself) with such message when fog is 50% or more player sidechat "Echo 1-1, aerial resupply is inbound! Ensure DZ is clear of enemy forces."; // this message will appear and next lines will be executed only, if fog will be < 0.5, so script will not exit earlier. sleep 8; CC_drop setfuel 1; _way1 = (group CC_drop) addWaypoint [position player, 0]; _way1 setWaypointType "MOVE"; _way1 setWaypointBehaviour "CARELESS"; _way1 setWaypointCombatMode "GREEN"; _way1 setWaypointSpeed "NORMAL";//changed to MOVE&CARELESS&GREEN, so plane named "CC_drop" shouldn't to engage in any combat or, hopefully, any other interacion or action beacuse of noticed enemy presence, so should to go, where is needed regardless of situation (group CC_drop) setCurrentWaypoint _way1; //possibly redundant, but will do not harm _way2 = (group CC_pilot) addWaypoint [getMarkerPos "HELI", 0]; _way2 setWaypointType "GETOUT"; _way2 setWaypointBehaviour "AWARE"; _way2 setWaypointCombatMode "YELLOW"; _way2 setWaypointSpeed "NORMAL"; _way3 = (group CC_pilot) addWaypoint [getMarkerPos "HOLD",0]; _way3 setWaypointType "CYCLE"; _way3 setWaypointBehaviour "AWARE"; _way3 setWaypointCombatMode "YELLOW"; _way3 setWaypointSpeed "NORMAL"; WaitUntil { sleep 0.1; _distance = CC_drop distance player; (_distance < 30) }; _para = "ParachuteMediumWest_EP1" createVehicle [0,0,0]; _para setpos [(getPos CC_drop) select 0,(getPos CC_drop) select 1,((getPos CC_drop) select 2) - 20]; _ammo1 = "USOrdnanceBox" createVehicle (getPos _para);//my proposition instead of undefined _pos. _ammo1 attachTo [_para, [0,0,-1.6]]; sleep 1.0; WaitUntil { sleep 0.1; ((getpos _ammo1) select 2) < 0.2 }; detach _ammo1;

I see. Often most obvious solutions just doesn't come into mind. :) Interesting. I like it. There is also an option, that vehicle is on road, but road turning and leads the other way before reaches calculated point. Now I began to wonder, if there is method to take into account also such circumstance. But for this may be needed script, that somehow follow the road to determine, if this road leads into impact area, or not, and if not, then calculates, at which point of road will be target while splash occurs (so must also to calculate lenght of the relevant section of road line). Well. Doesn't matter. :)

Still there are problems: not defined _pos variable and incomprehensible to me usage of "start" and "end" global variables start = _this select 0;//why this variable "start" is global (without _))? Will be used outside this script? end = _this select 1;//lack of "_" if (fog < 5) then //maximum fog is 1, as far, as I know maybe you want 0.5 here? { player sidechat "Echo 1-1, aerial resupply is inbound! Ensure DZ is clear of enemy forces." } else { player sidechat "Weather is Echo 1-1 aerial ressupply is a nogo." };//deleted "selects". Don't know, why they was here, but select is not used that way start = sleep 8;//What this should do? 8- second pause? then only "sleep 8;" should be here. To what refer "start" and end "variables"? (Try rather to name yours global variables in more distinctive, unique way eg CC_Start instead of Start, cause some other script or addons may to use global variable of same name when this name is too common) _distance = CC_drop distance player;//"drop" is name reserved as some particle effect command, so change was required; added by me below "waitUntil" loop makes this line redundant - may be deleted CC_drop setfuel 1; _way1 = (group CC_drop) addWaypoint [position player, 0]; _way1 setWaypointType "SAD"; _way1 setWaypointBehaviour "COMBAT"; _way1 setWaypointCombatMode "RED"; _way1 setWaypointSpeed "NORMAL";//such waypoint (SAD&COMBAT&RED) will make CC_drop vehicle behavior very "militant", so its behavior will be hardest to control and to predict. This is, what you want? I think, better eg MOVE&SAFE&GREEN or something like that; Assumed, that way1 is not used by other scripts, so may be local, so added "_" (group CC_drop) setCurrentWaypoint _way1; //possibly redundant, but will do not harm _way2 = (group CC_pilot) addWaypoint [getMarkerPos "HELI", 0]; _way2 setWaypointType "GETOUT"; _way2 setWaypointBehaviour "AWARE"; _way2 setWaypointCombatMode "YELLOW"; _way2 setWaypointSpeed "NORMAL"; _way3 = (group CC_pilot) addWaypoint [getMarkerPos "HOLD",0]; _way3 setWaypointType "CYCLE"; _way3 setWaypointBehaviour "AWARE"; _way3 setWaypointCombatMode "YELLOW"; _way3 setWaypointSpeed "NORMAL"; waituntil { sleep 0.1;//to make script a little lighter _distance = CC_drop distance player; (_distance < 30) };//_distance variable was previously defined only once, so was never changed since then, so this waituntil loop is needed for cyclically (10 times per second) refresh of its value and condition check. _para = "ParachuteMediumWest_EP1" createVehicle [0,0,0];//when _distance < 30, loop is ended and next lines are executed _para setpos [(getpos CC_drop) select 0,(getpos CC_drop) select 1,((getpos CC_drop) select 2) - 20];//I'm not sure, but probably this is code, that do, what you want here. Probably some brackets are redundant here, but makes code clearer, at least to me _ammo1 = "USOrdnanceBox" createVehicle _pos;// _pos variable not defined, should be earlier line like _pos = getPos something; _ammo1 attachTo [_para, [0,0,-1.6]]; sleep 1.0; WaitUntil { sleep 0.1; ((getpos _ammo1) select 2) < 0.2 };//sleep added, some bigger height in condition setted, cause sometimes height of object on the ground may be very slightly bigger than 0 detach _ammo1;//lack of "_" end = exit;//what this should do? "exit" is a command, that is ignored in sqf. if this should to end script, just delete this line. Script will end here anyway. Maybe also create bookmark at this page: http://community.bistudio.com/wiki/Category:Scripting_Commands_ArmA2 Is very useful... Also, to check, why yours script is not working, try to find yours RPT file and use it often: Where is my RPT file

Just tried Utes mission on pure Arma2 1.11. Encountered two problems: - error message at start: "class land_fortified_nest_big_EP1 no longer exists" - target point for "move to the base" task is every time located on [0,0,0] position (lower left corner of the map, open sea)...

However, if some group is cached, so in given moment only group leader exist on map, Hetman will count only this leader as own unit, because HAC takes into account only units "phisically" present on map when making its decisions. So caching for HAC-controlled groups is very bad idea - HAC will think, that most of his forcers suddenly died (big morale drop, most likely turning into defensive mode) or, if groups was cached before HAC init, that has only not cached leaders of groups under control (also, because AT- and AA-soldiers (and other specialistic units) will be also cached, HAC will consider, that has no AT or AA weaponry to his disposal and will take this fact into consideration when making his decisions).

True, HAC as much as possible stays away from low-level AI (unit and group level; there are only very few exceptions, as limited AI for choppers and trucks on cargo missions, or smoke deploying before withdrawal) and takes control mainly over waypoints designation for controlled groups. HAC can and will try to flank, to keep reserves, to use recon, to handle cargo and logistics vehicle support, to choose preferable terrain at target area for given kind of forces, to use best available kind of forces against given enemy and to keep given forces away from enemy weaponry, that is highly effective against that kind of unit/vehicle. He also may go to the defensive stance, if opponent's advantage is high enough. All this (and more) is "fuzzy" by randomizations, where chances for given order are dependent of HAC's leader "personality" (chosen or randomized). About reveal: currently, if RydHQ_KnowTL config parameter is true (default), all groups led by human-controlled unit will share info about known position of all allied and known to any controlled (allied) unit enemy forces. If this parameter is false, only HAC's Leader group have access to that informations. Anyway groups led by AI teamleaders shouldn't have such info, because this may affect their behaviour in unrealistic way (exactly as this 900 meters sniping possibility). This is only for human TL as some kind of intel from HQ, that helps to fill his orders better, with greater awareness of situation on the battlefield. So this shouldn't affect pure AI forces under HAC control. Maybe try to turn off mentioned variable by making its value false at init or in any moment you want, and then check, if such sniping ability is still present.

Haven't big knowledge, and haven't enough time, but know, where info about Call for Fire procedures can be found. For example: http://www.globalsecurity.org/military/library/policy/army/fm/6-30/f630_5.htm As far, as I know first is always so called "locstat" - GRID position of FO. Obviously neccessary for POLAR, but also needed to aware the battery, where shouldn't fire. :)

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) 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.

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.