fight9

Try either ropeDestroy or ropeCut.

Yes, switch is case sensitive. I compensated for that in my original post by making everything lower case using the toLower command. EDIT: removed new code, values were wrong and oyu already figured it out. EDIT 2: I looked at your code again and the only thing wrong I see is the default for the switch. The way you have it now, the first value of 30 will be removed even if a different condition is found. You can use a default in the switch though. _maxShots = switch (_class select 1) do { case "AssaultRifle": {120}; case "Handgun": {150}; case "MachineGun": {210}; case "Shotgun": {60}; case "Rifle": {90}; case "SubmachineGun": {150}; case "SniperRifle": {30}; case "Launcher": {0}; default {30}; };

Good news! According to today's dev branch update, progress bar colors can now be changed with ctrlSetTextColor http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2870115&viewfull=1#post2870115

Change it to this and the default will be 30. EDIT: or the easier method. I should of thought of that first... _maxshots = 30; if (_silencer == "muzzle_snds_B") then {_maxshots=30}; if (_silencer == "muzzle_snds_H") then {_maxshots=60}; if (_silencer == "muzzle_snds_M") then {_maxshots=90}; if (_silencer == "muzzle_snds_L") then {_maxshots=120}; if (_silencer == "muzzle_snds_H_MG") then {_maxshots=200}; EDIT 2: You could also do it without classnames using BIS_fnc_itemType _weapon = currentWeapon player; _class = _weapon call BIS_fnc_itemType; // returns ["category","type"] ie ["Weapon","SubmachineGun"] _maxShots = switch (toLower _class select 1) do { case "assaultrifle": {30}; case "handgun": {60}; case "machinegun": {90}; case "shotgun": {20}; case "rifle": {30}; case "submachinegun": {60}; case "sniperrifle": {10}; case "launcher": {0}; };

You need a cool metal breaking sound effect to go with it too!

BIS_fnc_helicopterGetHitpoints can return a list of a vehicles hitpoints in a nice array. The easiest method I have found. It works on all vehicles. It's from TOH so that's where the name comes from.

You can use the method BIS uses... something like this, using their function // returns varName if it has one, or assigns one if not _oldVar = _oldVic call BIS_fnc_objectVar; deleteVehicle _oldVic; // from your script _newVic = createVehicle [/* code */]; // from your script // assigns _newVic the same var names as _oldVic _newVar = [_newVic,_oldVar] call BIS_fnc_objectVar; but the problem may be that the script is not running again for the new vehicle _newVic = createVehicle [/* code */]; // from your script _script = [_newVic] execVM "respawnScript.sqt";

The BIS respawn module function already does it via BIS_fnc_ObjectVar. Which is a quite useful function for setting a var name and syncing it across the network.

Oh, ok. I guess I was confused. I seem to have skipped over the line, "Heres what i have not including the waypoint portion.". Be sure to read the rest of Fockers guide. It was invaluable to me when I was first getting started.

In your addWaypoint command, you have _Group, not GrpOne. You are giving the waypoints to yourself (or the parameter that is sent to the script), not the created units. If you launch with -showScriptErrors, the game will tell you errors. Also, fockers guide should of covered topics like _this select 0, which selects the first position in the array _this. If you are calling the script from an addAction attached to yourself (the player), then the array _this consists of [object with action, caller, addaction id]. _this select 0 is selecting the first element in the array, the object with the action attached.

Sure... What I got from this was he wanted the inventory, but on a shoebox.. Though, he worded that like it was just an example and the inventory was not the goal, the model was. I guess if you really want to do it, you would have to script a weaponHolder onto the shoebox object and use that as an inventory. But if you hide the weaponHolder, can you still access its inventory? Maybe through the action command. Perhaps something like this could work... _box = createVehicle ["Land_WheelieBin_01_F", getPos player, [], 0, "CAN_COLLIDE"]; _gear = createVehicle ["WeaponHolderSimulated", getPos player, [], 0, "CAN_COLLIDE"]; hideObjectGlobal _gear; _gear addItemCargoGlobal ["FirstAidKit",5]; _box addAction ["Open Box",{_this select 1 action ["Gear",_this select 3]},_gear]; As for replacing an objects model, that cant be done without an addon.

No, the function can read it as well. FT_fnc_add = { (_var0 + _var1 + _var2) }; // no params sent to the function _var0 = 0; _var1 = 1; _var2 = 2; hint str (call FT_fnc_add); // "3" This has some uses too but nothing that great that I can think of off the top of my head... Maybe if you are constantly defining the same local vars in different scopes... you can have a global function like that to do more complicated tasks. However, using parameters instead makes a function much more robust, since you don't always have to use the SAME local variables. It works the same way you would use a local function or a #define function. // essentially it looks like this to the engine hint str (call { (_var0 + _var1 + _var2) }); // "3

I will try to explain the difference to you and explain why it is happening like that. However, I am by no means an expert and if any/all of this is wrong, someone please correct me. I'll probably explain some stuff you already know, but in case you don't... Okay, First thing, functions! Functions are essentially a global variable with code attached to them. They save time by not having to rewrite the same code over and over. Plus they keep code looking nice. // First, define a function FT_fnc_add = { /* addition math code here */ }; // then call that function _params call FT_fnc_add; // the engine sees this as _params call { /* addition math code here */ }; Now, variables! Specifically local variables and private variables. A private variable will always be a local variable but a local variable will not always be a private variable. Now, NOT privatizing variables can be useful, but not commonly used. There are some BIS functions that will modified the original variable parameter instead of creating a new one. I'll make a simple function to show you the adverse effects of not privatizing and having local variables with the same name. // lets make a simple functions for adding two OR three numbers together FT_fnc_add = { _var0 = _this select 0; _var1 = _this select 1; _var2 = if (count _this > 2) then {_this select 2} else {0}; // optional third number, 0 by default (_var0 + _var1 + _var2) }; notice how they are NOT private // Now lets use that function private ["_var0","_var1","_var2","_add"]; _var0 = 0; _var1 = 1; _var2 = 2; hint str _var2; // will show 2 _add = [_var0,_var1] call FT_fnc_add; // adds variables 0 & 1, but not 2 hint str _add; // will show 1 hint str _var2; // will now show 0 hint format ["_var0: %1 | _var1: %2 | _var2: %3 | total: %4",_var0,_var1,_var2,_add]; // shows "_var0: 0 | _var1: 1 | _var2: 0 | total: 1" Since _var2 was an optional parameter, default set it at 0. However, since it was not private, _var2 in my script was changed to 0 as well. That would not happen if it was private. Long story short, using a function looks like this to the engine: // Now lets use that function private ["_var0","_var1","_var2","_add"]; _var0 = 0; _var1 = 1; _var2 = 2; _add = [_var0,_var1] call { _var0 = _this select 0; _var1 = _this select 1; _var2 = if (count _this > 2) then {_this select 2} else {0}; // optional third param (_var0 + _var1 + _var2) }; When you look at it like that, you can see how your local variable is getting changed by another script/function.

Not possible without making an addon.

One of the functions is changing the variable. Make sure to privatize your variables to avoid this.

You'll want to use ctrlSetText and buttonSetAction.

Great functions guys! Very useful. Thank you.

Since these are hitpoints and not selections (what setHit uses), you would use setHitPointDamage. // 0 - no damage || 1 - full damage vehicleName setHitPointDamage ["HitVRotor",1]; EDIT: word of caution, setting "HitEngine", "HitBody", or "HitFuel" above ~0.75 will usually cause the vehicle to explode.

well, it returns an array of all a vehicles hitpoint names in strings. For example: ["HitEngine","HitRotor","HitRFWheel","HitGlass1",etc,etc]; So, if you want to see a list of all the GhostHawks hitpoints, you could use a hint, or send it to the rpt file, or copy it to clipboard. // hint in game hint str (vehicleName call BIS_fnc_HelicopterGetHitpoints); // print to rpt file diag_log (vehicleName call BIS_fnc_HelicopterGetHitpoints); // copy to clipboard copyToClipboard str (vehicleName call BIS_fnc_HelicopterGetHitpoints); just use the debug console to run one of those

BIS_fnc_helicopterGetHitpoints Works on all vehicles, not just helos

The link was already in his post. Here it is again: http://feedback.arma3.com/view.php?id=20750

The last one worked for me through the debug console. Edit: both of these version worked for me. player addEventhandler ["killed", { _files = ["killCamShort2.sqf", "killCamShort.sqf", "killCam.sqf"] call BIS_fnc_selectRandom; _script = format ["deathCam\%1",_files]; handle = [(_this select 0),(_this select 1)] execVM _script; } ]; _files = ["killCamShort2.sqf", "killCamShort.sqf", "killCam.sqf"] call BIS_fnc_selectRandom; _script = format ['[(_this select 0),(_this select 1)] execVM "deathCam\%1"',_files]; player addEventHandler ["killed",_script];

Oh, i think eventHandler code is in its own scope. The above local variables are not defined within. player addEventhandler ["killed", { _files = ["killCamShort2.sqf", "killCamShort.sqf", "killCam.sqf"] call BIS_fnc_selectRandom; _script = format ["deathCam\%1",_files]; handle = [(_this select 0),(_this select 1)] execVM _script; } ]; Sorry about the compile comment. I was thinking call, not execVM. The difference is you call code rather than a string. Or try using a string instead of code: _files = ["killCamShort2.sqf", "killCamShort.sqf", "killCam.sqf"] call BIS_fnc_selectRandom; _script = format ['[(_this select 0),(_this select 1)] execVM "deathCam\%1"',_files]; player addEventHandler ["killed",_script];

use compile to turn string to code

Unfortunately, you can't. This is because it is set through "texture" and not "color". I was able to get around the issue by creating a second, separate progress bar. It went something like this. _var = 0.4; // 0.0 - 1 If (_var > 0.3) then { _blueCtrl progressSetPosition _var; _redCtrl progressSetPosition 0; } else { _blueCtrl progressSetPosition 0; _redCtrl progressSetPosition _var; }; This way, if _var is less than 0.3, the red bar shows. If it is over 0.3, then the blue bar is shown. You could potentially make it much more intricate. Just know, you need a different control for each color; since its defined in the GUI config class.