tryteyker

Hey, continuing onwards from my latest issue, I've promptly run into another one. inRangeoOfArtillery. It always returns false no matter what the distance is. Here's the cde I'm using: _artillery = [_this,0,missionNamespace getVariable "ArtilleryUsed",[objNull]] call BIS_fnc_param; // Artillery used. (OBJECT, UNIT) _amrounds = [_this,1,missionNameSpace getVariable "RoundsUsed",[0]] call BIS_fnc_param; // Amount of rounds. (NUMBER, INTEGER) _delay = [_this,2,missionNamespace getVariable "SetDelay",[0]] call BIS_fnc_param; // Delay in seconds between shots. (NUMBER, FLOAT) _round = [_this,3,missionNamespace getVariable "ShellUsed",[""]] call BIS_fnc_param; // Type of round used (STRING, CLASSNAMED) _target = [_this,4,missionNamespace getVariable "MarkerPositionUsed",[[0,0,0]]] call BIS_fnc_param; // Target. (POSITION, MARKER) Variables defined. Artillery is the unit name of a BLUFOR Scorcher, whilst "Round" equals "32Rnd_155mm_Mo_Shells". _target is a marker position properly defined. This is how I call inRangeOfArtillery: _inRange = _target inRangeOfArtillery [[_artillery], _round]; It ALWAYS returns false. I've checked every variable and it is properly defined (all have proper values). Distance of the marker doesn't play any role whatsoever. I've tested from 500m to 2000m, it always returns false. I've no idea why, any ideas?

Advanced Artillery Support System Version 1.1 tryteyker What is the Advanced Artillery Support System (A-A-S-S)? Essentially, the AASS is somewhat of a hybrid between the groundwork for a much more complex artillery system and an already functional artillery system that can be used by mission makers on the go. It offers basic functionality that you'd expect from a support system, aswell as a Graphical User Interface that provides necessary information to the user when they need it. It is also, however, a base script that can be expanded upon. The main function of this support system can be edited by any mission maker and tweaked, allowing them to adjust the A-A-S-S to suit their missions needs. To guide mission makers through tweaking the function, there are plenty of comments on what every single line of code does. How do I implement the Advanced Artillery Support System (A-A-S-S) into my mission? A basicfile structure has already been set up for the mission maker. This file structure should be left untouched, as it is crucial to have the A-A-S-S function properly. The only file that the mission maker needs to worry about is the init.sqf. In there is a single line implemented which executes the A-A-S-S (it is an addAction). Commented lines have also been added to allow seperation from the rest of your init.sqf. In the init.sqf, you only need to add the unit, or units, that is/are supposed to receive the action to access the A-A-S-S. Nothing else needs to be done and you will be able to use it afterwards. What if I want to adjust the A-A-S-S to suit my mission better? Before you adjust the A-A-S-S for your needs, take a quick look at the Rights section below. It will explain what you are allowed to modify and use in your (publicly) released missions and what you aren't. Once you've done so, here's how to modify the function: Navigate to YourMissionFolder\TRT_AASS\functions\fn_fireMission.sqf. This function is the core of the A-A-S-S. Practically all lines of code are commented and explained to allow even those who are fairly new to scripting to understand what is happening. For those who wish to extensively modify this file, I've included a few notes below. Notes about the modification of fn_fireMission.sqf This file currently does not include the following things: - Advanced trajectory calculation - Extensive support for artillery units that come with an addon. This file currently does include: - Support for all of the artillery units currently in the game (exception: MLRS, read Issues section for further info) - Ability to directly call this function (it is not dependant on any GUI elements, read notes inside the function for further info) - Basic trajectory calculation (It is calculated by the engine, basic velocity effects etc) Keep the above things in mind when modifying this file. You may want to, at first, look at trajectory calculation as it is not custom-made but instead relies on engine calculations. Issues - The MLRS Artillery Unit is not currently supported as it does not react to Fired Eventhandlers properly. - If the user closes the map too quickly after placing a marker, the function will not fire. - There is no ingame documentation for end-users. - No explanation on pre-set markers for end-users. (Preset marker requirements are: Type DESTROY, Color RED, text FIRE MISSION) - Preset markers may not be deleted after fire mission is done. - Only the basic ammunition types (Sh_xmm_AMOS,R_230mm_HE) are supported. Edit x\selection\typsel.sqf to add more ammunition types. Rights You may not modify any Graphical User Interface (GUI) elements provided to you with this script/function. You are not allowed to re-use these GUI elements to their full extent and outside their intended purpose (ie with this function/script). You are allowed to modify the main function/script (fn_fireMission.sqf) to suit your missions needs. You are also allowed to re-use this script directly and without GUI elements. Appendix The purpose of this appendix is to inform the mission maker of variables used in mission namespace as to not conflict with any missions that also use these variables (although highly unlikely). All of these are only defined when the main function is used with provided GUI elements. You'll find it within the spoiler. Changelog v1.1 (Hotfix) - Tweaked: Increased time it takes for artillery to aim and fire at target. (fn_fireMission.sqf) - Fixed: MAP button now properly opening map (dialogs.hpp, file structure not setup properly) v1.0 - Initial Release DOWNLOAD MEDIAFIRE ^ (VERSION 1.1)

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.

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.

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

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.

Just slightly off topic, does arma actually load folders inside mission folder? I see you've got Guest and Uploaded there, never seen those. oh god folders actually work now what is this Also, that green is amazing :P By the way OP, did you make sure to copy the mission into the missions folder in Documents instead of missions folder in arma 3 directory? If it's available to play but not available to edit you may have just copied it to the wrong directory.

setAccTime 1; https://community.bistudio.com/wiki/setAccTime This only works in singleplayer though.

Yeah it seems to be pretty inconsistent. The in-game option to turn on squad radar always reverts to false too, at least for me.

Hi, with Apex preview, there's a new squad radar used in the Prologue campaign. I've looked around a bit and I'm pretty sure it's defined in CfgInGameUI >> SquadRadar. It's a neat vanilla replacement for STHud, but does anyone have an idea on how to get it into a mission? cutRsc/cutObj don't seem to be working, but to be fair I haven't messed around with it too much as I'm about to head to work.

What splashscreen are you talking about exactly?

Hi, you're going to have to bear with my here because I'd need 5 morning coffees before I could write any sort of coherent dialog code, so I'm going to just give you pointers instead and hopefully you'll be able to figure it out yourself. So the idea is that if you want a dialog element (in your case the structured text) to change based on a listbox entry, you need to go at it in a specific order. Think sorta back-end and front-end. You were at it with lbSetData and setVariable etc, and that's the back-end stuff you have to do as the dialog initializes. Basically, each listbox entry (1, 2 and 3) gets values and data assigned to them (through lbSetData etc, if it's used) BEFORE the user sees the dialog. Once the dialog's been initialized and the user can click through it, you can start to worry about what happens if the user selects different listbox entries. This is where your ctrlSetText bit comes in, because it's essentially front-end: it doesn't do anything but show the user some text. So what you want to use is a User Interface Eventhandler, more specifically onLBSelChanged, to catch if the user selects a new entry. This is the sort of tricky part, as you first of all have to find the corresponding structured text view (if you are, for example, doing a gear view), or, like in your case, you would probably need to stuff relevant data into the relevant structured text box. I have no idea what the two structured text boxes do in your case, so you'll have to figure it out on your own unfortunately. The onLBSelChanged EH I talked about earlier is best written into the dialog config itself. There's different commands like ctrlAddEventHandler, but these don't work as well as config-based commands. In the code below you'll see 2 things: onLoad (further up), and the onLBSelChanged EH. Think of the onLoad parameter (which can do whatever, could display a hint but most common is a function call / script execution) as the back-end stuff. Here, you do all your lbSetData, setVariable etc so it's there once the dialog has finished loading. The different Eventhandlers (which need to be assigned to each listbox individually) are the front-end stuff, they catch the selections made by the player. Always use _this, regardless of if you execVM or call/spawn a script, because it gives you the control (not the IDC, so you will have to use alternative syntax of many commands. More on that later) and the selected element index of the listbox. This allows you to change the structured textboxes as necessary. You'll have to iterate through each listbox individually in the onLoad file, which might be a bit tricky considering you've also got multiple values you want assigned (apparently). Also, I would recommend using IDCs and not controls, as alternative syntax of many commands (so _control lbAdd "text" instead of lbAdd [_idc, "text"]) is unreliable mid-mission. Here's the modified dialog code: class Pasi_HUD { idd = 5500; movingenable = false; onLoad = "[] execVM 'dialog_init.sqf'"; class controlsBackground { class MainBackground: life_RscText { idc = 1600; x = 0.29375 * safezoneW + safezoneX; y = 0.313 * safezoneH + safezoneY; w = 0.4125 * safezoneW; h = 0.418 * safezoneH; colorBackground[] = {0,0,0,0.7}; }; }; class controls { class RscListbox_1500: Life_RscListbox { idc = 7771; x = 0.304062 * safezoneW + safezoneX; y = 0.335 * safezoneH + safezoneY; w = 0.211406 * safezoneW; h = 0.341 * safezoneH; onLBSelChanged = "_this call fnc_changeText"; }; class RscButton_1601: life_RscButtonMenu { idc = 7772; text = "START"; colorBackground[] = {0,0,0,0.7}; colorText[] = {0,0,1,1}; x = 0.613437 * safezoneW + safezoneX; y = 0.335 * safezoneH + safezoneY; w = 0.0825 * safezoneW; h = 0.066 * safezoneH; }; class Descriptiontext: Life_RscStructuredText { idc = 7773; text = ""; colorBackground[] = {0,0,0,0.7}; colorText[] = {1,0,0,1}; x = 0.530937 * safezoneW + safezoneX; y = 0.489 * safezoneH + safezoneY; w = 0.165 * safezoneW; h = 0.187 * safezoneH; }; class Data: Life_RscStructuredText { idc = 7774; text = ""; colorBackground[] = {0,0,0,0.7}; colorText[] = {1,0,0,1}; x = 0.530937 * safezoneW + safezoneX; y = 0.423 * safezoneH + safezoneY; w = 0.165 * safezoneW; h = 0.044 * safezoneH; }; }; }; The idd can be changed as necessary up top, I just like 5500. I'd recommend setting one only if you have multiple dialogs, as you then may need to call the Pasi_HUD dialog again. The IDCs of the listboxes are extremely important, so don't set them to -1. You will need them later. This is probably a really long-winded explanation that leads you nowhere but it's the best I can do atm. Morning coffee count is still only 3 after all :P I've done this for a mission of mine before, so if you want you can look through the code, but it's semi-complex as it uses a lot of different variables that are defined all over the place, so if it confuses you just ditch it. https://github.com/CER10TY/Modular-Campaign/tree/master/%40M.C/addons/Module_Camp/Module_Camp/missions/HubState.VR/operatorlist Click through there, it's a lot of functions and dialogs (and none if it is very clean).

If you're on apex preview branch you should see Position: X, Y, Z, Rotation: Z and Size: A, B, C. C is the height attribute.

Nope, not working. Any other ideas? OK so I should probably google some more before I open up new topics.. "new" squad radar. Take a look at alt syntax here: https://community.bistudio.com/wiki/showHUD