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).

Disregarding if this is realistic or not for the year 2035 where ArmA III occurs, how would I go about measuring distance along my rifle's IR laser attachment while active? I already have an eventhandler for drawing text/icons on-screen (or I could use a simple hint message), so all I really need is: Find primaryWeapon selectionPosition + direction of the IR laser emitter if my weapon has one attached. Determine if the attachment is currently activated (there should be NO rangefinding while laser is OFF). Imitate the laser's collision with the environment to find the laser's end-point to measure the distance to. Scripting hints for any of the three points above will be much appreciated, as will references to similar/related posts and answers. Thanks in advance lads/ladettes!

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.

Haha, it works! Excellent answers in both posts, thanks! I can now draw a crosshair where the laser is pointing, indicating range to target. I also have some logic in place to make sure this only happens if I have tactical or VR goggles equipped, but here is the basic "Draw3D" eventhandler code: _txtXhair = ""; _posXhair = positionCameraToWorld [0, 0, 10000]; if (player isIRLaserOn currentWeapon player) then { _posLaser = eyePos player; _posXhair = _posLaser vectorAdd (player weaponDirection currentWeapon player vectorMultiply 5000); _hitLaser = lineIntersectsSurfaces [_posLaser, _posXhair, player]; if (0 < count _hitLaser) then { _posXhair = (_hitLaser select 0) select 0; _txtXhair = str(round(_posLaser distance _posXhair)); }; _posXhair = ASLToAGL _posXhair; }; drawIcon3D ["\a3\ui_f\data\IGUI\Cfg\Cursors\weapon_ca.paa", [1, 1, 1, 0.50], _posXhair, 1, 1, 0, _txtXhair, 0, 0.02, "TahomaB", "center", false];All I am missing now is regarding question 1. As far as I know eyePos returns your eyes' world position but what I need is the laser pointer or weapon muzzle's position, either in model or world space. My best bet for finding this is selectionPosition at the moment, but I struggle to find the correct selectionName matching my current weapon's muzzle.Currently the crosshair is offset slightly since the line is emitted from my character's eyes along the weapon's aim direction, instead of from the weapon's muzzle/laser emitter along its aim direction. The offset is easy to spot with NVGs at night while aiming the weapon and squeezing off a round; the crosshair is somewhat off to the side of your weapon sight reticule. Bonus points to anyone who is able to solve this final detail for question 1, then the solution will be perfect! Thanks again for the excellent example and answers already provided.

Shamelessly stolen/inspired by The Terminator, has anyone ever pondered making a coop mission pitting you against an army of unmanned vehicles? Imagine in 2035 a computer virus of unknown origin infecting all UAV/UGV control software on Altis island, taking over and connecting the drones to an encrypted network hive mind AI that is sending them out to locations of high priority, population density or human resistance to search and destroy or secure fuel/ammunition. If you're spotted by a Darter light UAV it transmits your location to a nearby Stomper UGV or Greyhawk UAV to hunt and kill you with thermal image recognition, heavy machineguns and laser guided bombs or missiles. SkyNet going live... Might not be too fair for the human players, but it IS a scary thought/mission experiment, and by 2035 or 2045 might not be too far-fetched if you consider Moore's Law of computation power doubling every two years. Alan Turing's machine was invented in 1940, Cray-1 supercomputer in 1976, IBM Watson in 2011, ArmA III in 2035... It would perhaps not be an "AI" but rather some form of pseudo-intelligent piece of software able to infiltrate wireless military data transmissions that can understand multiple drone camera outputs and override drone control inputs, following a complex ruleset to such an extent it makes humans on the ground fear very much for their lives. Such a man-made "AI" hive mind would not need to exceed human intelligence, it simply has to excel at image recognition, target prioritization, be able to manage its limited drone fleet, fuel reserves and ammunition. It would seem almost omniscient, have near perfect aim, no remorse, and only one objective: eradicate all human life on Altis. Makes you somewhat uncomfortable, knowing there's a possibility this could actually happen in our lifetime. Doh, just remembered... The drones would not be able to rearm or refuel themselves.. Humanity is saved, yay! Anyway, has something like this been scripted/attempted already?

Make sure addon is loaded, then start 2d editor, place the CWS Config module in mission, save, play mission in multiplayer, CWS injury should then load automatically. Or, make sure addon is loaded, then play any mission in multiplayer as Zeus, place a "Load CWS" module on top of a unit on the map, CWS Injury should then load automatically.

Regarding missing script files, I got a bit further after making some minor adjustments. Here is what I did: In cws_injury\dialogs.hpp change ChessmastersWoundingSystemDisplays so it becomes "cws_injury\functions\ui\displays\" without the first backslash (\) character. In cws_injury\cfgFunctions.hpp do the same for the six file paths, again removing the first backslash (\) character. Once this is done, I no longer get any missing script errors and can start the mission, both on a dedicated or a non-dedicated server. I assume this is because the #include statements do not need the initial backslash when run as a mission script, but need it when CWS is loaded as a mod. Sadly, however, I am still not seeing any CWS modules when I log into Zeus. According to the Curator article, community addons must have their modules placed in the editor to appear. Since we try to use CWS as a script and NOT as an addon, this is not possible. I then tried various things on the Zeus init field to get the modules loaded, but so far without any luck: activateAddons ["cws_injury"]; this addCuratorAddons ["cws_injury_ModuleConfig", "cws_injury_ModuleCWSLoad", "cws_injury_ModuleDamageUnit", "cws_injury_ModuleEmpty", "cws_injury_ModuleFailsafeReload", "cws_injury_ModuleRevive"]; call compileFinal preprocessFileLineNumbers "cws_injury\functions\init\fn_initCWS.sqf"; I found the addon/module names listed above in the cws_injury\config.cpp file, so they should be correct, but I see no CWS modules appearing as Zeus. The first option SHOULD be the correct procedure, but once I open Zeus I get a message "No entry 'config.bin/CfgPatches.cws_injury'.". The Curator article mentions the activateAddons statement can only be executed before the mission loads, but even if I put the statement inside init.sqf I still get the same error message when opening Zeus (even if I copy-paste the CfgPatches class from config.cpp into description.ext). So I have given up getting the script version working for now. Until Chessmaster or someone else can get back with a working solution for the script version, I will resort to the mod setup version instead.

Awesome mod! Question: Is there a userconfig file for AGM somewhere, housing all the user options and keybinds? Some mods like ACRE etc. store this under a modname subfolder of "C:\Program Files (x86)\Steam\SteamApps\common\Arma 3\userconfig". Having this file allows editing settings outside Arma 3, and allows you to reimport your old settings if you ever uninstall/reinstall AGM. Suggestion: Perhaps a separate keybind for wind measurement. Also, when changing keybinds for AGM, you are given the choice of Save or Cancel. Perhaps this could instead be Clear or Cancel? Then just save the keybind automatically when it is pressed. With a Clear option you can remove a keybind you don't need without having to bind it to some obscure keyboard button. Keep up the good work!

Sorry for reviving this post (although it is less than 4 months old); if the below is not relevant feel free to move to anew post. Problem: No analogue control of reverse vehicle movement. Description: The "Car forward fast" binding, when mapped to an analogue controller's axis, works just fine once you get out of the controller's deadzone; you can set the vehicle's max speed depending on how far you push the stick/throttle/etc. But the "Car back" binding, when likewise mapped, is different outside the deadzone; here the vehicle always accelerates until reaching its top reverse speed, regardless of how far you push the stick/throttle/etc. Question: Am I using incorrect vehicle control bindings for cars, or is this just an issue with the Hunter vehicle I tested (always reverses at -55 Kph regardless of controller input), or is this an ongoing issue that is yet to be fixed? If so, is there a corresponding bug on the feedback tracker I can follow or should I open a new one?