• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

FLR in XML doesn't work like floor() in C++

A

Anthony31

Messages
1,129
Country
australia
It's amazing the things one can learn.

So yesterday I finally figured out the FLR in XML does not work exactly like floor() does in C++ and that is why one of my radio gauges was doing stupid things.

FLR is defined in the SDK as "Calculates nearest integer number which is less than the source number"

while floor(x) is defined as largest integer <= x

The tricky difference is the "less than" versus the "<=".

So in FSX XML "45.56 flr" returns 45 and "45.00 flr" returns 44 (technically 44 is the nearest integer less than 45)

While in C++ floor(45.56) returns 45 and floor (45.00) returns 45 (less than or equal to makes all the difference).

floor is great because it just gives you the integer part of the number you are checking.

flr is not so great because it gives you 1 less than you expected if the number has no decimal places.

The trick when using FSX XML flr is to add a small fraction (eg 0.0000001) to the number before you use flr.

I think it is about time that I stopped using XML gauges and went fully C++ :)
 
Actually XML flr is like C++ floor(). But the way the value is displayed will depend on whether it comes from a user's direct input or is the result of a floating point calculation. For example, if it is 44.9999872 and you display it in a string using !3.2f!, you'll get 45.00. Now if you display (the same value) flr !3.2f! you'll get 44.00.

Tom
 
You may be right. Just did a little simple testing on flr and it was working as floor().

Problem is, in the gauge environment (where I was taking a radio Mhz freq and converting it to a BCD frequency so I could write it to (&gt;K:COM_RADIO_SET) ) it wasn't working well.

I wonder if it was possibly a floating point problem with the stack calculation. This is the code I was using to extract the second decimal place from A28_Commwork. If A28_Commwork was 19.325 then it should return 2 but under some conditions it was returning a different number. The bizarre thing is that sometimes the same value would work and sometimes it wouldn't.

(L:A28_CommWork,number) 100 * flr 10 % (&gt;L:A28_FR_COMBCD,number)
 
I simply added a tiny fraction to eliminate the weird rounding of numbers...
Code: 
(A:COM STANDBY FREQUENCY:1,Mhz) 100 * 0.1 + 10 % flr (>L:B737_Com1Stby_100ths_TUNE,enum)
 
Good point Tom

I too found that adding a small fraction got things working again. In my case 0.001 worked fine. I wish it hadn't taken me 2 hours to figure it out :) .
 
You must log in or register to reply here.
Back
Top