loyalguard

Yes, create a trigger (either radio if you want the SL to request) or with a condition that when the helo enters. Then in the on act code of the trigger you can use isServer (if multiplayer) and the createVehicle command to spawn a vehicle. You can do all of this inside the triggers field and do need an external script.

Your efforts on this Kju are greatly appreciated!

It has been a long time since I messed with adding actions to units via configs/scripting, but from what I can recall, you need would need to add an addAction to the unit via an (extended) init event handler. The addAction would need to have a condition to only display the action if the unit had a specific item in inventory. Here is some example init EH code using a wet suit just as example pirposes (change to whatever is applicable -- does not have to be a uniform) to give the action (untested): _this addAction ["Activate Adaptive Camo", "adaptiveCamo.sqf", (arguments, 6, false, false, "", "uniform caller == ""U_B_Wetsuit""")] Then of course you need code for adaptiveCamo.sqf to change the texture of everything. I do not what you were trying before, but setObjectTexture might be an option but depending on the selections, I am not sure how much is replaceable. You would have to capture everything the unit is wearing and holding and then re-apply texttures or mod every possible item with the texture variants and switch them out for their counterparts. You know a lot more about textuing than I do so I defer to you on texturing issues. I hope this helps a little!

KevsnoTrev is correct that you cannot yet switch off the lights in the Alpha. Once this is resolved, I will release my ArmA Electrical Grids script pack and addon (see my signature for my projects links to versions for A1 and A2) for A3 that will make it easy to switch off lights in a specific area or the whole island. I have also found a way to include lighthouse, runway lights, and possibly other light sources (that are not affected by swtichLight). Until then, all you can do is destroy the lights or possibly use hideObject to hide them.

I just tried in the unit init line the following and it worked for a blur unit dressed in civ clothing: this addWeapon "ItemMap"; Give it a shot and see if it works in your scenario.

You can also check out the function BIS_fnc_codePerformance as well (you can find it in the functions viewer). It takes the following parameters: Parameter(s): _this select 0: STRING - tested expression _this select 1 (Optional): ANY - Param(s) passed into code (default: []) _this select 2 (Optional): NUMBER - Number of cycles (default: 10000)

I have found the method below (adjust the 5 as necessary) posted here by Deadfast to be effective: this && {((getPosATL _x) select 2) < 5} count thislist > 0 It basically says if the trigger is activated and there is at least one unit under 5m above terrain level then the condition is met. There is also a new A3 command, isTouchingGround that simplifies it further if you want to ensure they are on the ground (will not work for an aircraft at low height) this && {isTouchingGround _x} count thislist > 0

You can view the A3 grenade configs using the in-game config viewer, the SIX Config Browser, or Dev-Heaven's Community Modding Bible.

These threads have the latest information: http://forums.bistudio.com/showthread.php?152866-Development-branch-discussion http://forums.bistudio.com/showthread.php?153686-Hacked-by-a-player-with-no-ID

You can use the setRadioMsg command to make it invisible until you are ready for it to appear. Put this in your init.sqf: 1 setRadioMsg "NULL"; _nul = [] execVM "tenMinTimer.sqf"; Create a script callled tenMinTimer.sqf (or whatever you want to call it) and put this in it: sleep 600; // Wait 600 secs (10 mins) 1 setRadioMsg "Put Whatever You Want Here"; Good luck!

Yes, as long as the the function name is global and loaded into memory on all machines (or at least desired ones) they can be in different scripts. Also, you do not have to create a function at all, you can use BIS_fnc_MP to execute a .sqf script file (just like execVM) as long as the script file is already on the machine. See my second example in #29 in this thread. That way you can put your code in a script and not have to worry about creating a function.

There is the triggerActivated command that will return true if a trigger has been activated? Will that do what you need?

I would also recommend adding your tag in front of every instance of cb (IGIT_cb) and in front of your function (IGIT_disabling_MoveLeft) to identify them as unique to you and again so they cannot be overwritten or confused for commands.

Covered by radioman above.

1. You cannot upload files to the forum, you have to use a file host (or host from your own public dropbox or the like) and provide a link. 2. If you make "cb" a local variable, any reference to its value is lost after the functions ends as it only exists within the scope of the function. You would either need to pass it to another instance or return it to the calling instance. That being said, having it as a global variable works just fine because its value is acessible and updated inside and out of the function. 3. If the function and the event handler are added in the init.sqf or other code that runs on all machines, then it would be muttiplayer compatible, but, only the player that calls the function will see the border. A quick note about tagging your global variables, you should your tag in front of cb just to make sure it does not overwrite (or is overwritten) by another use of cb in the mission or any addons the player is using. Further, I see that you use the IG_ tag in the name of the .sqf. FYI , although not compuslory, the de facto standards for tags are 3-5 characters. More info here and here.

I believe the following would accomplish the same effect (appears on every machine). in the init.sqf or anywhere else as long as it is on every machine: // Create a function that will make a unit jump. fnc_switchMoveJump = { private ["_unit"]; _unit = _this select 0; _unit switchMove "AovrPercMrunSrasWrflDf"; }; in a script or other instance when you want to activate the animation: // Spawn the switchMove function passing to it the unit you want to animate, with no other parameters it will execute everywhere but JIP will not see it later. [[player], "fnc_switchMoveJump"] spawn BIS_fnc_MP;

This is untested but it should work. Paste this into blue1's init line: modelOffset = [0,-4,0]; worldPos = truck1 modelToWorld modelOffset; [color=#333333]blue1 setPosATL [worldPos select 0, [/color][color=#333333]worldPos[/color][color=#333333] select 1, 0][/color]; What this does is use the modelToWorld command to determine a four meter offset to the left of truck1 and then setPos blue1 there. I used four meters because the offset is from the center of the vehicle, not the side, so this makes sure you are clear of the vehicle. If distance needs to be be adjusted you can change it. I think -4 puts it to the left but I cannot remember if negative is left or right so if on wrong side just make the negative number a positive number (4).

I realize all the consternation over BIS_fnc_MP, but the beauty of that command is that it solves the above problem by giving you the option to call/spawn the function on the same machine as well. The parameter marked in red below (designated as target) can accept different types of values (see the link for details). When you use a boolean and make it true (or do not include it all by default), it will execute everywhere to include on the machine that called/spawned it. [[myArg1, myArg2], "myFunction", [color=#ff0000]true[/color], false] spawn BIS_fnc_MP; To expand further, if you do not want/need to create a function, you can also use BIS_fnc_MP to execute an already existing script to include passing arguments by using it to call/spawn the BIS_fnc_execVM function: [[[myArg1, myArg2], "myScript.sqf"],"BIS_fnc_execVM",true,true] spawn BIS_fnc_MP;

Here is a start: https://community.bistudio.com/wiki/Mission_Editor:_Debug_Console The expression field let's you run code without having to create a new script and execute locally (or globally if MP). The watch fields (four of them) allow you to enter an expression (or even a variable name) and see the current result, so if you put getPos player it would show your position. The buttons open the other features, camera mode is especially helpful.

You can try disableAI "AUTOTARGET" and see if that works. It often does for me. You might have to tell it to watch something first to make sure he is not looking in a random direction first.

I agree the debug console is a great tool for testing! Some other tips only for testing are: 1. Use the new camera feature of the debug console to see if units are behaving correctly without physically being there to observe. 2. Make the player invincible so you do not get killed and have to start over: player allowDamage false;(vehicle player) allowDamage false; 3. Use onSingleMapClick to instantly teleport the player anywhere on the map: onMapSingleClick "player setPos _pos; true;" 4. If you have a lot of objectives you can save each one as a single mission, test them individually, and then merge missions and connect them logically as necessary before the final test.

Just perusing the Biki and saw those and then the dev branch change log! Those are fantastic additions (and deletions).

It is possible to have a base and a mobile respawn point, you just need some sort of mechanism (automatic or manual) to determine where the player will spawn. Now, I lied a little, you can only have on respawn type. For "BASE" respawn, the player will always respawn at the respawn_west (or east) marker(s). So the way this will work is that after respawn you will teleport the player with setPos. If, you want this to happen automatically, you would set a condition that as soon as the player is alive again you teleport him or her. If you want it to be a manual decision by the player, you could use an addAction to give the player the option to choose to teleport to the mobile respawn point from the base respawn point. Here is some code: init.sqf // Execute a script to add a killed event handler to the player. _nul = [] execVM "killedEH.sqf"; killedEH.sqf // Make sure the player is alive. waitUntil {alive player}; // Add a killed event handler that will execute a specific script whenever the player is killed. _killedEH = player addEventHandler ["killed", {_nul = [] execVM "chooseRespawn.sqf"}]; chooseRespawn.sqf // Make sure the player is alive. waitUntil {alive player}; // Add code here to setPos the player, give him an addAction to choose to teleport to another position, etc.

Instead of the object, you could save the variable to the player himself (or herself).

The command getMarkerPos gets the coordinates for you automatically. So, if you want to move respawn_west to a different marker's location (well call it nextMarker just for this example) you would do this: "respawn_west" setMarkerPos (getMarkerPos "nextMarker");