Grumpy Old Man

No need to use switch or if statements, you also don't need to use + or pushback to add elements to an empty array if all you want is to filter an already existing array for certain criteria. The select command is your friend: _allowedColors = ["colorgrey","colorred","colorguer"];//important to type these all in lowercase for the check to work _filteredMarkers = allmapmarkers select {toLower getMarkerColor _x in _allowedColors}; When checking for strings it's important to put both strings into the same case, I'm sure that's one reason your check is failing, since the markers color could be defined as "colorRed", so checking for "colorRED" will fail since string comparison is case sensitive. In that case a simple systemChat will do, no need for format, since markers and marker colors are already supposed to be strings and will throw an appropriate error message if something went wrong. Cheers

Sure, updated the first link in my post above. Cheers

Sure, as long as you give credit and document any changes made to the original files. Cheers

Sure it's possible, depends on how you want to implement it though. Since you could blacklist either entire vehicle classes, only certain named objects, objects that hold a lockout variable etc. Better to implement it the way you want it to work, there's not really a one in all solution for this. Cheers

You can also use _this = this execVM "scripts\jetFixer.sqf"; instead. When using params inside the .sqf there should be functionally no difference. See example 2 on the wiki: [123] call { params ["_myvar"]; }; // Below would produce the same result as above 123 call { params ["_myvar"]; }; Cheers

That's because you don't pass anything into the execVMed script, the first parameter is mandatory if you want to pass stuff inside the scope of a called/spawned/execVMed snippet. Depends on were you're using this line, in the objects init field it could be something like this: //jet init field _this = this execVM "scripts\jetFixer.sqf"; Also use params to declare passed variables inside a scope, like this: params ["_veh"]; if (((getPosATL _veh # 2) < 10) && ((speed _veh) == 0)) then { hint "Stay parked for 10 seconds to fix your jet."; sleep 10; _veh setDamage 0; _veh setFuel 1; _veh setAmmo 1; hint "Your jet has been fixed, you are ready for takeoff!"; }; Also fixed the missing bracket and a possible oversight with getPosATL (I believe you want the altitude be below 10). Not tested but should do the trick. Cheers

An if statement always requires the basic syntax of if () then {}. You're missing the "then" part. Also check those round brackets, they don't add up. Cheers

Show the entire thing you tried, since the snippet posted by me still works fine. The snippet you posted doesn't do anything to the fuel storage, it just returns an array of objects holding fuel cargo. Cheers

Hey, just saw the PM and gonna post here in case anyone else might want to do the same. You can tweak the detection range in scripts\GOM\functions\GOM_fnc_aircraftLoadoutInit.sqf within GOM_fnc_aircraftLoadoutResourcesCheck line 1687 and within GOM_fnc_updateVehiclesLB line 1952, 50 is default value, adjust this value in both lines to your needs. Cheers

Try using an MPHit EH (with addMPEventhandler command) and use animateSource instead animate and ditch the remoteExec. From a quick glance at your snippet this might solve the issue. Cheers

Can't find the thread anymore but something similar has already been requested. This will play a predefined song with an object as sound source, wait until it's done and add the action again, should work fine in MP: //radio repeatable action //init.sqf TAG_fnc_radioSong = { params ["_object","_caller","_ID"]; _object removeAction _ID; [_object,"ivean_polkka"] remoteExec ["say3d",0]; sleep 144; _object AddAction ["Play Polka again", {_this spawn TAG_fnc_radioSong}]; [_object,["Play Polka again", {_this spawn TAG_fnc_radioSong}]] remoteExec ["addAction",0]; }; //radio init field [this,["Play Polka", {_this spawn TAG_fnc_radioSong}]] remoteExec ["addAction",0]; If you want a vehicle/object to be the sound source, then the snippet above should do the trick. Cheers

This is revealed in the respective entry. Cheers

Medical supply vehicles seem to be an exception considering there's no respective config entry similar to transportAmmo/transportRepair etc. According to the wiki it's the attendant config entry. Cheers

No clue what you're on about, that snippet makes no sense, _arr is nowhere defined and why are you storing player points as marker text just to parse it? Are you alright? Cheers

Hard to tell from the info you're giving, since there's a few ways to solve locality. You can handle the addAction functions on the server and broadcast them to player clients, or you can put anything addAction related into initPlayerLocal.sqf, so every player gets his own addAction without the need to use remoteExec etc. Cheers

If the vehicle returns anything but -1 from the respective getter commands it should work. As in: getFuelCargo YourVehicle;//returns -1 -> can't add fuel cargo using setFuelCargo command When a vehicle is configured for ammo, fuel, repair and medical cargo then you can refill it, Vehicles that don't have the config for it can't be modified that way unfortunately. You could probably fake it with attaching an invisible supply vehicle attached or similar, doubt it's worth the effort. Cheers

Alternatively one could handle stuff like this entirely on server and only broadcast points when needed. Cheers

That's because your "Players_Points" is undefined, most likely, try this: _playerPoints = _x getVariable ["Players_Points",0]; Will return 0 if the player doesn't have the variable set, otherwise it will return the proper points. Cheers

If you're not doing anything in the else part of the if statement, just leave it out. Also don't confuse any of the brackets and use a script editing program with sqf syntax highlighting to avoid those errors in the future. Can recommend Poseidon which has all the functionality you could ever want. When working with booleans you can easily get rid of if then checks when all you want is a simple state switch from true to false, same for the if condition. When checking for a variable that contains boolean you can simply use the variable, no need to compare it to bool like this: //bad practice _something = true; if (_something == true) then { //stuff }; //way better _something = true; if (_something) then { //stuff }; I can see no point in checking the "var_lk_noncom" variable, since it does exactly the same as a captive check, unless I'm missing something. _wArray = weapons player; _hints = ["You are a Combatant!","You are a non-Combatant!"]; _state = (_wArray isEqualTo []); player setCaptive _state; hint str (_hints select _state); //will set player captive when no weapons are found, also displays appropriate hint No point in arguing about spamming setCaptive command since, as you stated, this snippet will run from initPlayerLocal.sqf it will only run once. If you plan on putting this inside an inventory EH like "Take" then you can simply check if the object taken is of a weapon category and then run your captive snippet. Using engine script commands is always preferred to using remoteExec or other means, especially when a command already is argument local, effect global, like setCaptive. Cheers

That's because you're not using the proper syntax, default data type expects an array of data types, in your second example you leave out the faulty syntax, so of course it works. This should work: params [["_side",west,[sideUnknown]]]; And hence this: test = [east] call { params [["_side",west,[sideUnknown]]]; _side }; should hold east side in "test" variable. Cheers

What about using the containerOpened EH to wait 2 seconds, then arm all passengers of the car with handguns/SMGs and let them jump out using reveal command for further fun? This way the players have to get rid of attackers, the vehicle will no longer be occupied by opposing forces and is available to be inspected again. Cheers

You're out of luck if those commands really don't work. Unless there's something you're doing wrong, just food for thought. Cheers

That's a 7+ years old CPU and a budget GPU. Why are you surprised with the fps you're getting from the components you mentioned? Also consider posting in the already existing hardware thread. Cheers

Well you can draw an icon over the door as long as it's locked, @Larrow posted a neat snippet that does this: Once the key has been found you can simply remove the draw eventhandler like this: TAG_fnc_drawLockIconID = addMissionEventHandler [ "Draw3D", {/*stuff*/}]; //then once the player picks up the lock item: removeMissionEventHandler ["Draw3D", TAG_fnc_drawLockIconID]; You can also display a text hint instead of the icon. Cheers

AI with Mk14 will engage at around 500m distance, maybe your target is just a few meters beyond that distance, when testing with AAF sniper with default GM6 Lynx at 800m he's one shotting one target after the other with using a simple "sn reveal en1". Play around a bit with weapons, distances and see what works. For multiple targets you could use something like this: //init.sqf or wherever you seem fit _sniper = sn; _targets = [en1,en2,en3]; _sniper setVariable ["TAG_fnc_targetList",_targets]; { _x addEventHandler ["Killed",{ params ["_killed","_killer"]; _targets = _killer getVariable ["TAG_fnc_targetList",[]]; _targets = _targets - [_killed]; _killer setVariable ["TAG_fnc_targetList",_targets]; if (_targets isEqualTo []) exitWith {true}; _killer reveal [_targets#0,4]; }] } forEach _targets; sn reveal [en1,4]; Every time the sniper kills a specified target, the next one will be revealed. I personally wouldn't use doTarget or anything similar, since the AI knows better which targets they can currently engage etc. Cheers