Heeeere's johnny!

Hi everyone, I just had a discussion about licensing and ownership of content created using SQF. Now, we were pretty soon clear about licensing as there's a global thread about it. But we were not clear about who actually owns the code. Is the creator the rightful owner of that code or is Bohemia Interactive or an affiliated company the owner. If last was the case, where can I read that up? Kind regards, Johnny

Automated Doors - v2.5 Download v2.5 from Armaholic What? For each player on the map, this script creates and removes triggers on nearby buildings which open the door if a player intends to walk through it and closes it again, when he walks away. This script is configurable and customizable on both server and client side. Features: all doors open and close automatically usable in Singleplayer (client side) or in Multiplayer (server side only) support for dynamic locations where this script should only work support for side specific locations, where this script only works for players of the respective side actions for the following features: enable/disable automatically closing doors enable/disable "Automated Doors" completely irreversibly* remove all actions related to "Automated Doors" globally force doors to stay open, no matter what the player's actions say can be terminated and restarted without trigger-leftovers or action-leftovers minimized server load due to need-based dynamic object management available as script and as addon *) Actions will be available again, if you rejoin the server (MP) or restart ArmA (SP) respectively Supported maps: Altis/Stratis (combined in one file) Chernarus Takistan Zargabad Utes Why? At some point, I got annoyed of having to walk really close to a door and sometimes even having to scroll, if my default action is something different, to get the right action to finally open it. Maybe there's some people out there feeling similarly. How? Download the script here. (Armaholic, same link as above) execVM "automatedDoors.sqf" If you use Automated Doors on a map which is not listed above, but has buildings from one or more of these maps or if you want to override the script's default behavior, paste the respective map name(s) as parameter into the script like this: [["Altis", "Chernarus", "Takistan"]] execVM "automatedDoors.sqf" If you don't do so, the script will automatically take into account all maps. Singleplayer: Using the script: Execute the above line once upon mission start - that's it. Using the addon: Start ArmA 3 with startup parameter -mod=@automatedDoors - that's it. Multiplayer: Execute this script server side once upon mission start. Client side execution is prevented by "isServer" check. After joining a mission running this script, it might take a few seconds until it actually works for you as new player, because the sever runs the "scan loop" regularly, not taking into account JIP or just spawned players. Further Information "Automated Doors" has two optional parameters: maps -> (optional, default: "all") defines the buildings to be taken into account by this script -> e.g. ["altis", "chernarus"] means, all buildings from Altis and Chernarus will be taken into account doorsStayOpen -> (optional, default: false) global definition of door closing behavior - if true, doors will have to be closed manually, player action "Don't keep doors open" has no effect - if false, doors will close automatically, player action "Keep doors open" has an effect You can easily customize important values, like the size of the area of the door triggers, the time between each scan for surrounding buildings or the area to scan on each loop. Do that by changing the defines at the beginning of the file (after the comment block). Define locations: If you want this script to only work in certain areas, create locations of type "Name" and set their name with the prefix "doors". This script will check on each scan loop if such locations exist. If so, it will only manage these areas. If all "doors" locations are deleted, this script will handle the whole map again. Side specific locations: If you create a location as described above and setVariable ["locationSide", any side here] to it, the doors inside that location automatically open and close only for players of that side. Have a nice Play! Changelogs:

Trigger List Changed - v2.1 This script is about handling units which enter or leave a trigger's list or trigger area respectively. This is different from handling "thisList" or "all units inside/outside the trigger". It's easy to handle units in the trigger's "thisList", but handling only those which just entered or just left is a different story. Such distinction might be important for instance if a certain value/operation should be added/reduced/applied/executed only on such units or when a unit enters in the very same 0.5 seconds as another unit leaves, which would let the number of units in thisList remain unchanged while one unit is actually different. This function should be executed server side only! Feel free to use, adapt, expand (and maybe give credit if you consider it useful, I'd be grateful :)). Download v2.1 from Armaholic Changelogs: Have a nice Play!

Issues I've encountered so far (constantly updated): - you cannot take food, drinks or other "non-weapon" items into your hands which when having no clothing with slots is really frustrating as you starve for no reason - when standing on a stack of items, it seems random whether the yellow or white font is the selected item (when pressing "F" to pick one up) - player does not fire straight, instead the shot always flies to the bottom right - "water drinked" in summary (death screen) - "You have maked blood transfusion" when doing a transfusion of blood or salin Feel free to add your experiences and bugs/glitches.

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];

It does prevent collision.

A bit more information might be helpful for those who don't know what to do with that. That syntax belongs into the init field of the unit. But its also possible to make this a bit more generic, so it doesn't depend on a single unit: Before the car is hooked: {_x enableSimulationGlobal false} forEach crew _car; After the car is unhooked: {_x enableSimulationGlobal true} forEach crew _car;

Hi, yes, I know the reason for that. Your files are fine, no matter where they are. It's in my code and I'm already working on a fix and will provide you with the updated script as soon as I'm done. Thank you very much for bringing this to my attention! I really appreciate your help. Have a nice Play! Johnny

I see. Didn't know that giving the object a name made this possible.

Correct me if I'm wrong, but to my unsterstanding, this ain't gonna work unless _object is anything but an object, because you can't format an object into a string.

I think the GetIn and GetOut event handlers fit your needs best: chopper addEventHandler ["GetIn", { if (player == _this select 2) then { systemChat "You mounted the chopper"; }; }]; chopper addEventHandler ["GetOut", { if (player == _this select 2) then { systemChat "You left the chopper"; }; }];