7erra

on each frame is a bit tricky in MP because not every client switches frames at the exact same time.

Showing script errors to clients might still be important. At least the user then knows that something is wrong. Eg. your are trying to pick up an item with an addaction from the ground but the addaction code is faulty. The player will never now that he cant pick it up.

That is a punch to the face for every content creator there is. I, for example, am spending hundreds of hours on my projects. Hearing such a comment is just unfair to everyone. In another post you refered to Life players as script kiddies. Altis Life is one of the most ambitious projects out there even if someone doesn't like it. Hell, even I have some prejuidices against people who are playing it. But at the end of the day there are so many people enjoying it, why talk badly about it? To not derail the topic of @opus132 any further: I can only talk about A2. Compared to A3 it lacks some really worthwhile features, imho the overall handling of a3 is better than a2 (inventory, movement, ...). Storywise you don't need any background to play a3. As already mentioned, modding is strong in both games, so nearly infinite supply of content 🙂

This is a known problem: https://feedback.bistudio.com/T80668. The setObjectTexture(Global) command will take the server's mission root and try to find the texture in a folder that does not exist for the client. Maybe working around it with @killzone_kid's method might work (http://killzonekid.com/arma-scripting-tutorials-mission-root/)?

Instead of using the box as the namespace (variable holder) just use profileNamespace. In this case the profileNamepsace of the server or whoever hosted it will be used. Keep in mind that using profileNamespace for persistency is not the best practice because it clutters the user's profile. If you need to save larger amounts of data use iniDBI or extDB. Also, declaring the function is neccessary only once. Create a game module and paste the function declaration in the init field of this one. Add the actions in the init line of the object. Game module init: TER_fnc_handleLoadout = { params ["_mode", "_this"]; params ["_target", "_caller"]; switch _mode do { case "save":{ _dbLoadouts = profileNamespace getVariable ["db_loadouts",[]]; _loadout = getUnitLoadout _caller; [_dbLoadouts, [getPlayerUID _caller, "loadout"], _loadout] call BIS_fnc_dbValueSet; profileNamespace setVariable ["db_loadouts", _dbLoadouts]; }; case "load":{ _dbLoadouts = profileNamespace getVariable ["db_loadouts", []]; _loadout = [_dbLoadouts, [getPlayerUID _caller, "loadout"]] call BIS_fnc_dbValueReturn; if (isNil "_loadout") exitWith { "No saved loadout found." remoteExec ["hint", _caller]; }; _caller setUnitLoadout _loadout; }; }; }; Object init: this addAction ["Save Gear",{ ["save", _this] remoteExec ["TER_fnc_handleLoadout", 2]; }]; this addAction ["Load Gear",{ ["load", _this] remoteExec ["TER_fnc_handleLoadout", 2]; }]; Script is not tested. I hate MP debugging.

That's a playable unit. Big difference. The onPlayerRespawn.sqf doesn't execute for AI units. Try the mission EH "EntityRespawn" or MP EH "MPRespawn" instead.

Soo is the unit a player when the unit dies?

What is BLUFOR_AI? And what do you mean with player AI? "Player AI" is a contradiction in itself.

Only possible with mods: If you could send me an example of a mission with a custom loading screen I could have a look at it.

limitSpeed and forceSpeed are AI related commands, not physics related ones. Try playing around with setVelocityModelspace.

With remoteExec. "Hello player 2, this is player 1 executing the script." remoteExec ["hint", P1]; P1 is the receiving player.

The pilot is probably in combat mode and tries to evade an enemy. Add this line to your helipad trigger activation: driver heli1 disableAI "MOVE"; And in the extraction trigger add this line: driver heli1 enableAI "MOVE";

True, the first example is sqs. But it is perfectly okay (and normal) to use sqf. this addEventhandler ["Fuel", {_this execVM "script.sqf";}]; The BIKI documentation seems a bit old. This one seems to be from April 2006 when the page was first created. Spawning the eventhandler and then calling a function is a bit redundant. You can just spawn the function from the eventhandler: _taskTargetObject addEventHandler [ "fuel", { quest_giver globalChat "1"; (_this select 0) spawn Mca_fnc_onVehicleFueled; } ]; This makes the _this variable accessible in the EH scope directly.

This script won't work. You are creating a new independent scope with the spawn command and passing no arguments ( [] ) to the new function. Instead try this: _taskTargetObject addEventHandler  [ "fuel", { quest_giver globalChat "1"; (_this select 0) call Mca_fnc_onVehicleFueled; } ]; Or if you really have to spawn it: _taskTargetObject addEventHandler  [ "fuel", { _this spawn { quest_giver globalChat "1"; (_this select 0) call Mca_fnc_onVehicleFueled; } } ]; Btw there is no "sqs" in any of your scripts. What did you mean by that?

In the init line put this: TER_fnc_handleLoadout = { params ["_mode", "_this"]; params ["_target", "_caller"]; switch _mode do { case "save":{ _dbLoadouts = _target getVariable ["db_loadouts",[]]; _loadout = getUnitLoadout _caller; [_dbLoadouts, [getPlayerUID _caller, "loadout"], _loadout] call BIS_fnc_dbValueSet; _target setVariable ["db_loadouts", _dbLoadouts]; }; case "load":{ _dbLoadouts = _target getVariable ["db_loadouts", []]; _loadout = [_dbLoadouts, [getPlayerUID _caller, "loadout"]] call BIS_fnc_dbValueReturn; if (isNil "_loadout") exitWith { "No saved loadout found." remoteExec ["hint", _caller]; }; _caller setUnitLoadout _loadout; }; }; }; this addAction ["Save Gear",{ ["save", _this] remoteExec ["TER_fnc_handleLoadout", 2]; }]; this addAction ["Load Gear",{ ["load", _this] remoteExec ["TER_fnc_handleLoadout", 2]; }]; Tested on SP, Hosted-MP, Dedicated This script will save the loadouts to a scripted database (more info) and save that variable to the object the action is attached to. It is persistent as long as the server doesn't get shut down. The database is only available on the server.

Does it make any difference wether you are running a mission without the mods? I have a slight concern regarding AGC that it might delete vital modules.

Hey @jonpas (I hope the correct one), would you know more about it? GitHub says you might have some more insight 🙂

Yeah the command is called drawIcon3D and has to be used with an "Draw" eventhandler. Getting the rank of the player depends on how you know which rank the player has, eg database or score.

There is no UAV "item". It is only converted to the corresponding backpack after disassembly and vice versa.

That's interesting 😆. I did the math (for a fuel truck, assuming resources are liters): density(Diesel) = 0.84 g/cm^3 = 840 kg/m^3 volume = 10^12 l = 10^9 m^3 density = mass/volume <=> mass = density * volume mass = 840 kg/m^3 * 10^9 m^3 = 8.4 * 10^11 kg Or one fifth of the world's crude oil production in 2009.

The entire mission is available here: The script above does not assign an admin. This is done in another script and it also doesnt compare any UIDs but instead uses BIS_fnc_admin to assign a variable to the user which says if he is an admin: https://github.com/Xeno69/Domination/blob/master/co30_Domination.Altis/clientui/fn_scacheck.sqf // by Xeno //#define __DEBUG__ #define THIS_FILE "fn_scacheck.sqf" #include "..\x_setup.sqf" d_pisadminp = (isMultiplayer && {(call BIS_fnc_admin) > 1}) || {isServer}; This script is run continuesly on the client. As soon as he logs in as admin the variable gets updated. MAYBE this will work: // by Xeno //#define __DEBUG__ #define THIS_FILE "fn_scacheck.sqf" #include "..\x_setup.sqf" d_pisadminp = (isMultiplayer && {(call BIS_fnc_admin) > 1}) || {isServer} || (getPlayerUID player in ["1", "2", "3"]); Where 1, 2 and 3 are your admin UIDs.

Gotta check the units not the array: CK_Enemies = CK_Enemies select {alive _x};

Two possible reasons that I know of: Spawning units in general. Counting a huge array. Try removing dead units from it. That would also simplify the {alive _x} count CK_Enemies in the while do condition to count CK_Enemies. Set a variable to false in the while do condition. If it is from outside of the script then you'll have to use a global variable. Also instead of: { CK_Enemies pushBack _x; } foreach units _grp4; You can use: CK_Enemies append units _grp4;

Hmm that's not good. Next two ideas: Run the script on each client remotely with a createVehicleLocal object Attach the object to an invisible unit, let that unit move from point A to point B

Yeah the GUI Editor is an ancient piece of technology. It doesn't make use of the ctrlCreate command but rather has hundreds of controls stored in its config and as @gc8 said, they are identified via their IDC.