Jump to content
Sign in to follow this  
n4gix

Beware; using the FS DecisionHeight variable (in XML)

Recommended Posts

After a discussion with a few users of my GPWS gauge about perceived wrong Callouts of "Minimums", I noticed some very peculiar implementation of the DH variable and events in FS.So I just post it here FYI.FS has a variable A:Decision height , and two events that changes it: (>K:INCREASE_DECISION_HEIGHT) and (>K:DECREASE_DECISION_HEIGHT).Now, some for some misterious reason, the internally used value of DH in FS is in METERS, not in FEET.As shown by:(A:Decision height,number) = 100(A:Decision height,meter) = 100(A:Decision height,feet) = 328.And to make it even more confusing:(>K:INCREASE_DECISION_HEIGHT): increments DH by 10and"x" (>K:INCREASE_DECISION_HEIGHT) increases DH with "x" meters.("x" is an integer number)so:15 (>K:INCREASE_DECISION_HEIGHT) increases DH with 15 meters.15.6 (>K:INCREASE_DECISION_HEIGHT) also increases DH with 15 metersNow, since DH is not used by any of the default gauges or other aircraft parameters, this has probably been unnoticed (Arne ???)And the addon gauges that DO use DH, usually use there own implementation of DH (with their own variable), because it's not possible to set e.g a DH of 100 feet with usual increments of 10 or 50 feet. Now of course you can interprete the value of (A:Decision height,number) as DH-in-feet, but this would conflict with normal rules of FS unit conversions where you can rely on the fact that you can read the value of a variable in the units you specify.Like in (A:Decision height,meter) or (A:Decision height,feet). Because then we would loose compatibility between addon gauges that use standard FS variables.Cheers, Rob

Share this post


Link to post
Share on other sites

I believe Steve Hanley (skymed) found this error back in FS2002. The easy fix was to use a "user" variable to dial in the DH and compare it to (A:RADIO HEIGHT, ) feet or meters depending on international settings (P:UNITS OF MEASURE, ) that way no coversions are needed nor required. The problem is of course to implement this into a "one size fits all" addon gauge as you would need to know the variable name of the users DH gauge. Not sure if the DECISION HEIGHT variable works correctly in C and/or if any one even uses it. Regards,Roman(KGRB)


20AUG21_Avsim_Sig.png?dl=1  FS RTWR   SHRS F-111   JoinFS   Little Navmap 
 

 

Share this post


Link to post
Share on other sites

Hi Roman,Yes, the solution with the "local" variable is simple and does work fine.The only problem with this is, that we lack a proper mechanism to "register" these kind of "addon" definitions for FS2004, so that any addon designer can reuse this info (so we get compatibility between addons) and does not have to re-invent the wheel everytime :-)Best regards, Rob

Share this post


Link to post
Share on other sites

The following applies to C gauge programming, apparently XML is the same... :(The TokenVars document states that DECISION_HEIGHT is in meters. Well, unless I no longer know how to convert meters to feet... they're wrong. It's in feet. When FS starts up, it defaults to a value of 100, which if you attempt to convert (because they're telling you it's meters) becomes 328ft... because you multiplied it by 3.2808399. Look at the two numbers... 3.28... 328... yep, it defaults to 100. To add insult to injury, when you use the DH key event to increment or decrement the DH, you get weird and wild incremental values. Now, try this: Stop converting DH to feet... it is feet. Suddenly, everything works as expected. ;)


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556


     Avsim Board of Directors | Avsim Forums Moderator

Share this post


Link to post
Share on other sites

Rob,Had problems too as you know.I took out your DH and replaced it with mine, where DH is compared with RA and the height of the plane on ground, in my case 9 feet.(all units in feet)Works ok.Jan"Beatus Ille Procul Negotiis"

Share this post


Link to post
Share on other sites

Ok Ok .... I'll join the club :-)And just interprete the internal "number" as Feet.After all, if we all do this, there's no problem ..Unless MS decides to make a gauge in FS10 that actually uses DH :-)cheers, Rob

Share this post


Link to post
Share on other sites

>Ok Ok .... I'll join the club :-)>And just interprete the internal "number" as Feet.>>After all, if we all do this, there's no problem ..>Unless MS decides to make a gauge in FS10 that actually uses>DH :-)It should work as expected, Rob! If you compare the set DH against your AGL, it is spot on... ;)IOW, if DH is set to 300', then when the a/c is slewed up to 300' AGL as reported by a Radar Altimeter, the DH "light" will come on at precisely that altitude...


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556


     Avsim Board of Directors | Avsim Forums Moderator

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...