Decision Height gauge

[Guest dwilliams]

Hi,I'm new to this forum but I read it quite often. I really need help with a Decision Height gauge for 2 problems, Please.1. The DH gauge is supposed to start at 200 and increase/decrease with the knob by 1; but, it doesn't do anything - just stays at DH 200.2. I need the gauge to flash on (DH bitmap below) and off for 3 seconds then remain on afterwards once activated.Here is what I have so far.(please ignore the position places - they are correct on the panel)// ---- DH 200 string Display ----DH %((G:Var1) 200)%!3d!// ---- DH Bitmap ----(G:Var1) (A:Radio Height, feet) < ?// ---- DH Adjustment Knob ----(G:Var1) 1 - 0 max (>G:Var1)(G:Var1) 1 + 1000 min (>G:Var1)Thanks,Danny

[n4gix 4,947]

First of all, you haven't specified any "units" for your variable. Without any unit being cited, it simply cannot work...(G:Var1,number)Second, there's a perfectly good stock variable you can use, so why mess with a G:Var? Also, there are the corresponding key_events to set your DH.(A:Decision Height,feet)(>K:Decrease_Decision_Height)(>K:Increase_Decision_Height)If you are trying to work without at least referring to the SDK, you are going to have a very hard time... ;)

[Guest dwilliams]

Hi Bill,Thanks for the advice(SDK). I forgot to use the L var since these 2 parts are on different gauges forming the DH and the G var is for within the same gauge - not to mention the units at the end I forgot to specify.So I cleaned it up and tried the (A:Decision Height,feet) and ran into a problem with the increments of only 10. Unfortunately the(>K:Decrease_Decision_Height)(>K:Increase_Decision_Height)changed my gauge numbers by 10 instead of 1; So, I went with a L var. It now works with the adjustment knob increasing/decreasing by 1 like I needed it too.How do I get this to start with 200 ft? I've tried ((L:DH,number) 200)and it shows as DH 200, but nothing changes as far as the numbers.Here is what I have now that works:DH %((L:DH,number))%!3d!(L:DH,number) 1 - 0 max (>L:DH,number)(L:DH,number) 1 + 1000 min (>L:DH,number)Danny

[spokes2112 179]

I had some parts of this code laying around. Modified to work with G:Vars. Tested -- The Blinking code kinda sucks though, cannot make any faster, 3 blinks in 3 seconds. Use whatever you'd like.. Maybe lookit over to make your own based on it..Have fun.RomanGvar1 = DHGVar2 = Initialize gauge start and Initialize climb above DHGVar3 = Initialize gauge once above DH and Monitor above/below DHGVar4 = Timer valueGVar5 = Final Trigger based on GVar2 and GVar3(*** GAUGE LOAD, CLIMB, DESCEND, GO-AROUND, RESET ON LANDING INITIALIZATIONS AND LOGIC ***)(G:Var2) 0 == if{ 200 (>G:Var1) 1 (>G:Var2) } (G:Var2) 1 == (G:Var1) (A:Radio Height, feet) < & if{ 2 (>G:Var2) } (G:Var1) (A:Radio Height, feet) < (G:Var2) 2 == & if{ 2 (>G:Var3) } (G:Var2) 2 == (G:Var1) (A:Radio Height, feet) > & if{ 1 (>G:Var3) } (A:AIRSPEED INDICATED, knots) 40 < if{ 1 (>G:Var2) 0 (>G:Var3) }(*** TIMER SETUP/RESET ON TRIGGER ***)(G:Var2) 2 == (G:Var3) 1 == & if{ (G:Var5) 0 == if{ (P:ABSOLUTE TIME, seconds) 4 + (>G:Var4) 1 (>G:Var5) } } els{ 0 (>G:Var4) 0 (>G:Var5) }(*** DH DISPLAY ***)DH %((G:Var1))%!3d!(*** BLINK/NO BLINK ON TRIGGER ***) (G:Var5) 1 == if{ (P:ABSOLUTE TIME, seconds) (G:Var4) < if{ (P:Local Time, seconds) 1.5 % int 1 == } els{ 1 } } els{ 0 }(G:Var1) 1 - 200 max (>G:Var1)(G:Var1) 1 + 999 min(>G:Var1)

[spokes2112 179]

MY APOLOGIES - DISREGARD THE ABOVE POST !!!! I was burning the after-midnight oil, 3:35 AM. Well anyway there were some minor logic problems etc... Those are fixed. Also, if copied from the forum, the format was just all bad, spaces, no spaces, were they donot belong etc... Attached are 4 versions of the same basic gauge.. From basic to advanced coding techniques with alot of cool code snippets - L/R click, Blink Code, Timers, Macros etc...In text format. Use as you wish.Have fun!!! Romanhttp://forums.avsim.net/user_files/185857.txt

[Guest dwilliams]

Roman, WOW!!!!! I know how you feel. I stayed up until a little after 4:00AM trying to figure it out. It didn't work and I thought it was just me. Thanks for the Christmas present. Wow, what a great code. I am trying them all to see what works best. So far the last one with the Macro's works great.I like the right/left click thing for 1 or 10 ft increase - awesome. I think the blink for the DH is a little too slow - if I change something will it blink faster?Can you please explain to me the meaning of the the following Macro's for this gauge?(>L:DH, number)(L:INI, number)(>L:INI, number)(L:PRI_TRIG, number)(>L:PRI_TRIG, number)(L:TIMER, enum)(>L:TIMER, enum)(L:FIN_TRIG, number)(>L:FIN_TRIG, number)Also, I know it's a lot, but I'm really trying to learn - can you please explain the (*** GAUGE LOAD, CLIMB, DESCEND, GO-AROUND, RESET ON LANDING INITIALIZATIONS AND LOGIC ***) for the last set of code.Thank you for all that you have done,Danny

[spokes2112 179]

Dan. Here are some answers to your questions... BTW I provide code like this as an example. The way I learned myself way back. Just keep pluggin at it. The syntax is a little difficult but the logic is not,Can you please explain to me the meaning of the the following Macro's for this gauge?This is only an idea of how I see how it works. Have done quite alot of programming in VB, VB.net and just a little bit of C#. In reality I donot care how it does it, just that it works. Mileage may vary..............In the FS xml syntax a macro is just a central place for a variable or constant. A value can go to it or come from it. For instance when @TO_FIN_TRIG i will be sending a value to (>L:FIN_TRIG, number) or if it states @FIN_TRIG I will be reading from (L:FIN_TRIG, number)A macro is no more than a declaration saying "I am here" when it comes to memory. C, VB programmers 'must' do this just to make it work. For instance (L:INI, number) means (L:INI, number) 'as read by FS' is going to take up this much space in memory and INI is its address. So when you call "@" INI it will write/read to the address provided.. Here's the problem in XML for FS. (That I see) If a variable is readable/writeable why couldn't you just have (L:INI, number) and write to it with >@INI ??? It just doesn't work, at least on my side. Tested over & over. Hence the @INI (read) and @TO_INI (write) in the macro declarations. If one writes code without a macro, every time it reads/writes to a 'new' variable it must reallocate memory for the new variable upon gauge loading or under certain coding circumstances. User created variables only..(L:MYVAR, number), not GVars. GVars are allocated for each gauge, G:Var 0-9. Many would say that in a gauge like this, that this is overkill, but I find that almost any gauge that you create, if more than just a toggle switch, macros can be your friend. Especially if there is alot of logic involved. For instance.. when reading through alot of code it is easier to realize @TEMP than (A:GENERAL ENG EXHAUST GAS TEMPERATURE, kelvin).... Again, Mileage may vary, and it's up to the coder to decide how he/she wants to do it. And the above is only my ideas, speculations. With the code I provided, it was just easier to understand the logic coding using friendly variable calls. I.E. @TIMER###########################Also, I know it's a lot, but I'm really trying to learn - can you please explain the (*** GAUGE LOAD, CLIMB, DESCEND, GO-AROUND, RESET ON LANDING INITIALIZATIONS AND LOGIC ***) for the last set of code.Yeah, there is alot of logic involved in the first , but just imagine if I included the TIMER stuff with that. Possible, but it would make my head hurt!!!For the first I'll break it down to each individual logical sections.@INI 0 == if{ 200 @TO_DH 1 @TO_INI } @INI 1 == @DH @RH < & if{ 2 @TO_INI } @DH @RH < @INI 2 == & if{ 2 @TO_PRI_TRIG } @PRI_TRIG 2 == @DH @RH > & if{ 1 @TO_PRI_TRIG } @SPEED 40 < if{ 1 @TO_INI 0 @TO_PRI_TRIG }1. @INI 0 == if{ 200 @TO_DH 1 @TO_INI } /---When the gauge is first loaded @INI = 0 it will then throw 200 into the DH once and @INI goes to 1. INI will never return to zero again until the aircraft is reloaded. And the click spots will keep it from dropping below 200. Promise.2. @INI 1 == @DH @RH < & if{ 2 @TO_INI } /--- Once the aircraft has departed and the altitude is above the decision height the gauge arms for DH triggers. There is no need for a DH alarm if you never made it that far IE engine failure on TO ( good luck) INI=2 PRI_TRIG= 0 or 23. @DH @RH < @INI 2 == & if{ 2 @TO_PRI_TRIG } /--- Basically what happens here is the same as above but is necessary if the aircraft goes above the DH trigger once armed, even after going below DH (Timer code has some code for this too) . IE Go-Around. INI=2, PRI_TRIG=24. @PRI_TRIG 2 == @DH @RH > & if{ 1 @TO_PRI_TRIG } /-- This is the primary trigger for the timer setup. The DH is armed and the aircraft has dropped below the DH. INI=2, PRI_TRIG=15. @SPEED 40 < if{ 1 @TO_INI 0 @TO_PRI_TRIG } /--- You have landed or crashed ;-). No need to have the gauge telling you that you're below DH height anymore.. Resets,,, INI=1 PRI_TRIG=0########################### I think the blink for the DH is a little too slow - if I change something will it blink faster?That's the best one I've seen after many hours of testing for this in XML (courtesy Arne Bartels) BUT.... It could be something like this.. NOT TESTED.. BUT WILL.. I NEED IT TOO!!0 1 1 1 0 0 1 1 1 0 10 ( @TIME 100000 + 100 * d 1 % r flr 100 % d 10 / flr r 10 % 9 == if{ + } ) caseRoman

[taguilo 33]

Hi Roman,I do not intend to dissapoint you :-) but macros in XML gauges have a different meaning from what I see you understand so far. You might want to read this threads in where I give some explanation about macros:http://forums.avsim.net/dcboard.php?az=sho...ing_type=searchhttp://forums.avsim.net/dcboard.php?az=sho...ing_type=searchhttp://forums.avsim.net/dcboard.php?az=sho...ing_type=searchhttp://forums.avsim.net/dcboard.php?az=sho...ing_type=searchRegarding the blink stuff, it's very simple to control not only the lenght of the cycle but the frequency of the blink itself:Pseudocode: (P:Absolute time,seconds) "seed" % "blink lapse" > !"seed" is the total lenght of the blinking cycle. For example, if you want something to blink on every second, you use 1, if you want it blink every half a second, use 0.5 , every two seconds, 2 ,etc.For each seed, you can determine how long would be the duration of both the visible and invisible part.Then: (P:Absolute time,seconds) 1 % 0.5 > ! ---> this will make the visible and invisible parts of half a second both. (P:Absolute time,seconds) 1 % 0.7 > ! ---> this will make the visible part 70% of the cycle (0.7 secs) and invisible parts of 30 % (0.3 secs). (P:Absolute time,seconds) 0.5 % 0.25 > ! ---> this will make the visible and invisible parts of a quarter of second both.You can invert the cycle by removing the "!" char.Hope this makes sense.Tom

[spokes2112 179]

Tom,Thanks for the links & BLINKY code !!!! -- looked through references. Now I'm a little more confused,, maybe need more time for the coffee to kick in. I'm going to test this later today from what I read.. Seriously doubt it'll work though. I know there are other ways to do it ... But this way would be so much simpler for certain things.(L:XPos, number)(>L:Xpos, number)(L:YPos, number)(>L:YPos, number) *** Code from something to make X move *** @TO_XPos ** Repeat for Y **** ****Something to display here****Kinda getting back into this after a long hiatus.. Way behind the 8 ball especially in GPS style coding... Too many projects so little time..Thanks again -- all input is good input!! Roman

[taguilo 33]

>Tom,>>....I'm going to test this later>today from what I read.. Seriously doubt it'll work though. I>know there are other ways to do it ... But this way>would be so much simpler for certain things.>> (L:XPos, number)> (>L:Xpos, number)> (L:YPos, number)> (>L:YPos, number)>>>> *** Code from something to make X move *** @TO_XPos **>Repeat for Y **** >>>>>>****Something to display here****>>Do not bother to test that because it won't work, ever. support only literal values OR literal macros, but NEVER an expression.For example :4590 (L:MyVar) + 12 (L:MyVar) -8**** THIS WILL WORK****Something to display here******** AND THIS WON'T****Something to display here****Tom

[Guest richie1935]

Hi Danny,This is a comment about the colors used in your coding of the DH. Red in FAA terms is always used as warning and as such requires the immediate attention of the flight crew and DH is meant as an advisory to the flight crew when they have reached the setting. As such it is usually colored in amber or yellow be it text on an EADI or EHSI or as an annunciator indicator. Having been involved in certification in the past this is an area that certification officials look for proper usage.There are FAA documents available on their internet web site that explains the proper usage of color annunciations.This is not to be meant as derogatory but only advice. I hope nobody takes this to offense.The above has been my experience in the past.Regards,Richie1935

[Guest dwilliams]

Thanks Richie,I never looked at it that way. I will change it accordingly. I always try to simulate the real world stuff whenever I can - and this is one of those instances.Thanks again for the good advice. I'm still working through this code trying to get it to blink a little faster(now in a yellow color). Thanks,Danny

[Guest richie1935]

Hi Danny,Glad you agree with my comments. I was working on a change to the EFIS for the default CRJ700 PFD to add DH for my own personal use so as not to get MS ACES mad at me. It works perfectly but I need to add a blinking using the blink code. My feelings on the blinking as I recall seeing on other systems is the DH initially blinks on 1 second, off 1 second, three times and then remains steady. This is from memory so I could be wrong.What I would like to see is a gauge that will call out the altitudes on descent like in the previous versions. That sure helps on CAT II and CAT III approaches instead of monitoring the RA. Nobody seems to have made on to work in FSX.Regards,Richie1935

[spokes2112 179]

Ritchie, No offence here. But i've seen you've made 3 total posts since 2850 whatever zulu yesterday, EVER. And 2 have criticized a "minimal" at the very least, problem with the code... Red, Green, Yellow, Chartruese, Who cares? The code was put there as an example. More of a contributor --> student. Where the student perse does the his/hers final mods to make the code, final result, the way he/she wants it. If it is incorrect per AEA,FAA or any-other TLA,FLA it should be corrected once released. Most gauge programmers have the order, laws, colors, operation etc.., of the gauge they are making before even starting to code. Otherwise it's all moot.Remember what the original post was here for...How to make something work..Colors, location, "blinky" timing are all irrelevant. That stuff is all gravy on top of the meat. And yes, I posted a set of code. It works. If the colors, timing are wrong, learn how to change it. That's what William is trying to do, and more. So do I. As each contributor can make more contributors and feed off others experimentation, tests, results... Do your own experimentation, tests, results, then contribute again. RomanProud "TEAM AVSIM" RTW race member.XP Pro, FS9, FR Locked @ 23, AMD 1800+ OCd to 1900+, APIC MProc Mod (24 IRQs), Latency Mods, ECS K7S5a V1.1, 7 fans, 1 gig, 100 & 60 Gig 7200rpm HD, ASUS/NVidia GeForce 64mb AGP on 21", NVidia FX5500 vivo 256mb (CRAP) on 18", Nvidia 93.71s ( The highest can go for the GeForce3 & 5500 combined ), Savage4 32mb on 15", BV services mods.

[spokes2112 179]

Dan, If your using the final coding example from the text attachement then in this element:@FIN_TRIG 1 == if{ @TIME @TIMER < if{ @TIME 1.5 % int 1 == } els{ 1 } } els{ 0 }%DH% The section that has exactly this: " @TIME 1.5 % int 1 == " is the blinky code, the rest are arguments why/why-not --> what something should happen. You could, as Tom ("taquilo") provided in an above reply, replace it with " (P:Absolute time,seconds) 0.5 % 0.25 > ! " But.... Since we used macros (P:Absolute time,seconds) has now being referenced by @TIME so the final replacement should be : " @TIME 0.5 % 0.25 > ! " just to keep the coding format similar. Although, his original will work just as good as a replacement. It "BLINKYS" pretty darn quick then.. Almost too quick, my old system might miss 1 or 2 blinks every once in a while. Just see his post to modify to taste... RomanProud "TEAM AVSIM" RTW race member.XP Pro, FS9, FR Locked @ 23, AMD 1800+ OCd to 1900+, APIC MProc Mod (24 IRQs), Latency Mods, ECS K7S5a V1.1, 7 fans, 1 gig, 100 & 60 Gig 7200rpm HD, ASUS/NVidia GeForce 64mb AGP on 21", NVidia FX5500 vivo 256mb (CRAP) on 18", Nvidia 93.71s ( The highest can go for the GeForce3 & 5500 combined ), Savage4 32mb on 15", BV services mods.