Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

  • Medals

Everything posted by pierremgi

  1. The initial value(s) can be on server (initServer.sqf) and publicVariable for clients. This way, the initial value(s) are not reset by JIP (they don't run initServer.sqf) On the other hand, when a player changes for other values (addAction or menu), these new values must be updated by publicVariable command also. In this case, the values are updated everywhere, so for JIP also. missionNameSpace setVariable ["yourVar", yourValue ,TRUE] is also a good way for broadcasting yourVar variable everywhere (so make it public and JIP compatible)
  2. trigger's condition is checked every 0.5 sec by default. Since 20.6, you can modify this parameter in editor. AnyPlayer present is a "preset" condition for this as specific variable. When the condition is met, you can use thisList in on activation field of the trigger. ThisList is always an array, here with all players who fired the trigger. Usually, it's quite impossible to have 2 or more players entering the trigger's area (so the condition) during the same 0.5 sec slot... but not impossible. Anyway, just pick (thisList select 0) as 1st player (even if the order is not guaranteed).
  3. wow! some basics: - local machine: player's PC (or server) but local variables are variables defined in a scope (so locally on PC and locally on (part of) script. - global can refer to all PCs (like commands ending by global as setTextureGlobal) but global variables (like your cam1) means "known by all scripts of the scenario on the PC(s)". If multiple PCs, each global variable, like cam1 has its own "life", i.e. there is no broadcast for value - public is a term for variables (roughly) and that's a way for making a variable "common". There are 2 ways: * using setVariable command with the 3rd parameter set tot true (see BIKI) * using publicVariable command EACH TIME the variable changes and must be updated for everyone. For script/code, we are speaking about remote execution or not (remoteExec command). Usually, it's easy to remote exec a command if needed. That depends on: - its argument(s). They can be local, global, server only... The need depends on the locality they apply. An example: allowDamage is a AL EG command. That means: must be applied where the unit is local, effects are global, so for everyone. As you can test, the (poor) option for disabling damage in editor worth in SP , or in MP on players. Just because such units, once played, change their locality (played unit is local to a client) , so your invincible unit will be killed. Such AL EG command "dislike" the shift of unit's owner. - on the other hand, a EL command like camSetFOV (AL EL) will give effects only locally. (Not a reason for remoteExecuting it, just think about same settings produce same effects) - there are other possibilities for commands: AG EG.. AL EG SE... Always refer to BIKI. For example it's a bad idea remoteExecuting setObjectTextureGlobal, already shared.Read BIKI links for details. - Last but not least, do not remote execute sqf or function unless that meets every argument and effect requirements (usually not the case). So, I suggest you to script yours codes in initPLayerLocal.sqf (means for each player) when a player sets something via addAction (or else). Make public some variables, so these values change for all players. As your MEH "draw3D" is a kind of loop, if you refer to these variables, your display can be updated (locally but everywhere).
  4. Your problem, IMHO, is that you want to synchronize UAV displays for all players: they must have the same picture, no matter who set the zoom and mode. For evident reason of broadcast, the displays are usually local. The best way to display the same thing on all PCs, even for JIP, is to run all possible things locally, then broadcast only little variables (like your _sMode or _sZoom) making them public instead of local. In such cases, use global sMode and publicVariable "sMode"; sZoom and publicVariable "sZoom"... and, as you are running a code on each PC, stop using setObjectTextureGlobal, prefer setObjectTexture. No need to broadcast such global command (it's even counter-productive: each JIP reset the texture for everyone!).
  5. pierremgi

    Using apply on group units

    Spawn that: [] spawn { // testGroup = createGroup [independent, true]; // totally useless (due to next line) testGroup = [getPos trg1, independent, (configfile >> "CfgGroups" >> "Indep" >> "IND_F" >> "Infantry" >> "HAF_InfSquad")] call BIS_fnc_spawnGroup; // call it sleep 0.5; // if needed: spawned units can be not completed before next line { _x execVM "unit_loadouts\checkgear.sqf" } forEach units testGroup; };
  6. pierremgi

    Headless clients dont work

    Where is the headless client? On hosted server, as 2nd session?, I'm not sure you'll gain any performance. Hosting means running mission as server and playing on the same PC , same session. A session is a launch. You are speaking about dedicated, server.cfg, What's the link with hosted mission? Perhaps are you running a dedicated session (using arma3server.exe if I refer to your first post), and a player session on the same PC (it's possible), but in this case, you don't have an hosted server. Perhaps you want yo launch somewhere a headless client... Same PC as server / player ? It's useless. Anyway, the first question is: what kind of server (dedicated or hosted, dedicated doesn't have any player/client in the same session)? The second question? : a headless client? What for? Most of the time, you don't need it. Think about dynamic simulation and spawn for units instead.
  7. The very first step is, as usual, clarify in plain language the aim of the script and effect(s) to obtain. Example: - in MP environment, (dedicated or hosted server, say dedicated), all / specific players can see/display a personal/global score (players, side, group..), for all / AIs / other players killed.... permanent / on any kill / on any player kill / on player kills only . That's the first difficulty, at least for me. Result can be as simple as the code I gave you and tested above, or an elaborated display with multiple entries.
  8. pierremgi

    Headless clients dont work

    Headless client is a... client, and it must run Arma as any other client. There is no client on dedicated server, by definition. Even with no interface, the dedicated server must run the mission. I doubt you can do that on a PC without Arma. If you are running a dedicated server, arma-3_server, you need to launch a mission in server parameter. There are plenty of missing things in your zip. https://community.bistudio.com/wiki/Arma_3:_Dedicated_Server https://community.bistudio.com/wiki/Arma_3:_Server_Config_File https://community.bistudio.com/wiki/Arma_3:_Headless_Client
  9. pierremgi

    Any Idea of Mine Detection?

    https://community.bistudio.com/wiki/Arma_3:_Field_Manual_-_Weapons_Advanced#Finding_Mines See also: disable/enableAI "MINEDETECTION"
  10. First of all, this code is supposed to save loadout/position/direction on server during the mission on server. So, in multiplayer session, during the session (as far as the server is running the mission). If you want to save something in SP or even hosted MP at home, you must save (what you want) in your profileNameSpace. You can use the MEHs "handleDisconnect" & "playerConnected" as above but your data must be saved in profileNameSpace, not missionNameSpace.
  11. pierremgi

    JBOY Boat Waypoints script

    in a waitUntil, it's safer to check for: isNil {anObject getVariable "blabla"}, or not, // double secured : anObject can be inexistent and blabla can be undefined. or even: anObject getVariable ["blabla",false] (so with a default value in case or undefined variable "blabla"). // simple secured by blabla by default. Fails if anObject is inexistent. If any doubt about the object's presence and the variable for the object, start like this: !isNil "anObject" && { anObject getVariable ["blabla",false] }
  12. Don't triple (even double) post! https://forums.bohemia.net/forums/topic/235999-task-not-completing/?tab=comments#comment-3446788 https://forums.bohemia.net/forums/topic/235994-how-do-you-prevent-a-randomly-spawned-vehicle-from-spawning-on-a-bridge/?tab=comments#comment-3446752
  13. Your code is false. You increment suicides + players killed! That's really what you need???
  14. pierremgi

    Questions: SOG Prairie Fire

    Hi, I don't have SOG on this hold laptop, so I can't test. On the other hand, try to find the turret by unitTurret in watch debug console . Then use lockturret.
  15. first of all thisList refers to a preset condition trigger (like BLUFOR PRESENT) and returns infantry and vehicles. For a helo, it returns the helo, not the pilot (except if you set trigger owner on the pilot itself (editor). So, the question is: are you sure thislist always returns the pilot of the helo as 1st element of this array? You should consider a simple: driver yourHelo along with yourHelo inArea thisTrigger
  16. private _playerSquadMates = units player select {!isPlayer _x && isNull objectParent _x}; //not a player, not in a vehicle, even parachute)
  17. AI REVIVE/HEAL SP/MP Last update 26th/11/2018 Hi all, Here is a script to allow AIs reviving and healing bros, according to parameters. This works in SP or MP. Compatible so far with AI RESPAWN script (see tag) Don't override the respawn system (MP) Incapacitation: This script relies on incapacitated status for players or AIs. This status is created when not existing (SP, or MP Ais) to allow revive scenario. parameters: REACT / HEAL DELAY / AI CAN REVIVE / KIT NEEDED / NEED MEDIC / AI CAN HEAL EXTRA GRP / BROS / WHITE FLAG ON MEDIC IN ACTION Parameters can be added to description.ext, class Params, just add what you want in classes: "react" "bleedOut" "noReviveForAI" "AiKit" "AiMedic" "bros" "whiteflag". So you can choose them while in lobby. Anyway, if you pass parameters calling the function, these params will override the lobby ones (except for bros class, see below). Code must run on all PCs. So, init.sqf, (trigger, non-repeatable, condition true)... Totally reworked (see below). EDITED: version with added parameter (see spoiler above. Should work fine in MP. Feedback welcome. Added possibility for multiple call lines. Last version with waypoints instead of domove + added parameter "white flag". Added one check more for distance form medic to wounded. What's a bro? - A bro is a unit (AI or player) who can be revived while unconscious, if some conditions are met (hard coded like within 200 m of another bro, or configured). In case of several healer candidates, the closer is elected. - That's also a unit able to heal unconscious unit (SP/MP) under the same conditions. But here, player(s) are not engaged in the process. They can heal but if an AI meet the conditions, this one will start the process. So, healer/healed is the same family: Bros. In which, the players are free to heal or not. How bros work (7th param or description.ext param class: bro ) - in SP, bros are switchable units by default. You can override this, passing a 7th param when calling MGI_fn_Revive, as shown in example (last code line). - in MP, * if bros class is present in description.ext, you can't override it; You have to choose one of the two settings: playable units or side player. Your description.ext should look like this (specifically for bros class): Bros = all players as default parameter means you can have different side and bros can heal anywhere.. if conditions are met. Keep on mind that disabled AI (slots) in lobby don't have existence and playableUnits = allPlayers (all playing guys), and not all playable units as in editor. So, each time you can let the slot as AI enabled, it's better. The list is updated anyway. The other possible parameter is set as WEST here. * if these parameters are not fine for your scenario, you can modify the bros class but you have to change the working line referring to your values: In the main function MGI_fn_Revive, look for: if (MGI_bros isEqualType 0) then { MGI_bros = [switchableUnits+playableUnits, WEST] select ("bros" call BIS_fnc_getParamValue); <<<<< THIS LINE CAN BE MODIFIED: [<your default array of bros>,<another choice>] select ("bros" call BIS_fnc_getParamValue) } else { MGI_bros = _MGI_bros }; * You can also delete the bros class in description.ext, and sets the 7th parameter as shown in the following example: [nil,nil,nil,nil,nil,nil,east] call MGI_fn_Revive; This way, here EAST will take place of the missing (and non over-writable) bros class. The other parameters are set to nil, for not overriding the other existing classes. * Don't forget, there is nothing mandatory, neither description.ext parameters, nor function parameters (See default above). You can add any unit in "bros" team, just setting a variable: yourUnit (or cursorTarget) setVariable ["passedBros",true,true]; Extra Examples: call MGI_fn_Revive // parameters are default ones, or defined by your description.ext: standard usage in MP (allowing parameters in description.ext) [nil,nil,nil,nil,nil,nil,east] call MGI_fn_Revive; // MP reworked/added side , class bros removed, other classes in description.ext [30,60,true,0,false,1,independent] call MGI_fn_Revive; // this will override the mission MP parameters in lobby, except the independent if bros class exist! Better usage for SP or even, in MP: [nil,nil,nil,nil,nil,nil,west,false] call MGI_fn_Revive; sleep 2; [nil,nil,nil,nil,nil,nil,east,false] call MGI_fn_Revive; Don't forget! bros class must be inactive/deleted in description.ext
  18. In SP, the player falls unconscious instead of dying. This allows to be healed by a Bro. If not, the player die. The only mean for respawning is to add the SP simple respawn module. In MP, the 1st rule is made by your settings in editor for MP respawn/revive. If the player must die/respawn without script or module, the player will die the respawn as well, with this script/module. No change! The only thing is that during unconsciousness, a "Bro" (AI or player) can heal you. That's also the case for playable units (as you can see they are also affected by MP settings in editor, at least they respawn) The 2nd rule is that any bro can be healed at his turn (even if not playable). That means he falls unconscious instead of dying and can be healed during a slot time.
  19. player setDamage 1 literally kill the unit, but doesn't trigger the handleDamage EH, and you are straight in failed revive status. So, the revive script can't work. If you want to use it, play "normally": You can blow up a charge... 😊 Same for MGI module.
  20. pierremgi

    [solved]PiP script and arsenal

    Well. I think it's a simple question of precedence (delay) for running script in good order. I tested with a monitor (I named it monitor) and a drone (I named it MQ_1) As I was on quick test in preview I replaced your sqf by: liveFeedUAV1 = { if (!isServer) exitWith {}; params ["_monitor"]; if (isNull _monitor) exitWith {}; _monitor setObjectTextureGlobal [0, "#(argb,512,512,1)r2t(uavrtt1,1)"]; cam1 = "camera" camCreate [0,0,0]; cam1 cameraEffect ["Internal", "Back", "uavrtt1"]; cam1 attachTo [MQ_1, [0,0,0], "PiP0_pos"]; fnc_selectZoom = { private _sZoom = _this select 0; switch (_sZoom) do { case "ULTRA WIDE": {cam1 camSetFov 0.46599999}; case "WIDE": {cam1 camSetFov 0.2}; case "MEDIUM": {cam1 camSetFov 0.1}; case "NARROW": {cam1 camSetFov 0.02}; case "NARROWER": {cam1 camSetFov 0.01}; }; }; fnc_selectMode = { private _sMode = _this select 0; switch (_sMode) do { case "DTV": {"uavrtt1" setPiPEffect [0]}; case "NV": {"uavrtt1" setPiPEffect [1]}; case "WHOT": {"uavrtt1" setPiPEffect [2]}; case "BHOT": {"uavrtt1" setPiPEffect [7]}; }; }; { private _actionTitle = format ["Select Zoom - %1",_x]; _monitor addAction [ _actionTitle, { private _Value = _this select 3 select 0; [_Value] call fnc_selectZoom; }, [_x],3.3,true,false,"","",8 ]; } forEach ["ULTRA WIDE", "WIDE", "MEDIUM", "NARROW", "NARROWER"]; { private _actionTitle = format ["Select Mode - %1",_x]; _monitor addAction [ _actionTitle, { private _Value = _this select 3 select 0; [_Value] call fnc_selectMode; }, [_x],3.3,true,false,"","",8 ]; } forEach ["DTV", "NV", "WHOT", "BHOT"]; addMissionEventHandler ["Draw3D", { _dir = (MQ_1 selectionPosition "laser_start") vectorFromTo (MQ_1 selectionPosition "laser_end"); cam1 setVectorDirAndUp [_dir,_dir vectorCrossProduct [-(_dir select 1),_dir select 0, 0]]; }]; }; in a trigger set to true (cond). In init field of the monitor : this spawn { sleep 3; _this call liveFeedUAV1} just to be sure the code liveFeedUAV1 exists before calling it. I placed a hunter as virtual arsenal In init field of the hunter (or everywhere else) : [missionNamespace, "arsenalClosed", { MQ_1 spawn liveFeedUAV1; }] call BIS_fnc_addScriptedEventHandler; That works as is, but if you want to ensure the deal: [missionNamespace, "arsenalClosed", { MQ_1 spawn {sleep 1; _this call liveFeedUAV1}; }] call BIS_fnc_addScriptedEventHandler;
  21. try with: while {!isNull _projectile} do...
  22. you can test it without if (isServer) then {...}; but I'm not sure that can tweak the EH. incomingMissile in supposed to be GA (global argument) and the code inside is EG (effet global). So? no clue. I can test in MP now. Perhaps the shooter is too close from the target?
  23. In MP, the MEH "entitykilled" runs where the MEH is scripted... so for any player in initPlayerLocal.sqf..., + server if init.sqf, or even, on server only if running on initserver.sqf That's the first point. The second one is, the inner code will run locally, whatever your first option. That means: in initServer.sqf, the code runs on server only. Difficult to make such code appropriate for a count based on players. in initPlayerLocal.sqf or init.sqf, all players (+ dedicated server if init.sqf) will run this code independently, whatever the killed/killer could be. So, it's ok for local score but a little bit more complex for counting your own kill. The score is not discriminant until you add a condition on _killer or _instigator Something like, in initPlayerLocal.sqf like: numDeaths = 0; addMissionEventHandler ["EntityKilled", { params ["_unit", "_killer", "_instigator"]; if (isNull _instigator) then {_instigator = UAVControl vehicle _killer select 0}; if (isNull _instigator) then {_instigator = _killer}; if (_instigator == player && _instigator isNotEqualTo _unit) then { numDeaths = numDeaths + 1; hint str numDeaths; }; }]; This score is local.Suicide (or self crash) doesn't count. You can add conditions for enemy kill only... or even just other killed players only (ZaellixA's code) but I'm not sure it was your intention. You could be also interested in handleScore EH (on server only)