Larrow

So it would be something like... Before we delete the vehicle in the action take a note of its type, I know not particularly needed for your script as they are all of the same type, but if you wanted to expand this later its easier to incorporate it now. //We create the cargo container that we want our aircraft to be transported in _blackHawkContainer = "B_Slingload_01_Cargo_F" createVehicle _blackHawkPos; //Make note of vehicle number and vehicle type on the wreck container _blackHawkContainer setVariable[ "wreckInfo", [ _vehNum, typeOf _target ] ]; Then for the trigger we do not need the inArea check, if the container is in thisList ( it must be satisfying the triggers activation settings) then it must already be in the trigger area. //Does something in the triggers thisList have a variable on it called wreckInfo thisList findIf{ !isNil ( _x getVariable "wreckInfo" ) } >= 0 TBH for this I would spawn a trigger from script for each wreck container( it means they maybe a few triggers active at a time depending on how many vehicles are currently dead but should not be a problem, you can even change their polling rate to make things less resource intensive ). Each trigger can then be set to [ "VEHICLE", "PRESENT", true ] then the trigger is only looking for this particular wreck crate "VEHICLE", eliminates all the confusion about getting the right object from the trigger. Ok this system is getting quite large now and has many parts that are all crammed into one script. It is at this point in a project where I would start thinking about what I have and separate it out into its parts. So lets think this through, we have... Initialisation of vehicles applying eventHandler adding wreck ( marker, action ) packaging wreck ( container, trigger ) repairing vehicle ( spawning new vehicle ) ...so lets make a script for each of these independently. Run out of time for today, going to continue when a get back later this evening/tomorrow.

Description.ext is missionConfigFile instead.

Added some comments, untested, not sure if it will fix your particular problem.

Short answer... _actionCode = { params [ "_target", "_caller", "_id", "_args" ]; // _args will be [_baseEntry1] as passed _args params[ "_to" ]; // _to will be _baseEntry1 Long answer, maybe an easier way to make the connections (this is presuming all exit/entries of the same number are tied to each other entry_1 goes to exit_1 and visa versa)...

addEventHandler So we are saying to the engine, when this vehicle is killed can you please notify us when it happens. As per the addEventHandler page, we provide the engine with some code to call to notify us by. The engine passes us some information into this code via the _this variable when the event happens. Event Handlers As per the Event Handlers page for killed you can see what is contained in _this. So we use params to pull the information from _this into some local variables, named whatever we like( although this page does suggest some names based on the information _this is going to contain for that particular event ). All params does is pull information from an array. Unlike when using select where you need to specifically prefix the command with the array to pull the information from, so _this... private _someLocalVar = _this select 0; ... if the prefix array for params is missing it defaults to using _this. e.g _this params[ "_someLocalVar" ]; params[ "_someLocalVar" ]; ...these two lines are exactly the same. In the first we specifically tell it to use _this. In the second the prefix array is missing so it just defaults to using _this.

Yes You can name it whatever you like, TAG is just a general wording to denote replacing it with your own so for instance you could name it KRAK_fnc_## as per your username or whatever you like. predifined! params is a command for defining variables passed in _this TAG_fnc_someFunctionParams = { params[ "_var1", "_var2" ]; } TAG_fnc_someFunctionThis = { private _var1 = _this select 0; private _var2 = _this select 1; } These two functions do exactly the same thing, define private local variables _var1 and _var2 from whatever was passed to the function in _this. [ "Hello", "World" ] call TAG_fnc_someFunction# _var1 would be "Hello", _var2 would be "World" We make a public local variable called _vehicleName and its equal to vehicle variable name in all lower case. When you name some object in the editor by filling out its variable name property two things happen when the mission loads... The vehicle is given a vehicleVarName of the STRING we gave in the property A global variable of the same name is made referencing said object SplitString returns an array of STRINGs of the original string broken up by the string passed to splitString, e.g _string = "1,2,3,4,5"; _split = _string splitString ","; // _split would be [ "1", "2", "3", "4", "5" ] _string = "Hello World"; _split = _string splitString "l"; // _split would be ["He","o Wor","d"] So by splitting "blackhawk1" by "backhawk" we end up with an array of just [ "1" ]. Select 0 just chooses the first thing in the array so "1". We end up with just the STRING number for that blackHawk based on its varName. _x is just the current thing being evaluated for that iteration of the forEach. So first time round its blackHawk1, second time its blackHawk2 etc etc. Well each blackHawk is already a global variable. As explained for varName above in 4. So in the script when we say blackHawk1 or similar this IS a global variable that references the object because we gave it a variable name in the editor. You can place the addAction in the new function as the same thing happens for every blackHawk. No, when the blackHawk gets deleted the global variable will still exist but it will be Objnull as the OBJECT it references no longer exists, is null. If you wish to clear any variable you need to set it to nil. Is this for MP or SP? There maybe some other things you need to take into consideration if this is for MP, like... Should not be initiated through init.sqf as this happens everywhere. So for each machine client/server. So should be in initServer only If so action would need remoteExec'ing to all clients and JIP

EventHandlers are always the way to go if available. Seeing as each blackhawk is handled the same, you could simplify your code to just... //bhWreckMarkers.sqf TAG_fnc_blackHawkDown = { params[ "_vehicle" ]; _vehicleName = toLower vehicleVarName _vehicle; // "blackhawk1" _vehicleNum = _vehicleName splitString "blackhawk" select 0; // "1" playSound "rhsusf_dws_warning_damagecritical"; _blackHawkCrashMarker = createMarker[ format[ "Blackhawk %1 down", _vehicleNum ], _vehicle ]; _blackHawkCrashMarker setMarkerType "mil_pickup"; _blackHawkCrashMarker setMarkerText format[ "Blackhawk %1 down", _vehicleNum ]; _blackHawkCrashMarker setMarkerColor "ColorRed"; driver _vehicle commandChat "We are going down!"; }; //Add event to each blackhawk { _x addEventHandler[ "Killed", { params[ "_killed" ]; //Call function to create marker and radio _killed call TAG_fnc_blackHawkDown; }]; }forEach [ blackHawk1, blackHawk2, blackHawk3, blackHawk4, blackHawk5 ];

Why init.sqf ? So this is happening everywhere! Should just be initServer.sqf and then remoteExec the loadout script to where the unit is local, due to some of the commands being LA. //initServer.sqf // detect and change all editor placed units { [_x] call CB_fnc_factionConfig; } forEach ( allUnits select { _x isKindOf "CAManBase" && { !isPlayer _x }} ); // add MEH to catch anything spawned CB_MEH_factions = addMissionEventHandler ["EntityCreated", { params ["_entity"]; if ( _entity isKindOf 'CAManBase' && { !isPlayer _entity }) then {[_entity] call CB_fnc_factionConfig}; }]; //CB_fnc_factionConfig // handles params[ "_unit" ]; //Everything here will already be CAManBase and !player //ignore special units with this variable // factions to re-paint private _scriptName = switch ( faction _unit ) do { case ( "BLU_F" ) : { "BLUFORnato" }; case ( "BLU_CTRG_F" ) : { "BLUFORspecops" }; case ( "BLU_G_F" ) : { "BLUFORion" }; case ( "OPF_F" ) : { "OPFORcsat" }; case ( "OPF_R_F" ) : { "OPFORspecops" }; case ( "IND_G_F" ) : { "INDFORfia" }; case ( "IND_C_F" ) : { "INDFORspecops" }; case ( "CIV_F" ) : { "CIV" }; }; [ _unit ] remoteExec[ format[ "CB_fnc_loadout_%1", _scriptName ], _unit ];

Strange, I have just tested it on my dedicated with no issues. Are you seeing any errors in the server or clients RPT? Is it maybe a copy and paste issue from the forum inserting hidden characters?

Lazy evaluation, part in curly braces is only done if the previous statement is true/satisfies the overall statement. Yes, if _shooter isNil then isNull _shooter makes no sense. If isNull _shooter is in braces then isNil returns true which satisfies the OR statement so isNull will never be evaluated.

I have changed the saved data from the server's profileNamespace to missionProfileNamespace instead. Just a better idea all around... you can use this system on multiple missions without it interfering with each other, or even share if needed you can use allVariables command on it to collect all data for deletion. I have changed the data from a single var for each piece of information ( e.g KIB_#_Pos, KIB_#_Rating ) to KIB_playerData_# ( where # is the reference to the player, as per previous either varName or uid ) which is an array holding ALL the data for that player. Makes it easier to find/delete without having to poll multiple vars. I have made an action menu for the logged in admin so they can manage the data... "Show Admin Menu" - Will display the options below "Delete Players Position" - Will delete the position data for the current player you are looking at "Delete Players Rating" - Will delete the rating data for the current player you are looking at "Delete Players Data" - Will delete all data for the current player you are looking at "Delete All Players Positions" - Will delete position data for all currently connected players "Delete All Players Ratings" - Will delete rating data for all currently connected players "Delete All Players Data" - Will delete all data for all currently connected players "Delete ALL Data" - Will delete all data EVERYTHING that has ever been saved "Close Admin Menu" - Will remove the options above other than Show Menu just so you can clear the clutter from your action menu Again totally untested, let me know if there are any problems. Update: New version that saves players starting position, added options to admin menu to reset position/rating. TEST MISSION

//initServer.sqf KIB_fnc_getPlayerData = { params[ "_player" ]; if ( vehicleVarName _player == "" ) then { _player setVehicleVarName format[ "Player_%1", getPlayerUID _player ]; _player call BIS_fnc_objectVar; }; [ profileNamespace getVariable[ format[ "KIB_%1Pos", vehicleVarName _player ], getPosATL _player ], profileNamespace getVariable[ format[ "KIB_%1Rating", vehicleVarName _player ], 0 ] ] remoteExec[ "KIB_fnc_setPlayerData", remoteExecutedOwner ]; }; KIB_fnc_savePlayerData = { params[ "_player" ]; profileNamespace setVariable[ format[ "KIB_%1Pos", vehicleVarName _player ], getPosATL _player ]; profileNamespace setVariable[ format[ "KIB_%1Rating", vehicleVarName _player ], rating _player ]; }; KIB_fnc_updatePlayerData = { params[ "_player" ]; while { true } do { [ _player ] call KIB_fnc_savePlayerData; sleep 300; }; }; //initPlayerLocal.sqf KIB_fnc_setPlayerData = { params[ "_position", "_rating" ]; //Only allow execution from the server if ( isMultiplayer && { !isRemoteExecuted || { remoteExecutedOwner isNotEqualTo 2 }} ) exitWith {}; //Set rating, not add to what they already have player addRating ( _rating - rating player ); player setPosATL _position; //Only once saved/defaults have been applied start saving data [ player ] remoteExec[ "KIB_fnc_updatePlayerData", 2 ]; }; params[ "_player" ]; [ _player ] remoteExec[ "KIB_fnc_getPlayerData", 2 ];

this and { player in triggerAttachedVehicle thisTrigger } Not that it makes any difference but if you are attaching a vehicle as an owner there is a command to retrieve the said vehicle.

Is just... private _selectedMission = _availableMissions deleteAt floor( random count _availableMissions );

When dealing with this you can use the side of the group of the unit. _realSide = side group _deadUnit; Does this exist? This variable will be Nil until the display is being shown and its onLoad has happened. This... ... can be replaced with just... _color = side group _oldUnit call BIS_fnc_sideColor; Surely when the mission starts this is just the side/group of the player. Not quite sure what you mean by team. Could this not be done with createMarker of type ICON, then the information would be available to all maps rather than handling them individually by placing drawIcon's on them all/

Well the MOVE command from the same menu ( when you add a waypoint ) has a similar function call... //--- Add waypoint _codeWP = _logic getvariable 'GUI_WP_MOVE'; _script = [_is3D,_pos,_shift,_ctrl,false,_selected] spawn _codeWP; However, I would not change this directly as I believe it is already set by the HC system... However, you will notice this code also has a call to a function stored on the HC logic. //--- Move handler _handler = _logic getvariable "onGroupMove"; if (!isnil "_handler") then {[_group,_wp,grpnull] spawn _handler}; This _handler is run both when adding a new waypoint(MOVE) or issuing an WP ATTACK. Although I am not sure if this is already in use by the system ( did a quick grep and could not see it set anywhere ). So you could use this to cancel the doStop by issuing a doFollow as suggested on the wiki doStop page. BIS_HC_1 setVariable ["onGroupMove", { params[ "_group", "_wp" ]; units _group doFollow leader _group; }, true]; Or there is always the missionEventhandlers for onGroupClicked, or it may even be possible to inject your own command into a subMenu of RscHCGroupRootMenu see how #USER:HCWPWaitRadio etc are manipulated in hc_gui.sqf . Having a good read through the hc files in \a3\modules_f\hc\data\scripts would be a good idea and may lead you to some ideas.

Eden Composition Spawning Been working my way through this problem every time i have 5 mins between other stuff. Looking for testers willing to test out compositions. I have put it through some simple testing and the test mission comes with some examples as player actions. DOWNLOAD Save a composition in Eden and then in your profiles folder (usually MyDocuments\Arma 3\) in the compositions folder find its composition.sqe. Copy its .sqe and place it in your mission folder in a folder called Compositions and rename it to something remember-able. Copy the LARs folder to your mission. Add to your description.ext.. class CfgFunctions { #include "LARs\spawnComp\functions\functions.cpp" }; #include "compositions\compositions.cfg" Create a file called compositions.cfg in your missions composition folder that you created above and add a class for your composition. e.g //LARs_spawnComp_debug = 1; //1 = RPT output, 2 = RPT output and ingame visual positioning info class CfgCompositions { class Walk { //Name that the composition is spawned by #include "walk.sqe" //Renamed composition.sqe }; }; Then when you want to spawn a composition.. _compReference = [ COMP_NAME, POS_ATL, OFFSET, DIR, ALIGN_TERRAIN, ALIGN_WATER, IGNORE_ATLOFFSET ] call LARs_fnc_spawnComp; Where.. COMP_NAME - Classname given to composition in CfgCompositions POS_ATL( optional, default compositions saved position ) - Position to spawn composition If not given or empty array passed then original saved composition position is used Also accepts OBJECT, MARKER, LOCATION OFFSET( optional, default none ) - ARRAY [ x, y, z ] ammount to offset composition, as a compositions base pos can vary from what you want when its saved DIR( optional, deafault 0 ) - Direction to face composition in, If POS_ATL is of type OBJECT, MARKER, LOCATION passing TRUE for direction will use objects direction ALIGN_TERRAIN( optional, default True ) - BOOL, Whether composition objects should align themselves to their positions surface normal ALIGN_WATER( optional, default True ) - BOOL, If a composition objects position is over water should they align themselves to sea level IGNORE_ATLOFFSET( optional, default False ) - BOOL, If True each item in the composition will ignore its ATLOffset that usually gets added to its Z(height) !FUCNTIONALITY CHANGED! The function call will also return a reference string for the composition. Which can be used with some of the provided utility functions. [ _compReference ] call LARs_fnc_deleteComp; Will delete the composition. [ _compReference ] call LARs_fnc_getCompObjects Will return an array of all the compositions items. [ _compReference, _item ] call Lars_fnc_getCompItem Passing an Object will return its composition ID or -1 if not found. Passing an ID will return the object or objNull if not found. [ _item ] call LARs_fnc_getItemComp Will return a the reference to the composition the item belongs to or "". Checking the RPT with LARs_spawnComp_debug = 1 set in the composition.cfg when spawning a composition will display info on the objects spawned. e.g 12:29:04 "spawning - Object B_Soldier_A_F - ID: 51, VarName target1" Where it displays.. Type being Group, Object, Trigger, Logic, Marker or Waypoint Classname of object ie B_Soldier_A_F Composition ID 51 For Object, Trigger, Logic it will show its VehcileVarName if it was spawned with one. For Group it will display the groupID For Marker its given name and Waypoints their waypointName ('identified' option in Eden) Priority order of which composition items are spawned in. You may need to get funky with object names, especially markers as they cannot exist twice and things like task names in modules. Although you can use the utility functions to get a reference to objects and link out side resources yourself as another possible solution. Again has been put through very limited testing. As you can see by the examples I have a... Camp Ant spawning with added foot patrol and a vehicle that executes a waypoint synced to one of the patrols waypoints. A man that will cycle his route. A working sector. A simple task using modules. A simple mission using modules, a random vehicle spawning at grouped markers with a unit init to moveIn and blowing it up via a trigger when it reaches a waypoint to complete task. Set up Roadblock, if near a road will spawn a checkpoint aligned with the roads direction. There are several others that i have written short description for in the CfgCompositions. Most likely missed loads of stuff 😕 and I know I have not test trigger and waypoint effects. So if you feel like testing it out and supplying feedback of what is/isnt working(a small example .sqe would be handy for tracking problems down) ... DOWNLOAD as I just do not have the time to test every conceivable permutation myself. Updates:

Are you sure the onTaskCreated code is passed anything at all in _this? Try testing what is being passed... BIS_HC_1 setVariable ["onTaskCreated", {hint format["_this is %1", [str _this,"nil"] select (isnil "_this")]}, true]; EDIT: According to hc_gui_menu.sqf it is passed the current waypoint the user is hovering over on the hc map. So your then saying... [GROUP, INDEX] call CBA_fnc_taskDefend ...Which is not what CBA_fnc_taskDefend expects Are you sure your error is not coming from CBA function? If you just want the defaults from taskDefend by just passing the group... BIS_HC_1 setVariable ["onTaskCreated", {_this #0 call CBA_fnc_taskDefend}, true];

//Random composition// _random_comp = selectRandom [ "Fire_Area", "Fire_Area_Big"]; //Spawn composition// random_fire_reference = [_random_comp, location1] call LARs_fnc_spawnComp; //***other code***// //Delete composition// random_fire_reference call LARs_fnc_deleteComp; hint format ["Composition cancelled %1", random_fire_reference];

_compReference call LARs_fnc_deleteComp; _compReference holds the returned STRING. However, you need to make sure _compReference is still valid, not nil, not gone out of scope. Maybe store it somewhere with setVariable or make it a global variable if it's the only comp you're dealing with.

Store the handle on the trigger using setVariable. _handle = ppEffectCreate ["FilmGrain", 2000]; _handle ppEffectEnable true; _handle ppEffectAdjust [0.3, 0.15, 1, 0.2, 0.5, 0]; _handle ppEffectCommit 3; thisTrigger setVariable[ "ppEffect", _handle ]; //terminate with ppEffectDestroy ( thisTrigger getVariable "ppEffect" );

You may also want to check kbAddTopic as well. This command is both LA and LE, so if your zeus_indfor is likely to move around ( on server as AI, or could be a player ) then you will need to add the topic on all respective machines. Either just add it everywhere or possibly use Local EH and check with kbHasTopic whether it needs adding.

Im going to guess that your script is running on the server. The wiki page says this command is LA ( Local Argument ). So if zeus_indfor is a player, from a dedicated server they will not be local, where as in Single/Local MP they would be. If zeus_indfor is an AI then its likely they are local to the server hence why it works. Try remoteExec'ing the command to where the unit who is to speak is local. ie //Replace //zeus_indfor kbTell _tellArr; //With [ zeus_indfor, _tellArr ] remoteExec[ "kbTell", zeus_indfor ];

Well you remove the original Condition and Activation with desactivation trigger, so with the ReloadAI_bob_enable trigger just replace them. ReloadAI_bob setTriggerStatements [ "true && round (time %60) ==1 and (({_x == '30Rnd_762x39_Mag_F'} count magazines bob) <= 1)", "bob addMagazine '30Rnd_762x39_Mag_F';", "" ]; Note the ' around the magazine name due to STRING in a STRING.

Use setVariable to store the spawned group somewhere, e.g either missionNamespace or on the trigger, so you then have access to it from the other trigger.