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

MSFS20 Changing the AP ALT hold altitudes in 20ft steps (instead of 100 or 1000)

Geoff_D

Geoff_D

Messages
497
Country
unitedstates
I am trying to implement in a KAP140 AP, changing the ALT hold value in 20ft steps
(This happens in the RL AP, if you are in ALT mode, and press the UP / Down Buttons, as opposed to using the rotary switch, which will do 1000 and 100 ft increments .

The problem I am having, is that either
Reading AP_A:LT_VAR_SET_ENGLISH only returns Altitude Rounded to nearest 100 ft
or
Setting K:AP_ALT_VAR_SET_ENGLISH only sets the Altitude Rounded to nearest 100 ft

("Strange" rounding occurs about about xxx25 ft)

I tried keeping track of the Hold Altitude with my own ApAlt variable
I can obviously inc and dec that variable by any about , 100ft 20 ft 1 ft etc


case "KAP140_Knob_Inner_INC":
this.ApAlt = this.ApAlt + 1;
SimVar.SetSimVarValue("K:AP_ALT_VAR_SET_ENGLISH", "feet", this.ApAlt);
this.CurrAlt = (SimVar.GetSimVarValue("AUTOPILOT ALTITUDE LOCK VAR", "feet"));
var x = this.ShowStatus(this.ApAlt + "#" + this.CurrAlt);
break;
Click to expand...

ApAlt is the variable I am keeping track of what I want the AP Alt to be set to

var x = this.ShowStatus(this.ApAlt + "#" + this.CurrAlt); is a routine to show Variables in the Gauge (Crude -- I need the better way !!)

So it is displaying the my wanted ApAlt, and the AP read CurrAlt HOLD ALT

As I INC up the value, ApAlt increments correct by (in this case) 1 ft
But CurrAlt jumps at about APAlt = xxx25 ft and can only be in 100's of feet resolution
.
ApAlt: 3518 3519 3520 3521 3522 3523 3524 3525 3526
CurrAlt: 3500 3500 3500 3500 3500 3500 3500 3600 3600

Same happens when I DEC

So how do I set the AP to have a Hold Altitude with 20 ft resolution


(Note: Yes, I am using the Knob, not the Buttons for this test -- In RL the knob only does 1000 & 100, while the Buttons do 20 (short press) and 500 (long Press) )
 
Not going to happen. It doesn't support it. Sorry. Just like vertical speed is restricted to 100' increments as well.
 
WarpD said:
Not going to happen. It doesn't support it. Sorry. Just like vertical speed is restricted to 100' increments as well.
Click to expand...
It's to going happen :) somehow ... :) Restrction are made to be broken !!!
 
Last edited:
Geoff_D said:
It's going happen :) somehow ... :) Restrction are made to be broken !!!
Click to expand...
And that's what irritates a customer the most. When you hack the core sim so that every single time there's a core sim update... they have to wait for you to hack the new version so they can use what they purchased.
 
Did I say "Hack" ? No ... Apparently there is a "Correct" way to achive what I need, as is being used by at least one Addon Developer.
 
WarpD said:
And that's what irritates a customer the most. When you hack the core sim so that every single time there's a core sim update... they have to wait for you to hack the new version so they can use what they purchased.
Click to expand...
I probably should start another thread on this, since it get's a bit off-topic; but I fundamentally disagree with the implications of what I understand you are saying here.

In this particular example:

The OP is trying to work around a restriction in the core sim, to work around a "limitation" in the core sim code that doesn't allow AltHold settings other then in 100 ft. changes.
While, for this (and other aircraft), this appears to be realistic (with whatever RealLife restrictions).
And has nothing to do with 'hacking the sim core code"; it's perfectly possible to implement this near as-real-as-it-gets , even in FSX (and based on the FSX-SDK).
In fact, using Tom's hints in the other thread, I just coded that.

And in general:
I DO agree with your remark on 'customer irritation'; being a freeware addon designer myself, I'm very aware of that.
OUR (addon designers) problem is that we are failing to 'educate' customers in explaining why we are unable to guarantee that something we design based on the current sim program version, might not work in an update of it.
Or: why their expectations of 'it works now, but not after I made a core sim update' is not realistic.

Instead of blaming the developer of the core sim program for their inability to maintain downward-compatibility when providing updates for "bugs" or changing the implementation that makes addons not work.
I, as an addon designer, have the luxury of limiting myself to make freeware addon stuff for a well-known and stable ('known-bug-wise", "SDK-wise") flightsim platform (FSX-Accell).
So I can test what I code myself, and works in future.

With your expertise, I'm sure you know the difference between "hacking the core sim code" and "using the behavior of existing core sim code and limitations of it, and published SDK" to implement a new/improved (real-life) feature.
Without that, the addon 'business' (freeware or payware) would be void.

That said, and even more off-topic:
Personally, and with the same arguments, I'm staying away from any addon development for the new MSFS for now.
Whatever an end-user thinks of it as-is now, it should be an addon-developer's worst nightmare.
The way it's being developed (as a continous 'service' based on the so-called 'agile' way of todays SW-development) makes me very sad; even as a simple user, I gave up on the continous (and likely) endless stream of patches and hotfixes, introducing new things, solving bugs and with it, introducing new bugs.
Making me feel I'm (at best) an alpha-tester.
Sorry for that rant, and not addressed to you .......

Just trying to explain why your remark on "customer irritation" and using the term "hacking" triggered my reaction.
Especially in a thread tagged for MSFS.

Regards, Rob
 
Do real life autopilots have 20ft increments? I can't remember the last time ATC instructed me to level of at 15,460ft.

I am not criticising but what is the purpose? Is it more for low level vfr flying?
Stinger

Sent from my SM-T813 using Tapatalk
 
stinger2k2 said:
Do real life autopilots have 20ft increments? I can't remember the last time ATC instructed me to level of at 15,460ft.

I am not criticising but what is the purpose? Is it more for low level vfr flying?
Stinger

Sent from my SM-T813 using Tapatalk
Click to expand...

Real KAP 140 units that don't include the optional Altitude Preselect rely on this ALT UP/DN to adjust the captured altitude so to remain on the level desired.
For example, if wanted to level at 3000 ft, once reaching and ALT pressed, the aircraft won't level off at that exact altitude; then UP/DN is used to adjust it until matching as close as possible.

Tom
 
taguilo said:
Real KAP 140 units that don't include the optional Altitude Preselect rely on this ALT UP/DN to adjust the captured altitude so to remain on the level desired.
For example, if wanted to level at 3000 ft, once reaching and ALT pressed, the aircraft won't level off at that exact altitude; then UP/DN is used to adjust it until matching as close as possible.

Tom
Click to expand...
Ah, i see. Thanks.

Sent from my SM-G935F using Tapatalk
 
rcbarend said:
Personally, and with the same arguments, I'm staying away from any addon development for the new MSFS for now.
Whatever an end-user thinks of it as-is now, it should be an addon-developer's worst nightmare.
The way it's being developed (as a continous 'service' based on the so-called 'agile' way of todays SW-development) makes me very sad; even as a simple user, I gave up on the continous (and likely) endless stream of patches and hotfixes, introducing new things, solving bugs and with it, introducing new bugs.
Making me feel I'm (at best) an alpha-tester.
Click to expand...
Rob... Couldn't have said it any better.
Roman
 
rcbarend said:
triggered my reaction.
Click to expand...
Next time I'll wrap my post in a spoiler tag and mark it as containing trigger words?? :yikes:

Seriously though... my point was that actually hacking the sim is a bad approach. Perhaps I read too much into his response, but I have run afoul of other developer's sim hacks to make their product do things that the sim doesn't support willingly. And then I get to deal with customers who get irate with me because another developer's hacks don't play nice with anyone else (and they don't really care either). So yeah... that's my trigger area. There's a "sandbox" defined by the sim and it's SDK/API. When one steps outside of that "sandbox", things tend to get messy, and that's really not good.

Writing one's own autopilot code, sure... overriding core sim behavior via a code hack... no, please don't.

My $0.02 and it's probably worth less... sorry.
 
You must log in or register to reply here.
Back
Top