Heeeere's johnny!

Yes I have and I did at first until I realized that intersect does not work with slider doors (like in the hospital) and I'm not sure if it works for fences like in ArmA 2. That's why I did the trigger approach. But as you may have seen, the triggers are only created in a certain area around players and they are removed as soon as no player is near a "trigger filled" building anymore, so I tried to keep the amount of simultaniously existing triggers as few as possible. But a few weeks ago, I saw that for at least some buildings, there is a generic approach without the need for huge lists of building positions. But I'll have to reseach that again as I cannot remember how it went, but if it works for all buildings, that would be a nice way to make this script map independent.

Hey guyz, thanks for the heads-up. Sorry that I was inactive lately, but I'm currently writing my diploma thesis, hence I don't have much time left for anything else. But I'll do my very best to step-by-step update the script and will notify you as soon as it's done. Please be a bit patient since in case of doubt my real life goes first. :) Have a nice Play! Johnny

You seemingly didn't tell that guy you were talking to, that you need your code to work with A2, because getAllHitPointsDamage is a command introduced in A3 v1.50. Since the syntax of the code you posted is incomplete, but you seem to have some solution already, I'd like to clearify for myself what exactly you mean by "damaged track or wheels". Do you want your event handler to only fire when at least one wheel is completely damaged?

As I understand it from looking at this, the "expression" in that array is the very "expression" as defined in the CfgCommunicationMenu. So I wonder if it's even possible to put the other labels like "text" or "enable" in there as well.

So what's the difference between the following two lines? _position in _location _position inArea _location Are they both actually the same or is one better than the other?

What does the title of your question have to do with a trigger and how are you trying to prevent enemies from spawning? Please be precise about what you try to do and what exacly does not work. And if it is important for the problem, please give a short info about what an MSO mission is for those who don't know.

Well, let me put it this way: In multiplayer, createTrigger broadcasts the trigger creation throughout the network, having said that I don't know whether this also counts for editor created triggers. Either way, I only know in this particular case, a rather inconvenient way of getting the same trigger statements on both server and clientside, for the client should play the sounds and the server should handle anything else regarding the units in the radiation zone. But assuming, you've established that, the easiest way is to find out how many seconds the sound file plays and then put it in a "while in radiation zone" loop with a sleep of the length of the sound file. In the trigger, it should look like this (untested): //condition: player in thisList //onAct: thisTrigger setVariable ["geiger", 0 spawn { while {player in thisList} do { player say3D "GeigerSound"; sleep 5.3; //if the sound is 5.3 seconds long }; }]; //onDea: terminate thisTrigger getVariable "geiger"; That way, the say3D will be done every x seconds, when the previous play is done.

"Actively engaging" triggers my cerebral database to autoquery for "fired event handler". But I'm too tired to write one right now. Let me see if I got that straight. If you set your trigger's condition to the following, it will never activate if an opfor unit is in the trigger area: this && 0 == {if (opfor == side _x) exitWith {1}} count thisList The trigger area is the area defined by the shape (ellipse or rectangle) and the sizes (width and height).

That would need to be added to the trigger, but clientside. But you can surely add a custom sound file to your mission and use say3D to play it.

You are obviously making the effort to bring object orientation to a non-object-oriented language which is a great thing if you ask me, because I honestly miss it in SQF. Having said that, I've never really used it yet, only watched your code to find out, how you've done it. ^_^ It's just that I've learned very quickly, how powerful databases are and I wouldn't wanna miss SQL for persisting text and numbers like in case of ArmA 3. The only reason(s) I can imagine why people would not use a true database for persisting data, is that they either don't want to learn SQL or they simply don't care how their data is stored as long as it's stored at all. I hope you can understand why I cannot like iniDB. Sorry, don't mean to offend you.

As far as I know, few people actually use real databases. From what I've heard so far, many scripters rely on plain and simple data persistence, such as iniDB. I personally consider iniDB horrible compared to the power and speed of an actual database, but nevertheless, maybe most people, if they use extDB, just use it as-is and don't see the need for an OO wrapper as you created it. :unsure:

Why do you need a trigger for that?

The following code works, when I replace the projectile with any other object, but I can't seem to find a way to get the action show up on the (smoke) grenade / light stick. player addEventHandler ["Fired", { _projectile = _this select 6; _projectile addAction ["Pickup this object", { _params = _this select 3; deleteVehicle (_this select 0); hintSilent _params; }, "You have picked up this object", 3, false, true]; //the following is just for visual tracking purposes _ehCounter = player getVariable ["ehCounter", 0]; _ehName = format ["eh_throw_%1", _ehCounter]; player setVariable ["ehCounter", _ehCounter + 1]; _arrow = createVehicle ["Sign_Arrow_Large_F", getPosATL _projectile, [], 0, "CAN_COLLIDE"]; [_ehName, "onEachFrame", { if (alive (_this select 1) && time - (_this select 3) < 10) then { (_this select 0) setPosATL getPosATL (_this select 1); } else { deleteVehicle (_this select 0); [_this select 2, "onEachFrame"] call BIS_fnc_removeStackedEventHandler; }; }, [_arrow, _projectile, _ehName, +time]] call BIS_fnc_addStackedEventHandler; }];

Another approach, which will also work on hilly terrain (because why not :D): _fnc_setDistance = { _params = _this select 3; _object = _params select 0; _object setVariable ["distance", (_object getVariable "distance") + (_params select 1)]; }; _object = createVehicle ["Sign_Sphere100cm_F", getPosATL player, [], 0, "CAN_COLLIDE"]; _object setVariable ["distance", 100]; _handle = _object spawn { while {true} do { _newPos = player modelToWorld [0, _this getVariable "distance", 0]; _newPos set [2, 0.5]; _this setPosATL _newPos; }; }; player addAction ["Move 100m Out", _fnc_setDistance, [_object, 100]]; player addAction ["Move 100m In", _fnc_setDistance, [_object, -100]]; player addAction ["Release", {terminate (_this select 3);}, _handle];

In addition to DreadedEntity's answer, we can make this even a bit more compass-independent: _fnc_setDistance = { params ["_target", "_caller", "_id", "_params"]; _object = _params select 0; _distance = _object getVariable "distance"; //_distanceDiff = _params select 1; _distance = _distance + (_params select 1); _object attachTo [player, [0, _distance, 0]]; _object setVariable ["distance", _distance]; }; _object = createVehicle ["Sign_Sphere100cm_F", getPosATL player, [], 0, "CAN_COLLIDE"]; _object setVariable ["distance", 100]; _object attachTo [player, [0, 100, 0]]; player addAction ["Move 100m Out", _fnc_setDistance, [_object, 100]]; player addAction ["Move 100m In", _fnc_setDistance, [_object, -100]]; player addAction ["Release", {detach (_this select 3);}, _object];