Jump to content

mrcurry

Member
  • Content Count

    641
  • Joined

  • Last visited

  • Medals

Everything posted by mrcurry

  1. Arma would not complain about a variable data Type change. It would when using a variable of incorrect data type in an incorrect setting. Only way your original code could do that would be the == operator, aka cfg_foo isn't a scalar before the comparison. Since it's a spam I'm gonna guess it's in a loop somewhere. Do some log printouts to check which part of your code is generating it. To write to log use: diag_log
  2. This should help with the civilian jumping back in the vehicle. Name the civilian, example: civ1 In civilians init: civGrp = group this; When players pick up the civilian make him join the players group. In trigger: //On activation [civ1] joinSilent civGrp; unassignVehicle civ1; moveOut civ1; //Do your move stuff here.
  3. mrcurry

    Extraction when a task is completed

    As I understand it you have your links setup as: Hold waypoint - Task Module - Trigger Links should be: Task Module - Trigger - Hold waypoint Trigger must be of type: Skip Waypoint Hope that helps!
  4. Well depends how you are showing the names but if you are using something running on each frame just save the last time the key was pressed and calculate the alpha value of the colour based on how long it was since the key was pressed. Checkout linearConversion command, it does the math for you.
  5. Ditch the file and put this in condition field: this && (((date select 3) >= 11 && (date select 4) >= 45) && (date select 3) < 12)
  6. As long as you only use the Task Framework functions you should be set.
  7. Did you create the task using BIS_fnc_taskCreate?
  8. I recommend using the "new" task framework instead. It does JIP and MP updates automagically. Arma 3 task framework
  9. 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.
  10. 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; }; } ];
  11. 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.
  12. 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.
  13. this addEventHandler [ "Engine", { params ["_vehicle", "_engineOn"]; if(!_engineOn) then { {moveOut _x} forEach crew _vehicle; }; } ];
  14. 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.
  15. 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.
  16. Try cancel it with BIS_fnc_taskSetState instead. ["mck_inv1", "Canceled" ] call BIS_fnc_taskSetState
  17. 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.
  18. 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.
  19. I'd assume those would be the weapons that have built in bipod such as some sniper rifles. Those bipods are not detachable.
  20. 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" };
  21. 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.
  22. Ditch the if () then {} and add the following to the actions condition string surfaceIsWater getPos _target
  23. 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.
×