Grumpy Old Man

Titan AA from Cheetah? Sure they can. Left mouse button. Cheers

This. Points 2-10 are only speculation without seeing scripts and/or mission. Point 1 is irrelevant if there's funky stuff running in a while true loop without sleep (or similar). "Lagging" tasks and units not being placed inside vehicles sounds like there's something off. Try it without mods and see if the issue persists. Cheers

No way to grab this from the config, as far as I know. Try this: GOM_fnc_buildingsWithPositions = []; GOM_fnc_grabAllBuildingPositions = { _initTime = diag_tickTime; _allHouses = "configName _x isKindOf 'HouseBase'" configClasses (configFile >> "CfgVehicles") apply {configName _x}; _allHouses resize 50;//just for testing, delete this line if you want to check all houses systemChat str count _allHouses; _allHouses apply { _house = _x createVehicle [0,0,0]; _positions = _house buildingPos -1; if (count _positions >= 4) then {GOM_fnc_buildingsWithPositions pushBack _house}; deleteVehicle _house; }; copyToClipboard str GOM_fnc_buildingsWithPositions; systemchat format ["Data evaluated in %1s.",diag_tickTime - _initTime]; }; [] call GOM_fnc_grabAllBuildingPositions; Be aware this will take forever for around 900 vanilla buildings. If anyone else knows a way to grab building positions from config would be great to know... Edit: Run this once to get all valid buildings that have more than 3 positions, the array of building classnames will be stored in the clipboard, simply paste it to a file and define it as an array for later in game use. Cheers

Well all houses/buildings are vehicles, so you need to filter CfgVehicles accordingly: _allHouses = "configName _x isKindOf 'House'" configClasses (configFile >> "CfgVehicles"); You need to filter for either "House" or "Building", since one of them has positions, the other has not. You can also filter current objects on the map, in case you run with mods and don't want to spawn a mosque in Chernarus. Cheers

What are you trying to do? If you want to access building positions just use the buildingPos command, way faster than storing all buildings and positions in an array, if that's what you want to do. Cheers

Solution without triggers: GOM_fnc_chopperPickup = { params ["_unit","_chopper"]; _unit setVariable ["GOM_fnc_pickUpChopper",_chopper]; waitUntil {time > 1};//put your condition in here to make the chopper move towards the player _chopper move (_unit getPos [50 + random 50,random 360]);//this will move the chopper near the player within 50-100m waitUntil {_chopper distance2d _unit < 300}; //now the player can throw a smoke to mark the landing area hintC "Throw smoke to mark landing area!"; _unit addEventHandler ["Fired",{ params ["_unit", "_weapon", "_muzzle", "_mode", "_ammo", "_magazine", "_projectile", "_gunner"]; if (toUpper _ammo find "SMOKE" >= 0) then { _unit removeEventHandler ["Fired",_thisEventhandler]; hint "Smoke out!"; _chopper = _unit getVariable ["GOM_fnc_pickUpChopper",objNull]; _wait = [_chopper,_projectile] spawn { params ["_chopper","_projectile"]; waitUntil {vectorMagnitude velocityModelSpace _projectile < 0.01}; hintC "The Chopper will land now!"; //spawn landing pad at smoke position and make chopper land _pad = "Land_HelipadEmpty_F" createVehicle getPosATL _projectile; _pad setPosATL getPosATL _projectile;//just in case... doStop _chopper; _chopper land "GET IN"; waitUntil {_unit in crew _chopper}; //cancel the landing _chopper land "NONE"; _chopper move getPosATL _chopper; sleep 5; _chopper move [0,0,0];//position where the chopper should move to } } }] }; //to run the function: [player,chopper] spawn GOM_fnc_chopperPickup; Using waypoints can be funky sometimes, doing this with a simple script snippet is a bit more convenient. This will allow the player to mark the landingzone of the chopper by throwing a smoke grenade, chopper will land and wait for the player to board it with engines on, then will move to [0,0,0] once the player is in it, you can add your own position or whatever. Cheers

You can also put this into one addAction: GOM_earplugID = player addAction ["Earplugs Off",{ _plugState = missionNamespace getVariable ["GOM_fnc_plugState",false]; 1 fadeSound ([1,0.15] select _plugState); player setUserActionText [GOM_earplugID, ["Earplugs On","Earplugs Off"] select _plugState]; missionNamespace setVariable ["GOM_fnc_plugState",!_plugState]; },0,1,false,false,"","_target isEqualTo _this"]; Also I wouldn't use soundVolume for checks, since the returned value will not gradually change over time, it will immediately take the value set by fadeSound, no matter the time parameter. Cheers

Another thing to add to the systemchats all over the place mentioned by @TeTeT, I usually put in a function that's used to hand out debug info to either hint, systemchat and/or .rpt. Can be called from any function since it's initialized via preInit and has useful parameters: GOM_fnc_debugging = true; GOM_fnc_Debug = { params["_override","_output","_message"]; if (GOM_fnc_debugging OR _override) then { if (1 in _output) then {systemchat _message}; if (2 in _output) then {hintSilent _message}; if (3 in _output) then {diag_log _message}; }; }; //this way you can enable debug messages like this: _localDebugging = true; [_localDebugging,[1,3],format ["Error in %1",_fileName]] call GOM_fnc_Debug; //will print the error in filename message in systemchat and .rpt log if GOM_fnc_debugging is set to true GOM_fnc_debugging = false; [_localDebugging,[1,3],format ["Error in %1",_fileName]] call GOM_fnc_Debug; //will print the error in filename message in systemchat and .rpt log only if the local debugging flag is set to true Just made this out of memory, the real function is a bit too intertwined with other stuff from my library but should give anyone a better idea on useful debugging stuff. Pretty much the backbone and mandatory for medium+ sized projects. Cheers

Forum can be funky sometimes, especially when multitabbing and writing in various tabs at once (and even 2+ browser instances). Had posts end up in other threads at least 2 times. Cheers

Been there, on my own stuff. Involved various functions spread all over the place. Wasn't much of a problem when working on it, coming back to this mess after a 6 month break on the other hand made me just start from scratch again, heh. Cheers

I usually keep stuff split by functionality/content as much as possible. Stuff that should be tweaked goes to a separate file into mission root for ease of access, like multipliers for enemy units, customizable parameters etc. data related stuff also goes to a separate file inside /script/GOM/something, like unit loadouts, arrays of positions etc. Then I put everything that's CPU intensive into pre/postInit calls where possible. Helps keeping things in order, especially when you reach a total of 150+ .sqf files, heh. That's about it. Cheers

Here's how you can do a simple time based lockout: test addEventHandler ["Firednear", {[_this select 0] call Frog_Roll}]; Frog_Roll = { params ["_target","_shooter"]; _lockoutTime = 5; _lastLockout = _target getVariable ["GOM_fnc_lockout",-_lockoutTime];//so it returns -5 as default, initially enabling the roll if (time < _lastLockout + _lockoutTime) exitWith {false}; //at this point the last lockout was more than 5 seconds ago, so we save the current lockout time on the unit, then roll _target setVariable ["GOM_fnc_lockout",time,true]; _rolls = selectRandom ["amovppnemstpsraswrfldnon_amovppnemevaslowwrfldr","amovppnemstpsraswrfldnon_amovppnemevaslowwrfldl"]; _target switchmove "amovppnemstpsraswrfldnon_amovppnemevaslowwrfldr"; }; Pretty straightforward, heh. Cheers

@HazJ how are you running the setVariable one for 0.0007ms? Do I really need to upgrade my CPU already? Heh... Cheers

Just for the curious: missionNamespace setVariable ["abc", 123];//0.001ms call compile format ["%1 = %2", "abc", 123];//0.0025ms Performance loss is kinda given. Some other reason for not using call compile format, in terms of sending code via network, though a bit unrelated to this topic. Cheers

Like @pierremgi stated, waiting for an escape keydown event might be the most fitting solution. Alternatively you could make it so players can only save gear at specific locations/objects, though that might not be suited depending on mission type. Cheers

Try getClientState, works on dedicated as well. Cheers

It's not, the in command doesn't care about upper/lower case, case sensitivity is only needed for comparing strings: "test" in ["Test","TEST"];//false "Test" in ["Test","TEST"];//true In the example made by the thread author there's no case sensitivity involved: (player in thisList) || (heli_1 in thisList) || (heli_4 in thisList) //same as (pLaYeR in thisList) || (hElI_1 in thisList) || (HeLi_4 in thisList) Cheers

No need for remoteExec addAction in SP, should be fine. Cheers

That's handled inside the executed code by addAction, which receives parameters on its own: GOM_fnc_respawnBoat = { params ["_oldBoat","_respawnedBoat"];//these parameters are passed by the respawn module _respawnedBoat addAction ["All into the boat",{ params ["_target", "_caller", "_actionId", "_arguments"];//these parameters are passed by the addAction /* _target will be the boat object, _caller the player who activated the action */ }]; }; Something like this. You'd probably need to remoteExec the addAction so that every player can see the action in MP. Cheers

You can do it all inside the respawn modules edit window. In the modules init field you can define the function, like this: GOM_boatRespawn = {systemchat str _this}; The modules init field will run on every machine, even on JIP so this is a convenient way to initialize the function that should run on respawn. Then in the expression field simply put: call GOM_boatRespawn This will execute GOM_boatRespawn when the vehicle is destroyed, and print the passed parameters into the systemchat as defined by the function. No need to name the boat or anything for the matter. That's really all there is to it. Cheers

As mentioned by @davidoss and @HazJ, the GetInMan EH is your best bet. The most important thing here is, that when entering a vehicle while holding the forward key, the GetInMan EH will fire before the player gets control over the vehicle, so the engine won't turn on and the vehicle won't start moving. Same goes for the vehicle GetIn EH. Quick example: player addEventhandler ["GetInMan",{moveout player}]; Cheers

Not getting your error, returns true just fine, make sure you're correctly writing either array1 or _array1 and don't forget the semicolons, heh. The arrayIntersect solution posted by @Schatten seems to be the best solution. Cheers

Ah well, can't have enough texture-changing commands, I guess. Cheers

Just tested my snippet above, doesn't work ingame, during mission runtime, as requested by @purzel. Maybe there's a workaround, no idea for now. Cheers

BI naming convention strikes again, setWeaponReloadingTime doesn't do what the name implies at a first glance, same for playerViewChanged EH (which still confuses the heck out of me how BI came up with that name considering the functionality of the EH, go figure). setWeaponReloadingTime only affects reloading single rounds, not magazines. Check the comments on the page for further info. Cheers