theend3r

Member
  • Content count

    314
  • Joined

  • Last visited

  • Medals

Community Reputation

51 Excellent

2 Followers

About theend3r

Recent Profile Visitors

220 profile views
  1. heli1 addEventHandler ["Engine", {if (_this select 1) then {(_this select 0) engineOn false}}]
  2. Change waitUntil {sleep 5; {alive _x} count [DMSK_enemyVeh1, DMSK_enemyVeh2, DMSK_enemyVeh3, DMSK_enemyVeh4] == 0}; to waitUntil {sleep 5; {{alive _x} count (crew _x) > 0} count [DMSK_enemyVeh1, DMSK_enemyVeh2, DMSK_enemyVeh3, DMSK_enemyVeh4] isEqualTo 0};
  3. Yes, that's correct. _something means it's local and that wouldn't work here Also, I made a mistake there, it needs typeOf to work player addEventHandler ["GetInMan", {if (typeOf (_this select 2) in mortars) then {[_this select 0] execVM "script.sqf"}}];
  4. https://community.bistudio.com/wiki/engineOn move waypoint with condition/hold waypoint at the location of the helicopter https://community.bistudio.com/wiki/land (didn't test for preventing startup)
  5. I was disabling FSM to stop the units from behaving retardedly like... Arma units but it stopped them from moving completely, no idea why. I needed them to run from A to B but I gave up. Making units do that is impossible in Arma.
  6. The wiki has it all, surprisingly : https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#GetInMan https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#GetOutMan mortars = ["mortar_class_1","mortar_class_2","mortar_class_3"...]; player addEventHandler ["GetInMan", {if (_this select 2 in mortars) then {[_this select 0] execVM "script.sqf"}}];
  7. Yes, you're right in both cases. The call shouldn't be there in my example and since you use object init then you need to predefine the function in a config, true. I got confused as I never use object init fields (except for singular unique objects) since it's generally a bad practice as it's a pain to change them. It's better to do everything from (server)init.sqf by collecting whatever you need in an array and working with it from there.
  8. That's the same thing, just checking if the player is inside and spawning emitters around the bounding box of the model one time and not continually seems more intuitive.
  9. You don't need that config at all, you can preprocess any file. fnc_bgs = call compile preprocessFile "bgs.sqf" is the same as fnc_bgs = {script contents of bgs.sqf}, it reads from a file and defines it as a function. Just do what I wrote above and it should work. But yes, your approach should work, too, but I like short fucntion names and a description.ext as short as possible.
  10. What kinda bridges are we talking about here? I though most bringes are very short. If you want to force a vehicle over super long bridges then you need to get the positions of two bridge segments (and invert it according to the way the vehicle is going, i.e. the velocity vector of the vehicle) and force that dir (so no adding velocity but hard setting of velocity).
  11. A particle newbie here, why do you continuously delete and respawn the particle emitter? Why not just move it with the player and check for conditions?
  12. I've seen this video so many times but it's still amazing.
  13. In the initServer.sqf or anywhere that runs only once and before you need to use the function.
  14. You only call that once. //init or preInit I guess fnc_bgs = call compile preprocessFile "bgs.sqf" //then each time exec by [unit name, "faction", "role"] call fnc_bgs