st_dux

There's no reason for argument passing not to work with onMapSingleClick. My guess is that you forgot to double up your quotes somewhere. Paste the onMapSingleClick line that's not working right, and I'll tell you why.

I'm not sure that it would. It's an old trick from ArmA 1 for having Searchlights that don't need to be manned. But yes, it used to work with moveInGunner. Give it a go and see what happens; if the game logic works, then I can probably come up with a remote control scheme.

Try putting a game logic in the gunner seat.

You can pass arguments to the script in the array preceding "execVM." Instead of having to go back into the script each time you wish to change a variable, simply pass those variable as arguments in the script call and have the script retrieve them via the special local variable, "_this". e.g.: Script Call: ["argument1","argument2",42] execVM "myScript.sqf" Script: _arg1 = _this select 0; // first element in passed array,string "argument1"; _arg2 = _this select 1; // second element in passed array, string "argument2"; _arg3 = _this select 2; // third element in passed array, number 42; // you can now use these local variables in your script, and when they are changed in the script call, they will be changed for the script

You must have something else in your mission that is causing the join to happen. Nothing below a waitUntil command will be executed until the condition is met, and since at least two of the waitUntil commands are working according to you, there is no explanation within the script as to how the join could be taking place immediately. In any case, the last waitUntil was designed to work with a dedicated sniper team group of two people; having more than two people in the group screws up the count in the waitUntil condition. To make it work with the way you've set it up, use the following: waitUntil {{vehicle _x == _x} count [teamSniper,teamSpotter] == 2}; [teamSniper,teamSpotter] join player; This still doesn't explain how the join is happening immediately, though. The way you had the waitUntil command set up, it should have never returned true. You'll have to do some troubleshooting to discover what it is in your mission that is causing the premature join. Also, how are you calling this script?

What happens when you do this? unitname fire ["pipebombmuzzle", "pipebombmuzzle", "pipebomb"] Also, addWeapon shouldn't be a problem in multiplayer. Make sure that the code is being executed on the server, not some client.

First, you will need to establish a list of UIDs for your whole clan. Put each UID in quotes, and separate each one with a comma. Now put that list in brackets, and voila, you have the master array to check against. Establish this array in the init.sqf file of your mission (if you don't have such a file, create one). You can put it anywhere you'd like in that file; it should look something like this: masterUIDArray = ["xxxxxxx","yyyyyyy","zzzzzzz"]; Now, copy and paste the following line into the initialization field of each vehicle for which you want access to be restricted: this addEventHandler ["GetIn",{if (getPlayerUID (_this select 2) in masterUIDArray) then {hint "Clan member confirmed -- Good Hunting!"} else {(_this select 2) action ["getOut",(_this select 0)];hint "You are not authorized to use that vehicle!"}}] And that should do it.

@FuzzyBandit: I believe the OP was using checkInside as a variable switch, although that isn't needed. Your suggested line in red would work, but it would only check for the sniper, not the whole team. Using a conditional count, as shown in my example code, allows you to wait until both are out, just to be sure.

As a general tip, ArmA 2 comes with a built-in function for spawning fully-crewed vehicles, which I recommend using: http://community.bistudio.com/wiki/BIS_fnc_spawnVehicle As for the issue with unloading the sniper team and the timing thereof, try something like this (assuming .sqf): _helo = (insert name of helicopter here); _sniperTeam = (insert group name of sniper team here); // move sniper dudes into helo {_x moveInCargo _helo} forEach units _sniperTeam; // have helo fly to LZ _helo move (getMarkerPos "Sniper_Infil"); // wait until helo is over LZ, then force helo to land waitUntil {unitReady _helo}; _helo land "LAND"; // wait until helo is near the ground, then tell the sniper team to get out waitUntil {(position _helo select 2) < 5}; {unassignVehicle _x} forEach units _sniperTeam; // wait until sniper team is out, then have them join the player and make the helo RTB waitUntil {{vehicle _x == _x} count (units _sniperTeam) == 2}; (units _sniperTeam) join player; _helo move (getMarkerPos "Sniper_Spawn") For stuff like this, it's generally easier to avoid waypoints entirely EDIT: Also, your usage of the comparison operator, "==", is incorrect. {checkInside == true} should simply be {checkInside}, and {checkInside == false} should be {!checkInside}. The comparison operators return a boolean value, but they cannot take boolean values as arguments, as that would be redundant.

CQB is absolute crap in ArmA 2: - Control is clunky as hell and feels robotic **** This is always the case in ArmA 2, but it matters a lot more in CQB. - Grenades are essentially unusable in a CQB context **** Nearly impossible to aim **** Bad, slow throwing animations **** Non-existent (default) or terrible (with ACE) grenade physics - No way to easily lower your weapon, so it gets "caught" on walls and other shit all the time, making it difficult to turn quickly or at all **** This problem could be circumvented by removing collision detection on weapons, but BIS doesn't want to do this

Actually, you can still do the right-click-targeting thing if you open up the target menu first. It's silly, but it works.

I can understand the computer performance issues (especially with ArmA 2), but I really don't get the "because it's just not the same" argument. ArmA 2 actually is basically the same as OFP: same engine, same basic mechanics, same style of gameplay. The only difference is that it has been improved in many ways, including vastly enhanced visuals, a plethora of new scripting commands and mission editor features, and far better AI. Sure, there were some great mods for OFP, especially WGL, but ArmA 2 has mods like this, too. ACE is the spiritual successor to WGL, including all of its core features and generally improving upon them. So where's the disadvantage here? The only thing you could say that OFP really had that was way better than its successors was its campaigns (CWC and Resistance). They were truly awesome, especially for their time, and neither the ArmA nor ArmA 2 campaigns have really been able to rival them. Once you've finished those, though, the newest version of OFP (i.e., ArmA 2) is clearly superior to the oldest version (even though OFP was a great game that I played to death).

Use cutRsc for your picture and titleText for your text. I believe that will work.

Purely out of curiosity, why would you join the OFP community now, nine years and two sequels after its release? ArmA 2 is just a very highly upgraded version of OFP, you know.

I don't understand the point of a few of these functions. Why create a function for distance when such functionality is already built into the game?

There is no reason to launch a script if you're going to use a trigger anyway (which would be the easiest way to do it). Simply make the trigger timeout value 2 seconds (make sure you use timeout, not countdown) and have the bomb created in the activation field of the trigger. If you want this to work on a dedicated server -- or any multiplayer environment, for that matter -- make sure that the bomb is created only once using an if statement server check. As an example: On Activation: if (isServer) then {nul = createVehicle ["ARTY_Sh_81_HE",position nameOfCrate,[],0,"CAN_COLLIDE"]} If you don't use a server check, then the code will be run on every machine and then broadcast to every machine (because createVehicle is a global command), meaning you would spawn one bomb per client + one for the dedicated server. With a high player-count, this could cause latency issues (not to mention it would look ridiculous). NB: nameOfCrate in the example needs to be changed to the name you have given the booby-trapped crate, and the class name for the type of bomb/shell to spawn can be changed to whatever you'd like.

Is there any way to disable it? I am creating a scenario where I want to blow up some static, empty tanks with satchel charges, and the ACE Armor Damage System makes this incredibly unreliable and seemingly random. I've found that it can be turned off by removing all HandleDamage event handlers from the tanks, but then none of the default damage effects are there, so the tank dies with zero visual cues. Anyone know of a proper way to turn this thing off?

Before doing anything with conversations, you need to get yourself an FSM editor. The AI-side of any conversation in ArmA 2 must be controlled by an FSM, so if you are unfamiliar with FSM editing, familiarize yourself with that first. Basically, the whole system works by automatically running scripts (for the player) or FSMs (for the AI) whenever kbTell is used. These scripts/FSMs can then be used to initiate more kbTells, creating a whole converstation. The kbAddTopic command is what ties everything together. In order to give the player choices, you need to use an apparently reserved variable, BIS_convMenu. A typical player conversation script will look like this (taken from the official mission "Dogs of War"): // collect reactions to BIS_convMenu _this _from _topic _sentenceid BIS_convMenu = []; //debug if (!isNil "BIS_DEBUG_DIALOG") then { if (_sentenceId!="") then { debugLog format["DIALOG- SQF of %1 initiated by %2 _sentenceId %3 sentence %4",_this, _from, _sentenceId, localize ("STR_"+"_sentenceId")]; }; }; switch (_sentenceId) do { case "beginning_cdf_briefing_S_2": {//USEUCOM say we're close to convincing Moscow that NAPA had nothing to do with the bombing. Without that the Russians've got no reason to be here. if (BIS_evidenceGathered >= BIS_evidenceNeeded) then { _this kbtell [_from, "beginning_cdf_briefing","beginning_cdf_briefing_C_1"]; //We may even be able to redeploy the MEU. It seems we got enough evidence to convince the rest of the Security Council. } else { _this kbtell [_from, "beginning_cdf_briefing","beginning_cdf_briefing_C_2"]; //I think there's no chance of the MEU returning any time soon. The weight of evidence just wasn't enough to convince the Security Council to reinstate US control. }; _this kbtell [bIS_CDFBegunov, "beginning_cdf_briefing","beginning_cdf_briefing_C_3"]; //Anyway, what do we do? }; case "beginning_cdf_briefing_B_4": {//You keep to your brief. Support the Chernarussian forces on the ground. However, due to your heroic efforts in the Sobor region, I am ready to offer you command over the operation. BIS_convMenu = BIS_convMenu + [[ localize "str_command_yes", _topic, "beginning_cdf_briefing_C_4", []]]; BIS_convMenu = BIS_convMenu + [[ localize "str_command_no", _topic, "beginning_cdf_briefing_C_5", []]]; }; case "beginning_cdf_briefing_B_7": {//You can still report to Marny and Stavovich here in the base for orders and intel but other than that you've got free reign to retake the north as you see fit. _this kbtell [_from, "beginning_cdf_briefing","beginning_cdf_briefing_C_6"]; //Thank you Sir. With your permission, we'll get started. }; }; // return the result BIS_convMenu BIS_convMenu is an array of arrays, each of which takes four arguments: 1. Text to show up in the menu (string) 2. Conversation topic as established using kbAddTopic (string) 3. Sentence ID of sentence to be said if option is chose, as defined by the bikb file tied to the conversation topic (string) 4. I suppose this is for optional arguments, but I've only seen it used as empty array (array).

I've actually figured out how to use the conversation system. I've even figured out how to use it with the conversation menu (that menu where you can choose your response). But I still have no idea what "call RE" means. Is that some sort of hard-coded function? How does it work? I AM SO CURIOUS.

I've had a look through some of the missions that come with the game to try and figure this conversation stuff out, and I keep finding a lot of lines like this: _nic = [objNull, m1, rKBTELL, m4, "global", "s012"] call RE; Can someone explain to me what "call RE" does? Is kbAddTopic even necessary? I never see it used in official missions. I just see a ton of these calls to the mysterious "RE."