Jump to content

mrcurry

Member
  • Content Count

    609
  • Joined

  • Last visited

  • Medals

Everything posted by mrcurry

  1. I recommend using the "new" task framework instead. It does JIP and MP updates automagically. Arma 3 task framework
  2. mrcurry

    Exporting Units?

    1. Make the loadout using the arsenal. 2. In the arsenal save the loadout. 3. Once in-game as Zeus plop down an appropriate unit on the side you wish him to be. 4. Use the Zeus module for Arsenal (Modules >> Zeus >> Arsenal) on the unit. 5. In the arsenal load the saved loadout and close the arsenal. Voilá, that should do it. Steps 3-5 can be repeated however many times you wish to after you done the first 2.
  3. this addEventHandler [ "Engine", { params ["_vehicle", "_engineOn"]; if( !_engineOn ) then { { assignedVehicleRole _x params [["_vehicleRole", ""]]; if( isPlayer _x or _vehicleRole == "Cargo" ) then { moveOut _x }; } forEach crew _vehicle; }; } ]; Just a simple check in the forEach loop. EDIT: Added support for kicking out AI assigned as cargo EDIT 2: An additional way would be to check the unit against the pilot's group. As long you don't have cargo units joining the crew's group (seems unlikely) this should be a safer approach. this addEventHandler [ "Engine", { params ["_vehicle", "_engineOn"]; if( !_engineOn ) then { private _pilotGroup = group driver _vehicle; { if( group _x != _pilotGroup ) then { moveOut _x }; } forEach crew _vehicle; }; } ];
  4. I prefer using the watch lines with very simple expressions or variables only. Anything complex I put in the console for a manual exec. This means if there is an error in my code I'll most likely catch it in game (using - showScriptErrors) without ever switching to the RPT.
  5. I just re-tested it on my end and it's working fine. Like X Pro said the code is intended to be put in the vehicle's init as is, no change required. The engine state is a boolean (true/false). All params does is parse it into a variable, in our case _engineOn, so we can use it in an easy and readable way.
  6. this addEventHandler [ "Engine", { params ["_vehicle", "_engineOn"]; if(!_engineOn) then { {moveOut _x} forEach crew _vehicle; }; } ];
  7. I don't see why you need to tell the player which way they are going but... (count thisList > 0 && { getDir (thisList select 0) < (getDir thisTrigger + 30)%360 && getDir (thisList select 0) > (getDir thisTrigger - 30)%360}) will return true if the first thing in the trigger is facing in the direction of the trigger +/- 30 degrees. If you want one trigger to handle both directions then ( count thisList > 0 && { getDir (thisList select 0) < (dirIn + 30)%360 && getDir (thisList select 0) > (dirIn - 30)%360 || getDir (thisList select 0) < (dirOut + 30)%360 && getDir (thisList select 0) > (dirOut - 30)%360 } ) just replace dirIn and dirOut with the respective directions for in and out.
  8. I'm at work so I don't really have time for an indepth explanation but this link should help you get the ball rolling. PositionAGLS See KKs example on how you can do it. Another way would be to utilise buildingPos command to get them to appear inside the building.
  9. Try cancel it with BIS_fnc_taskSetState instead. ["mck_inv1", "Canceled" ] call BIS_fnc_taskSetState
  10. Grumpy, side player does not return GUER or WEST or EAST. It returns a type Side which when displayed is represented with the text GUER, WEST or EAST. Small but important difference. The engine still views and handles the return like a type Side. GUER does not exist as anything other than a text representation of the side. Same technically goes for EAST and WEST but for those a matching command/engine variable happens to exists. It really boils down to inconsistent naming standards but I'd say that's a trademark for earlier BIS games. I prefer using the newer blufor, opfor and independent for this very reason since they are easier to differentiate. Hell I'd even go so far as to say this kind of conversation is why they were introduced. Hope that makes more sense.
  11. I just tested it with the Lynx and the Zafir both of which have non-detachable bipods. No you can not detach bipods on all weapons. If you want to get rid of those your options are limited to making an addon or a feature request. It's entirely possible BIS_fnc_baseWeapon does not strip away some weapons' bipod. Do you have any examples of weapons where this happens cause that might require a bug report.
  12. I'd assume those would be the weapons that have built in bipod such as some sniper rifles. Those bipods are not detachable.
  13. The GOM_fnc_functions.hpp contains the full CfgFunctions class. Either edit it and include it inside the CfgFunctions or simply copy the contents (minus the class CfgFunctions and associated brackets). This is what I've done: //GOM_fnc_functions.hpp class GOM { class dialog { class aircraftLoadout{file = "scripts\GOM\functions\GOM_fnc_aircraftLoadout.sqf";}; }; }; //Description.ext #include "scripts\GOM\dialogs\GOM_dialog_parents.hpp" #include "scripts\GOM\dialogs\GOM_dialog_controls.hpp" class CfgFunctions { #include "fnc\cfgfunctions.hpp" #include "scripts\GOM\functions\GOM_fnc_functions.hpp" };
  14. I'll also add that while "global" triggers are indeed created on each machine their states can vary from client to client. Example: trigger with condition "player in thisList" will only activate when THE player enters. Think of a global trigger as lots of network copies rather than a single entity.
  15. Ditch the if () then {} and add the following to the actions condition string surfaceIsWater getPos _target
  16. 1. Build your composition in Eden. 2. Aim the eden camera on the center of your composition. 3. Open debug console and run ObjectsGrabber something like so: t = [ screenToWorld [0.5,0.5], 50, true] call BIS_fnc_objectsGrabber 4. Paste (Ctrl+V) the contents into whichever file you wish to save them in (in the mission folder). How you save it exactly is up to you but the simplest way would be a global variable in your init.sqf: testComposition = *the pasted content here*; 5. When you wish to spawn the composition simply call ObjectsMapper with the relevant content like so: [ testPosition, random 360, testComposition ] call BIS_fnc_objectsMapper; For more info on the functions see: BIS_fnc_ObjectsGrabber BIS_fnc_ObjectsMapper Until BIS figures out a decent way to package compositions with missions I'd say the above is your best bet.
  17. Here's a way to do it without the dummy if you so desire. What it does: - Replicate contents of given type from one container to another including containers (backpacks and vests and uniforms), if I remember right it should transfer the correct ammo count for each magazine too. What it doesn't: - Check cargo sizes to see if contents fit in the new container. Everything is squeezed in. Use as you wish. I've done it in three functions, you may define these as you wish, I personally use CfgFunctions to define 'em. If you change the tag it you also need to update fnc_transferContents since it calls the other two. mis_fnc_transferContents mis_fnc_getContainerContents mis_fnc_setContainerContents Example usage: //Short [box1, box2] call mis_fnc_transferContents //Long [box1, box2, ["weapons", "magazines"], true, true] call mis_fnc_transferContents
  18. Are you testing this on server or in editor? Is the server using a command whitelist to prevent hacking? If yes is hideObjectGlobal allowed? Are you using a command whitelist in mission? If yes is hideObjectGlobal allowed there?
  19. mrcurry

    Teleport player and his group

    What's the reason behind using the above instead of _leader setPos _position? Normalising the parameter to PosAGL?
  20. mrcurry

    MP/PVP - Only one side is allowed to respawn

    The case was merely an example to illustrate my point. I only posted to stop someone not as well-versed in Arma editing as you or me from misinterpreting what you wrote as an absolute truth. It's a simplified model that also only applies in specific use cases. It's frankly irrelevant what you do with your activation or deactivation statements. Triggers will keep updating thisList even after they have executed activation or deactivation, repeatable or not. thisList is not updated when the activation or deactivation is fired. thisList is updated at all times, the trigger's internal logic executes activation and deactivation based on the condition field' returned value, true or false. thisList is initialized on mission startup (or on trigger creation incase of a spawned trigger) with a short delay (time > 0.5) and is updated by the trigger automatically. If you pass the variable into an activation code such as below thisList will at all times reflect the situation inside the trigger event. Since arrays are passed by reference you can for instance do this to show who is in an area at any given time. //Trigger condition: true //Trigger activation: run = true; 0 = thisList spawn { while { run } do { hintSilent str _this; }; };
  21. mrcurry

    MP/PVP - Only one side is allowed to respawn

    This is not true: triggers (and thereby thisList) updates every 0.5 seconds (or there abouts, my memory is a bit fuzzy). You can have a trigger with condition "false" (aka it will never run any code on it's own) and still use it as a detector using list triggerName command. You are right however that a BLUFOR trigger will not detect a dead BLUFOR player as dead units belong to the civilian side.
  22. mrcurry

    MP/PVP - Only one side is allowed to respawn

    Condition field of trigger: (blufor countSide allPlayers) isEqualTo (count thisList) Just make sure no other blufor ever enter the trigger area and that should do it. Also might wanna make it a server only trigger and execute this instead. ["end2"] remoteExec ["BIS_fnc_endMission"];
  23. mrcurry

    MP/PVP - Only one side is allowed to respawn

    Cool idea, do link the mission when it's ready. I'd love to try out something like this. To do what you want add a respawn eventhandler to blufor that hides them, disables their sim and activates a spectate, se below. //In initPlayerLocal.sqf if(playerSide isEqualTo BLUFOR) then { player addEventHandler [ "Respawn", { player hideObjectGlobal true; player enableSimulation false; [ "Initialize", [ player, [blufor], //Allowed sides false, //Allow spectate AI false, //Allow free cam, probably want this off for a PvP true //Allow 3rd person cam ] ] call BIS_fnc_EGSpectator; } ]; }; Edit: If you do this you cannot rely on !alive to check if they are still breathing. To get around that create a custom respawn point for BLUFOR somewhere out of sight, put a BLUFOR present trigger around it and simply check if all BLUFOR are in the trigger. If they are, they are dead and you can safely end the mission.
×