dreadedentity

In Arma we have the concept of locality. It's easier to understand using real objects like soldiers, but additionally anything shown to a user is only shown locally (on that computer). So your call to BIS_fnc_showNotification will only show to a player, on that computer, when that line of code is run. Since you are not running the game through that computer, nothing is shown to you, and if you were able to somehow connect as the dedicated server it additionally has no interface, so nothing would be shown anyway. Luckily we have a command called remoteExec which allows us to specify that we want some code to execute on remote machines (other people's computers). Ok, all of that just to say use this instead: ["notiNewMechRec"] remoteExec ["BIS_fnc_showNotification", 0]; If you are planning to do a lot of multiplayer scripting you will need to be very familiar with all of this, but you'll get better at it as you use it more

There is some wasted performance with this due to previous design choices but you can run a repeating loop over allUnits and set the event handler from 1 computer (server is probably best). Check against an object variable (get/setVariable) whether to add event handler or not. Adding MP event handler is already global so no need for remoteExec

That's what I'm trying to highlight, you've applied a strange scaling factor to all of your controls and now you input values from -10 to 40 to get screen position and control size. Regardless of safezone or pixelGrid, values should be supplied as a percentage of the viewport, they should only ever be between 0 and 1, that's what everyone will be familiar with... I'm unfamiliar with your process but I think it's quite standard to save your controls as "GUI Editor" format as well as class controls due to the GUI Editor automatically importing clipboard data. I think the best option for you would be to load the editor format, fix scaling, then re-export

Welcome to the world of Arma GUI scaling and "responsive" design I think first it will be helpful to affirm your understanding of the different UI scaling commands: Viewport (no auto-scaling commands) - Absolute position (expressed in percentage) as if a 4:3 screen was superimposed over your current monitor safeZoneX - Offset necessary to apply to Viewport to get the real "0" value on monitor. Scaled to "real" monitor size behind the scenes (using resolution set from settings menu) safeZoneY - Same as above but for Y axis safeZoneXAbs - Same as safeZoneX but scaled for multiple monitor setup (if 1 monitor then the same as safeZoneX) safeZoneW - Scaling factor to get the real width of monitor. Scaled to "real" monitor size automatically (using resolution set from settings menu) safeZoneH - Same as above but for height safeZoneWAbs - Same as safeZoneW but scaled for multiple monitor setup (if 1 monitor then the same as safeZoneW) pixelH - Height of 1 pixel pixelW - Height of 1 pixel pixelGrid - Grid size based on screen resolution, interface size and configs (I don't know this system very well so this is just copied from elsewhere on the wiki). Pixel grid seems to be 12x6 so I'm not sure where you got "(5 * 0.5 * pixelW * pixelGrid)" from Have a look at the SafeZones page on the wiki for a write-up (I recommend looking at all the pictures first then try to make sense of the words). Also check out Arma 3: Pixel Grid System for information about the pixelGrid. You're mixing up 2 different UI systems without having a strong understanding of them which is adding to the confusion (safezone and pixel), stick with 1. Since I'm most familar with safeZone, I'll continue with that. First change your defines to all be in safezone types: #define UI_GRID_X (safezoneX) #define UI_GRID_Y (safezoneY) #define UI_GRID_W safeZoneW #define UI_GRID_H safeZoneH #define UI_GRID_WAbs (safezoneWAbs) #define UI_GRID_XAbs (safezoneXAbs) /*#define UI_GRID_HAbs (safeZoneH) */ //There is no such thing has HAbs or YAbs in arma, multimonitor setups are assumed to be in-line, horizontal, so these are not necessary Before we even get to scaling, a history lesson is in order. In the early days of computing when CRT screens were the height of technology (think 90's and earlier TV's eh?). In case you need a refresher, they were those big, heavy, and square behemoths that everybody and their grandmother seemed to have and displayed nothing but General Hospital after school. Well those monitors had an aspect ratio of 4:3. This kind of monitor has been given a somewhat (un)affectionate moniker of "squares" by me, although you can clearly see now that they were not quite square Why does Arma support this even though every monitor you have touched in the past 10 years (probably) has been 16:9? Arma is old. Older than 2013 when Arma 3 was released. This codebase has been evolving since OFP which was released in 2001. Now since the first LCD monitors were not created until the mid 90's (and they were 4:3 too anyway), OFP was more than likely going to be played on a 4:3 monitor, which would have been the most common aspect ratio of the time. Now, let's talk about scaling. If you have a 1080p monitor (first of all your aspect ratio is 16:9). This is better for humans to look at because it takes up more of your active vision (4:3 monitors had dead-space on either side where your brain could pay attention to things not on the monitor). There is some math stuff, dealing with the golden ratio (Wikipedia), that I don't quite understand, but my previous sentence should more than explain it. Anyway, since we have affirmed your knowledge on the different scaling commands it should be easy to understand that accurately placing components on the screen in Arma requires 3 things, a percentage of how much of the Viewport, multiplied by scaling factor (width or height), plus Offset (X or Y). Thus: (0 * safeZoneW) + safeZoneX //left edge of current resolution (0 * safeZoneH) + safeZoneY //top edge of '' (1 * safeZoneW) + safeZoneX //right edge of '' (1 * safeZoneH) + safeZoneY //bottom edge of '' //Can, of course, be simplified to: safeZoneX safeZoneY safeZoneW + safeZoneX safeZoneH + safeZoneY I hope this helps to demystify GUI scaling in Arma somewhat for you

No problem, can't wait to see what you're going to make with this

This script pretty much just teaches you how to make dialogs lol //data = /* DATA ARRAY GOES HERE [["GROUP NAME", "PATH TO PICTURE"],[],[],etc] */; data = [ ["test 1", "#(argb,8,8,3)color(1,0,0,0.5)"], ["test 2", "#(argb,8,8,3)color(0,1,0,0.5)"], ["test 3", "#(argb,8,8,3)color(0,0,1,0.5)"], ["test 4", "#(argb,8,8,3)color(1,1,0,0.5)"], ["test 5", "#(argb,8,8,3)color(0,1,1,0.5)"], ["test 6", "#(argb,8,8,3)color(1,1,1,0.5)"], ["test 7", "#(argb,8,8,3)color(0,0,0,0.5)"] ]; //#Tizuwo private _guiEditorOutput = [ 1.063, ["quickgui",[[0,0,1,1],0.025,0.04,"GUI_GRID"],0,0,0], [1500,"RscListBox",[1,"",["0.322812 * safezoneW + safezoneX","0.276 * safezoneH + safezoneY","0.137812 * safezoneW","0.224 * safezoneH"],[-1,-1,-1,-1],[-1,-1,-1,-1],[-1,-1,-1,-1],"","-1"],[]], [1200,"RscPicture",[1,"#(argb,8,8,3)color(0,0,0,0.5)",["0.467187 * safezoneW + safezoneX","0.276 * safezoneH + safezoneY","0.203437 * safezoneW","0.224 * safezoneH"],[-1,-1,-1,-1],[-1,-1,-1,-1],[-1,-1,-1,-1],"","-1"],[]], [1600,"RscButton",[1,"Pick Group",["0.322812 * safezoneW + safezoneX","0.514 * safezoneH + safezoneY","0.065625 * safezoneW","0.028 * safezoneH"],[-1,-1,-1,-1],[-1,-1,-1,-1],[-1,-1,-1,-1],"","-1"],[]], [1601,"RscButton",[1,"Cancel",["0.395 * safezoneW + safezoneX","0.514 * safezoneH + safezoneY","0.065625 * safezoneW","0.028 * safezoneH"],[-1,-1,-1,-1],[-1,-1,-1,-1],[-1,-1,-1,-1],"","-1"],[]] ]; disableSerialization; private _display = createDialog ["RscDisplayEmpty", false]; { private _control = _display ctrlCreate [_x # 1, _x # 0]; _control ctrlSetText (_x # 2 # 1); _control ctrlSetBackgroundColor [0,0,0,0.5]; _control ctrlSetPosition ((_x # 2 # 2) apply {call compile _x}); _control ctrlCommit 0; } forEach (_guiEditorOutput select [2, 4]); { lbAdd [1500, _x # 0]; } forEach data; (displayCtrl 1500) ctrlAddEventHandler ["LBSelChanged", { private _index = _this # 1; (displayCtrl 1200) ctrlSetText ((data # _index) # 1); }]; (displayCtrl 1600) ctrlAddEventHandler ["ButtonClick", { (lbCurSel 1500) call myScript; closeDialog 0; }]; (displayCtrl 1601) ctrlAddEventHandler ["ButtonClick", { closeDialog 0; }]; That should get you most of the way there 🙂

Interesting requirements (restrictions?). GUI can be built with sqf-only but is a lot more tedious. Can't work on this now but will edit later. I can treat this like a speed challenge 😛

In the editor double click on the rectangle above your units (this is the group icon) and there should be a box that says INIT; paste this there: this setCombatMode "YELLOW";

So there are 2 things that could be happening here I think. One, when someone in the group detects an enemy, the group goes into "combat" mode. The squad leader might be ordering a new formation. That would be a lot more difficult if that's the case Two, the units are breaking formation to engage targets. In this case you can use setCombatMode "YELLOW" and hopefully they will stay in formation

How do you create the convoy?

What command are you using to make them shoot?

I'm more than a year late seeing this so maybe you've already found the answer, but this is caused by race conditions created in user-scripts. The short answer is that display 46 just doesn't exist at the time that code runs, so no EH can be added. That can be easily checked with: //in any "initX" script at the very beginning with uiNamespace do { myVar = findDisplay 46; }; uiNamespace getVariable "myVar" //put in console as a Watch variable; returns displayNull which is shown as "No display" I can't give you the long answer as I am only knowledgeable enough with the initialization order to make my stuff work 😛 You may have realized this by now, but the actual important thing here and why it works is suspending the script with waitUntil allows time for the display to get created. You may already know that some commands just don't seem to work in init.sqf until it has been suspended in some way. Sleep will work just the same to create this effect. This is the exact reason why you'll see "sleep 0.001;" at the very beginning of so many of my init.sqf's

admin

That seems to be more of a statement than a question but I'll respond as if you're asking how to do the above. This ends up being more complex than you'd expect it to be due to the way Arma handles dead; Most of the "allX" commands don't return dead units. And even if you get references to the dead units they are all on CIV side. Fortunately we can get their original side from the config in CfgVehicles The formula to calculate the percentage of dead units would be: number dead / total units So after you put down the trigger edit it's settings to: Type: None Activation: Anybody Activation Type: Present Condition: count (allDeadMen inAreaArray thisTrigger) / count (thisList select {_x isKindOf "Man"}) > 0.5 You have to make sure you are only counting "Men" from thisList (will contain animals eg snakes n stuff) Checking side of dead men can be done in a similar way from config values as mentioned above: (allDeadMen inAreaArray thisTrigger) select {getNumber (configFile >> "CfgVehicles" >> typeOf _x >> "side") == 0} //side == 0 OPFOR //side == 1 BLUFOR //side == 2 GUER //side == 3 CIV (+ animals) I know there's a lot of optimization that can be done, but I'm pretty sure this works and I have to go heheh 😛

This is too ambiguous. Are you asking because: You need similar functionality - There are numerous ways to do this You want to know the exact implementation - How would we know? You believe it is not working properly

Boom Now with 100% more MP compatibility *Mic drop* Github mirror

I've never even heard of this lol

This bug is like a fine wine, getting better with age 😄

On BIS_fnc_holdActionAdd wiki page there is a thing that says "UI that shows all icons", if you put that code in a normal addAction and run it I believe I remember seeing the "progress" rings there. There's 24 if I remember correctly

that just makes it better

Try not to think about it like this, but like...little pop quizzes from the devs

It's worth thinking about if you have a very script-heavy mission and need to offload some processing to the clients. If not, then maybe not so much

This just isn't going to be possible because of the locality of event handlers. While it would be simple to restrict unit spawning to the server only using remoteExec, the only player that has the same locality as the server is the player that hosted the MP mission; If it is a dedicated server then nobody will have the same locality as the server. Additionally there could be any number of players (well, 128) that could shoot the unit at any given time, but the event handlers are all local and will only fire where the shooter (not the target) is local. Thus the only way I can think of this working is that each client adds it's own event handler to the unit; that can be easily done with remoteExec and use 0 as the "target" parameter: [/* remoteExec args */] remoteExec ["addEventHandler", 0]; edit: I didn't see there was a page 2 and basically just rewrote everything _foley already said...

I'm pretty sure say3D immediately stops when an object dies, so since it was already dead it probably never played. In the wiki page for say3D there is an example (#2) showing how to fake a dead person playing a sound, alternatively use playSound3D

Just wanted to drop in again to say instead of checking if the unit is alive every time, just check until it dies then remove the event handler if (alive _target) { //do EH code } else { _target removeEventHandler [_thisEvent, _thisEventHandler]; }; A side note, it definitely sounds like this is for MP so make sure you remoteExec since event handlers have local effects