Here is my Dilemma
My past experience with ZenDesk has been less than impressive.
I sent in a CTD Bug, with MiniDump analysis, and all I got was some irrelevant canned response about how to setup the profile for a Joystick !!
So here it is - Not a Complicated CTD, but an exposed, visible, bad Java coding error that is causing a significant issue with LOC/DME approaches.
Any Plane using the GN530 (ie C172 Classic) uses the ASOBO AS530
The 530 is correctly displaying bearing as a rounded Integer . ie 240
The 530 should display DME (in NM) as a rounded float to 1 DP. ie 12.5
It is really obvious that whoever coded this, just copied the Bearing code and edited it incorrectly for the DME code.
Yes, they made it display fixed(1) ie to 1 DP, but they still Rounded the Distance to an Integer, so it will always display with a ZERO after the DP.
This makes it virtually useless when trying to use the DME for any Instrument procedure, and is very obvious if you try.
The FIX, is to correct the DME code.
ie (Round( DME * 10))/10 display Fixed(1)
instead of Round(DME) display Fixed(1)
Simple. Obvious error in code, takes all of 30 seconds to edit and fix.
But hours of “SCRUM” & then /Days/Weeks/Months before that can actually happen
The Dilemma is, I can fix it in a 30 sec edit on my PC, and then 30 seconds to check if it has been overwritten twice a month when there are updates
Spend the considerable time & effort to submit a ZenDesk report, assuming it ever gets to ASOBO, or is just not on Backlog (for ever)
Yes, The RIGHT and COMMUNITY GOOD thing to do is to try to submit the Zendesk report, but the likely hood of it getting fixed, is almost as slim as getting into the cockpit on a Trans Atlantic flight after 9/11.
This is just one example of something that should be so easy to fix because the fix is so obvious and clear, but unless a large number of MSFS users report it and “Kick up a fuss”, the chances of it getting any attention are almost zero.
So, what I have decided to do is post the BUG information that I would send to ZenDesk, and see how many of you, consider it important enough to submit to ZenDesk yourself.
This is what you might consider submitting:
BUG: in AS530.js (as of patch release #4)
DME is being displayed as a “Rounded” INTEGER, with a trailing zero after the DP.
The 530 is meant to display DME to one Decimal Point ie 12.3, not with the training digit after the DP always forced to zero.
Line : 57
? Math.round(SimVar.getSimVarValue(“Nav DME:1”, “Nauticle Miles”)).toFixed(1) : “–.-”));
? (Math.round((SimVar.GetSimVarValue(“NAV DME:1”, “Nautical Miles”)*10))/10) .toFixed(1) : “__._”));
Fixing this Bug will allow pilots flying planes using the AS530, to be able to carry out VOR/DME and and other DME based procedure, with the required precision, that the 530 should be displaying.
(above mod- Tested and 100% operational 10/17/2020 13:59 EDT @N6722C)
Note: If you want to temporarily FIX this yourself, a closely accurate fix, without altering the file size, which is to be avoided, is to just replace the Math.round with 10 spaces (using a simple text Editor like Notepad . DO NOT use a Word processor !!)
File size should then not change.
EDIT MSFS file at your own risk !!
This may not be a “BIG DEAL” for VFR Gamers, but for Simmers flying affected GA planes, it is a “PROBLEM”