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.
@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)
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
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
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
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
@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.
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.
Hi Sylvain Back in August, you said 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. Now SU6 is released, and I do not see this change ?
Altitude_indicator = 2 is still set for all Asobo Planes that previously had
it set to 2 So it is still referencing the Baro in the Transponder, and has
not been updated to Altitude_indicator = 1, to reference the Baro in the AP
Maybe I am missing something and not understanding what actually got changed ?
(or the change did not go through ? )
Hello. It seems the change didn’t go through. I’m sorry about this, I’ll make
sure it’s all good with SU7.
Thanks Sylvain for the update. Of course, it would not be such an issue if
some of the planes were not encrypted, they could be easily modded by users,
at least until such time as Asobo did an update. If its still a work in
progress, maybe a new parameter **altimeter_standard = ** to define which
altimeter stays at Std Pressure calibration, ( as in a Transponder) even when
the B key is pressed to set all the other ones. (see previous post in this
thread)
Hi Sylvain Back in August, you said 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.
--------------------------------------------------------------- For some
reason though, it did not make it into sim Update 6 Now, Nov 18, it still
has not made it into Sim Update 7 Altitude_indicator = 2 is still set for
all Asobo Planes that previously had it set to 2 So it is still referencing
the Baro in the Transponder, and has not been updated to Altitude_indicator =
1, to reference the Baro in the AP Maybe I am missing something and not
understanding what actually got changed ? (or the change did not go through
again ? )
I wonder if this has any effect on the ATC expedite climb bug?
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.
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)
You do appreciate that all 3rd panes that have followed ASOBO mis-assumption
about this, and hence are all wrong. IF the solution is to keep the ambiguous
DOCS and Kernal code the same, and not correct it, **then ALL Planes, Asobo &
3rd Party, ( with altimeter_indicator = 2 to try to ref the AP) will need to
be updated !! ** and each day this continues, more planes are added to the
sim, with this issue . But I am not going to mention this again here in
this Forum… " You can lead a horse to water, but you can’t make it drink
"
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 ).
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:
