Senshi

@soolie: Yeah, that was my impression as well, but it never felt right to have to drag along some "homegrown" version of the common.hpp . I stumbled multiple times already because the various "templates" floating around in the net and the wiki have been deprecated by an Arma update. @hoverguy: Thank you! I didn't know I had to look for "_CT_LISTNBOX" to get the actual template for "RscListNBox". It is somewhat confusing because the "RscListNBox" is also defined in the config.cpp . Can you enlighten me how RscListNBox is related to _CT_LISTNBOX? In my mission, I simply define the RscListNBox, and all is well. I am guessing it's linked by the style = 102 (or style=CT_LISTNBOX, with it defined as 102) of Rsclistnbox and idc=102 (or type=102?) of _CT_LISTNBOX? And is there a way to figure out - without trial & error - which attributes are mandatory (such as "rowHeight")?

I have had this issues multiple times now: I want to implement GUI stuff in a mission, which requires me to define all the necessary resources for it. My question is: Where can I find the original definitions used by ArmA 3 itself? I was expecting to find them in ui_f\a3\ui_f\config.cpp, however, e.g. the RscListNBox entry looks like this: class RscListNBox { style = 16; shadow = 0; font = "RobotoCondensed"; sizeEx = "( ( ( ((safezoneW / safezoneH) min 1.2) / 1.2) / 25) * 1)"; color[] = {0.95,0.95,0.95,1}; colorText[] = {1,1,1,1.0}; colorDisabled[] = {1,1,1,0.25}; colorScrollbar[] = {0.95,0.95,0.95,1}; colorSelect[] = {0,0,0,1}; colorSelect2[] = {0,0,0,1}; colorSelectBackground[] = {0.95,0.95,0.95,1}; colorSelectBackground2[] = {1,1,1,0.5}; colorPicture[] = {1,1,1,1}; colorPictureSelected[] = {1,1,1,1}; colorPictureDisabled[] = {1,1,1,1}; period = 1.2; x = 0; y = 0; w = 0.3; h = 0.3; class ListScrollBar: ScrollBar{}; class ScrollBar: ScrollBar{}; };When I copypaste this to use for a control in my mission, I get the error message: "No entry FILEPATH/ListN.rowHeight".When I add this attribute, everything works fine. Why is this attribute not set in the config.cpp of the ui.pbo? ArmA3 will need that attribute set as well for all its purposes, right? I'm guessing there must be another location where this is defined? EDIT: And where do the templates from this page come from?

Look in your userfolder (C:\Users\xxx\Documents\Arma 3\xxx\missions) and see if the mission.sqm (if 2D editor) still shows your content (check for entries with "class ItemXX"). If yes, you at least still have your content, and the issue is somewhere else. If it's not showing your stuff in the sqm, then your mission is down the drain, because the files were overwritten somehow.

I don't really know if there's an easy way to do that. As a (somewhat complicated) workaround/hack, you could draw a custom control over it, to "black out" the playerlist (or even just the side icons, so users can still look up who is online). Basically: Create a resource on the map display (finddisplay 12 displayctrl 51 IIRC) that is a simple black box. Make sure it is placed in the right xy position and has the right width/height. Bear in mind that you will have to learn how Arma GUI positioning works. I like KK's tut as a lookup for that: http://killzonekid.com/arma-scripting-tutorials-gui-part-3/ Players have screens with different sizes, so you can't use simple absolute positioning, but it's not overly difficult to figure out proper positioning. You will also have to find the correct displayctrl (IDC) of the "players" tab, so you can use a "Draw" MissionEventhandler to detect when that particular menu is actually open. You'd have to dive into the ui_f.pbo, find the map control definitions, and find the correct displays and controls to target for the player menu.

Well, give it a try and tell us if it works for you! It can equally well work or not, it's hard to tell in advance. There's two ways missions are made for ArmA: Either you rely on the editor and work it all out using the provided modules OR You use the editor only for the basics (placing units/objects), and do all the rest in script files (.sqf) . Davidoss describes the latter way. Most veteran mappers/modders go for the script approach, because it is WAY more versatile and powerful, if you know what you're doing. I actually believe many started with the first approach, but inevitably stumbled upon issues they couldn't solve inside the editor, forcing them to learn sqf. That's why many of the sqf mappers/modders can't really help you much with the editor modules, they simply are not using them. If you are new to Multiplayer mapping, there's a very important concept you have to learn: Locality. An excellent tutorial (and learning resource in general) is KillzoneKid's page. In your specific case, the big question is: Are the created/added/updated tasks local to each player or synchronized globally? Again, Biwiki tells you what's up. Tasks are created local for each player. So you as a mapper have to ensure that the tasks are created for everyone. This is fairly easy for missions where everyone plays together from start to finish, but is much trickier for missions that allow Join-In-Progress (JIP). If you rather want to stick with modules, see if it works for you (and feel free to report back here, people - me included - are always eager to learn!). If you want to script, and the task should be given from the start of the mission, this would be a simple approach: Add this to your init.sqf: [west,["task1"],["Kill this super important officer!","Eliminate HVT","hvtmarker"],hvt,true,2,true] call BIS_fnc_taskCreate; // This creates the task at the start of the mission. hvt addMPEventHandler ["MPKilled", { // This event handler is added to the object named hvt (placed in editor). The code inside the curly brackets will only execute when the condition MPKilled is true. The condition simply means "hvt is no longer alive". ["task1", "SUCCEEDED",true] spawn BIS_fnc_taskSetState; // If hvt is dead, we update the task to show it was completed successfully. }]; Assumption is:Your team plays as west. The HVT unit is named "hvt". Code is not tested, but should be easy enough to make it work if errors occur.

Use addAction to add entries to the action menu. Use attachto to attach objects to the player. The popup thing could be done using notifications (e.g. https://community.bistudio.com/wiki/BIS_fnc_showNotification)or simply hint / hintsilent. The biwiki is a great resource to get started!

I'm currently trying to find a way to get the (abstract) mass of a magazine. And I mean all kinds of magazines, including vehicle weapons. Basically I want a good automated way to quantify how much "bigger/larger/heavier" a 32x120mm HE shell magazine is compared to a measly 30x6.5mm STANAG. I was hoping "mass" or "weight" in CfgMagazines would be a good indicator, but sadly both of these attributes are only sparsely populated in ArmA3 magazines. I also looked at CfgAmmo (hoping I could multiply cfgMagazine "count" with a mass value in CfgAmmo), but the only thing there that resembles what I'm looking for is "cost". Which does not refer to the "price", but to the "reluctance to use it" for AI (so they don't use "expensive" ammo on cheap targets). Still, "cost" is close to what I'm looking for, but not really perfect (e.g. demo charges have a very high cost, 4 times that of a single 120mm APFSDS). Anyone have any ideas where else I could look? How does ArmA calculate bullet drop, if it is not mass-based?

All the infantry weapons' magazines do have mass (CfgMagazines >> "name" >> mass) and the values are sensibly filled. For vehicle weapons' magazines, this value is usually set, but not useful (default value seems to be "8". Sadly this even coincides with some infantry magazines that actually have the mass of 8, so filtering isn't that easy either). However, that is not necessarily a true equivalent for the projectile mass, because both the actual magazine case as well as the bullet casing are included, both not being relevant for the projectile that is expelled. And both constitute a significant part of the mass of a magazine.

Another test result: It's possible to get the volume of a projectile by spawning it and then calling boundingbox on it (boundingbox and boundingboxreal return the same results for fairly primitive models such as projectiles). In my quick test I got the following results (volume = length * width * height): B_9x21_Ball 0.004126984154 B_556x45_Ball 0.008610160447 B_65x39_Caseless 0.008610160447 B_762x51_Ball 0.004126984154 B_127x108_Ball 0.004126984154 DemoCharge_Remote_Ammo 0.002899307657 G_40mm_HEDP 0.0002912889915 M_Scalpel_AT 6.66293707 Sh_125mm_APFSDS 0.1410523565 Sh_155mm_AMOS 0.004233596937 Sh_82mm_AMOS 0.004233596937 Rocket_03_AP_F 0.6234897105 Missile_AGM_01_F 16.35820198 Bo_Mk82 0.5038736875 This also shows it's not really useful, as the mere boundingbox of some missiles or bombs is much larger than their actual volume because of fins extruding from the main body. Others seem to use the same model for different ammo. I also tried getMass on them, but projectiles are not PhysX objects, so it always is 0. Another problem is that I actually have to SPAWN the projectile to get this data. So I have to cause a massive detonation somewhere in the ocean at the start of the round, probably causing some severe lag, just to get the volume.

Maybe try https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#IncomingMissile Not sure if it triggers only on vehicles with radar.

Yup, a display solution probably would be much better for FPS. You still will have to do a lot of map-to-screen calls to get each "cell's" position, but at least you don't have to move things around all the time.

Look into https://community.bistudio.com/wiki/ctrlMapScreenToWorld Feed your desired screen position ([0.5,0.5] for screen center) to that function, and you should get the map position coordinates. In your case, you'd have to update the positions every time the mapview is moved/zoomed. As there's no particular eventhandler for that, you probably have to rely on the "Draw" eventhandler to update the markerpos. Map markers are always bound to map positions, so you will always have to convert screenspace to worldspace. Make sure to run the "Draw" cycle only when the map is shown to save some FPS when not on the map view _eh = ((findDisplay 12) displayCtrl 51) ctrlAddEventHandler ["Draw", ' if (!visibleMap and !visibleGPS) exitWith {}; // Only go through all the hazzle if the map is actually openHow to process positions? Save the "current" positions of your markers at the end of each Draw cycle (oldpositions). Then get the new map center coordinates (above function) and manually calculate the new "should be" screen positions for all markers as offsets in screenspace. Then, simply convert screenspace coords to worldspace using the reverse of above functions. If you use the default main map, remember that this map is NOT fullscreen, so you should retrieve the actual map size using ctrlPosition on the map (finddisplay 12 displayctrl 51).Also remember that that display 12 ctrl 51 is also used for the GPS / Minimap in Vanilla, it's just smaller. Using ctrlPosition should make it work for that as well, as it returns both position (x,y) and size (width, height). A good additional read to better understand how Arma's screenspace works is KK's GUI tutorial on it: http://killzonekid.com/arma-scripting-tutorials-gui-part-3/ EDIT: Had some time, so I did a quick debug console example: markerx = createMarkerLocal ["test", position player]; markerx setMarkershape "ICON"; markerx setMarkerType "hd_objective"; markerx setMarkerText "Test"; ehtest = ((findDisplay 12) displayCtrl 51) ctrlAddEventHandler ["Draw", ' if (!visibleMap and !visibleGPS) exitWith {}; _screencenter = (finddisplay 12 displayctrl 51) ctrlMapScreenToWorld[0.5,0.5]; markerx setMarkerPos _screencenter; ']; In this case, it doesn't matter where the marker is created, as I always move it to map center as soon as I open the map. In your case, you proabably want to set up a marker matrix with positions in screenspace(!). Then you can use a foreach loop inside the eventhandler to update each marker: // On mission init slopemarkers = []; _mapcontrolsize = ctrlPosition(finddisplay 12 displayctrl 51); for "_i" from 0 to 159 do { for "_j" from 0 to 89 do { _marker = createMarkerLocal [("slope" + str(_i) + "_" + str(_j)), [0, 0]]; _marker setMarkershape "ICON";_marker setMarkerType "hd_dot"; slopemarkers pushBack [_marker, [(_mapcontrolsize select 0) + (_i / 160 * (_mapcontrolsize select 2)), (_mapcontrolsize select 1) + _j / 90 * (_mapcontrolsize select 3)]]; } }; ehtest = ((findDisplay 12) displayCtrl 51) ctrlAddEventHandler ["Draw", ' { _marker = _x select 0; _screenpos = _x select 1; _worldpos = (finddisplay 12 displayctrl 51) ctrlMapScreenToWorld _screenpos; _marker setMarkerPos _worldpos; } foreach slopemarkers; ']; However, you will notice your large number of markers will cripple your FPS when in mapview. All this converting from screen to world space and setMarkerPos is pretty costly in performance. You can add an additional check to see if the map has been moved or zoomed(changes in ctrlMapScale for zoom, changes in mapcenter for move) to only update the map then, but it still will cause severely lagginess while panning&zooming. Maybe add a reasonable delay on the updates (simply add a sleep 3 for "update only once every 3 seconds") in addition to that. I'll leave that to you to figure out :) .

That's exactly what I meant with "offsets it". It's just semantics ;) . Air friction is definitely NOT "mostly the same" for different projectiles. Neither in real life nor ingame: 7.62mm has -0.001 6.5mm has -0.0009 5.56mm has -0.0012 40mm APFSDS has -0.00012 40mm GPR has -0.0006 120mm HE shell has -0.000275 120mm APFSDS has -0.0000396 Titan_AA has 0.05 (positive, as apparently all missiles ) GBU12 LGB has -0.0005 There are drastic differences in air friction, which is the whole reason why there's about a dozen different AP shell types alone. And yes, mass influences it, but is not the decisive factor (see the wikifor some details. Definitely not useful for a size/volume indicator. @pedeathtrian: You are correct. My mistake :) . So that doesn't help me either. --- Is there a way to get the bounding box of projectiles? That way I might get an indicator for volume. And how does the vanilla reload on ammo truck work? That one does seem to take different amounts of time depending on projectile type (even if it is insanely quick in all cases). Anyone know if/where to find that in the config/functions?

I know how to access config data ;) . However, as already stated in OP, both weight and mass are fairly useless attributes, because they are mostly not filled ( = 0). airfriction however could be an interesting approach. Still, anyone know how the effect of gravity is calculated on bullets (= bullet drop?). If there's a way to access that, that'd be an even better indicator for mass. Gravity is directly related to mass, whereas airfriction depends on shape (and can seriously be offset by active propulsion such as in missiles). Manually defining weights always works, but is inflexible. I definitely want to define as little as possible in a static way.

Also noticed that both GetInMan and GetOutMan seem to be broken right now. The only workaround would be to use the regular "GetIn" and "GetOut" EHs right now, but those you'd have to add to every single vehicle in your mission: { _x addEventHandler ["GetIn", "diag_log format ['[--WH Logs--][**GETIN**]%1 Enters %3 in %2 Seat',_this select 2,_this select 1,_this select 0]"]; _x addEventHandler ["GetOut", "diag_log format ['[--WH Logs--][**GETOUT**]%1 Exits %3 From %2 Seat',_this select 2,_this select 1,_this select 0]"]; } foreach vehicles; EDIT: @killzone_kid : Version 1.56.134787, current "stable". EDIT2: Didn't consider that with GetIn, _this select 0 and _this select 2 have to be swapped. Fixed in example.

The game treats the respawnonstart as a "suicide" (killed and killer are the same object). But I thought a bit more on the computational side: I'm guessing there's not really a way around an "if-check" inside the killed EH anyway, so I can just do the global variable solution. I'm unsetting it after first use ( = nil), so the if condition is a simple isNil). Shouldn't be too harmful computationally. The only way around it would be to somehow add the EH after the first respawn, in a guaranteed manner. I guess I could do that by using a nested EH: The first EH is only there to register the "actual" EH after the respawnonstart "kill" has occured and then is removed&deleted. A bit codespammy, though. Thanks for the input, gave me some ideas to play around with :) . EDIT: The double EH "solution" looks now like this and works fine: EH_playerKilled_first = player addEventHandler ["Killed", { if (true) exitWith { // Catch respawnonstart kill player removeAllEventHandlers "killed"; // If you have multiple Killed EHs, you can also use: player removeEventhandler ["killed", EH_playerKilled_first] _EH_playerKilled = player addEventHandler ["Killed", { // This is the actual eventhandler content! Do whatever you actually wanted in here. _this spawn { sleep 1; if (!(player getvariable ["BIS_revive_incapacitated", false])) then { // Killed EH triggers on incapacitation if "Revive" respawnsytem is used. This if-check detects this incapacitation. pv_addTickets = [playerside, -1]; publicVariableServer "pv_addTickets"; }; }; }]; }; }]; In my case, the "actual" kill eventhandler is supposed to deduct 1 ticket from the player's team when the player is killed in combat.

I have a mission that uses respawnonstart = 1 (necessary for MenuPosition respawn type). I also have event handlers that trigger on "Killed" and "Respawn". Sadly, both of these get triggered by the "respawnonstart" as well, something that I absolutely DON'T want them to. How can I best detect a "first respawn" in an MP environment? Either to explicitly exclude that from the eventhandlers, or to register the eventhandlers only after that initial spawn.

That would work, yeah. But using a global variable for this seems wasteful and "ugly".

It's not about flaming, it's about the newcomers having reasonably answerable questions. Posing a broadscale "I want something super unique and awesome, but I don't know anything!" and just hoping that someone serves you everything on a silver platter is not how it works. It's just sensible to first start to actually try and tackle the issue oneself. Then, once you hit actually concrete issues, you will find a lot of help here. Questions like OP only warrant broad/vague answers right now: Yes, it is possible to do what you want (very little isn't possible). The rough approach would be sth. like willithappen outlined. Neither is your project ridiculously difficult to accomplish, so it's a good starter, actually. However, it's not gonna be easy if you have no idea about scripting. So I suggest you "get an idea" about scripting. There's no way around that if you want to achieve anything, and you can will have a much better foundation to ask questions on. :)

http://forums.bistudio.com/showthread.php?189670-Listbox-amp-ListNBox-black-picture&p=2896515&viewfull=1#post2896515 Solution for black pictures/icons is in this thread. BI changed some class attribute names a couple of patches ago. Any old GUI stuff will have that issue. Short version: Change "picturecolor" to "colorpicture" in the UI dialog definition.

Different versions? Check your local mod cfgcompared to the server's.

You gotta make sure the engineon false is executed after the unit has landed (as in: the BIS_fnc_Unitplay is complete). As BIS_fnc_Unitplay is spawned in a separate thread (= spawn command), you need to wait for it to be done. Which should be possible using a script like this: heli1 engineOn true; _handle = handle = [heli1, recpath, [], true, true] spawn BIS_fnc_UnitPlay; waitUntil {scriptDone _handle}; heli1 engineOn false; However, sometimes the AI is stupid and still wants to immediately restart the engines. You can "cheat" a bit and use heli1 setFuel 0; If there's no fuel, the AI can't start the engine :) . I'd guess this won't work using init fields and triggers, instead you have to use "proper" scripting (sqf files).

Yup. The automatic map markers on map for friendlies and enemies are caused by a difficulty setting. If you only want those disabled, but leave the rest at regular, you'll have to change this setting in your server's arma3profile file: https://community.bistudio.com/wiki/Arma_3_Difficulty_Menu#Extended_map_info

The Titan is not added because the script doesn't add it, obviously... Either use a script that adds weapon dynamically (which makes them also work for any addon weapons you have) like below or search armaholic and similar for other popular crate filler scripts. There are plenty, and most of them work well.

Execute this engineon false; after landing