tryteyker

I would recommend defining a default value when using getVariable, as it returns Any otherwise and that may lead to unexpected errors. So use player getVariable ["moab_isInfected",false] instead, same with the helmet. https://community.bistudio.com/wiki/getVariable

Yeah the prologue had a forced regular difficulty for some reason. But still, it'd be interesting to implement this permanently in a mission because it's a good vanilla substitute for STHud from what I can see, unless it also shows enemies that are closer than 50m.

What is _car? lbSetData accepts only strings, so if _car is an object it will not work.

Try this: curatorModule setCuratorCoef ["delete", -1e10]; curatorModule setCuratorCoef ["edit", -1e10]; https://community.bistudio.com/wiki/setCuratorCoef Worth noting that this approach will apparently result in an on-screen error warning as setCuratorCoef is directly tied to the cost of the action, at least according to this BIKI page.

Can you send a screenshot of your UI? I'm assuming you're working with a listbox and two structured text elements which you want to change depending on what element is selected in the listbox. The problem with ctrlSetText in this case is it's static. You'll have to work with something like onLBSelChanged if you want to change text depending on the currently selected listbox element.

If you want civilians to move to the players position on their own they'll have to be in their own group, as knowsAbout 'elevates' the query to group level instead of individual units. You could write up a function which basically iterates through nearTargets (as kylania mentioned) and then checks the targets' knowsAbout value. The thing with nearTargets is that it's already based on knowsAbout, so the position is only an approximate. Personally I'd use that position instead of the current player position, makes it somewhat better. Just to give you an idea I've thrown together some code, about to head to work so it's not going to work: fn_checkForTargets = { _targetList = _this select 0; // nearTargets value _player = _this select 1; // Player unit _civ = _this select 2; // Civilian _targetPos = []; // Will return this later for "_i" from 0 to (count _targetList) - 1 do { private ["_currentTarget","_currentTargetPos"]; _currentTarget = _targetList select _i; _currentTargetPos = _currentTarget select 0; // Assumed position value if (_civ knowsAbout _currentTarget > 0.5) exitWith { // Somewhat arbitrary value, will have to test. nearTargets only includes recognized targets which means there's a min knowsAbout value too, just don't know it. _targetPos = _currentTargetPos; }; } _targetPos; }; You get the idea, hopefully.

That's a good start, but it's not quite there yet. The removing part works well, but a bit too well really. Problem is that the vest gets removed permanently and trying to take on the old vest will remove that one too. But thanks for the idea, it's definitely a start. I modified the code slightly, it's kind of a dirty workaround but I'm not too worried about that since it's an SP mission: player addEventHandler ["InventoryOpened", { private _unt = _this select 0; currentVest = vest _unt; publicVariable "currentVest"; }]; player addEventHandler ["Take", { private _unt = _this select 0; private _itm = _this select 2; if (vest _unt isEqualTo _itm && _itm != currentVest) exitWith {removeVest _unt}; if (backpack _unt isEqualTo _itm && _itm != currentVest) exitWith {removeBackpack _unt}; }]; Probably don't need the publicVariable either but added it just to be safe. Now all that remains is to find a way to immediately switch it back without losing the picked up vest (since if you removeVest all contents will be lost) I think it's safe to say this isn't really going to work. I'm manually re-adding the original vest (currentVest) to the unit via _unt addVest currentVest, in addition to a forEach loop to add all the old items back in. Problem is, the actual unit gets an empty vest whilst the container unit (BLUFOR unit) gets an exact copy of the vest with the items added via the forEach loop. Looks like _this select 0 isn't always the unit that the EH is assigned to, or the EH runs twice.

Hi, so googling this issue actually lead me to a couple Daily Mail articles instead of anything useful (not even kidding) so I figured I'd try my luck here instead. Right now I'm trying to prevent the player (SP mission) from taking enemy vests or backpacks, similar to how uniforms are locked to the specific side. More specifically, the player is Syndikat (INDFOR) and as such shouldn't be able to pick up BLUFOR/OPFOR vests or backpacks. Just to clarify, the contents should still be available for the player to pick up.

What car are you trying this on? All of BIS' cars should use CarHorn but I've only tested it on the Hatchbacks. Either way, you can hop into the car yourself as driver and use this to check for all weapons of the vehicle: hint str (weapons (vehicle player)) If one of the weapons is CarHorn, then the code above should work (I know it doesn't but we'll get to that). The thing with forceWeaponFire is that it requires a firemode. The most common ones are obviously "Single", "Burst", "FullAuto" but these usually only work for regular infantry weapons. Other weapons, like gatlings, use "close", or in the case of the car horn there's "this". To check for weapon fire modes: hint str (getArray (configFile >> "CfgWeapons" >> currentWeapon (vehicle player) >> "modes")); The above code is sort of on-off considering that in this case "CarHorn" probably won't be the selected weapon, so I'd just recommend hopping into the config viewer and looking up the relevant item yourself. Either way, whenever you have "this" as a firemode, you have to replace "this" with the weapon name (in this case, "CarHorn") instead. Also, you will need to make sure that the unit that actually "fires" the gun is used in forceWeaponFire (which in this case is the driver). If the issue isn't about wrong weapon names then I'm guessing it's because of mp locality, where are you executing the code?

(driver car) forceWeaponFire ["CarHorn","CarHorn"]; Basically when remote operating a vehicle's weapons, you need to specify the unit that is operating the specific weapon (in this case, the driver is operating the horn) instead of the vehicle itself. "CarHorn" as a weapon has one mode, "this", which means you'll have to replace "this" with "CarHorn" instead. More info here: https://community.bistudio.com/wiki/forceWeaponFire

If you're doing a classic shop system, why use triggers? Because addAction in combination with an object like a laptop or whatever is much more reliable considering that you will have access to the caller via _this select 1 in the script that's executed, and triggers are just a nuisance to work with in your case. You have lists like list trigger and such, but filtering out a single unit from it when multiple units are guaranteed to be inside of it is really just adding unnecessary work, plus you'd have to consider locality issues as list only has local effect.

I'd say don't use player in MP games, even if you execute the code locally (and are 100% sure of it, ie through !isServer or something similar) because return value of 'player' can be non local sometimes (although quite frankly I don't know how rare that is). How are you executing the code? init.sqf?

http://steamcommunity.com/sharedfiles/filedetails/?id=667375637 When it comes to mods you'll have to google around, but most big mods (like RHS) have excellent documentation that provide all classnames. Another way would be to just head into the config viewer and look for the specific prefix (in your case HLC mod, so the prefix would be hlc_) that most (not all) mods use. (RHS uses rhs_ etc etc)

Don't forget about 'model' config value. Incredibly useful in cases like this. getText(configFile >> "CfgWeapons" >> _weapon_classname >> "model") In the case of G3A3: "\hlc_wp_g3\mesh\g3a3\g3a3.p3d"

You can run these from anywhere. AddAction, init.sqf, up to you. Just make sure you've got a marker set up at the DZ, and if you are using multiple units make sure they are grouped together (fn_halodrop.sqf doesn't support array specifically, dunno why I never added that tbh) and then use group player or similar.

You don't really need to worry about saving backpacks if parachutes are open from the start, as units are simply moved into the parachute as driver (since it's a vehicle). It's a bit trickier with HALO as you'll need to make it visually appealing in the process. The actual behind-the-scenes stuff isn't hard, since all you'll need to do is store the backpack items from the units backpack and apply it once the unit has landed. However, since you'll want the backpack to show during flight, you need to use setVectorDirAndUp and a lot of jazz which is basically trial and error to attach the weapon holder (which has a backpack in its cargo) to the front of the unit as it HALOs into the AO. I've got 3 functions from our framework ready to use depending on what you want to do, although the halodrop.sqf function may require additional tweaking with attachTo to make the backpack a snug fit. Also halodrop.sqf scatters units somewhat randomly (uses +random 100 on both x- and y-axis for each individual unit) to prevent any collisions, although a static radius like in fn_paradrop would probably be better. fn_paradrop.sqf: /* * Author: Kingsley * Paradrops the given groups/units at the given position and height * * Arguments: * 0: Units, groups or side to paradrop <GROUP/OBJECT/SIDE> * 1: Position to drop units at <POSITION ATL/MARKER NAME> * 2: Height to drop units from (meters) <NUMBER> * 3: Radius in meters <NUMBER> * * Return Value: * None * * Example: * [[grpOne, grpTwo, unitOne, unitTwo], [0,0,0], 500] call ARC_fnc_paraDrop; * [west, [0,0,0], 250, 1000] call ARC_fnc_paraDrop; * * Public: Yes */ if (!isServer) exitWith {}; params [ ["_objects", [], [[], sideUnknown]], ["_position", [], [[], ""]], ["_height", 250, [0]], ["_radius", 500, [0]] ]; if (_position isEqualType "") then {_position = getMarkerPos _position}; if (count _position == 0) exitWith {}; _height = _height + round (random 50); private _dzMarker = createMarker [format ["ARC_paraDropDZ_%1", _position], _position]; _dzMarker setMarkerSize [_radius, _radius]; _dzMarker setMarkerShape "ELLIPSE"; _dzMarker setMarkerAlpha 0; private _units = []; if (_objects isEqualType sideUnknown) then { {_units pushBackUnique _x; false} count (allUnits select {side _x == _objects}); } else { { private _item = _x; if (_item isEqualType grpNull) then { {_units pushBackUnique _x; false} count (units _item); } else { if (_item isEqualType objNull) then { _units pushBackUnique _item; }; }; false } count _objects; }; { private _paraPos = [_dzMarker] call CBA_fnc_randPosArea; private _parachute = createVehicle ["Steerable_Parachute_F", (_paraPos vectorAdd [0, 0, _height]), [], 0, "NONE"]; [_x, _parachute] remoteExec ["moveInDriver", _x]; false } count _units; deleteMarker _dzMarker; fn_halodrop.sqf: /* Author: tryteyker Description: This script gives units parachutes, saves their backpackas and drops them at the specified position at the given height. Parameter(s): 0: GROUP, OBJECT or SIDE - units to use 1: POSITION - positin to drop units at 2: NUMBER - height to drop at Returns: BOOLEAN - true once all units have been processed Example _done = [west, 250] call ARC_fnc_haloDrop; */ private ["_units","_pos","_height"]; _units = switch (typeName (_this select 0)) do { case "GROUP": {units (_this select 0)}; case "OBJECT": {[(_this select 0)]}; case "SIDE": {allUnits}; }; _pos = _this select 1; _height = _this select 2; _processUnit = { private ["_haloPos","_backpackItems","_backpackType","_emptyShell"]; params ["_unit","_pos","_height"]; _haloPos = [(_pos select 0) + (random 100), (_pos select 1) + (random 100), (_pos select 2) + _height]; _backpackItems = backpackItems _unit; _backpackType = backpack _unit; _emptyShell = createVehicle ["GroundWeaponHolder", getPosATL _unit, [], 0, "CAN_COLLIDE"]; _emptyShell addBackpackCargoGlobal [_backpackType, 1]; removeBackpack _unit; _emptyShell attachTo [_unit, [-0.1, 0.8, 0.8]]; // This part may require tweaking as backpack may not end up in front of the unit. _emptyShell setVectorDirAndUp [[0,0,-1], [0,1,0]]; // This part adjusts the backpack to be upright. _unit addBackpack "B_Parachute"; _unit setPosATL _haloPos; // Unit starts dropping at this point. [_emptyShell, _backpackType, _backpackItems, _unit] spawn { params ["_emptyShell", "_backpackType", "_backpackItems", "_unit"]; while {(backpack _unit) == "B_Parachute"} do { sleep 1; switch (stance _unit) do { case "STAND": { _emptyShell attachTo [_unit, [-0.1, 0.8, 0.8]]; }; case "CROUCH": { _emptyShell attachTo [_unit, [-0.1, 0.9, 0.38]]; }; case "UNDEFINED": { // Stance during parachuting is 'undefined' _emptyShell setVectorDirAndUp [[0,-1,0], [0,0,-1]]; _emptyShell attachTo [_unit, [-0.1, -0.1, -0.6]]; }; }; }; _unit addBackpack _backpackType; clearAllItemsFromBackpack _unit; {_unit addItemToBackpack _x} forEach _backpackItems; deleteVehicle _emptyShell; }; }; if (typeName (_this select 0) == "SIDE") then { {if (side _x == (_this select 0)) then {[_x, _pos, _height] call _processUnit}} forEach _units; } else { {[_x, _pos, _height] call _processUnit} forEach _units; }; fn_haloprep.sqf (saves backpack, gives parachute, but does not drop unit above AO): /* Author: tryteyker Description: This script is a light version of the HALO Drop one, with the unit only being given a parachute. Parameter(s): GROUP, OBJECT or SIDE Returns: BOOLEAN - true once all units have been processed Example _done = west call ARC_fnc_haloPrep; */ private ["_units"]; _units = switch (typeName _this) do { case "GROUP": {units _this}; case "OBJECT": {[_this]}; case "SIDE": {allUnits}; }; _processUnit = { private ["_unit","_backpackItems","_backpackType","_emptyShell"]; _unit = _this; _backpackItems = backpackItems _unit; _backpackType = backpack _unit; _emptyShell = createVehicle ["GroundWeaponHolder", getPosATL _unit, [], 0, "CAN_COLLIDE"]; _emptyShell addBackpackCargoGlobal [_backpackType,1]; removeBackpack _unit; _emptyShell attachTo [_unit, [-0.1, 0.8, 0.8]]; _emptyShell setVectorDirAndUp [[0,0,-1], [0,1,0]]; _unit addBackpack "B_Parachute"; [_emptyShell, _backpackType, _backpackItems, _unit] spawn { private ["_emptyShell","_backpackType","_backpackItems","_unit"]; _emptyShell = _this select 0; _backpackType = _this select 1; _backpackItems = _this select 2; _unit = _this select 3; while {(backpack _unit) == "B_Parachute"} do { sleep 1; switch (stance _unit) do { case "STAND": { _emptyShell attachTo [_unit, [-0.1, 0.8, 0.8]]; }; case "CROUCH": { _emptyShell attachTo [_unit, [-0.1, 0.9, 0.38]]; }; case "UNDEFINED": { _emptyShell setVectorDirAndUp [[0,-1,0],[0,0,-1]]; _emptyShell attachTo [_unit, [-0.1, -0.1, -0.6]]; }; }; }; _unit addBackpack _backpackType; clearAllItemsFromBackpack _unit; {_unit addItemToBackpack _x} forEach _backpackItems; deleteVehicle _emptyShell; }; }; if (typeName _this == "SIDE") then { {if (side _x == _this) then {_x call _processUnit}} forEach _units; } else { {_x call _processUnit} forEach _units; }; These should all work, used the paradrop one in session yesterday and nobody died (just make sure, and make doubly sure if you're using ACE, that the wind is set to something reasonable, otherwise you'll experience things worse than Vietnam) (commented some code, changed setVectorDirAndUp to attachTo as the former is only responsible for making the backpack stand upright)

Hello, running into a bit of an issue with CfgORBAT here. I'm trying to configure a static CfgORBAT background which would permanently show a logo regardless of which unit is selected. Like this: https://community.bistudio.com/wikidata/images/5/57/A3_ORBATViewer.jpg(You can clearly see the TF Aegis logo in the back) Now, if I've got this right, the unit insignia is the one that is supposed to show in the background of the CfgORBAT view when it is opened. Unfortunately, it doesn't seem to work for me as the background just remains white regardless of unit insignia (or texture). Not exactly sure if there's other ways to open ORBAT (besides fnc_openORBAT or something similar I suppose) but I'm dealing with the ORBAT view exclusively through placed ORBAT groups on the map. Not sure if this changes anything but I figured it's safe to mention. Also, any ideas on how to go about adding in a custom texture? The path needs to be absolute, but the pbo is going to get shuffled around a lot. The easy part is figuring out how to get to mission root, but the hard part is to implement it in description.ext (since MISSION_ROOT + file_path don't work). RIGHT, so after about 3hrs of wrestling with __EVAL and __EXEC I finally found the magic one liner to get mission root and add on the image path. __EVAL((__FILE__ select [0, count __FILE__ - 15])+"img\kdoh_ca") Who knew that __FILE__ actually returnd a string? I sure as hell didn't for the past 2 hours. GOT IT! So the insignia is actually the one defining the background. I'm not quite sure if the relative path was the issue (insignia did show up under the unit, so I guess not) or rather that colorInsignia[] was set to {0,0,0,1} instead of {1,1,1,1}. Either way I used absolute path plus colorInsignia set to white and that fixed it. ORBAT also sticks to the last loaded insignia, so it won't turn blank if you enter the ORBAT view through another unit.

https://community.bistudio.com/wiki/hideObject

If you want to use safezoneX just change the type of position of the UI element by double clicking on it (where you can also define classname, text, etc) in the GUI editor. If you decide to edit the GUI at a later time by loading it into the editor again, be aware that the position type changes back to GUI_GRID_X and you'll have to manually edit all controls to use safezoneX again instead.

I haven't worked with scrollbars that much, but you may have to use sliderSetRange first before being able to use sliderPosition (effectively) due to the range not being defined (but then again there may be a standard range defined in the parent config - I don't know, just throwing ideas out)

If you're going to do this to multiple vehcles then yeah I'd recommend just running the loadout script either way. You could just check if the loadout script has already been run (maybe use setVariable to note special loadout, just an idea) if you're planning on executing it mid-mission or something. It's generally not worth it to run it all through config if you can use faster and more efficient methods.

You could probably throw together a for loop which adds the different cargo spaces (TransportX as kevsnotrev mentioned above) into one (or multiple arrays) using getArray. Then compare that array (using isEqualTo because == is unable to compare arrays) to your own array (which you either threw together using magazineCargo, backpackCargo etc, OR if you have the different config entries stored in their own variable you can use the xCargo commands directly without needing to make your own variable) to get any differences. Just to make sense of it a bit more, here's some pseudocode-ish (using 1 variable): _cargo = []; { _cargo += getArray(configFile >> "CfgVehicles" >> "B_MRAP_01_gmg_F" >> _x; } forEach _configEntries; // These are relevant config entries like TransportItems etc etc etc if (_cargo isEqualTo _newCargo) then { // _newCargo would be thrown together out of magazineCargo, backpackCargo etc // do stuff }; (this is pretty terrible code, it's not going to work straight out of the box) But you get the idea - basically pull all relevant cargo with getArray out of config, then compare that to another array which includes the current cargo. I have no idea what the different arrays (like TransportItems) actually include, but you should obviously have the same structure in your _newCargo as your _cargo array.

Just to add, the reason the action isn't changing is because duty.sqf isn't a responsive file per se. AddAction is a static command, it just adds text to an object plus a file (or code since A3) that will be executed once the player selects the action in the action menu. What this means in practice is that once the player clicks on "Go on duty" on the Duty Desk, the script will see that the variable Cop Duty is true, so it will remove all actions and add "Go off duty" instead, but only once the player actually executes the action.

The switch statement is pretty simple: It checks a variable and depending on that variable's value it will execute the different code blocks. To explain it in general terms, imagine you've got a variable named _value that either has the values "a", "b", or "c". Depending on the value you want to output different statements (note that it should technically be case sensitive). Syntax for that would be: _value = "a"; switch (_value) do { case "a": { hint "A!"; // This would be executed, because _value equals "a". }; case "b": { hint "B!"; }; case "c": { hint "C!"; }; default { hint "It's none of these!"; // In case _value does not equal either "a", "b" or "c". Note the missing colon : when using default. }; }; So all you'd really need to do is define a variable where you either have "pollerhoch" or "pollerrunter" as string values, and then you use the above syntax to implement it and do the stuff. I don't know how you're getting all your values etc so I've explained it in really broad strokes here, plus it's also a really long-winded explanation.

The statement itself already checks if the condition evaluates to true, so you don't compare a boolean value with a boolean value. All you need is to use getVariable, because it already returns true (or false). HOWEVER, you need to change the variable from 1 to true for it to work. 1 isn't true and neither is 0 false, SQF unfortunately doesn't work that way. Correct code: if ((_this select 1) getVariable "copDuty") then { removeAllActions DutyDesk; DutyDesk addAction["Go Off-Duty", "Core\Cop\OffDuty.sqf"]; }; if !((_this select 1) getVariable "copDuty")) then { DutyDesk addAction["Go On-Duty", "Core\Cop\OffDuty.sqf"]; hint "Went on Duty~"; }; Davidoss was slightly faster than me :P