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

MSFS GetGameVarValue

Geoff_D

Geoff_D

Messages
497
Country
unitedstates
WarpD said:
This system seems horribly messed up and inaccurate.
Click to expand...
At last something we can BOTH agree on.

I really don't understand a separate baro for the AP, let alone the transponder. The transponder typically gets input from either an encoding altimeter (the value provided is the pressure altitude) or from a "static altimeter" that is always at 29.92. There is no need for the transponder to have a baro setting of any type whatsoever. That would not be realistic.
Click to expand...

If course it would be "Realistic" - The Transponder has its own Baro, that is ADJUSTABLE, but NOT by the Pilot. It gets calibrated to a fixed 29.92 by the Aircraft mechanic .. but in reality , can DRIFT.
SO, yes, to simulate drift and miscalculation, the SIM's Transponder would have an adjustable Baro, but only adjustable by some sort of "maintenance procedure"

But you are missing the whole point of this thread.

For an AP, that has its own Baro, and the means to adjust that baro, as it is that baro that the AP should use for its Altitude function.
In MSFS, the KAP140AP has Baro is index 2
In MSFS, the KT76c Transponder has Baro index 3

In system,cfg, under {AUTOPILOT}, "altitude Indicator" is set to 2, because it is baro Index 2 that we want the kernel AP Altitude hold code to use.

BUT.. the kernel, after reading "altitude Indicator" = 2, "MUST" be incorrectly adding 1 to that, so it uses Baro 3 = The TRANSPONDER, which is wrong. !!
(the classic, software programming error, do you start counting from zero, or from 1 )

The only reason why it can "Appear" to work correctly, is because, if you are LAZY, and do not manually adjust the Baros as you would in real life, but instead, press B that will set ALL baros, and the AP using the Trasponder baro, now set by the B key, will appear to be working correctly.

This is not Theory, this is not a Guess, it can clearly be shown to be the case, and "IT IS SO WRONG" -- and needs to be fixed.
 
E

eric_marciano

Messages
531
Country
france
You're probably right Geoff, I am part of these "lazy" pilots who press B when the altimeter is wrong, so I never saw this bug. Next time I will pay more attention and will adjust the baro manually.
When you say it is wrong, do you think it can only be fixed by Asobo in the sim code itself? If so, did you report the bug to have it fixed?

Eric
 
Geoff_D

Geoff_D

Messages
497
Country
unitedstates
eric_marciano said:
When you say it is wrong, do you think it can only be fixed by Asobo in the sim code itself? If so, did you report the bug to have it fixed?
Click to expand...
TO correct the issue, the kernel code should be corrected.

Everyone, Asobo & Developers have "assumed" "altitude Indicator" = 2, is referencing Baro Index 2.
Thatis both Logical and KISS. but it is not actually specifically Document that this is so in the SDK.
It is just assumed to be so, by copying the Asobo plane Examples.
SO, all the Asobo Planes that use the GA Autopilots have this issue. and do most 3rd part planes
Its far better (IMHO) to fix the BUG in the Kernel code, than to Mod all the aircraft, both ASOBO & 3rd Party.to cover up the kernel bug.

ie Put it right in the CODE so it operates like everyone expected -- and Then DOCUMENT it.

It has been reported,

The initial response was "it has always been like this, back from FSX days" -- but to me that's no excuse to keep the bug perpetuated !

---------
Now you know what is happening incorrectly, its very easy to prove it to yourself as well.

Fly the C172 Steam, on AP at 3000ft, no matter what weather... use the B key to set all the baros .
Then adjust the AP's baro .. the plane will stay at 3000ft, but the Transponder Altitude Indicator will move !!

If you were able to set the C172's "altitude Indicator" =1, then the AP's baro would be the one used by the AP, and the plane would change altitude as expected.
If you were able to set the C172's "altitude Indicator" =0, then the Steam Gauge Altitude baro knob, would be the used by the AP. and the plane would change altitude as expected
 
Geoff_D

Geoff_D

Messages
497
Country
unitedstates
Interesting -- The Carenado M20R must have figured out the they needed to set "altitude Indicator" = 1, for the AP with a Baro index of 2. (Good Job)
I bet they are keeping that one a Company "SECRET"

Unfortunately, it would seem their Altitude Encoding Transponder, always display FL 0000
OH well, you can't have everything RIGHT, or there would no need for Updates , or TECH SUPPORT



 
You must log in or register to reply here.
Top