Chuggacharles

Apologies i didn't read your post properly. That might be a problem with the syntax of execVM, your example may be trying to use execVM as an argument rather than the filename. Try this: [[], "myScript.sqf"] remoteExec ["execVM", 2];

When the mission is ending you could either use remoteExec to execute a script/command only on the server by setting the targets argument to 2, or you could use isServer to check in an if statement whether the current machine is a server, and the if statement will only be true on the server. You might also be interested in exit.sqf just keep in mind this is run on all clients so you will have to use one of the two options above if you put it in exit.sqf,

No, the problem is with setVariable. profileNamespace setVariable ["GW_scoreData_NS", GW_scoreData, true]; The third argument is optional and determines whether the server will broadcast the variable publicly to all clients after it is made. The problem is profileNamespace variables can't be broadcast, so instead of using the third argument, when you want players to receive the GW_scoreData_NS value, you just broadcast GW_scoreData instead because they should be the same value like so: GW_scoreData = profileNamespace getVariable ["GW_scoreData_NS", 0]; GW_scoreData = GW_scoreData + 1; publicVariable "GW_scoreData"; //GW_scoreData is broadcast to all clients sleep 0.2; profileNamespace setVariable ["GW_scoreData_NS", GW_scoreData]; //GW_scoreData is used to set the value of GW_scoreData_NS, both variables contain equal values //instead of profileNamespace setVariable ["GW_scoreData_NS", GW_scoreData, true];

profileNamespace variables can't be broadcast, since GW_scoreData is the same value as GW_scoreData_NS anyway, you might as well just broadcast that instead.

Apologies for the missing bracket! If you use notepad++ you can install a SQF syntax plugin which should make reading code a little easier.

I can't speak for customising ACE Arsenal but i can shed some light on how you can determine a players role. If your roles are static all the time then you could just go through the simple process of setting the units var name in the editor, and using that to determine their arsenal options. But assuming you need a slightly more dynamic approach then so long as your base roles are from the vanilla game it is pretty easy to do. Every units config should contain an entry called role, so all you would need to do is get this entry. e.g: _classname = typeOf player; _role = [configfile >> "CfgVehicles" >> _classname, "role", ""] call BIS_fnc_returnConfigEntry; This will get the classname of the players unit and then return its role. The problems start when you try to use this approach with modded units, as even some of the most polished and otherwise excellent mods (e.g CUP and RHS) have neglected to edit this entry for their units leaving all of them with a 'rifleman' role. My personal work around for this is to check both the classname of the object and the display name to see if it contains common keywords e.g 'MG' and 'Machine' for Machine Gunners (If anyone has a better solution to this i would be very interested in hearing about it) This is less than ideal however, so unless you have a reason to use modded units that don't have these entries defined, then i would avoid it. If your roles are static all the time then you can also just go through the much simpler process of setting the units var name in the editor, and using that to determine their arsenal options. You should be able to use a similar concept if you need to get specific types of weapon but instead you probably be best off checking the config parents of the weapon with either isKindOf or BIS_fnc_returnParents Hope that helps a bit!

The _magsleft variable syntax is incorrect. _magsleft = (_x == _newMagazine) count (magazines _unit); Firstly, because _x == _newMagazine is a condition check, which checks to see if code returns true or false, it needs to be enclosed in curly brackets to denote that it is code like so: _magsleft = {_x == _newMagazine} count (magazines _unit); This script will only count magazines if they are equal to _newMagazine. However this also won't work because magazines returns an array of classnames of each magazine the unit holds, but _newMagazines returns an array of information about the individual magazine. So instead you want to get the classname from the _newMagazine array, which is located at index 0. _magsleft = {_x == (_newMagazine select 0)} count (magazines _unit); _newMagazine select 0 gets the classname from the _newMagazine array, which is then compared to _x , if the classnames match then it will be added to the counter.

The if statement i posted above only creates the variable if the variable doesn't exist in the specified namespace already, so it won't reset. When you want the score to reset to 0 all you need to do is add a check somewhere to test if either team has reached 3 point and then use setVariable again to make the value 0.

You should be able to do this pretty easily by setting the variable in the serverNamespace. e.g //initServer.sqf if (isNil {serverNamespace getVariable "scoreCounter"}) then { serverNamespace setVariable ["scoreCounter", 0] }; As this has to be run on the server, naturally you will have to broadcast the value of the variable to all clients whenever they need to access/view it. You will also have to update the variable again with setVariable every time you want to modify it. Alternatively if you wanted the variable to last across multiple game sessions you could use profileNamespace. I've never used either myself so i'm not aware of whether there are any pitfalls to this but this should work for your purposes. https://community.bistudio.com/wiki/Namespace

I was speaking generally, for any array where you want to check if something is in the array, findIf is faster because it stops as soon as it finds the thing it's looking for. If you only want to execute code when a vehicle is empty, there's no point checking the rest of the elements if you have already found at least one living unit in the vehicle. It won't make much of a performance difference in the example above because the findIf command is only being used for the crew array, which is likely to be small anyway but it's probably good practice to get into the habit of using findIf when possible. Otherwise deleteVehicleCrew _x should be faster than using deleteVehicle _x on each crew member and vehicles select {side _x == east or side _x == independent} is hopefully faster than nearestObjects. (Though these are educated guesses)

You can also use this which should be more efficient: { if ((crew _x) findIf {alive _x} != -1) then { deleteVehicleCrew _x; deleteVehicle _x; }; } forEach (vehicles select {side _x == east or side _x == independent}); findIf is a better alternative to count where you're just checking for the presence of something as it stops iterating as soon as it finds something that meets the condition whereas count will continue untill it reaches the end of the array.

So long as you're getting your original position from an object you can very easily do this with getRelPos: this addAction ["Teleport Central",{player setPos (pb2 getRelPos [1, (random 360)]}]; This will get a position 1m away from the object in a random direction. If there's a particular reason you need to use ATL then you'll have to go about converting the position to ATL as getRelPos will return AGL, but that shouldn't be difficult.

I'm not familiar with the technical side of how ACE does its weight system but are you sure this isn't something you can get from config files? I notice that magazines have two sub-config entries for mass and weight, assuming mass is the correct value you need, then you should be able to use something like this to retrieve it: _magMass = [configfile >> "CfgMagazines" >> (secondaryMag), "mass"] call BIS_fnc_returnConfigEntry; From what i understand of the ACEfunction, its weight values are based on this number so you should be able to use this as a starting point at least.

No problem! Removing the action on all clients should be quite simple, you just need to retrieve the actionID and then remove it locally again on each players machine. The easiest way to do this would probably be to move BIS_fnc_holdActionAdd to its own script file and execVM it from remoteExec like so: "tskAction.sqf" remoteExec ["execVM", 0,true]; Inside tskAction.sqf would be the BIS_fnc_holdActionAdd but instead you call it and assign it a variable e.g: tskActionID = [//whatever params you have] call BIS_fnc_holdActionAdd; This variable will then return the actionID which you can refer to in order to remove the action, such as by adding this to the script that runs when the action is complete: [player, tskActionID] remoteExec ["removeAction", 0, true]; I can't guarantee that this will work as expected with JIP players as i haven't messed around with that much myself but this should at least provide a start! Also if removeAction doesn't work try: [player, tskActionID] remoteExec ["BIS_fnc_holdActionRemove", 0, true];

I think the issue is most likely that that the action you are adding is local to each client, and so the script that runs upon the action being completed or interrupted etc is also run locally. This would not be a problem except that the functions refer to the 'tsk' variable which only exists on the server and does not exist on the players machine. You therefore need to make 'tsk' public like so: tsk = format ["tsk%1", random 100]; publicVariable "tsk"; If this is what's occuring, you should also be aware that any other script that any of your scripts that are being called from the action with execVM are also being run locally, you should make sure if you don't want them to run on a players machine, that they are remoteExec'd on the server, and similarly if you want all machines or clients to run those scripts you should remoteExec them appropriately as well.