Altitude Preselector Display Bug

intjmastermind

When adjusting the preselected altitude, as you pass each 1000 ft going up, the hundreds value goes from "900" to "1000" but the thousands value doesn't increase.

i.e. 37,900 -> 37,1000 -> 38,100

Going down...

38,100 -> 37,1000 -> 37,900

Black Square

Wow. That's a wild one. I can't reproduce that over here. What does that even look like? They are completely different text elements. You're saying the "1000" in the hundreds place now overlaps the "37" in the thousands place? Can you share a screenshot?

These are the things that really baffle me about software sometimes. Looking at the code, there would almost have to be a difference in how the modulo operator is implemented between your computer and mine for this to happen.

intjmastermind

It says I don't have enough privileges to add a picture, but yes the "1" overlaps the last digit of the thousands.

intjmastermind

Imgur link: https://imgur.com/a/Wm91zex

Black Square

That's unbelievable. I'm at a loss for words. Before I start ranting about how math appears to be broken on your computer (it wouldn't be the first time in MSFS 2024, at least), can you do one test for me?

When the incorrect number is displaying, could you try adjusting the barometer setting to see if the instrument is generally working and reacting to your inputs?

intjmastermind

Yeah everything otherwise works fine with the altimeter and the autopilot is able to capture an altitude written as “15,1000” correctly at 16,000.

I’m running Intel 14900K, Win 11 24H2, FS2024 SU3 (latest beta update), English USA localization.

Black Square

Thanks for checking. In case I sound too astonished, let me be clear, the implication is that your computer thinks...

38,000 / 1,000 = 37
1,000 / 1,000 = 1,000

I know that might sound impossible, but I've already seen it with the same mathematical operator in MSFS 2024 when it was released.

In theory, I could add some special code to watch for this situation, but that seems a little silly doesn't it? To look for when mathematics is no longer working as it has for the last 200 years? (Surprisingly, the modulo operator was only conceived in 1801.)

Sorry I'm being a little more animated than I usually am here. Some days, you just think you've seen it all...

Since I always do my best to offer support to users having any problems, I can walk you through investigating this with me, if you would like. It would take a little work, but I would be very thankful. You can't be the only person on earth for whom this will present itself.

intjmastermind

Sure, happy to help!

Black Square

Thanks! Well, seeing as I am quite baffled by this one, let's start by loading the debugger and looking for errors.

I've never tried this, but I believe you might be able to view the debugger without installing anything by going to http://127.0.0.1:19999/ in your web browser while the simulator is running. If not then you might have to install the SDK from the developer menu. I can walk you through this too, if you're not feeling confident.

Once you have the debugger open, look for the blue link with "ALT" in the name. Once you've clicked it, click the tab for "Console" at the top of the window. There will be some red errors from when the system was powered up at the top. Try rolling the knob through the suspicious altitudes, and see if this generates any new errors.

I'm also going to try this on two more computers later myself, and I will keep an eye out for it.

intjmastermind

Ok so I figured it out!

If I only use the in-cockpit altitude select knob, or its associated H-events, then the altimeter behaves normally and displays the preselected altitude correctly.

Last night, I was modifying the LVAR bksq_AltitudePreselect_1 by incrementing or decrementing it by 30.48 to create a 100 ft change in preselected altitude. That seemed to be the problem. After adjusting the LVAR, the “1000” bug appears, and persists, even if I subsequently use the knob for further changes.

Interestingly, after the bug appears, if I then return the pre-selected altitude to 0000, and then only use the knob, the “1000” does not appear again.

This leads me to believe there is a floating point precision bug because it only occurs when I’m incrementing or decrementing the LVAR by 30.48.

The solution is simply to use the provided H-events and not mess with the LVAR!

Black Square

@intjmastermind said in Altitude Preselector Display Bug:

This leads me to believe there is a floating point precision bug

This was the conclusion I arrived at today, myself. The implementation of the "floor" and modulo operator is still not perfect correct (this is one that every software language does just a little differently, believe it or not...), but I meant to ask you if you were using hardware to interact with the knob.

Sounds like there are two ways to solve this problem. I can think of something to try on my end, but we could also figure out why you guys need to interact with that variable in meters instead of the feet that I use. Perhaps the best solution is to do both. Thank you for looking into that today, though!

intjmastermind

You’re welcome!

I prefer to modify the underlying LVAR directly instead of relying on increment/decrementing commands for several reasons.

It bypasses any built-in acceleration. I get the same rate of change each and every time. Without it, some planes apply an acceleration to the speed/altitude/heading values, and I find that annoying and unpredictable.
I can customize behaviors such as a short press adjusting the altitude by 100 ft increments, while a press and hold adjusts the altitude in 1000 ft increments above 18,000 feet and 500 feet below 18,000 feet.

intjmastermind

UPDATE: Modifying the LVAR using units of Feet does work!