jacmac

http://files.enjin.com.s3.amazonaws.com/148378/module_gallery/original/1505223.jpg (164 kB) http://files.enjin.com.s3.amazonaws.com/148378/module_gallery/original/1505225.jpg (425 kB) http://files.enjin.com.s3.amazonaws.com/148378/module_gallery/original/1505229.jpg (570 kB) Generic_Vehicle_Service_G (New Link) The included test mission called GVS_Test_Mission.Stratis has been updated. In the test mission, simply land on the helipad or drive the vehicle into the coned area. Documentation Updated: /*================================================================================================================= Generic Vehicle Service by Jacmac Version History: A - Initial Release 3/22/2013 B - Updated documentation, no script alterations 3/26/2013 C - Revised trigger reuse handling, now server controlled 4/21/2013 D - Major revisions to how GVS works; triggers, sounds, in vehicle signs, & on screen display changes 10/13/2013 E - Updated gvs_triggers.sqf due to createTriggers and isServer being a fail 10/13/2013 F - Updated gvs_triggers.sqf with UAV support, mods to generic_vehicle_Service.sqf for UAV detection 10/19/2013 G - Added crazy work-around for the turret reloading problem until the developers fix the ARMA bug, quieted loop sounds 3/14/2014 Features: -Rearms, Repairs, and Refuels Land, Helecopter, Plane, or UAV as desired -Wait times are adjustable and refuel/repair occurs only as needed, for example 50% repair is 5x longer than 10% repair. That could be 50 seconds vs 10 seconds or 5 minutes vs 1 minute. -Uses display names where possible rather than type names in messages to players. -Use this with a marker placed on the map (see below). -Displays live activity in a dialog control rather than messages going out through vehicle chat. -Diaplay control is now based on layers, so interference with other scripts/mods using RscTitles should be eliminated, however see below for more information. -gvs_watcher disallows a vehicle from re-using any service point for a specified period. -Triggers on player being the driver of the vehicle, but the player does not need to remain in the vehicle while it is being serviced. -Introducing 3D sounds into this version -Greatly simplified the method of trigger creation using markers, it is more or less automatic now instead of a manual process Requirements: gvs_init.sqf GVS initialization gvs_triggers.sqf Generates triggers from markers gvs_watcher.sqf Delays use (reuse) of service points sounds.sqf Sound utility functions cfg_lookup.sqf Utility functions simple_text_control.sqf Display/Dialog control for structured text colors_include.hpp Color definitions control_include.hpp Standard control includes stc_include.hpp Simple text display control definitions Misc sound files (.ogg files included) Add the following into your mission's description.ext: #include "gvs\colors_include.hpp" #include "gvs\control_include.hpp" #include "gvs\stc_include.hpp" Add the following into your mission's init.sqf: execVM "gvs\gvs_init.sqf"; To use GVS: 0. Copy the gvs directory into your mission folder. 1. Create marker(s) on the map. 2. Name the marker(s) gvs_veh_x, gvs_hel_x, gvs_uav_x and/or gvs_pla_x where x = some number (e.g. gvs_hel_0 is a helecopter service point). 3. Uniquely name vehicles as desired. 4. Run the mission Display Information: GVS uses RscTitles for the information display. It is very possible that missions you try to integrate GVS into will also use RscTitles. By default layer 301 is used for GVS, you can change it if you happen to be using 301 already, numbers in the tens of thousands have been tested successfully. I you integrate GVS into a mission that is already utilizing RscTitles, for example "Domination", you will have to integrate the display class definitions. For example, in the Domination description.ext consider the following code: class RscTitles { #include "x_dlg\RscTitles.hpp" #include "gvs\stc_include_alt.hpp" //Alterntive display class definitions }; The display location and background color can be changed by altering the _display_Settings variable Text colors can also be altered by changing the constants through out the code prefixed with 'RGB' Colors can be found in colors_include.hpp Additional Notes: REQUIREMENT: Your vehicles must be uniquely named. GVS uses the names of vehicles to control re-use of a GVS trigger. This means if you put 10 Hunters on the map all named "BigHunter1", the first one to use a GVS will lock all of the others out until the re-use timer expires for "BigHunter1". For script spawned vehicles you will need to implement something like this if you want them to be able to use a GVS trigger: Example 1: _kh60_Pos = [3962,4618]; _veh = "O_Ka60_F" createVehicle _kh60_Pos; _varName="ka60_1"; // <----This must be unique per vehicle _veh SetVehicleVarName _varName; _veh Call Compile Format ["%1=_this ; PublicVariable ""%1""",_varName]; Example 2: _xloc = (floor ((random 100) + 3950)); _yloc = (floor ((random 50) + 4550)); _veh = "B_Quadbike_F" createVehicle [_xloc,_yloc]; Global_QUAD = Global_QUAD + 1; _varName=("Quadbike_" + (str Global_QUAD)); // <----This must be unique per vehicle _veh SetVehicleVarName _varName; _veh Call Compile Format ["%1=_this ; PublicVariable ""%1""",_varName]; Long term re-use of a trigger is controlled per vehicle instead of per player, this is a major change from the previous version. Each trigger you set up with GVS needs a public variable associated with it and these need to be initialized in init.sqf. The public variables prevent the GVS trigger from being immediately used by anyone or any vehicle on the server, while it is currently in use. This prevents scenarios where one player triggers GVS, then get out of a vehicle and another player gets in the same vehicle and causes a second triggering of the GVS (this was seen to cause problems). The default time for re-using a trigger has been changed to 200 seconds in gvs_watcher.sqf. A player can possibly trigger two or more vehicles to use various GVS triggers for different vehicle if they are all in close proximity, this can mean that the display of the information will get a little wonky, but everything will function normally as far as the vehicles rearming and repairing. =================================================================================================================*/

Color Constants Download Color List I have procedurally converted the 500 colors on the Color List above into a .hpp file. Here is a sample (except the tabs are lined up in the file on 4 spaces per tab): #define ARRAY_ALICEBLUE [0.94,0.97,1,1] #define ARRAY_ALICEBLUE_HALF [0.94,0.97,1,0.5] #define ARRAY_ALICEBLUE_OPAQUE [0.94,0.97,1,0.75] #define ARRAY_ALICEBLUE_PART [0.94,0.97,1,0.25] #define COLOR_ALICEBLUE {0.94,0.97,1,1} #define COLOR_ALICEBLUE_HALF {0.94,0.97,1,0.5} #define COLOR_ALICEBLUE_OPAQUE {0.94,0.97,1,0.75} #define COLOR_ALICEBLUE_PART {0.94,0.97,1,0.25} #define HTMLCOLOR_ALICEBLUE '#F0F8FF' #define RGB_ALICEBLUE "'#F0F8FF'" As you can see with the ARRAY and COLOR prefixes, there are four alpha versions for each color.

Copied into the Addons folder and created an @ folder?

Download: 1st BBR EZ Markers Version 0.5 (Beta) EZ Markers is a mod that generates map markers and optional 'signs'. The intent is to provide easier access to map markers as well as utilizing a large number of markers generated to MIL-STD 2525C standards (not all of them, just the relevant symbols that would be typical in ARMA). The mod is currently functional, however much of the symbology has not been implemented yet. Some of the interface needs tweaking for easier use. I can use any feedback on how to improve the functionality. The mod is mostly self explaintory, but check the video for a quick demo. Keys are provided, but I have not checked their validity, please let me know if the signing is incorrect. The mod is Client/Server, the Server executes the creation of markers and send commands for the clients to create signs. Most of the execution is client based. Network traffic is minimal (unless dozens are creating markers and signs all at the same time). I need opinions on whether limits should be placed on players (sign creation could get out of hand).

Well, you are spot on with the orientation, I do need to implement that. The marker add-on you referenced isn't necessary to integrate, I already have a large number in there and will be adding more. What I haven't done yet is make the markers accessible, only the "Quick List" is functional at the moment. There are three drop-downs you will be able to use to select the unit type, size, and affiliation. That will effectively add hundreds of markers you can't see right now.

There are also some transient conditions that can cause trigger misfires. If a trigger requires a player to be a driver of a vehicle for it to fire, the player alone can cause the trigger to fire just after they exited as the driver of a vehicle. For a short period the player is both a driver of a vehicle and not in a vehicle at all.

I updated the download link.

I haven't seen vvs, but there has to be a way to modify it to name vehicles as they are created. Ask him, he probably could tell you what can be changed to make it name vehicles.

What you might be able to achive is a 'fake out'. Create two versions of the dialog, one that is interactive, and a copy that is not. When the dialog is closed, then the rscTitles replaces it on the fly. The player probably won't notice the switcheroo. Lots of work though, especially if the dialog is complex.

I've seen this on occasion when the player jumps out of the vehicle just as the service is ending. I don't know what causes, but the trigger conditions definitely don't allow anything except the driver of a vehicle to trigger. I suspect there is some kind of latency between a player exiting as the driver (still flagged as a driver) and the trigger going off. It is like for a split second when you exit a vehicle you are the driver of yourself, which is not valid, yet exists for a very small period of time. ---------- Post added at 03:40 PM ---------- Previous post was at 03:38 PM ---------- Yes, look for the sound script and change the radius parameter. It's probably around 50 meters, I can't remember off hand, but you can set it to 5 meters. You can also lower the volume way down on it. I'm also amazed that anyone recognized the voices, congratulations! ---------- Post added at 03:41 PM ---------- Previous post was at 03:40 PM ---------- I'll update it with a new link, the free download services are pretty flaky these days.

Is this a problem? _markerCiv = createMarkerLocal "[2412.01,6036.33,-0.839965]_marker";

cbChecked always returns false, regardless of the checkbox state and cbSetChecked does not affect the state of a checkbox. However, the CheckBoxesSelChanged event does correctly report the selection state, so it is possible to track the state, just not set or query the state. I'm wondering if the recent change from rscCheckbox to rscTextCheckbox has something to do with the problem?

Maybe it would pan out better to make one pass to get the highest rank and join the new group via a foreach, then join the rest to the new group via another foreach without checking for ranks on the second pass. Is it possible that the count of the group units is being altered slower than the loop because joinSilent is a global funtion? In other words joining a unit from one group to another requires time for the count to change on the next check? [_unit] joinsilent _newGrp; sleep 0.25; //wait a long time for testing _ct = _ct + 1;

I'm thinking about writing a more complex add-on that could handle such scenarios. GVS really is generic. It looks up configs and such, but it's all just a delay for setVehicleAmmo 1. I am interested in what you are describing, but it would not be a simple matter to implement this in a hurry.

So there is a blurb in the documentation regarding RSCTitles. Basically there can only be one class definition for RSCTitles for the whole mission. This means that many missions designers don't understand and add other scripts into their mission with description.ext #includes that have RSCTitles definitions. The effect is that the last class definition for RSCTitles will overwrite any previous definition. To resolve this issue, you must find any other RSCTitles definitions and combine them into one. I included an alternative method of defining RSCTitles for situations like this: class RscTitles { #include "x_dlg\RscTitles.hpp" #include "gvs\stc_include_alt.hpp" //Alterntive display class definitions }; In the example above (entered in DESCRIPTION.EXT directly), RSCTitles contains two includes, one is for another script (Domination) and the other is GVS. This allows both scripts to use RSCTitles, but definitely OPEN and EXAMINE the differences between stc_include.hpp and stc_include_alt.hpp files. You may need to alter other developers scripts somewhat to use this method of class definition. If you understand classes at all it will make sense. The only other thing to worry about after this is the layer numbers, they must be unique. It is unlikely that two scripts will happen to use the same layer numbers, but it will cause one control to step on another and they can end up ping-ponging. RSCTitles and Dialog's in general are a confusing animal to understand, it took me quite awhile to completely grasp and I still seem to find new things about them. They are very quirky and the developers did not follow any hard rules with their development. A lot of the biki documentation is old and only semi-accurate for Arma 3.

Thanks. I'll update the biki myself then; I wish they would put it in the notes instead of the discussion... And confirmed, lbSetCurSel does fix the problem.

The code below populates the listbox just fine, but lbSetSelected has no visible effect. I've tried the same thing with a combobox; lbSetSelected doesn't appear to do anything. The combobox will be populated, but the box shows blank until the player selects an item. disableSerialization; _disp = findDisplay IDD_DIALOG1; _control = _disp displayCtrl IDC_Quick_List; _controlnum = IDC_Quick_List; _count = 0; { lbAdd [_controlnum, _x select 2]; lbSetData [_controlnum, [_count,_x select 1]]; lbSetPicture [_controlnum, _count, _x select 0]; _count = _count + 1; } foreach ArrayQuickList; _control lbSetSelected [1, true];

((""LandVehicle"" countType thislist > 0) || (""Air"" countType thislist > 0) || (""Ship"" countType thislist > 0)) && Et cetera, et cetera.

If I define this in description.ext (assume the icon is located in a directory called markers): class CfgMarkers { class TEST_Cross { name = "Simple_Cross"; icon = "markers\cross_ca.paa"; color[] = COLOR_GOLD; markerClass = "draw"; size = 24; shadow = 0; scope = 1; }; }; Should this work? TESTMapClick = { _pos = _this select 0; _marker = createMarker ["Marker1", _pos]; _marker setMarkerType "TEST_Cross"; }; What I'm getting is an error stating No Entry bin\config.bin/CfgMarkers.TEST_Cross I'm not sure how to declare the class. I saw a similar class declaration on the biki at https://community.bistudio.com/wiki/cfgMarkers But I actually declared it using properties found in the Config Viewer for CfgMarkers in Arma 3.

setVehicleInit used to be used, but in Alpha, some foolio created a virus-like script that utilized the command to cause everyone to fly around like superman. So what you need to do now is utilize: https://community.bistudio.com/wiki/BIS_fnc_MP.

Solved: Make sure the source image dimensions are a power of 2 (32x32, 64x64, 512x128, 64x256, etc). Step one, use GIMP to export TGA (no RLE compression): Step two, load in TexView and export as a paa (no changes made): Step three, define the class: class BBR_RscPicture { access = 0; type = CT_STATIC; style = ST_PICTURE; idc = -1; shadow = 0; fixedWidth = 0; x = 0; y = 0; w = 0.200000; h = 0.150000; colorText[] = {1, 1, 1, 1}; colorBackground[] = {1, 1, 1, 1}; font = "PuristaMedium"; sizeEx = 0; size = 0; }; class BBR_Ribbon: BBR_RscPicture { idc = 12003; text = "bbr\ribbon.paa"; x = -3.5 * GUI_GRID_W + GUI_GRID_X; y = 23 * GUI_GRID_H + GUI_GRID_Y; w = 27 * GUI_GRID_W; h = 3.5 * GUI_GRID_H; }; And finally, the blown output in game; what did I do wrong that caused the colors to be fouled?

The problem turns out to be the image dimensions. Everything has to be scaled to a power of 2, or the export from Texview will be screwed up. If you don't see ARGB8888 or DXTx in the output box, the export is going to be bad. It will look OK in Texview, but in game it will be wrong.

I think you could get most of the information in a rscNListBox, but it isn't going to work much like a menu 'tree'. It would just be a flat list of items in the listbox. A tree control would be helpful, but the only such thing is usable only by the executable code, not scripts.

I think you need to just define them: class VScrollbar { color[] = {1, 1, 1, 0.6}; width = 0.021; autoScrollSpeed = -1; autoScrollDelay = 5; autoScrollRewind = 0; shadow = 0; }; class HScrollbar { color[] = {1, 1, 1, 0.6}; height = 0.028; shadow = 0; }; class ScrollBar { color[] = {1, 1, 1, 0.6}; colorActive[] = {1, 1, 1, 1}; colorDisabled[] = {1, 1, 1, 0.3}; thumb = "\A3\ui_f\data\gui\cfg\scrollbar\thumb_ca.paa"; arrowFull = "\A3\ui_f\data\gui\cfg\scrollbar\arrowFull_ca.paa"; arrowEmpty = "\A3\ui_f\data\gui\cfg\scrollbar\arrowEmpty_ca.paa"; border = "\A3\ui_f\data\gui\cfg\scrollbar\border_ca.paa"; }; Then add them: class RscDisplayTest { idd = 3000; type = CT_COMBO; movingenable = false; class Controls { class MyTextBox: RscStructuredText { type = CT_STRUCTURED_TEXT style = ST_MULTI; lineSpacing = 1; idc = 1235; size = 0.09; text = " "; x = 0.32815 * safezoneW + safezoneX; y = 0.4575 * safezoneH + safezoneY; w = 0.343 * safezoneW; h = 0.315 * safezoneH; class MyTextBoxScroll: ScrollBar { }; }; }; }; I don't know if this will work or not, but defining the scroll bar in the control would seem to be the way to get it included if RscStructuredText can support a scroll bar. Oh and all of the code I quoted can't be used without SA-MATRA's direct permission if you care what he thinks LOL. :D

It works. Like I said, if there is no gunner, the pilot will be switched to the gunner position to reload for a split second. Otherwise the gunner executes the code and it works that way too. Moving to the gunner position to adjust the gun has no effect on the process. What might be weird is that a pilot that gets out and walks around during the reloading may or may not cause a failure to reload, if a gunner is not present.