Heeeere's johnny!

As of 14 November 2015, 0:10 GMT: 3 explosions in Paris (two explosions roughly 16 and 20 minutes into the football match Germany vs. France) Avenue Jules Rimet (in front of Stade de France) Métro-Goncourt Boulevard Voltaire corner Passage Saint-Pierre Amelot 35+ dead police confirmed: at least one explosion was a suicide bomber 6+ shooting scenes, including the shopping mall "Les Halles" and the square "Place de la République" 60-100 hostages taken in concert hall "Bataclan"police stormed the hall two assassins were killed an unknown number of hostages were killed president François Hollande declared emergency rules in France as a whole (not only Paris) and closed France's borders german football team is still in the stadium several subway stations closed, some tracks will stay closed the next days schools and universities in Greater Paris stay closed this Saturday (in France, School is Monday, Tuesday, Thursday-Saturday) unconfirmed rumours:reportedly two dark-dressed, not-masked young men shooting with AKs in concert hall "Bataclan" reportedly one of the shooters shouted "C'est pour la Syrie" ("That's for Syria") (France is bombing ISIS camps in Syria) reportedly two assassins are still on the run

I'm aware of that, but that does not include granades, satchels and other stuff.

Just out of curiosity, why do you need playableUnits and switchableUnits? And could you not solve the first part of your trigger statement with a setTriggerActivation statement?

Dunno if even with the quadbike that's the very intention actually. With the parachute, I agree, that shouldn't count into the "invulnerable in vehicle" case. But consider it not a bug, but rather a feature, since shooting paratroopers is a war crime. ;)

Touché! Nevertheless, I guess we all agreed on the principle, regardless the copy-paste-ability.

As an alternative approach - correct me if I'm wrong, but afaik - if you don't set a trigger area, the trigger should work for every unit on the map: _trigger = createTrigger ["EmptyDetector", [0, 0, 0]]; _trigger setTriggerStatements [ "player != vehicle player", "player allowDamage false", "player allowDamage true" ]; Nevertheless, I agree with terox on bull_a's solution.

Indeed, I'd really love that. The thing is, when it comes to CSS, there's certain things that would have to be ommitted, because they can't be handled by the "dialog engine" (if that's even the right way to say it), like for instance "tranksform" or tilting objects. Or there's gotta be a BI-custom css-free and "style"-tag-free way to style HTML dialogs for ArmA.

It's fairly simple while {condition} do { //do stuff here }; As long as the condition returns true, the while loop will continue to run. So if you simply put a variable which has the value true inside the condition and you don't change that variable somewhere, the while loop will infinitely run.

If you have a look inside some vanilla PBO files, like ui_f_data.pbo, you will already find some HTML files. In fact, there is a support for HTML files already in place as you can read up in the BIKI pages for HTML-Files and DialogControls-Text. But I personally have not managed to include an HTML file as a dialog into one of my missions, because it's not as intuitive as I hoped.

Not that I would want to advertise my content, but I reckoned this to be the easiest and fastest way: _safezoneTrigger = createTrigger ["EmptyDetector", _yourSafezonePosition]; _safezoneTrigger setTriggerActivation ["ANY", "PRESENT", true]; _safezoneTrigger setTriggerArea [10, 10, 0, false]; _safezoneTrigger = [ _safezoneTrigger, {_x allowDamage false;}, {_x allowDamage true;}, true ] call fnc_triggerListChanged; Using this little script: [sCRIPT] Trigger List Changed v2.1 - Handle units which entered/left a trigger's list That way, every unit entering the trigger area (Safezone) is invulnerable. Every unit leaving the trigger area is vulnerable again. EDIT: I'm not sure right now whether this also affects the vehicle's crew, but I believe it doesn't. You might need to add some respective code to the trigger list lines above: if (_x isKindOf "Car") then {{_x allowDamage false;} forEach (crew _x);} if (_x isKindOf "Car") then {{_x allowDamage true;} forEach (crew _x);} Only the unit activating the trigger gets its allowDamage set.

Well, in your case, you are lucky, because code inside the trigger statements is always executed on every client connected to the server (including the server itself). Nevertheless, once your trigger is done, any player connecting to the server after the mission has started will not have that event handler. But if no player connects to the server after mission start, it's fine.

You can use the code like that, yes. But you need to be aware of two things: 1) The event handler should be executed server side (in a multiplayer mission), because it will only work on the machine where the event handler was added. 2) "HandleDamage" will be executed for every damaged part of the unit. That means, if a granade causes the damage, your prisonner_ai.sqf will be executed many times. 3) "HandleDamage" will continue to trigger even if the unit is already dead. You can read the details here: https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#HandleDamage

I'm confused. So you execute your prisonner_ai.sqf script IF the units damage is lower than 0.8. But that means, the script is always executed unless you manage to create a damage of 0.8 or more with one shot without killing him, did I get that right?

I'm not 100% sure, but I assume that the resulting damage is regarding the "selection" (body part) where the unit is hit. So, instead of checking the damage value returned by the handler, check the damage of the unit. The problem with that is that the unit's damage value is updated after the EH is done (I'm also not 100% sure on that). So a workaround would be to spawn a script inside the EH which does the job: { _x addEventHandler [ "Dammaged", { _this spawn { sleep 0.5; _unit = _this select 0; if (damage _unit >= 0.9) then { _unit execVM "hostage\prisonner_ai.sqf" }; }; } ]; } foreach thislist Also, instead of using the (old) "Dammaged" EH, try the (newer) "HandleDamage" or "Hit" EHs.

Well, have a look at the above line and search the "}" which is closing that for-loop. You will not find it, because it's missing. Now, let me show you how I would have indented your code. Since I can't understand it either, you decide whether that's correct. Note that there is a ";" (semicolon) on line 7 when it has to be a ":" (colon): case opfor; { Also, have a look at line 126 to 134: Is that going to work? I doubt it. Please, for the sake of saving life time and nerves, start your ArmA 3 with the startup parameter -showScriptErrors (with the leading "-"), because it's going to show you things like that! And finally, let me tell you on behalf of I guess all of us who posted here: You cannot expect the community to help you if you provide obfuscated code like this. It doesn't matter if you provide a list of what these obfuscated variables mean. If we cannot read the code as-is, we won't help simply because WE CAN'T.

BIS_fnc_listPlayers is obsolete since command allPlayers. BIS_fnc_param and BIS_fnc_MP are already mentioned. Since you can use find toLower _someString to search if something exists in a string, I consider BIS_fnc_inString obsolete, too. But speaking of strings, I'd even like to have a command like findLast which finds the last occurance of a "needle" in a "hay stack". For those who follow proper naming conventions, this can simplify a lot of stuff with simple one line string sub selection. I had to write a custom function for that. Not a big deal, but it's pretty essential to all my larger projects and sometimes very intensively used, so speaking performance here, a scripting command could improve that to some extent. * What functions would benefit from dedicated scripting command? - BIS_fnc_relPos - BIS_fnc_dirTo - all stacked event handler functions At least I am using latter fairly heavily, often even adding one on key down and removing it on key up again. Since we all know that "EH" is an abbreviation for "event handler", wouldn't it be sufficient to shorten a potential future scripting command to "addStackedEH"?

To my knowledge, setDammage doesn't do anything in ArmA 3 since this is a depricated (and incorrectly spelled) command. Use setDamage instead.

I'm kindOf a freak when it comes to code performance, so yes, this is my nitpick of the day. :D You're right, who knows what code already runs and whiles and waits until ... just because ArmA is running. Still, good coding behaviour will sooner or later pay off when all the little things people do out of lazyness or because "it doesn't matter" start to stack up and in a sum will actually matter. A simple example I witnessed was a life mod with dozens of addAction statements which partly had very complex conditions. One or two complex conditions won't actually matter. But with a bunch of them, you could see a massive drop in frames compared to playing without all these actions. And a lot of these actions had conditions containing "playerSide == west" which you could easily avoid if you only added the action in the first place, IF the player has the respective side.

... especially because waitUntil "only" runs (roughly) on each frame, but while runs as quickly as possible which is a bit of an overkill for this purpose, if you ask me.

Thanks Dreaded, rydygier and ceeeb made me already aware of such loop holes. ;)

What is the longest syntactically correct string of scripting commands you can create? To setup the rules: - only scripting commands, spaces, brackets: ( ) [ ] { } and logical operators: = ! & | , ; ? : < > + - * / ^ % - no functions - no global, local or special variables (like _x, _forEachIndex etc.) - no strings (meaning anything wrapped in quotes) - no numbers - no dull repetitions like infinitely long switch-case blocks or if (true or true or true or ... ;) Let's make two categories: 1) number of words only the number of words is important, not their length 2) number of characters only the number of characters (excluding logical operators and spaces) is important, not how many words they come from Here's a starter: diag_log str ((getPosATL (allPlayers select floor random count allPlayers)) select floor random count getPosATL player) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 words and 99 characters The above code grabs the position of a random player and prints a random value of that position into the RPT log. Have a nice Play! Johnny PS: If you find any loop holes in the rules to create infinitely long strings, please let me know. ;)

@all, please don't feel discouraged by Larrow's response. He's playing in another league (no offense ;)) and I'm still curious about the community's creativity! :D I consider as special variables basically any local variables, which do exist in certain code blocks or event handlers or whatsoever, because "the engine placed it there", like _this in basically any script/function or _x and _forEachIndex in the forEach loop or _pos, _units, _shift, _alt in the onMapSingleClick EH. I must admit, I am fairly partly amazed since this massive script produces an output, but testing it as driver in the B_MRAP_01_hmg_F, it gave me a -1. I wonder if that's correct... As long as the repetition is needed for an actual purpose and can't be avoided, I'd say it's fine. :rolleyes:

Thanks! :) ... and yeah, rules updated. ;)

You may create infinitely long arrays, that's true ... and dull. :P But you can't select using a number, because numbers are forbidden by the rules. ;)

I don't know if there's any specific command to enable/disable mines, but try enableSimulation. There are some different approaches which come to my mind, depending on how you created the mines. If this minefield contains all mines throughout the map, you may iterate over allMines and disable them all. If you create them by script (not in the editor), you should put them into an array which you can then setVariable to the trigger which then can be gotten by the respective trigger statement and be iterated through. If you create them in the editor (which I assume), you can create a location covering all mines in that mine field, then iterate through allMines and check for each mine, whether it's in the location, so you can determine which you have to disable.