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/