plane icon Welcome to Microsoft Flight Simulator’s SDK Q&A Platform!

You have questions regarding the SDK? DevMode Tools? SimConnect? You would like to submit an idea for future improvements, seek help or exchange knowledge? You’re in the right place.


Please take a moment to read the platform’s guidelines before you get started!


question

N6722C avatar image
N6722C asked FlyingRaccoon commented

System.cfg [AUTOPILOT] altimeter_altitude referencing incorrect altimeter ?

Is System.cfg [AUTOPILOT] altimeter_altitude referencing incorrect altimeter ?

For example, take any Asobo GA plane, ie the C172 Classic:

SYSTEM.CFG
[AUTOPILOT]
altimeter_indicator = 2


=======================================


COCKPIT.CFG
[ALTIMETERS]
altimeter.0 = 1
altimeter.1 = 1
altimeter.2 = 1 ; KAP140 altimeter
altimeter.3 = 1 ; Transponder altimeter


STEAM GAUGE ALTIMETER
SimVar.SetSimVarValue("K:KOHLSMAN_INC", "number", 1);


KAP.js -------------- (Autopilot)
if (this.RightBlockCurrDisplay == 2) {
this.RightBlockReinitTime = 3000;
switch (_args[0]) {
case "KAP140_Knob_Inner_INC":
case "KAP140_Knob_Outer_INC":
SimVar.SetSimVarValue("K:KOHLSMAN_INC", "number", 2);
break;
case "KAP140_Knob_Outer_DEC":
case "KAP140_Knob_Inner_DEC":
SimVar.SetSimVarValue("K:KOHLSMAN_DEC", "number", 2);
break;
}



KT76C.js -------------- (Transponder)
getAltitude() {
return SimVar.GetSimVarValue("INDICATED ALTITUDE:3", "feet");
}


================================================

ISSUE

[AUTOPILOT]
altimeter_indicator = 2 ---- The AUTOPILOT designated Altitude Reference

altimeter.2 ; KAP140 altimeter (Autopilot)

Which implies the Autopilot will use altimeter2 in the Autopilot KAP140
(which is what it SHOULD)

But setting altimeter_indicator = 2 is actually using altimeter,"altimeter_indicator" + 1) ie the Transponder altimeter.3 ;

As it function now:
altimeter_indicator = 0 -----> altimeter.1
altimeter_indicator = 1 -----> altimeter.2
altimeter_indicator = 2 -----> altimeter.3


But clearly, it was assumed by ASOBO that altimeter_indicator = 2 -----> altimeter.2

which is how they have coded all their planes to refence the AP with altimeter.2

but is really using altimeter.3 (typically the Transponder)


BTW: The Transponder Baro "SHOULD" stay at Std Pressure 29.92, no matter what the others change to when the "B" key is pressed (another issue)


==================================================

PROOF

C172 example above
With current altimeter_indicator = 2 -- Adjust the KAP140 baro setting -- make no difference to AP altitude hold height
Set altimeter_indicator = 1 -- Adjust the KAP140 baro setting -- will adjusts AP altitude hold height
Set altimeter_indicator = 0 -- Adjust the Steam Gauge Altimeter Knob -- will adjusts AP altitude hold height

This becomes obvious when using te Baro knobs to adjust Altimeter settings
If you use the "B" key, ALL Baros are set, and the issues is not apparent.


Suggested Solution

Correct the kernel incorrect indexing.

This will make all Asobo Plane work correctly, and also 3rd party planes that assumes the 2:2 index matching, copying the Asobo Plane examples.


It would seem that a few 3rd part Plane developers have caught this, and altered their altimeter_indicator from example 2, to a working 1.

(But did they tell any other developers, or even Asobo ?).

They will need to correct their Planes if Asobo corrects the issue in the Kernel.





aircraft
10 |10000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

3 Answers

·
N6722C avatar image
N6722C answered N6722C edited


@SYLVAIN


SDK: System Config Definitions

[Autopilot]

Missing descriptions.

Asobo & Dev are Guessing (?) what theses value mean, and these logical guesses do not appear to be always what is programmed in MSFS --


ie "altimeter_indicator" # vs Index values.


===========================

From the P3D SDK, which has more details entered:

attitude_indicator Indicates which attitude indicator system on the aircraft is being referenced by the autopilot.
0 = the first, and is the default.


With hindsight, seeing how this is actually working in the SIM

for Example in the C172 steam gauge Aircraft

0 = Index 1 The Steam Altimeter Gauge

1 = index 2 The AP

2 = index 3 The Transponder


Asobo demo planes, and many 3rd party planes, copying Asobo's example, are setting attitude_indicator =2 (assuming this is referring to altimeter index2), but really it is calling index 3 which is the Transponder (which is incorrect)


10 |10000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

FlyingRaccoon avatar image
FlyingRaccoon answered N6722C commented

Hello N6722C,

First, thank you very much for the very detailed report.
Don't worry, I had seen your post and started investigating a similar issue on a different aircraft. What surprises me is I came to different conclusions. It seems to me system.cfg and cockpit.cfg files are all using indices starting from 0, and the simvar update should use indices starting from 1.
I need some more time to test the C172 classic.

Anyway, I already filled a ticket on this and our autopilot developer will have a look.

Thanks again for reporting this.
Regards,
Sylvain

11 comments
10 |10000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

N6722C avatar image N6722C commented ·

Hi Sylvain

Any progress with this -- namely a decision on which direction Asobo may be taking

(a) Define the index definition in the SDK, and update all aircraft to match
or

(b) Define the index definition in the SDK, and update the indexing code in the sim, so that the Asobo Planes, and those designed, using the Asobo Planes as an example, do NOT need to be changed

or

(c) Some other resolution

Regards

Geoff


0 Likes 0 ·
N6722C avatar image N6722C commented ·
Hi Sylvain

Not seen any updates/changes in the SDK on this matter.
Has a decision been made yet on how to address this issue , or even if it is planned to be addressed ?

Regards

Geoff


0 Likes 0 ·
FlyingRaccoon avatar image FlyingRaccoon ♦♦ N6722C commented ·
Hello Geoff

Developers are still working on the issue. I'll let you know when a fix has been found and what choice was made.
Regards,
Sylvain

0 Likes 0 ·
N6722C avatar image N6722C commented ·

@SYLVAIN

  • Any progress on this ? maybe its already been addressed in the upcoming update ?

    I do not know the Ticket number, but any update would be appreciated.

    One suggestion, regarding the keyboard B key setting ALL altimeters.
    Maybe a a solution is to add another .cfg parameter to specify the Altimeter Index that should stay at Std Pressure. (Typically one in a Transponder)

ie

altimeter_standard = 3



Whatever the solutions(s) , its either going to need a change in the MSFS Code, or all the planes out there that have used the ALtimeter_Index incorrectly,(Includung Asobo Planes) will need to be updated because of confusion with the SDK documentation and Asobo examples.



0 Likes 0 ·
FlyingRaccoon avatar image FlyingRaccoon ♦♦ N6722C commented ·
A fix has been done for SimUpdate6 and is basically just fixing Asobo planes cfg files.

We probably want to avoid any regressions on third party modules.
The documentation will warn people about this.

-1 Like -1 ·
N6722C avatar image N6722C FlyingRaccoon ♦♦ commented ·
This one appear to have been abandoned.


You said it would be corrected in SU6, with an update to the documentation to explain that it was going to remain as is, and that planes old plane that assume the old documentation, would need to be update.

I must admit I found this an ODD solution, because fixing the Indexing code, woud have then matched the old documentation, and all current planes would then work, and not need modifying.


In any case, it would seem that this correction did not make it into SU6, or SU7.

The documentation does not point out the original error,and expanding how it is not going to get changed.
The Asobo planes have not been updated, so still use the incorrect Baro fro their AP.

Understandable, things get missed, so


Please could you give us a current update on this issue


ie Currently, the Asobo C172 Classics, is still using the Transponder Baso as its AP altitude reference, so chnaging the baro in the AP, does not have the effect it should, as well as there being no way to now set the ALtimerter & AP baro to std, above FL180, (unless the weather is STD, and one presses the B button)


2 Likes 2 ·
Show more comments
Parorng avatar image
Parorng answered FlyingRaccoon commented

I wonder if this has any effect on the ATC expedite climb bug?

3 comments
10 |10000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

N6722C avatar image N6722C commented ·
Good Question.


The problem is masked when it could be an issue, if the B button is pressed to set ALL altimeters to the current altimeter setting.
Then it does not matter which pressure sensor is feeding what.

It will set the Transponder to current Altitude, Incorrectly if Pressure is not STD, as the Transponder is meant to indicate Flight Level, not altitude.
However assuming ATC in MSFS is looking at the Plane's ACTUAL altitude, and not the FL from the Transponder (Not all planes have transponders !@!), then if all the Baros are set with the B key, all "appears" to be OK.

One way to check, if the ATC expedite climb is associated with this , or not, would be to fly in Clear Skies, (altimeter std 29.92), hit B button, and then see if ATC stops pestering to expedite climb..


It starts to get overly complex and dependent, when there is are basic errors, that sometimes compensate for each other. Might be much easier to fix the underlining error, and then evaluate the remaining situation.


I had hoped that all this was behind us by SU6, and then later by SU7 -- but it does not seem that anything has changed.








0 Likes 0 ·
N6722C avatar image N6722C N6722C commented ·

My Apologies .. I was mistaken. @FlyingRaccoon

It looks like the Asobo Planes were updated in SU6 and SU7 as described about to have their altimeter_indicator changed from 2 to 1, so it correctly used the KAP140 AP's baro.
I assume this to be true, as they now works correctly, but since the .cfg files for these Asobo Planes are Encoded, there is no way for users to look and see for sure.


I cannot find any reference in the current SDK to the Indexing situation.( maybe so far, its only documented as a comment in flightsimulator.exe ? ), but at the moment, that seems almost irrelevant, as most of the 3rd party planes that use the KAp140, do not even set a value for altimeter_indicator in their config file, so it defaults to 0, the Panel Altimeter setting knob !!! (so in fact few, if any Developers need to update their planes ).





0 Likes 0 ·
FlyingRaccoon avatar image FlyingRaccoon ♦♦ N6722C commented ·

Hello @N6722C


I'm relieved. I was starting to investigate if we add a problem at package ingestion because the unencrypted packages were working as expected.

Regarding the indexing, we didn't change anything to avoid any regressions with existing packages.
Instead we added notes in the documentation to warn people about this:
1644833413748.png

Regards,
Sylvain

1 Like 1 ·
1644833413748.png (68.7 KiB)

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 5 attachments (including images) can be used with a maximum of 19.1 MiB each and 23.8 MiB total.