sjakal

No luck on my end either. My best guess is it's because [Mute] is an Active Text embedded into part of the player/squad xml details pane and not its own control or button. player groupChat "MUTE-like display controls"; { _disp = _x; { _ctrl = _x; if (ctrlType _ctrl in[11] or toUpper(ctrlClassName _ctrl + ctrlText _ctrl) find toUpper("MUTE") > -1) then { systemChat (str(_disp) + " " + str(_ctrl) + " (" + ctrlClassName _ctrl + ") " + ctrlText _ctrl); }; } forEach allControls _x; } forEach allDisplays + (uiNamespace getVariable "IGUI_Displays"); Searching for MUTE in uppercase control classnames or texts does not find the [Mute] link but maybe other control fields should be concatenated into the find string. Maybe I can't find it because I'm only one player on the server. Oh well, regardless of finding it, I also struggle to activate non-buttons or get their associated action.

And another quick/dumb question: What are the script commands for reading/changing the current MFDs shown? In my case I have a script that used to "showGPS false" if player was not wearing appropriate goggles or helmet. This no longer works, neither does showHUD [false x8] and (findDisplay 311) closeDisplay 1 does not work either.

Hi phronk/hustler, I sent you a Steam friend invite if you need a tester/guinea-pig :) script sounds wonderful! Steam name should be Sjakal, arma profile Bishop. My timezone is CET so compared to your US timezone it may be tricky to be online at the same time, but perhaps in my late evenings or weekends it can work. I've played Arma since it was called Operation Flashpoint, and I have some Arma scripting experience (i.e. currently fiddling around with my own revive system).

Finally found it on my own LAN server; I local exec the code below to find maplike display controls based on their control type or class name: player groupChat "Maplike display controls"; { _disp = _x; { _ctrl = _x; if (ctrlType _ctrl in[100,101] or toUpper(ctrlClassName _ctrl) find "MAP" > -1) then { systemChat (str(ctrlIDD _disp) + " " + str(ctrlIDC _ctrl) + " " + ctrlClassName _ctrl); }; } forEach allControls _x; } forEach allDisplays + (uiNamespace getVariable "IGUI_Displays"); One of them listed "311 101 CA_MiniMap" so I picked that one for ctrlAddEventHandler draw calls. It seems after version 1.70 the GPS minimap is now in allDisplays list as Display #311 and Control #101. My script above does not show in which of the two lists it found the minimap; before ArmA 3 version 1.70 the GPS minimap used to be in the IGUI_Displays list instead, as Display #133 and Control #101. Below are the four most common map variants you can hook into; idx 0 is from allDisplays and idx 1 is from IGUI_Displays. Please let us know their display/control/list if you discover further map variants. case "UAVMAP": {_idd = 160; _idc = 51; _idx = 0}; case "ARTYMAP": {_idd = -1; _idc = 500; _idx = 0}; case "BIGMAP": {_idd = 12; _idc = 51; _idx = 0}; case "MINIMAP": {_idd = 311; _idc = 101; _idx = 0}; PS: Adding draw calls to one GPS minimap will show them on the second MFD as well. Perhaps after additional content updates more of the IGUI_Displays list will be consolidated into the allDisplays list.

Good stuff, looking forward to seeing this. Reminds me of the original Ghost Recon situational awareness HUD (hoping there will be some incoming fire/enemy/ping arcs added as well). I also wonder if any of this has synergies with description.ext showHUD vehicle radar and vehicle compass, and the upcoming Jets DLC aircraft radar; if it's possible to streamline them together for fewer variations of those HUD elements. Only to whatever extent is reasonable of course; I know there's a big difference from personal range awareness HUD to a full-blown aircraft and AAA radar HUD, but still it may simplify things for users and developers having fewer variations. And maybe if it's possible to merge some of its info to the GPS minimap when it is shown, so you only have the minimap taking up screen space with the radar info added on top. Apologies if this was all discussed before. And finally if group member name list can synergize with or be replaced by the commanding menu with a few improvements, again to reduce the amount of redundant HUD elements on screen for group leaders and members.

Sorry if this is not a useful answer, it's merely my own thoughts regarding AI load balancing: Would be nice if server could monitor every connected host's FPS (dedicated server, headless or player client) and when needed transfer ownership of an AI group to the machine with best reported FPS (dedicated server itself, headless or player client). Seeing as Zeus players already own their spawned AI groups, it should be possible transfer any AI groups to another machine on the fly if the previous machine is overloaded or disconnected (hopefully in a JIP compatible manner without the AI losing information on known enemies, waypoints, scripting, etc). This might reduce the need for a Headless Client. Any AI addons/scripting must then be able to continue running on the new machine where the old machine left off. Nasty. I am wondering if anyone has experimented with something like this? This would be done in addition to any COOP multiplayer code optimization and AI caching (or similar temporary disables until players are nearby).

Hi, please redirect if answered elsewhere. As part of my Steam launch options (along with -nolauncher -useBE to skip the launcher) I have added the parameter: -profiles=. This lets me store my settings/profiles under the Arma 3\Users game subfolder. Why I want to do this is irrelevant to this topic; my problem after doing this is as follows: The game does not seem to properly save its graphics options, and I cannot see any arma3.cfg file was modified after launching the game with the parameter shown above. I also cannot see ANY arma3.cfg file in the Arma 3 folder, or any subfolder under that. I do see arma3.cfg in my old Documents\Arma 3 folder, but this file is not modified with latest changes (nor should it be). Perhaps part of the issue might be Arma 3 lacks write access to the arma3.cfg location? I find this hard to believe, however, as the game created the Arma 3\Users subfolder on its own without my help/interaction. So, to repeat the question: Is there an issue with the game not saving its graphics options to arma3.cfg when using the -profiles parameter? And in which location is arma3.cfg stored in this case? Thanks for the help. PS: Be careful with Steam launch options and referring to non-ascii folder names, as Steam does not seem to support such characters. For instance, I cannot input Æ Ø or Å characters (and possibly many more).

Hmm, busy weekend so I haven't had time for testing yet, sorry. Maybe if you have a demo mission I can simply load up? I updated my own code example above to avoid some confusion over PositionAGL vs PositionASL and slightly improve performance. Turning on the IR laser in my own demo mission costs me roughly 2 frames per second now. I also tried updating the laser position in one loop 20 times per second and redrawing it on screen separately via the eventhandler each frame but did not notice any performance improvement. Of course this slowdown matters most during AI heavy 12v12 firefights or more where FPS is already below 45 without the script running. PS: My demo mission has some other features beside the IR laser rangefinding (see the Briefing section on the Map screen) that are likely to affect the FPS also; Dynamic View Distance increases terrain draw distance and lowers object draw distance the higher up you are flying, and Augmented Reality shows target icons if you wear tactical goggles and a GPS receiver. The Stealth AI part in particular is work in progress; dragging dead bodies has not yet been implemented. Slot up as SUPPORT 1 Squad Leader for Zeus access.

Whow! Nice stuff - if it has similar precision it is definitely preferable. I also noticed frame drops due to all the vector mumbo jumbo I do every frame. The auto-correction is just icing on the cake. I'll give it a whirl over the weekend and report back! On quick inspection the offset seems to work if you permit rangefinding only when the player is aiming their weapon. Lowering the weapon is likely to affect the laser position and precision. You can test this quickly by replacing the (cameraview == "GUNNER") with (true) and engaging freelook. Will take a closer look in the weekend, and I might be able to improve performance on my own implementation as well. Talk to you later :)

Alright, I think I finally have SOMETHING! Try this code in place of my previous examples: //Default to 5000m in front of camera if laser is disabled _arXhair = positionCameraToWorld [0.000000, 0.000000, 5000.000000]; _arXtext = ""; _arAngle = 45; if (player isIRLaserOn currentWeapon player) then { _posXhair = AGLToASL (player modelToWorld (player selectionPosition "Weapon")); //Create the three axes from the player character model weapon memory point _right = _posXhair vectorFromTo AGLToASL (player modelToWorld (player selectionPosition "righthand")); _forward = player weaponDirection currentWeapon player; _up = _right vectorCrossProduct _forward; _right = _forward vectorCrossProduct _up; //Offset the laser start position using the three axes created above _posLaser = _posXhair; { //This default LaserOffset below seems to work OK if (isNil "LaserOffset") then { _posLaser = _posLaser vectorAdd (_x vectorMultiply ([0.700000, 0.770000, 0.100000] select _forEachIndex)); } else { _posLaser = _posLaser vectorAdd (_x vectorMultiply (LaserOffset select _forEachIndex)); //These three axis and offset drawlines can be hidden when no longer needed if (_forEachIndex == count LaserOffset - 1) then { drawLine3D [ASLToAGL _posXhair, ASLToAGL (_posXhair vectorAdd _right), [1,0,0,1]]; drawLine3D [ASLToAGL _posXhair, ASLToAGL (_posXhair vectorAdd _forward), [0,1,0,1]]; drawLine3D [ASLToAGL _posXhair, ASLToAGL (_posXhair vectorAdd _up), [0,0,1,1]]; drawLine3D [ASLToAGL _posXhair, ASLToAGL _posLaser, [1,1,0,1]]; }; }; } forEach [_right, _forward, _up]; //Find the laser end position by using a 5000m line intersect check _posXhair = _posLaser vectorAdd (_forward vectorMultiply 5000.000000); _hitLaser = lineIntersectsSurfaces [_posLaser, _posXhair, player]; if (0 < count _hitLaser) then { _arXhair = ASLToAGL ((_hitLaser select 0) select 0); _arXtext = str(round(_arXhair distance ASLToAGL _posLaser)); } else { _arXhair = ASLToAGL _posXhair; _arXtext = ""; }; _arAngle = 0; }; drawIcon3D ["\a3\ui_f\data\IGUI\Cfg\Cursors\weapon_ca.paa", [1, 1, 1, 0.5], _arXhair, 1, 1, _arAngle, _arXtext, 0, 0.02, "TahomaB", "center", false];Then go in-game, activate the weapon IR laser, and then Local Exec the following via Debug Console: LaserOffset = [0.700000, 0.770000, 0.100000]You should then see a red, green, blue and yellow guideline somewhere near your player character when in 3rd person, and your crosshair should now be roughly at where the IR laser is pointing. Using the red, green and blue guides, you can now adjust your offset in real-time via the in-game Debug Console until you are satisfied. Notice how the yellow line indicates your offset from the "Weapon" position.Granted, the axes do not align perfectly with the weapon's right and up axes, but it should still be an improvement over eyePos since that was not weapon-relative but this new position seems to follow the weapon around even when you peek around corners. Once you are satisfied the drawLine3D commands can be commented out to hide the visual guides and increase FPS slightly. Experiment as needed and please post your findings and preferred LaserOffset :)

Good idea with spawning a lasertarget, and nice find on checking player is aiming! I tried some variations of nearestObject in Debug Console, sadly to no avail, always resulting in <NULL-OBJECT> most likely since the laser attachment has no logical game object but only a model. systemChat str(aimPos player nearestObject "acc_pointer_IR")So it seems hardcoded offsets are still the most valid option, but as pedeathtrian mentions we need two non-colinear and weapon-relative direction vectors to do that, and so far we only have weaponDirection. The eyeDirection vector might be non-colinear, but it is not weapon-relative. A shell casing eject direction would be a good alternative, if such is accessible via scripting commands. Oh! Or maybe a vector from "Weapon" to the "righthand" memory point since it is practically glued to the weapon at most times anyway.But yeah, the optimal solution of course is somehow reverse engineering the in-game laser beam start or end point. _posXhair = ASLToAGL _posXhair; // insert the two code lines below here _posLaser = ASLToAGL _posLaser; drawLine3D [_posLaser, _posXhair, [1,1,1,1]];PS: Add the lower two lines above to my previous code to draw the line simulating the laser beam on-screen if you have not done so already, it makes visualizing and offsetting the positions easier.

At work myself so will follow up later today. Quick thoughts: Using "pilot" position may give issues similar to eyePos if player lowers their weapon while laser is active. The "Weapon" memory point avoids this potential issue. I also totally agree; investigating models is way too tedious so a good hardcoded default offset is the way forward, with special offsets for special weapons as needed. Thanks for the rapid responses guys!

Quick morning update. According to this reddit it is currently impossible to get a man's current weapon object. It is easy to find the weapon classname, but impossible to get a reference to the weapon object itself. One tedious fallback option then is traversing the configFile hierarchy for currentWeapon and the "acc_pointer_IR" laser to find their proxy/memory point offsets from the weapon/proxy point of origin, and then use their combined offsets from the player selectionPosition "Weapon". To avoid such tedium, a final alternative is simply hardcoding an offset from player selectionPosition "Weapon", but this has obvious disadvantages; you have to hardcode different offsets for each weapon in the game, and any possible modded weapons you wish to support in the future. Guess I'll have to further investigate the cfg hierarchy but I doubt it is even possible to find the proxy/memory point offsets in there. Oh well... You've gotten me very far guys, thanks!

Yeah, I've been struggling with exactly that. Looking at the IR laser at night on close range walls/targets, it seems the endpoint of the IR laser has no relation to where your optics or iron sights are zeroed, so I get the feeling my best bet is using the muzzle/sights/optics as point of origin instead of the laser emitter. I read somewhere that weapons or their sight attachments have an "eye" or "opticsView" memory point, but that implies I somehow need to get a reference to the weapon or attachment model in the Cfg hierarchy, starting from the player character. Alternatively I could just start the laser from the current weapon muzzle position in world or player model space, but again I struggle to find that position. Hopefully this is somewhat easier and already possible using standard OPF/ArmA commands, so I can avoid traversing Cfg/model hierarchies on subordinate weapons/attachments. The "Weapon" memory point on the player is a very good suggestion, although it seems to be quite heavily offset from where the weapon actually is. Testing this as Zeus after I kill an AI soldier to drop his weapon, I think the "Weapon" memory point is about ½m to the side of the rifle when it lies flat on the ground. Perhaps I could hardcode an offset from here into the center of the weapon. I will investigate this further tomorrow. Thanks again for the tips and help you've given already guys! This is indeed just perfectionism or nitpicking :)

I think the problem with primaryWeaponItems or weaponAccessories is they simply return the classname of the weapon attachment, and not the model's memory point for the laser emitter. I tried this in the in-game debug console, but all I got was position [0, 0, 0]: systemChat str(player selectionPosition "acc_pointer_IR")I tried looking at Animations while in-game but as far as I know it only shows the animation names, and does not show the various memory points of my current character model. I would probably have to inspect the actual player/weapon/laser in a model tool/editor to find the memory point. Once that is found, hopefully its name can be used for the selectionPosition.