pierremgi

if you don't want to bother you with case sensitive switch do, there is a similar coding: call { if somethingTrue exitWith {fisrt Option Code}; if somethingElseTrue exiwith {secon dOption Code}; if .... exitwith ....; in Case Of: Default Code; }; Here exitwith just exit out of the call. There is a difference with switch do process, for default block, but imho this method is clearer.

This feature seems not implemented. If you edit the uav.fsm and requester.fsm, (in arma3\addons\module_f.pbo) you can see there is nothing to do with that.

The only interesting damages are given by getAllHitPointsDamage and transferred by setHitDamage or setHitIndex . If you pick damage to further apply setDamage , you'll never recover the former damage status, just applying an average of damage on each parts of the vehicle.

I can't reproduce that. Check for startPos eveywhere again. If sentinel takes velocity, that's because it's not touching ground (i.e. the deck). Check the positioning of your UAV by isTouchingGround command. (out of map cursorObject is always null, use cursorTarget or vehicle name). Normally, you can recover addAction on respawn because I scripted for that. I don't know (and I don't care) if it's compatible with other mods playing with menus. I'm scripting for Vanilla (+ vehicles mods like CUP or RHS), but in any case for ACE or exotic mods altering menus. I don't know if it's your case. It's just an info. I spent hours to test sentinel on carrier or ashore, with different pylons, so, except if you have a reproducible mission (or uploaded file), I can't help anymore.

Thanks for your feedback. The skin and loadout problem should be solved now. That was due to some blowing "at once" vehicles and my new performance saving EH. Please Try it now. When you write: 0 = [[veh1,veh2],["startpos"],10,true,false] spawn MGI_fnc_VehicleRespawn (I know you changed "start" for "startPos" everywhere, due to your scenario), that means veh1 will respawn on its start position, but veh2 will respawn by default on its death position. (unless you're writing ["startPos","startPos"]) So, 0 = [vehicles,vehicles apply {"start"},10,true,false] spawn MGI_fnc_VehicleRespawn just means that you apply to the array of vehicles, an array of "start" as parameter, with the same number of elements in array. You can even write something like: _arrayOfVeh = vehicles select {_x isKindOf "landVehicle"}+vehicles select {_x isKindOf "air"}; _arrayOfpos = (vehicles select {_x isKindOf "landVehicle"}) apply {"death"}+ (vehicles select {_x isKindOf "air"}) apply {"start"}; 0 = [_arrayOfVeh,_arrayOfPos,10,true,false] spawn MGI_fnc_VehicleRespawn if you want to respawn planes and helos on death positions and ground vehicles on start ones. Don't forget, spawned vehicles are not taken into account with this kind of line. You must do a loop or use side parameter for that (or use my advanced module, to be corrected soon).

Corrected for spawning vehicles on carrier at sea. + some improvements like helo ditching and in flight edited aircraft (already flying at mission's start). All feedback welcome. Some difficulties for respawning at death position an aircraft colliding with the ground (no previous damage). The solution needs some extra tests.

@dyrmoon You should try with allMissionObjects "explosion"

which mods? did you script something to add laser/light on weapon? did you check your files integrity in steam, arma in library, right click for properties, local files?

Hello. Welcome on forum. thisList is a special variable for triggers, which returned the objects (units/vehicles) satisfying the preset conditions (example BLUFOR present). You can use it in condition and on activation fields but not in on deactivation field where it doesn't mean anything. thisList select 0 is just the first object in the list (if any).

Sorry for the time difference. For MGI tactical pack, you can find the notice (pdf) in the addon folder, usually located in arma3\!workshop. On server the conditions are not often met, intentionally. I can pbo a specific mod, with a specific key for signature, so the server owner will have to accept it. For MGI advanced modules (signed also), the notice (WIP) is here, last module.

Interesting question and BI skipped that. I wrote somewhere it was a miss for the "Laws of war" DLC. Anyway, I edited 2 addons: -1st one is a simple "make prisoner", right clicking while aiming (temporary zoom), under certain conditions of course (see MGI Tactical pack); - 2nd one allows prisoners and escort to jail. (see MGI advanced modules). If I remember both aren't compatible each other. I'm aware, it's not a splendid behavior, but at least, that works in MP. Not so often feedback on that.

As Beno_83AU wrote: forgetTarget . That's the solution for your specific case.

Marker is a bad idea. I implemented that just in case you don't want to respawn at start or death positions. I'm about to fix this problem without extra workaround but I discover that ditching disabled helo (say a stationary Huron fired by a single Titan AA MPRL) don't fire the MEH "entityKilled" when the Huron sinks and becomes wreck. It's weird. Working around (one more time!) on a specific Arma behavior.

It seems to me that you can loose an helo at sea without triggering the MEH "entityKilled" I tried several landing at sea (ditching). The helo sink, becomes wreck and not alive but the MEH can't take that into account. For sure, maritime events are not at the best in Arma (even allowDamage false for player can't work in diving)

WIP. Lack of time.

Some mods?

Formerly, in these scripts, "start" is used as a string different from any marker, saying you want to use the initial position for respawning. "death" is also a specific string for respawning where the vehicle was destroyed/crashed. If your mod/script uses "start" as marker name, not my bad, the vehicle will respawn at this marker just because my script checks for any marker before other possibilities. So, if you have a marker named "start" and you want to respawn at initial position, the simplest workaround is to modify the script for reading another string, no matter which one, but you must be consistent, so change "start" by "anyNameYouLike" everywhere in the script. The result will be the same. If you read the "notice", a simple "anyNameYouLike" as parameter will be efficient for any vehicle to be respawned on its initial place. "start" (or "anyNameYouLike") and "death" are generic. No need to refer at one vehicle. Read the explanation.

Welcome text: Do what you want in initPlayerLocal.sqf Message for special key or other stuff: think about briefing (intel module: create diary record, in editor) At least, the player can read that when he wants. General message: waitUntil condition on server (initServer.sqf or init.sqf and if(isServer) then ....) ; then, as example, remoteExec hint, add JIP param (all details in BIKI).

You need to read some topics about MP. Your aim is easy but there are so much things to understand to make MP work properly. MP scripting Event scripts initialization order locality code optimization and most of their links, not mentioning extra knowledge to run it on a dedicated server. All players must have all the sqf files to be run. That's not a problem, they are loaded at start if your fellows discover the mission. For example, you host your mission and when people join they download the mission.sqm but also all the sqf paa ogg... folders if any. As a good habit, try to manage: - server things through specific sqfs that you can call from initserver.sqf - player things through initPlayerLocal.sqf A very good place to run a text for JIP without boring the others. - init.sqf is a common code for server and players. It runs at server start and alongside JIP. So its code can ruin (reset) your ongoing scenario by re-running some global effects and data. Same for all init fields of all objects/units in editor. That doesn't mean you can't use them but a server condition will be added most of the time. Keeping on mind when / where / why any code runs is mandatory. And where the results /effects occur also. One of the most powerful but probably hardest thing to understand is the remote execution. You can execute some codes remotely on other PCs. That doesn't mean you will send missing files like pictures or sounds, but you'll trigger some displays or events on whole or specific PCs. Start to read. Bis_fnc_MP is obsolete. Hard to resume. Have fun!

Anyway, if you spawn units, you can make them join an existing leader (edited or not), so they will follow his waypoints (if any). If you don't want to join an existing leader, you need to write your waypoints with the waypoint commands like addWaypoint... (see BIKI). I guess you are using Jebus and Gaia for that and you probably encounter some problems due to these codes. You should ask their authors. For checking some waypoint feature, enable the console and watch for waypoints yourGroup apply {[_x, waypointType _x]} Note: I never used the skip waypoint, totally useless as far as you can deleteWaypoint with a little code: waitUntil {someCondition before the waypoint is reached (check currentWaypoint)}; deleteWaypoint theWaypoint.

Imho, except if you have a multi CPU on your PC, there is no added value to run HC + player instances on the same PC. HC is made for discarding the CPU load (of the server), redistributing some AIs features on a remote PC. Are you sure you need to divert AIs calculations from server, to your PC already in charge of your player (+ your AI group + owned vehicle)? Not saying that you multiply broadcast data which need sync between server / HC / other clients.

You have choice between (works in SP/MP): the easiest: a simple trigger (not server only, no area), type #end1, with: allUnits findIf {side _x in [EAST,INDEPENDENT]} == -1 in condition field or, if you prefer a scripted way, in initServer.sqf: addMissionEventHandler ["EntityKilled", { if (allUnits findIf {side _x in [EAST,INDEPENDENT]} == -1) then {"EveryoneWon" call BIS_fnc_endMissionServer} }]; The second one is probably preferable, especially when you have plenty of units (>200). Note: But I'm not sure it's the most reliable. The MEH fires ONLY on each kill but what if a multiple final kills (enemy helo crash, without anymore unit to kill after that)? I don't know. You can just hope that the final MEH (several for crash) will meet the condition. This remark is just an intuition, not a proven tested fact. On the other hand, a trigger will check for the condition every 0.5 sec., no matter the "events". So, you have countless and regular opportunities to finally meet the condition.

Difficult to help more in this case. We don't even know if !alive is applied on spawned units... Without any more details about codes/reproducible scenario, the problem can hide anywhere. Just my 2 cents, I don't have any time to check Jebus + Gaia + your own mission. Sorry.

1. No need to remoteExec this addAction (keep that for applying an action on a spawned object/unit). just, in initPlayerLocal.sqf: akce1 = player addAction ["Označit pole", {deleteVehicle Pole1AddKoule;},[],1.5, true, true,"","<condition here>"]; player setUserActionText [akce1 , "Označit pole", "<img size='3' image='smoke3.paa'/>"]; 2. the condition field is enough to display/hide the addAction (which is not removed but ready to be displayed). Use preferably the specific local variable (see BIKI) "_this inArea actionTrigger" 3. So, it's weird to removeAction in this case. But... you need to think about respawning player who will loose all added action: add this code (in initPlayerLocal.sqf also): player addMPEventHandler ["MPRespawn", {params ["_plyr"]; _plyr addAction ["Označit pole", {deleteVehicle Pole1AddKoule;},[],1.5, true, true,"","_this inArea actionTrigger"]; player setUserActionText [akce1 , "Označit pole", "<img size='3' image='smoke3.paa'/>"]}] }]; Suggested whole code in initPlayerLocal.sqf: fn_akce1 = { akce1 = _this addAction ["Označit pole", {deleteVehicle Pole1AddKoule;},[],1.5, true, true,"","_this inArea actionTrigger"]; _this setUserActionText [akce1 , "Označit pole", "<img size='3' image='smoke3.paa'/>"]; }; player call fn_akce1; player addMPEventHandler ["MPRespawn", {params ["_plyr"]; _plyr call fn_akce1}]; 4. As you can see above, the trigger condition itself doesn't matter, you are using its area only. then, the addAction has its own condition related to the player in area of the trigger. This condition is neat but checked on each frame (instead of twice a second for a trigger). And your (action) code seems to be not repeatable (you delete an object without mentioning some re-creation). So, if you want more help, further questions are: - Do you need this trigger? is the trigger far from the deleted object? could you replace the trigger area condition by a simple distance to object? - why not applying the addAction to the object instead of the player (see also BIKI orange framed comment for conditions)? So, no need to think about respawning players.

Yes a trigger checks the condition every 0.5 sec. Using trigger or EH is OK. The problem here is to avoid a count inside an area as big as the map (so position related for nuts here). So forget the presence inside the trigger area, or a use of inArea inside the EH. Focus on global count: EAST countSide allUnits == 0 && INDEPENDENT countSide allUnits == 0 or better allUnits findIf {side group _x in [EAST,INDEPENDENT]} == -1