Recommended Posts

Hi all,I'm working on my first panel for FSX and have run into some quirky behaviour with a radio stack gauge I'm making which I'd really appreciate some help with. I'm using the following gauge string:%( (A:COM STANDBY FREQUENCY:1, MHz) 100 * 1 div 100 /)%!3.2f!...which works fine except when the frequency on the default radio stack reads XXX.20 mine reads XXX.19. Similarly for these values:Default MineXXX.45 XXX.44XXX.70 XXX.69XXX.95 XXX.94For all other values my readout is correct. Can anyone tell me what I'm doing wrong?Many thanks,DD

Share on other sites

On closer inspection, the 3 digits to the left of the decimal point always display correctly, but the 2 to the right are sometimes off by 0.01. The weird thing is that the digits on the right which don't work vary depending on the value of the digits on the left. For example, "127.67" works fine, but "128.67" displays as "128.68". I'm even more baffled than I was before :/.DD

Share on other sites

Hi DD I use ((A:COM1 STANDBY FREQUENCY, MHz))%!6.2f! for all simple frequency number displays.

Share on other sites

Hi, here is an example that explains the oddity:-Default freq = 118.67894 - the value is rounded to 2 decimals so it shows 118.68-Using your formula :118.67894 100 * = 11867.894 1 div = 11867100 / = 118.67 Solution = use Paul's approach or (A:COM STANDBY FREQUENCY:1, MHz) 100 * near 100 /Tom

Share on other sites

Thanks very much for the help guys - I'm away for the weekend, but will give your suggestions a go as soon as I get back.Cheers,DDP.S. A bit of a daft question, but is it "reverse Polish notation" (as in 303 squadron) or "reverse polish notation" (as in "wax on, wax off")? I've seen it written both ways in the docs and was just wondering which is correct.

Share on other sites

Polish, pronounced as pO-lish...not as pAH-lish... ;)

Share on other sites

Hi BillDon't you mean Polish as in Poland and not Polish as in Kiwi? :)(I'm really sorry - that was an awful joke and I'm not sure it travelled outside the UK. Kiwi is a brand of shoe cleaner, as well as a native of New Zealand).-Dai

Share on other sites

>Hi Bill>>Don't you mean Polish as in Poland and not Polish as in Kiwi?>:)>>(I'm really sorry - that was an awful joke and I'm not sure it>travelled outside the UK. Kiwi is a brand of shoe cleaner, as>well as a native of New Zealand).I polish my Polish shoes with Kiwi, before chasing kiwi's in the outback... :)

Share on other sites

I thought I understood what was going on after reading Tom's explanation, but when I had the sim display the frequency to several decimal places, I found that the variable only contains values up to the third digit after the decimal so presumably the zeroes beyond that can't be having any effect.I've tried both Paul and Tom's suggestions, but neither seems to exactly replicate the behaviour of the default radio stack (which ignores the third number after the decimal point so that XXX.625 is displayed as XXX.62 and not as XXX.63). I then tried breaking my original formula down into its components and found the following (with a frequency of 127.700 as displayed by the tooltip):((A:COM1 STANDBY FREQUENCY, MHz) 100 *) gives 12770.00((A:COM1 STANDBY FREQUENCY, MHz) 100 * 1 div) gives 12769.00 (!)((A:COM1 STANDBY FREQUENCY, MHz) 100 * 1 div 100 /) gives 127.69...so it would seem to be the DIV operation which is calculated incorrectly thereby throwing off the final result. In the end I got tired of banging my head against the monitor and just drew the frequencies to 3 decimal places and used a mask image to hide the final digit, which has done the trick but I'd still love to know why the DIV didn't work.Onto another couple of questions: 1. I'm using (A:COM STATUS:X,enum) to control the visibility of the comm radio digits, so they don't display if they have no electricity or have failed, but I couldn't find equivalent variables for the other radios (specifically ones which are also triggered by a failure). I'm assuming there must be some -what do you guys use?2. When you press C or T, for example, part of the comm or transponder frequency changes colour and can be adjusted with the + and - keys. Is there a variable somewhere which stores the identity of the variable which is currently controllable with these keys?Cheers,DD

Share on other sites

I'm wondering why you're doing all that math to begin with.(A:COM1 STANDBY FREQUENCY, MHz) returns the value as 127.700 and thus should be at the actual value you seek to begin with. I believe if you want the value as 127700 you should be asking for (A:COM1 STANDBY FREQUENCY, KHz).

Share on other sites

Hi Ed,The reason I was using the formula is because (A:COM1 STANDBY FREQUENCY, MHz) doesn't produce the same results as the default radio stack.For example, when the frequency is 128.525 (as displayed by the tooltip), the default radio stack will display 128.52 but (A:COM1 STANDBY FREQUENCY, MHz) displayed in "3.2f" format will give you 128.53.The weird thing is, it's not consistent - if you decrement the whole part of the frequency to 127 so the tooltip now reads 127.525, the default stack will display 127.52 and this time so will (A:COM1 STANDBY FREQUENCY, MHz) displayed in "3.2f" format.It's this effect of a change in the whole part of the frequency causing a change in the displayed fractional part which I'm trying to avoid. The formula was intended to multiply the frequency by 100 (12852.5), truncate that using DIV 1 (12852), then divide by 100 to give the same result as the default radio stack (128.52).Cheers,DD

Share on other sites

>Hi Ed,>The reason I was using the formula is because (A:COM1 STANDBY>FREQUENCY, MHz) doesn't produce the same results as the>default radio stack.>>For example, when the frequency is 128.525 (as displayed by>the tooltip), the default radio stack will display 128.52 but>(A:COM1 STANDBY FREQUENCY, MHz) displayed in "3.2f" format>will give you 128.53.>The default radio stack is a C++ gauge, thus uses different code to produce it's results.>The weird thing is, it's not consistent - if you decrement the>whole part of the frequency to 127 so the tooltip now reads>127.525, the default stack will display 127.52 and this time>so will (A:COM1 STANDBY FREQUENCY, MHz) displayed in "3.2f">format.>It's the DIV function in the XML that's causing part of the problem. The other culprit is the format command. The "best" method for this is to extract the remainder from the 12.5xx value so that you have it separate... then based on that value add either .02/.05/.07 or nothing. While I know diddly squat about XML... if it has a mod function, that's what you need.>It's this effect of a change in the whole part of the>frequency causing a change in the displayed fractional part>which I'm trying to avoid. The formula was intended to>multiply the frequency by 100 (12852.5), truncate that using>DIV 1 (12852), then divide by 100 to give the same result as>the default radio stack (128.52).>Cheers,>DDYep... you can't truncate with a division or the format command.

Share on other sites

>Yep... you can't truncate with a division or the format>command.My understanding of the DIV command (as opposed to division) was that "A B DIV" (in reverse Polish) meant "the number of times B can be divided completely into A" so "12852.5 1 DIV" should truncate it to "12852". Have I misunderstood the function, or are you just saying that that operator is unreliable in FSX?The list of operators in the docs gives % as the symbol for taking the modulo, but I've tried both that and "mod" with no success. I did wonder if maybe a different symbol has to be used in the xml (in the same way that "<" is replaced by "<". I couldn't find any mention of this in the docs, though.Cheers,DD

Share on other sites

No... if you're taking 12852.5 and wanting to eliminate the fractional part... it will, by default, round up if the fractional part is 0.5 or higher.As for the modulo operator... as I've stated, I don't do anything XML so am very little help there. Sorry. :(

Share on other sites

Hi, formatting uses C# formatting styles for floating point numbers (and int/string as well) , so:!nnnn.2f! will round a number to the nearest centesimal fraction.In your example 127.6999999 shows 127.70127.6999999 100 * gives 12769.99999 !5.2f! then shows 12770.00Now, 'div' operator doesn't care about formatting, therefore it just removes the decimals making an integer: 12769 ; !nn.2f! then adds the decimal places in 0, because it is an integer - shows 12769.00Rest of the operations apply to an integer number, so if you divide by 100 127.69 is obtained, AND if you 'div' this value the result is 127 !nn.2f! = 127.00Hope this clarifies the whole thing. And regarding the default radio stack, it is a C gauge as Ed stated, and is probably using a truncation to two decimals:127.6999999 100 * = 12769.99999 near = 12770.00 100 / = 127.70 You might try this last approach and see what happens :-)Tom

Share on other sites

Just go with "PVE's" response ( # 3 in this thread ) the "f" print format has been the same since I wasn't even a glint in my Pollack dads eyes. ( HINT.. The MS C version is the same, IBM 700, FORTRAN etc..... ) "f" print = "total digits" . "dot" "number of digits following, rounded appropriately"So go with the above ( PVE ) ,,,, no math,,,, just %!6.2f!% Regards from a Pollack,Roman

Share on other sites

Thanks for your continued patience in trying to explain the behaviour to me guys, but I still don't quite understand what's happening:Tom, I tried your formula i.e. (A:COM STANDBY FREQUENCY:1, MHz) 100 * near 100 / ...but I still get anomalous behaviour. For example when the frequency is 127.675 that formula gives 127.68, but when the frequency is 128.675, it displays 128.67. I understand your point about how extra digits to the right of the cut-off point could cause rounding errors, but the thing is there are no other digits - the value of the variable is always a multiple of 0.02500 (when drawn to 5 decimal places) i.e.xxx.00000, xxx.02500, xxx.05000, xxx.07500 ........etc to xxx.97500I don't understand how xxx.67500 can be rounded to xxx.68 for one value of xxx, but to xxx.67 for a different value of xxx. It's no big deal, as I've worked around the problem by just drawing the variable to 3 decimal places and masking the last digit, but it is a bit perplexing.More importantly, though, does anyone have any suggestions about the variables I'm trying to track down i.e. those which indicate nav1 failure, nav2 failure, adf failure, transponder failure, and which variable is currently adjustable with the + and - keys?Cheers,DDEdit: Sorry I missed your post, Roman. PVE's method also produces different results from the default stack e.g. it rounds xxx.025 down to xxx.02, but it rounds xxx.125 up to xxx.13. (In both cases, the default radio stack rounds down so it displays xxx.02 and xxx.12, respectively).

Share on other sites

I see you still don't get it. Let's try again :)"but the thing is there are no other digits - the value of the variable is always a multiple of 0.02500 (when drawn to 5 decimal places) i.e.xxx.00000, xxx.02500, xxx.05000, xxx.07500 ........etc to xxx.97500"Yes there are other digits, *masked* byt the !n.5f! function.123.0249999999998987957432 -> !3.5f! -> 123.02500 That's the reason you see 127.675 as 127.68 and 128.675 as 128.67. Instead of 'near' try using 'flr' which rounds to the lowest integer.But if I were you, I'll follow Paul (pve) and Roman (spokes112) advises and use !n.2f! or !n.3f! instead of all these maths...Tom

Share on other sites

Played with this a bit and I see what you mean DD. I came up with this one which seems to work:((A:COM1 STANDBY FREQUENCY, KHz) 10 / flr 100 /)Why that would be any different than:((A:COM1 STANDBY FREQUENCY, MHz) 100 * flr 100 /)is beyond me, but MHz exibits the same rounding oddness.Jim

Share on other sites

>Yes there are other digits, *masked* by the !n.5f! function.>123.0249999999998987957432 -> !3.5f! -> 123.02500 Ah I finally see exactly what you mean - thanks for persevering m8 :). I'm still a bit baffled as to why the var would store a number such as the one in your example rather than just 123.025 exactly, but I can live with that degree of bafflement :).>But if I were you, I'll follow Paul (pve) and Roman> (spokes112) advises and use !n.2f! or !n.3f! instead of all>these maths...That's basically exactly what I did -I'm using just the frequency variable (formatted !n.3f!), with a mask image to eliminate the third digit after the decimal.Cheers,DDEDIT: Thanks for the tip with your KHz formula, Jim - I'll try that too.

Share on other sites

DD & Others Plz show the whole string code.. blah blah Your "f" print probably is the source of multiple roundings, there should be no math involved.%!3.2f!% will not cut the mustard. go with %!6.2f!% Regards,Roman

Share on other sites

Caught you on the last post..... NO MATH NECESSARY (stop) NO MASKING OF DIGITS NECESSARY (stop)It's the print format within the string that is causing the FUBAR. The print format can have alot of power ( rounding, pre, - post, zeros etc...) get the print format right and it's all good. Regards,Roman

Share on other sites

Print format was %!6.2f!% . I forgot to mention in my last post that I'm using FS9, but the bottom line is ((A:COM1 STANDBY FREQUENCY, MHz))%!6.2f! doesn't give the expected result. Try it, tune to 123.12 and you'll see that it returns 123.13, for example, at least it does for me.Also, if you try something like (A:COM1 STANDBY FREQUENCY, number), you'll see that there's no such thing as a number like 123.0249999999998987957432 for radio frequencies. You'll get values like 123025000, 123050000, 123075000, etc.Incidentally:((A:COM1 STANDBY FREQUENCY, number) 10000 / flr 100 /)%!6.2f!also seems to work.Jim

Share on other sites

Just tried Jim's KHz formula i.e. %((A:COM1 STANDBY FREQUENCY, KHz) 10 / flr 100 /)%!6.2f!...and it worked perfectly without the need for using ".3f" and a mask, which simplifies things so I'm a happy camper :). I don't know why almost the exact same formula but in MHz:%((A:COM1 STANDBY FREQUENCY, MHz) 100 * flr 100 /)%!6.2f!...produces different results but it certainly does, presumably FSX must be doing some kind of rounding when it converts from MHz to KHz.>Also, if you try something like (A:COM1 STANDBY FREQUENCY,>number), you'll see that there's no such thing as a number>like 123.0249999999998987957432 for radio frequencies. You'll>get values like 123025000, 123050000, 123075000, etc.It took me a while to get my head round this too, but I think that Tom must be right that the MHz values of the variable really do contain weird values like that -there's no other explanation for the variations in rounding.The thing to remember is that you're never seeing the full unrounded value. Even if you ask for the value to be displayed to 10 decimal places, you'll see 123.5000000000 but the real value might be 123.49999999999999999999999. It's a bit like Shrodinger's cat: by looking in the box, the waveform is collapsed so you never get to see the cat alive and dead at the same time. Hmmm perhaps a better description would have been "It's not much like Shrodinger's cat" :).When you ask for the variable in KHz FSX must do some kind of internal rounding on the weird MHz value as well as just multiplying by 1000 which is why the anomalies don't occur with the KHz version of your formula. I guess something similar must be happening when you're asking for it as a "number" too i.e. (A:COM1 STANDBY FREQUENCY, number).Cheers,DD

Share on other sites

>The thing to remember is that you're never seeing the full>unrounded value. Even if you ask for the value to be displayed>to 10 decimal places, you'll see 123.5000000000 but the real>value might be 123.49999999999999999999999.Well, my understanding is that "number" returns the raw variable before any calculations or rounding take place. In this case it's a 9-digit whole number, simply "Hz".>When you ask for the variable in KHz FSX must do some kind of>internal rounding on the weird MHz value as well as just>multiplying by 1000 which is why the anomalies don't occur>with the KHz version of your formulaKHz isn't arrived at by multiplying MHz by 1000, it's arrived at by dividing Hz (or "number") by 1000. Likewise, MHz is arrived at by dividing Hz by 1 million. There's something screwy with the hard wired formula that converts Hz to MHz is what I think. Doesn't seem like there could be much go wrong with dividing it by 1000000 but computers don't think in "tens" so maybe in machine language it's actually 999999.999999999999999999999999 or something, who knows. KHz would halve that error, so maybe that's why we get away with using KHz but not MHz. Purely speculation of course.Glad you finally found a formula you like, I was really hating the mask :) .Jim

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×

• Tom Allensworth,
Founder of AVSIM Online

• Hot Spots

• 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!