pierremgi

Not sure what you intend to do but, as general considerations: - in MP, addAction on object can have different behavior if object is owned by the server (empty vehicle at start for example), or owned by one player (player driving the vehicle). You should have to remoteExec the code; - anyway, the sound will not move with the vehicle.

At least, the nearestTerrainObjects is more useful for returning "HOUSE" objects. (as example easy to check on Vanilla ARMA). Just test it! NearestObjects returns far more objects, which couldn't be taken for HOUSE in real world, like every runway lamps... and much more. It's far more consistent for what you're waiting for, with nearestTerrainObjects HOUSE. On the other hands, you can find some objects detected by nearestTerrainObjects HOUSE and not by nearestObjects HOUSE, like cargo20_grey_f.p3d. (explanation seems to be in the BIKI page and reported here at the end). Now, about placed objects via editor, still using HOUSE with both commands, placing 2 or 3 similar airport towers (next to Stratis airfield) within the airport area, nearestTerrainObjects will fail to detect the added towers (detect only the map embedded one) meanwhile nearestObjects will included all of them within the same radius. The BI documentation is not very clear about that. You can even think the contrary after reading: " In contrast to nearestObjects this command [nearestTerrainObjects] returns terrain placed objects like trees, rocks and buildings which don't necessarily need an associated config class.

Please, could you explain what could be the difference between: private _spawnthisnade = ""; and _spawnthisnade = ""; Thanks.

You can try also, in the init field of a player: if (isServer) then {this setVariable ["loadOut",getUnitLoadout this]; this addEventHandler ["respawn",{(_this select 0) setUnitLoadout ((_this select 0) getVariable "loadOut")}]}; Read the BIKI page. They are some limitations with some "dynamic" backpacks. NB1: you can add some code in event handler to remove the gear on dead: removeAllWeapons (_this select1); .. and so on. NB2: For thus who would like to respawn with the same amount of ammos in each mags, at death, and clean the corpse, here is my script.

Not sure that assigning the vehicle is the best solution in case of shift or respawn or else. What you can do is to set a variable for the vehicle when spawned: _veh setVariable ["creator", _thisPlayer]; then, you can delete it: {deleteVehicle _X} forEach (vehicles select {_x getVariable "creator" == _thisPlayer});

Thanks Grumpy. I just forgot displayAddEventHandler was an UI EH. I focused on UI in IngameSetUIEH... I lost my Latin in all these action/inputaction, UI EH, display's and so on. Even if I already scripted some lines with that !

No error here as far. You're probably execVM something else with this script.

So, what fires your trigger? I don't understand how you can have a disabled RED unit already inside the trigger without firing at start. I don't understand the chronology of your trigger and when thislist works for the truck.

Which one? It's not an action "in menu" like "disassemble". "Watch" or "WatchToggle" aren't detected by the ingameUISetEH "action", if I'm right. Neither "rearm"... I don't know how to say that in English but input actions (UI EH "action" doesn't fire) seem to me different from Arma 3 actions (UI EH "action" fires).

{_x enableSimulationGlobal true;} forEach thisList; Some questions - if OPFOR presence triggers, so what is the result of thislist ? You don't mention what is the side of the truck. - the enableSimulationGlobal works well for me. So verify thisList. Make the trigger on server only. - as far as the sim is disabled then enabled, you don't need to add a condition in the first waypoint (what for?)

You need 2 triggers with area for presence (blufor present): - one immediate, say trg1, for the kill of the officer: In cond field: this && !alive officer1 - one delayed with a timeOut (check with 30 sec but works for 300), say tgr2 : in cond field : this add a 3rd trigger in cond. field : triggerActivated trg1 or triggerActivated trg2 link it to a task state module "succeeded" link the state module to the task module (created or assigned).

You need to spawn a "groundWeaponHolder" (a sort of invisible recipient), instead of your grenades. Then fill it with your grenade (addItemCargoGlobal does the job).

Place a simple trigger. set fuel to 0 for the tank in editor . When your trigger is activated (server only, it'sbetter): tank1 setfuel 1;

You need 2 triggers with area for presence (blufor present): - one immediate, say trg1, for the kill of the officer: In cond field: this && !alive officer1 - one delayed with a timeOut (check with 30 sec but works for 300), say tgr2 : in cond field : this add a 3rd trigger in cond. field : triggerActivated trg1 or triggerActivated trg2 link it to a task state module "succeeded" link the state module to the task module (created or assigned).

Read the last Seafood post. It works perfectly. You don't need any trigger. Just a workable "respawn_something" marker (or respawn module), the respawn attributes on "custom position", and the (_this select 0) in EH to be sure you're selecting the new player and not the corpse! just add the isServer condition: if (isServer) then {this addEventhandler ["respawn", {jet1 = createVehicle ["B_Plane_CAS_01_F", getMarkerPos "respawnmarker1", [], 1000, "FLY"]; (_this select 0) moveInDriver jet1}]}

Don't write anything in description.ext for respawn. Just use the editor multiplayers menu. The mix of two is weird. Test furthermore: - 2 respawn points; - choice of the respawn position (editor menu).

Ah ok. In a player's init field, you must refer to this (global variable) not to _this, which is a local one, not acceptable in this context. But you can do: this spawn {_unit = _this; <any code with _unit>} . Not useful for an EH, but for any code with scheduled sequence like sleep, waitUntil...

Not exactly. EH passes default parameters. So, an array for _this, anyway.

Your face must be declared in cfgFaces, referring to a file in an addon. Then, use setFace command in init field of the unit. RemoteExec it from server. Here is the example from BIKI page: if (isServer) then {[this, "AsianHead_A3_02"] remoteExec ["setFace", 0, this]};

Mine is working quickly on any map (no need to have declared hill locations), any radius, without any repeated BIS function.

What map?

Just math: MGI_elevatedCheck = compileFinal " _posHigh = _this select 0; _posTest = ATLtoASL _posHigh; _radius = _this select 1; if (_radius == worldSize) then { _posTest = ASLtoATL [worldSize/2,worldSize/2,0]; _radius = worldSize /2 }; _rangeSqr = MGI_range^2; _bestHigh = _posTest select 2; _n = (round _radius) min (worldSize / 10); _c = _radius / (sqrt (_n - 1)); for '_i' from _n to 0 step -1 do { _rho = _c * sqrt (_i + 0.5); _theta = 137.508 * (_i + 0.5); _ckPos = _posTest getPos [_rho,_theta]; call { if (_ckPos distanceSqr MGI_posRef > _rangeSqr) exitWith {}; if ((getTerrainHeightASL _ckPos) > _bestHigh) exitWith { _posHigh = ASLtoATL _ckPos; _bestHigh = getTerrainHeightASL _ckPos }; }; }; _posHigh "; MGI_HighestPt = { params [["_pos",[0,0,0]],["_range",worldSize]]; MGI_posRef = _pos; MGI_range = _range; _posHigh = [_pos,_range] call MGI_elevatedCheck; _posHigh = [_posHigh,_range /10] call MGI_elevatedCheck; _posHigh }; _highestPt = [<any position here>,<radius> (optional)] call MGI_HighestPt;

My bad! thisList is updated. It's just the fact that a script in on act. is not a loop which leads to an instant picture of thisList. So you can use an updated thislist in a loop (on act. only) or through a "on act./on deact." process. Just a point: On my mind, there is no way to access thisList before the condition is met... It seems evident, but that makes difference with a deactivated (after activated) trigger.The script has it's own life even after the trigger's deactivation.

Without any interest for multiplayer missions.

disregard. No mean found.