mjblay

Zehn's Advanced GPS, Laser Designator, and Rangefinder Mod Hello to the Armaverse, this is the first release of my first mod, the Advanced GPS, Advanced Laser Designator, and Advanced Rangefinder mod. All three come with new features: Advanced GPS Features: On-map GPS display that changes into an interactive control on mouse-over. More detailed 5-digit easting and northing coordinate system that allows precision down to 1 x 1 m grids on the map. New display that follows your map mouse cursor with larger, more readable text and precise easting and northing coordinates. "Find" function that allows you to enter easting and northing coordinates on which to automatically center your map. Measurment of distance between your position and your cursor. Bearing of your cursor with respect to your position in either degrees or angular mils. Ability to draw a straight line to measure distance and bearing from one point to another. Ability to link with Advanced Laser Designator or Rangefinder to calculate observed position. Advanced Laser Designator and Rangefinder Features: There are four total new items, both the laser designator and rangefinder come in two versions: first focal plane reticle and second focal plane reticle. First focal plane reticles have accurate mil-hashes labeled with numbers. This makes range estimation possible using mil subtensions if use of the laser rangefinder is not possible or not desirable. This also greatly facilitates communication between sniper and spotter. Azimuth display can be changed between degrees and angular mils for more precise long-range direction. Items can connect to Advanced GPS. Coordinates of observed position displayed when connected to Advanced GPS and range to observed position is known. Ability to mark map with observed position if player posesses Advanced GPS. Laser designator thermal imaging is now actually White-Hot and Black-Hot; no more green Advanced Laser Designator and Rangefinder Realism: Rangefinding and target designation lasers are separate. Rangefinding laser is modeled after 1550 nm IR laser found on common modern-day military hand-held rangefinders. Rangefinding laser is not constantly on. The user can control its emission to send a single pulse or a pulse every second. This prolongs battery life and maintains stealth (IR lasers can be seen by night vision). Accuracy of range measurement is +/- 1 m up to 2500 m but decreases beyond that range. Accuracy of range measurement is decreased by rain and fog If rain or fog is dense enough, rangefinding measurements may not be possible. I also threw in a new LRPS clone with an illuminated reticle based on the Schmidt & Bender P4L Fein that has an integrated compass that can also be toggled between degrees and angular mils (again, helping with accurate communications between sniper and spotter). Videos Version: 0.1 Download Location: Dropbox @Zehn_Root.zip or TinyUpload @Zehn_Root.zip -- Extract this into a folder called @Zehn_root in your Arma 3 directory. It includes addons\zehn_root.pbo and addons\zehn_root.pbo.Zehn.bisign. Also included in the .zip file is a mission file to use in testing the items called Zehn_Mod.stratis. After you unzip, drag this folder into your single player missions folder if you want to play around with the items. Class Names: Future Plans: Known Issues: A Call for Help? References: Credits and Thanks: I welcome your feedback, comments, questions, concerns, and criticism. Have fun with it! -Zehn

Yes, my apologies to the community, but I've been pretty busy with real-life stuff since I released this and my clan disintegrated so I haven't been spending as much time with ArmA 3 as usual. That, and I'm an amateur programmer at best -- sometimes it would take me 6-8 hours just to figure out a certain component of the mod. After working on it for a few weeks after its initial release, my plans to split it into two separate mods (an AN/PSN-13 with the map overlay that works in the current mod and an LTLM similar to the TRIGR from Bae Systems) seemed to be a little more than I was ready to handle. I may pick it up again eventually, and I would certainly be open to collaboration with other authors. If nothing else, I hope some other mod maker takes a look at the code to see how I did the continuously-updating map display that changes to an interactive dialog when you mouse-over it. So far, I haven't seen any other mods with this type of functionality or mods that use this type of solution (combined display and hidden dialog overlying it) to overcome the problem of having an interactive dialog that is continuously updated in the main map view. One thing I did see was what appeared to be a view through the viewport of a modern LTLM. It was only onscreen briefly, but it appears on the introductory clip in the TV show Bomb Patrol Afghanistan. I think if I were to eventually undertake a more realistic LTLM, I would model the viewport after the one in this clip with all the data at the bottom. Thanks for your post! Zehn

Sorry, was out of town for the Labor Day weekend Yes, thank you for that detailed feedback. In watching the video, it seems that the custom User Action Menu items added by my mod are interacting with other custom User Action Items, likely added by the mission. I again tried to recreate this behavior with a new mission in the mission editor and could not get it to happen. One issue I did discover, however, was that when changing from a scoped view when a weapon is equipped directly to the binoc view with any of the rangefinders, the displays do not work. I'll add this to the initial post as a known issue and try to find a solution for it. With regard to the bug that happens when using the User Action Menu, my goal is to get rid of this mod's reliance on the User Action Menu altogether. I'm not certain that'll fix the problem though. Again, thanks for helping so much with this feedback. Again, let me express my apologies for being so green in the mod-making world, but I'm not sure how to go about making a separate server key. In reading ArmA: Addon Signatures, it notes the following: Advanced usage scenario: Server keys One addon can be accompanied by multiple signatures, each signed with a different key. One application for this can be server admin can create his own key for his server, and can use it to sign all addons on the server he considers safe. Note: For this usage style, signature files for the addons need to be distributed to all users connecting to that server. If you have specific instructions for how I should make a different key, I'd be happy to follow them. Yes, apologies for leaving that hint in there. It was for debugging. I forgot to comment it, but it'll be gone in the next version. Hmm, I'll have to look into that. I'm not really sure why that would happen. I'm going to start a known issues list and put it on the first page of this thread. Then I'll work on them as I get time.

Well, I just tested it at some length, trying all the different custom User Action menu items (Turn Rangefinder On, Establish GPS Link, Change to Degrees, Single Rangefinding Pulse, and Increase/Decrease Rangefinder precision) and the bearing and elevation were continuously updated regardless of whether the User Action menu was displayed. I'm not sure why you're experiencing this. If you check your Arma .rpt files, there may be an error logged that helps. With regard to Ctrl-M to display the on-screen GPS, I confirmed that it often does not work with this mod. Apologies for that. Again, in future releases, I plan to overhaul the key binding and key press code. -Zehn

Thanks for all the feedback! It really helps. I tested the GPS UI using windowed mode at different window sizes, and it seemed to work ok that way. I'll have to try playing full-screen at different resolutions. I believe that likely stems from my keypress handler which is not ideal. With future releases, I plan to use CBA to allow the user to assign keys to the mod's functions. As in the bearing/azimuth stops updating when you open the User Action menu (i.e. mouse menu)? I haven't noticed this, but I will take a look at it. The rangefinding laser is designed to work in only two modes, however: Continuous mode in which a rangefinding laser pulse is sent out once every second, and Single pulse mode in which one laser pulse is sent out only so as to range one target The rangefinding laser is separate from the target designation laser, which can be kept on continuously and is still controlled using the left mouse button. The target designation laser will not work for rangefinding. The two modes of the rangefinding laser can be controlled with the user action menu. I changed how this works from the stock Arma laserdesignator and rangefinders because having a laser sending rangefinding pulses continuously wastes battery, is not very stealthy, and is really not useful. Laser is electromagnetic radiation, after all, and what kind of stealthy JTAC or sniper team would want EM radiation beaming from their position continuously whenever they put their laserdesignatior/rangefinder up to their eyes? Sounds like a great way to get mortar rounds landing on your head. Ideally, in future releases of the laser designator/rangefinder, I would like the rangefinding laser to emit a beam visible by night vision gear whenever the rangefinding laser is in use, but I'm working on revamping the GPS display first.

I took care to comment most of the code pretty well. There were a few places where I was lazy with the commenting, mostly just because I was in a hurry to get it published. But sure... if you want to modify it so it drops a map marker on everyone's map, it shouldn't be that difficult to do. I think the ideal solution would be to have the rangefinder interface with a more advanced GPS module that could store the marked coordinates in a list of saved points (waypoints). And from there, you could interact with the GPS, click on the saved point, and decide to display a marker for that point on your map only, on everyones everyone's map, or send the coordinates to a bluefor tracker like cTab. I'm working on that more advanced GPS module now.

No, I intentionally designed it so that the mark would only show up on the user's map. That's to prevent everyone from grabbing the laser designators, marking targets, and spamming everyone's map with similar markers. So it currently puts a mark on your map only, and then if you want to share it with others, you can choose the appropriate level of sharing (command channel, side channel, etc.) and make another more detailed marker right on top of it. It only takes a few more seconds. Alternatively, if you just read the 4- or 5- digit easting and northing coordinates to your command element, they could use the GPS part of this mod to precisely locate the target on their own maps and mark it appropriately.

After reading the discussion in the dev branch about minimizing use of the HUD and recalling how Arma 2 ACE let you feel how heavy a magazine was, I asked myself the question: Why does ArmA 3 not have windowed magazines? These are nothing futuristic. They are simply magazines with a clear plastic window on the side that shows how many rounds are left in it. See here: PMAG® 30 AR/M4 GEN M2 MOE® Window, 5.56x45 Magazine. And I thought that hiddenselections[] combined with setObjectTexture would be a great way to script the magazine texture to change each time a round is fired to make it look like there are less rounds in the mag. But alas, I couldn't find any stock magazines with hiddenselections[] in their configs. So having windowed mags would mean creating a new mod. After working so much on my , Advanced Laser Designator/Rangefinder, and Advanced LRPS mod (coming soon), I have a pretty good handle on config files and scripting. But I have essentially no experience with modeling.Are there any others out there who would be interested in working with me to make windowed magazine models that could be automated to display accurate round counts?

Sorry I never replied back to this, but thanks for saving me some time in looking into it. I wondered why nobody else had done this yet.

I've done something very similar, i.e. randomly choosing between two options, like this: _num = floor (random 2); //yields either 0 or 1 _str = if (_num == 1) then {"init mov"} else {"init non"}; _p1 sidechat _str; EDIT: Spike beat me to it...

Great, thanks for the feedback! Yes, I hard-coded the up and down arrow keys to control some of the function of the laserdesignator and rangefinder. I thought my script should have only handled the keypresses if viewMode was GUNNER and ALT was pressed in addition to up or down arrow. In retrospect, however, hard-coding the key bindings was a mistake. In the next release, I'll use CBA to allow the user bind custom keys, and I think it'll resolve this issue.

Thanks for the feedback. I really like your own mods, btw. I think I'll pursue splitting this up into a single TRIGR LTLM and a separate GPS map utility. I have looked into the AN/PSN-13, and GIS Modding Studio has already made an excellent stand-alone GPS unit similar to the AN/PSN-13, the AN/PNC-212 SMGR. Unfortunately, their unit does not display when the map screen is displayed, and it has no interaction with the map mouse cursor. [table=width: 75%, align: left] [tr] [td=width: 50%]My take on GPS is inspired by the civilian unit I use all the time -- the Garmin GPSMap 60csx -- and the UTM system which is similar to the Military Grid Reference System. The GPSMap 60csx unit can be loaded with color topographic maps (much like the Arma 3 map) and has a cursor that can be moved around (also like the Arma 3 map). When you move it, it displays the coordinates of the cursor and other information about the terrain around the cursor: Since this kind of technology is already widely available in real-life in the civilian market, I wanted this kind of functionality in the Arma 3 map. And as yet, I haven't seen any mods that interact with the map cursor the way mine does, including the excellent cTab mod.[/td] [td][/td] [/tr] [/table] Your suggestion about the AN/PSN-13 does give me another idea though -- I originally modeled my GPS control to look something like the GPSMap 60csx's display, but I think I could pretty easily change that grey/black display to one that looks like the AN/PSN-13: [table=width: 75%, align: left] [tr] [td] Garmin GPSMap 60 csx [/td] [td] Advanced GPS Control [/td] [td] AN/PSN-13 [/td] [/tr] [tr] [td] [/td] [td] [/td] [td] [/td] [/tr] [/table] And your code inspired me further, specifically this part in your init.sqf: if (worldName in ["Chernarus", "Bootcamp_ACR", "Woodland_ACR", "utes"]) then {AB_Latitude = 50; AB_Altitude = 0;}; if (worldName in ["Altis", "Stratis"]) then {AB_Latitude = 40; AB_Altitude = 0;}; if (worldName in ["Takistan", "Zargabad", "Mountains_ACR"]) then {AB_Latitude = 35; AB_Altitude = 2000;}; if (worldName in ["Shapur_BAF", "ProvingGrounds_PMC"]) then {AB_Latitude = 35; AB_Altitude = 100;}; if (worldName == "fata") then {AB_Latitude = 30; AB_Altitude = 1000;}; I could use something like this to add the MGRS grid zone designation and 100km square identifiers to the mod. Altis would be 35S LE, and Stratis would be 35S LD...

I'm thinking of separating these out into two separate mods. The Advanced GPS would still function much like it does now. I think I'd replace the four laser designator/rangefinders with one more realistic TRIGR that was ordered by the US Army. Here are links to information about it: BAE Systems TRIGR (Target Reconnaissance Infrared Geolocating Range Finder) TRIGR Brochure Possible changes to the current mod: The TRIGR incorporates its own GPS unit, so linking it to a separate GPS unit would not be necessary. The TRIGR max zoom is 7x (as opposed to the current mod's max zoom of 60-75x). I haven't seen the reticle of the TRIGR, so I would keep the one designed by BIS and modified by me. I will try contacting BAE Systems, however, to see if I can get an image of the reticle. If I don't hear from BAE, I may add a "Quality" display to the reticle that appears similar to cell phone reception icons to denote the quality of the laser signal received back (helpful in inclement weather) I would change the widened binocular view to a more circular monocular view. I would remove the "Add Map Marker" function since it would no longer link to the Avanced GPS module. I may attempt to make a new tripod on which to mount it I would not change the errors that fog and rain cause in rangefinding. Or perhaps I'll keep this mod as-is and just make two additional but separate mods -- A GPS mod and TRIGR mod. Any thoughts?

Great addition. Thanks for your work! Noticed this while playing around with it: Error in expression < Str(round((Kestrel4500_TOTAL select 3) / (Kestrel4500_ENTRIES select 3) * 10) /> Error position: </ (Kestrel4500_ENTRIES select 3) * 10) /> Error Zero divisor

Apologies guys... still pretty new at all this. I tested earlier versions of in multiplayer and it had no problems. I haven't tested it on a dedicated server. @bamse, I appreciate you taking a look at it. @KeyCat, I hadn't even thought of versioning it. As it's still pretty new and I'm sure there are bugs to work out, I guess it'd be 0.1.

I'm working on a mod that will place a map marker on an observed position using a laser designator or rangefinder. When you're looking through either one of these optics, you can press a hot-key that will mark the map. It also provides precise (i.e. 5-digit) easting and northing coordinates of the observed position on the display of the optic so you can call in an artillery strike or air strike verbally without opening your map. Here's a sneak preview of the image.. The arrows up top are added in photoshop afterward... don't mind them. -Zehn

Since I'm also relatively new to the Arma scripting world, would you mind helping me with this? I have a Map/GPS addon that is 90% complete, and I have my own version of a functions library which essentially consists of all my functions as .sqf files in a folder called "functions" within the root of my add on folder: Zehn_Root\functions fn_GetAzimuth.sqf fn_Init.sqf fn_IntegerLength.sqf fn_KeyPressed.sqf fn_MouseDIK.sqf fn_MouseUp.sqf fn_PadZeros.sqf fn_RoundNumDigits.sqf fn_ScalarToString.sqf fn_ToggleUIVariable.sqf I have tried declaring them using the following class placed in my config.cpp: class CfgFunctions { class ZehnRoot { tag = "ZehnRoot"; class ZehnRoot { file = "\Zehn_root\functions"; class Init { postInit = 1; }; class GetAzimuth{}; class IntegerLength{}; class KeyPressed{}; class MouseDIK{}; class MouseUp{}; class PadZeros{}; class RoundNumDigits{}; class ScalarToString{}; class ToggleUIVariable{}; }; }; }; fn_Init.sqf always runs with no problem when the addon is loaded, but an time I try to reference one of the other functions by calling it like [] call ZehnRoot_fnc_GetAzimuth; it nothing happens (checked this by putting hints and diag_log lines in the called functions. So instead, in the fn_Init.sqf, I just use the preprocess compiler to assign them to variables and then later use the variables to call them: Zehn_fnc_GetAzimuth = compile preprocessFileLineNumbers "\Zehn_Root\functions\fn_GetAzimuth.sqf"; [] call Zehn_fnc_GetAzimuth; Any ideas on what I might be doing wrong with my functions library?

I had the same kind of challenge when I first started several months ago. Having some knowledge of other scripting languages and some C++ helped, but it was still confusing at first just figuring out what an SQF was and how it was called. I looked around on youtube a lot and played around with individual missions that I downloaded. I opened those up and learned from them. I found it easiest to start developing scripts with missions before even thinking of undertaking a mod. Other places that helped me were KillZoneKid's blog, the Scripting commands for Arma 3 BIS Wiki page, the more general Arma 3 Scripting Topics BIS Wiki page, and of course these forums. Without getting into too much detail, to make barrels appear at random times in random positions, I would: 1. Create a mission in the editor 2. Open the mission folder and create a myscript.sqf file (the place for the code of your script) that will generate a barrel 3. Create a trigger in the mission editor that executes your script (see for how to make radio triggers run code.)4. Run the mission and use the radio commands to execute the trigger I would put something like this in the "ON ACT." code box of the trigger: nul = [] execVM "myscript.sqf";

Has anyone else noticed that the rangefinders in the laser designator, range finder, and thermal scopes don't work well in VR? The first two examples are from using "TRY" button in the Virtual Arsenal. Note that the distance to the target's rifle (i.e. the nearest face of the object?) is 98m while the distance reported by VR in the TGT display in the right lower corner (maybe the distance to the center of the object?? though 2m is an awfully thick solidier). 98m using rangefinder 98m using nightstalker Are they using different algorithms to calculate the 98m and 100m ranges to target? The second example is from building a VR mission in the mission editor. The range to the ground is reported, but the range to a target is not always reported. This second issue is not as easily reproducible, but it seems to happen when targets are farther away. No range with cross-hair on target Range found with cross-hair immediately before target I found this using the stable 1.24.125979. I haven't found these issues reported elsewhere, and if nobody else has seen them reported, I'll add it to the feedback tracker.

Actually, thinking back to it, I found that the hardest part about putting the bearing in the scope was finding a way to be sure the RscText displayed every time your soldier was looking through the scope. Unfortunately, there is no event handler that fires when you look through the scope. You could attach an initialization event handler to the soldier/unit and have it check the cameraView every 0.5 seconds to see if it changed to Gunner, but I worried that would be really CPU intensive. Instead, I just developed a pretty comprehensive key press handler and attached it to the main display using the keydown event handler. This way, every time a key is pressed, it checks if the key is the optics key and if it is, it displays the RscText and starts a while loop that updates it. The while loop only runs while cameraView == "GUNNER" (since the camera view changes when you are not looking through the scope anymore) and after the while-loop exits, it hides the custom RscText again. Anyone have any input on these two methods or know of any better way to start a while-loop only when your solider is looking through the scope?

I did this to make a custom LRPS scope with the bearing/azimuth that the scope is pointing displayed in either degrees or milliradians. I will release this scope shortly. You can see a video of it at youtube video cDpMbSCfiGU. It's not hard to get the bearing of the weapon and display it with a custom RscText display that's updated every 0.3-0.5 seconds. But finding the range to the observed position is MUCH more difficult. I spent months trying to figure out this problem, and my own custom solutions were not nearly as good as the BIS solutions. The problem with my solutions is that they would almost always "see through" buildings and other objects. Even after I took that into account, the best I could do was estimate the distance to the center of a large object (like a hangar), not the face of the object nearest to me. Here's some of the code I used for finding the distance: fn_GetRange.sqf /* File: fn_GetRange.sqf Author: Michael Zehnpfennig, aka mjblay, aka Zehn Description: Find range from a player's eyePos to intersection of the camera direction vector (obtained by accessing the Z-axis in the array retured by positionCameraToWorld) with any object. If no such intersection exists within the player's viewDistance then return -1. Parameter(s): None Returns: SCALAR - range in meters */ private ["_detectorPos", "_endOfSightLine", "_sightLineObjects", "_range", "_detectorObjects", "_Ubound"]; // -------------------------------------------------------------------- // SIGHT-LINE OBJECTS METHOD // -------------------------------------------------------------------- // This method uses the lineIntersectsWith command to collect an array // of objects with which the line between the player's eye position and // a point (viewDistance + 1000m) away down the player's sight-line. // the objects in the array are ordered in from farthest to nearest, so // taking the last one and grabbing its position allows for calculation // of the distance between it and the player. This method has two flaws: // first, large objects like an airport hangar may intersect the // sight-line several meters away from their center, but getting their // position returns the center of the object. The second is that this will // detect objects along the sight-line on the other side of terrain and // return their distances. _rangeSLO = 0; // range from sight line objects _endOfSightLine = positionCameraToWorld [0, 0, viewDistance + 1000]; _sightLineObjects = lineIntersectsWith [eyePos player, _endOfSightLine, player, objNull, true]; if ((count _sightLineObjects) > 0) then { _Ubound = count _sightLineObjects; _rangeSLO = (eyePos player) distance (getPosATL (_sightLineObjects select (_Ubound - 1))); }; // -------------------------------------------------------------------- // SCREEN-TO-WORLD METHOD // -------------------------------------------------------------------- // This method seems less "authentic" but it may use less resources, // and I may substitute it with the for-loop near-objects method below // _range = (eyePos player) distance screenToWorld [0.5,0.5]; // if ((_range > viewDistance) || (_range > 4000)) exitWith {_range = -1;}; // -------------------------------------------------------------------- // NEAR-OBJECTS METHOD (inspired by ArmA 2 ACE) // -------------------------------------------------------------------- // This method takes the weapon direction vector and marches down that // vector starting 10 m from its origin at the player's weapon/binoc, // taking 1m steps. At each step, it assesses for objects (any kind of // object -- house, plant, unit, etc) within 1 meter and if an object is // found, it exits the loop and _rangeNeO is no longer increased. This // also happens if its height above terrain level reaches zero, // indicating a collision with land. Unfortunately, this method seems // particularly bad at detecting houses and buildings, so I had to add // the sight-line objects method above. If neither of the above happens, // the weapon vector is probably pointed toward the sky, so return -1. _rangeNeO = 0; // range from near objects _detectorPos = [0, 0, 0]; for [{_rangeNeO = 10}, {(_rangeNeO < (viewDistance + 1000))}, {_rangeNeO = _rangeNeO + 1}] do { _detectorPos = positionCameraToWorld [0, 0, _rangeNeO]; _detectorObjects = _detectorPos nearObjects 1; if (((_detectorPos select 2) < 0) || ((count _detectorObjects) > 0)) exitWith {}; if (_rangeNeO > viewDistance) exitWith { _rangeNeO = -1; }; }; // Unfortunately, it is necessary to calculate range using both the // sight-line objects method and the near-objects method. I tried // putting an if-then loop above to bypass the near-object's for loop // if objects were found using the sight-line objects method, but // occasionally when pointing at terrain only, an unexpectedly high // range would be displayed indicating that an object was in the line // of sight, but on the other side of a hill. A way to toss out that // result would be to use the terrainIntersects command to check if // terrain intersected the line between the closes object and the // player's eye position, but that command is reportedly very CPU // intensive so I avoided it. Instead, I get both ranges above and // use the logic below to choose the most appropriate range. if (((count _sightLineObjects) == 0) || (_rangeNeO == -1)) then { // either no sight-line objects were found or no near objects were found; // either way, return the result of the near objects method _range = _rangeNeO; } else { if ((_rangeNeO < _rangeSLO) && (_rangeNeO > 0)) then { // sight-line objects were found, but their range was greater // than that of the near-objects/terrain intersection found // using the near-objects method so return its range _range = _rangeNeO; } else { // sight-line objects were found, and their range was lesser // than that of the near-objects/terrain intersection found // using the near-objects method so return the sight-line // object's range _range = _rangeSLO; }; }; // return the appropriate range _range -Zehn ---------- Post added at 01:11 ---------- Previous post was at 01:06 ---------- Since it's my first post here, it wouldn't let me attach the video. Here it is: -Zehn