tryteyker

In the script it looks like you're missing a set of curly braces. You're opening up the while loop, but you forgot to "open" the forEach loop with one. Corrected version: while {(true)} do { { _x setposasl [(getposasl _vic select 0)+(random _dist2 - _dist)*sin(random 359),(getposasl _vic select 1)+(random _dist2 - _dist)*sin(random 359),(getposasl _vic select 2)+(1.4+(random 2))]; sleep _time+(random 5); } forEach _tgArray; // x seconds for testing sleep 10; hint "a new target is made"; sleep 5; } Also yeah the trigger should be repeatable. Repeatable triggers don't call themselves every frame if a unit is standing inside of them (afaik but it's been a while) but rather "Repeatable" just tells the engine "this thing may be called more than once".

Since STHUD checks config values "engineer" and "attendant" you'll probably have to change the class of the unit itself. The only 'dynamic' class change happening are AT and MG types as they check the "UIPicture" config value of the players weapon. The reason your version doesn't work is because config values can't be changed of a unit (class) can't be changed mid-mission, since they're already loaded in. Actually the above is no longer true for latest STUI version (which includes STHUD). It's now switched over to using pictures directly, and there's no longer a special icon for EOD/Engineers. They've also added a specific override value to make a unit an attendant: player setVariable ["isatd_", typeOf(_unit)]; Try setting that variable instead. MG and AT are still determined by checking value "UIPicture" of primary and secondary weapon respectively.

Yeah that's due to "land" command. It has 3 values: "LAND", "GET IN", "GET OUT". Pretty sure there was some way to make AI land completely and force their engine to be on, but that's too much magic for one post (in other words I'm too lazy to look it up :P). "GET IN" will be a very low hover above ground though, which should be enough.

The tutorial video uses a map-placed helo pad (which is of course recognized by Arma), but to be able to land anywhere else effectively you'll need to place your own (invisible) helipad. If you use your own and place the (transport) unload waypoint directly on top of it, the helicopter group should "claim" that helipad as theirs, allowing you to place landing zones next to each other.

Placing an invisible H-Pad with a Transport Unload waypoint (assigned to heli pilot / co-pilot) right on top of it. Then throw in the following into waypoint activation for good measure: heli_name land "LAND" If the helicopter is transporting a group of people, their GET OUT waypoint will have to be right next to the Transport Unload waypoint, and both waypoints will have to be synchronized. By placing the TR UNLOAD waypoint right on top of an invisible H-Pad Arma should pick up the correct pad for the waypoint 95% of the time. Pessimistic estimate :P https://community.bistudio.com/wiki/Waypoint_types#Transport_Unload Just to clarify that landAt != land, and landAt doesn't work with helicopters.

Hi, slight inconvenience here: I'm trying to get a CfgMusic entry "ported over" to CfgSounds so I can use it with playSound3D etc, but I'm kinda stuck when it comes to referencing the sound. I've got the relative path from configFile, but that doesn't really help me since missionConfigFile is always starting from description.ext and not the specific mod folder I'm looking at. I'd like to avoid using absolute paths because that absolute path is probably different for 30+ people, but I'm assuming there's no other way to reference it. At that point I guess I might aswell rip the .ogg out of the modset and place it in my mission, even if it makes the file size explode. Example config path: \RHNET\Thirsk5\music\sova.ogg But again, doesn't really work when using it with CfgSounds in description.ext. - https://community.bistudio.com/wiki/Description.ext#CfgSounds In my defense, I'm absolutely terrible at reading the most relevant docs :P

I got a couple questions: What are you using the R_60mm_HE for? I don't see a point in attaching it to the heli pre-crash. I also don't know why it's a global var but that may just be an oversight, and it's not really that important anyway. When are you planning on doing this? If the sequence is at the start stuff like initPlayerLocal.sqf is going to be really useful, but if it's mid mission it's slightly more complicated. Why BIS_fnc_execVM? Pretty unnecessary, especially in conjunction with [] spawn {}. You may want to look into remoteExec/remoteExecCall instead of BIS_fnc_MP as the former has replaced the latter since Tanoa update. This all ultimately depends on when you execute this. As it's a dedi you've got a few init files to help you along the way, especially when it comes to creating markers on client's machines, creating the blackout effect etc. However, if you do this mid-mission it'll be slightly more complicated but nothing remoteExecCall can't fix.

For reference, the "driver" classnames of the UAV/UGV are B_UAV_AI, O_UAV_AI or I_UAV_AI depending on side. These can be created via createUnit, but createVehicleCrew is still easiest to use in general.

I don't think that you'd run into issues with using the EH + remoteExecCall even with a larger player count, especially if you only display a hint that somebody hit someone. You'll want to make sure you execute the hint only on the machine where the hint is needed, which in this case is the person that shot somebody. In addition to that make sure you use remoteExecCall (not remoteExec).

A syntax highlighter is completely irrelevant for the general community though, so this is probably the best section to post it. Also, how long did you work on this? Seems like a LOT of typing it all out manually :D

Creating an invisible or really small object like a cyan pointer which you delete afterwards is probably the best, in conjunction with something like forceWeaponFire to fire the flare muzzle.

Well that's a really good question actually, it works properly at least. Thanks for that, didn't know it existed.

Hi, I've got a script ready to go that draws an objects bounding box on the map (with a marker), but it's not working quite right. A3 in general has pretty generous bounding boxes, especially with buildings, but this function expands them by quite a bit which leads to some issues. Comparison picture, with the left end of the bounding box that is drawn on map marked in red, and the actual bounding box displayed in green (boundingBoxReal) and blue (boundingBox) (http://killzonekid.com/arma-3-bounding-box-utility/): http://images.akamai.steamusercontent.com/ugc/1617175662587958314/9872DB01F114FBAB8458F44B09BA81E67F8D7EBF/ I'm using a CUP building in the above example because they generally have better bounding boxes. This is the script that draws the marker: /* * Author: Kingsley * Draws the object bounding box on the map * * Arguments: * 0: Object <OBJECT> * 1: Color <STRING> * 2: Alpha <FLOAT> * * Return Value: * None * * Example: * [this, "ColorBlack", 0.5] call ARC_fnc_drawOnMap; * * Public: Yes */ if (!isServer) exitWith {}; params [ ["_object", objNull, [objNull]], ["_color", "ColorBlack", [""]], ["_alpha", 0.75, [0.00]] ]; private _box = boundingBoxReal _object; private _pos = getPos _object; private _uname = format ["bounding_box_marker_%1", str _pos]; private _marker = createMarker [_uname, _pos]; _marker setMarkerPos _pos; _marker setMarkerBrush "Solid"; _marker setMarkerShape "RECTANGLE"; _marker setMarkerColor _color; _marker setMarkerAlpha _alpha; _marker setMarkerDir (getDir _object); _marker setMarkerSize [ (_object modelToWorldVisual (_box select 0)) distance (_object modelToWorldVisual [(_box select 1 select 0), (_box select 0 select 0), (_box select 0 select 0)]), (_object modelToWorldVisual (_box select 0)) distance (_object modelToWorldVisual [(_box select 0 select 0), (_box select 0 select 0), (_box select 1 select 2)]) ]; nil I haven't written it and to be honest I'm terrible at this whole modelToWorld stuff so I have no idea how to fix it.

Functions, yes. You don't use execVM for functions because by definition they're executed multiple times. execVM, as austin mentioned, is for one-time only scripts that are thrown away afterwards. It's good practice to write functions if you're using the code multiple times, but most of the time in Arma you will not be using code multiple times (like setting a task - you can obviously write a function for it, yes, but you might as well do a script if you're only setting it once. This approach obviously depends on how you go about it). The performance gain is often minimal and you need to do a lot of looping and scheduling to bring the whole ship down burning and crashing and all that if you want to burn Armas actual FPS to the ground. I'm not saying code optimisation is shit and shouldn't be looked after, but writing functional code that works even if it uses scheduled environment is #1 priority every time. If you're interested in some stats when it comes to code optimisation: https://community.bistudio.com/wiki/Code_Optimisation

Isn't isNil the wrong check anyway? That'd imply that _target as a variable is non-existant but since it's previously defined, the if statement returns false. I always mix up isNull and isNil though so might just be me. Either way, if target is a soldier, you might as well use !alive if you want to do a check.