Jump to content

Rydygier

Member
  • Content Count

    4805
  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by Rydygier


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


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


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


  4. I can measure FPS drop, or time of work for script; obviously can to recognize lags or slow downs... But how to accurately determine, how affects on the system resources a given script (how much % of them it consume while running in given scenario)? Is there any handy tool (that maybe displayes such info on screen, so is possible to compare load with and without script running) or method suitable for such purpose? Simply I want to control, how exactly my scripts will affect on mission flow and vice versa...


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


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


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


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


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


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


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


  12. Rydgier, let me explain what I was trying to do with select/goto. I was hoping their was a way to do something like where whether the "then or else" is true than the script skips to a certain block of code, within the same script. Like the goto command I guess?? And than understand the loop system. Which I think I understand a little better from yalls help. The main thing is I wanted to if fog was too heavy the script to exit and the player would be forced to try again later if the fog has cleared up. Thats why I tried to send the script to exit in the "else" statement. I know im probably not making much more sense. I know commands and quite a few statements. I guess my main concern now is, like you said, learning to structure and loop my scripts. I need to be able to effectively and cleanly (not kill me CPU) check for conditions throughout the mission or after certain things happen. And than for more complicated scripts use variables and complicated scripts like attachto. If you all could continue to help me understand the select 0,1,2,3 thing and how or if that is used to select certain blocks of codes based on the output of conditions that would be awesome. :)

    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)

    It is important to understand, what is the "scope" thing. Simply - it is a script level. Generally code in {} brackets is a sub-scope - scope of more "inner" level (in rare situations, eg when spawn {some code}; is used, contents of {} (some code) will be completely separate scope, same as other, independent script - see below how to proceed then). Variables with "_" (local) are recognized only in scope, where was defined and in all more inner sub-scopes. There are also some other things with this concept, but enough of this for now. So, if you prepare such code:

    if (fog > 0.5) then {_message = "noGo"};
    
    player sidechat _message;

    Message will not appear, because _message is definded in sub-scope (so recognized only in this and more inner scopes, if some exists), and next used in main script scope.

    This however will work (message will appear regardless of fog, but kind of message will be dependant of fog level):

    _message = "On the way!";
    if (fog > 0.5) then {_message = "noGo"};
    
    player sidechat _message;

    because _message was defined in same, main scope, as that, in which _message is used at end of the code. It is also proper changed from "On the way!" to "NoGo", because changes maded after definig are recognized everywhere, where variable itself is recognized, unless private command is used...

    This will work also, message will be dispalyed, when fog will be heavy enough

    if (fog > 0.5) then {_message = "noGo";player sidechat _message};
    

    and this too:

    _message = "noGo";
    if (fog > 0.5) then {player sidechat _message};
    

    BTW about this:

    start = _this select 0; 
    end = _this select 1; 
    

    Such code is used to introduce, here as two global variables (usually there will be local variables) of names "start" and "end" some values from entirely other scope (eg other script) into this script. _this represents an array of such values, select 0 represents first value from _this array, select 1 - second.

    For example let's say, that you prepared "first.sqf" script:

    _FirstVar = 0;
    _SecondVar = "teddybear";
    
    [] execVM "second.sqf";

    There are two variables defined - a number and a string. And you want to use this values in executed from here "second.sqf" script, that looks like:

    hint (str _FirstVar);
    sleep 5;
    hint _SecondVar;

    But this is not working, because local variables was defined in other scope (other script). How to make this work? Two methods for example...

    First: to make these variables global (delete "_"). Now, after defining, will be recognized by any other script/scope:

    FirstVar = 0;
    SecondVar = "teddybear";
    
    [] execVM "second.sqf";

    and:

    hint (str FirstVar);
    sleep 5;
    hint SecondVar;

    but if you change value of this global variables in "second.sqf", then for "first.sqf", and for any other script/scope too, their values also will be changed, so usually better way for "second.sqf" may be:

    _first = FirstVar;
    _second = SecondVar;//now you operate on local variables with same value, as these global, so there is no risk to change global variable value for all scripts/scopes
    
    hint (str _first);
    sleep 5;
    hint _second;

    Second way, probably best, is to use _this array:

    "first.sqf"

    _FirstVar = 0;
    _SecondVar = "teddybear";
    
    [_FirstVar, _SecondVar] execVM "second.sqf";//all inside [] brackets will pass into "second.sqf" as _this array

    "second.sqf"

    _first = _this select 0;//(means _first = _FirstVar)
    _second = _this select 1;//(means _second = _SecondVar)
    
    hint (str _first);
    sleep 5;
    hint _second;

    Now "second.sqf" will work.

    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;
    


  13. defining counter variables for each round type.

    I see. Often most obvious solutions just doesn't come into mind. :)

    I also check to see if the target is on the road, and if it is, I look for a road near the calculated impact point.

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


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


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


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


  17. *Check radio protocol. I need someone with military knowledge to read my messages and see if they fall in line how it should be done in real life.

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


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


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


  20. Yes, UAV has it's limitations. But maybe this way is more realistic? I don't know. And yes, it has tendency to crash. Maybe this will help with poor spotting:

    setSkill_array

    for example try to add this to UAV's init field:

    this setskill ["spotDistance",1];this setskill ["spotTime",1]

    maybe plus set overall skill to maximum...

    BTW, about this:

    	{
    if ((UAV_1 knowsAbout _CheckedUnit) >= 0.01) then {_x reveal _CheckedUnit}
    }
    foreach units group Player1; 

    It will work, but all group members share the same knowledge, so there is no need to reveal for all of them, in fact revealing only for group as a whole, or only for group leader will be sufficient. So, if this is about only one group, then foreach loop is uneccessary. Try this instead:

    if ((UAV_1 knowsAbout _CheckedUnit) >= 0.01) then {Player1 reveal _CheckedUnit};

    should be same effect with this:

    if ((UAV_1 knowsAbout _CheckedUnit) >= 0.01) then {(group Player1) reveal _CheckedUnit};

    and this :)

    if ((UAV_1 knowsAbout _CheckedUnit) >= 0.01) then {leader (group Player1) reveal _CheckedUnit};

×