Autopilot altitude select bindings

Qazme

@Callsign_DISCO said in Autopilot altitude select bindings:

@Black-Square Yes that is the one - I am new to SPAD but the others are all working (entered the same way). Will try again today.

Each time I create a new event for the two encoders and just copy/paste the code from the manuall - works on literally all the other custom events I have added - not sure why this one is weird unless I maybe have a conflicting bind in MSFS itself (haven't found one).

There won't be conflicting binds unless you have created them. These are unique to Starship. If you created them using the client events area it should be a simple matter of binding those actions to your physical control and then in SPAD you can use the :Show Log" button and spin your control. See what command it's issuing, might help you diag what's going on and make sure your encoder is working as expected.

Black Square

The conflict could be with something else setting the altitude target via the native events, perhaps? Just an idea.

Callsign_DISCO

Removed possible conflicting binds that could be in 2020 and 2024 - get all but ALT SEL to work in 2020, but no function in 2024 - this is on the free trial of SPAD.neXt but shouldn't be an issue.

Have tried Set and Increment with values of 0, 1, 100, etc. Pretty sure it is just my inexperience with SPAD and 2024 but a little frustrated.

Black Square

Hopefully someone else with more SPAD experience will chime in, but perhaps this post, or this thread might have something to do with it?

Marionettework

@Black-Square said in Autopilot altitude select bindings:

I might revisit this again specifically for Starship, but intercepting those inputs is a dangerous game in MSFS. Intercepting any control input involves a very convoluted system of abstraction, but it can sometimes have unintended results. Intercepting the autopilot inputs is even more so, judging by what I've seen in other code. I'll look into it.

After flying a bunch of flights I still don't understand why you chose to make custom inputs just for these Altitude values, but not for anything else. All my other autopilot bindings works as they did in the Velocity XL, they are all bound to standard MSFS functions and are assignable in MSFS controls configuration:

Heading incr/derc
VS incr/decr
IAS incr/decr
Heading set
Turn on VS mode
Turn on IAS mode
The ONLY ones that are not working in Starship are Altitude incr/decr and Altitude select.

What do you mean it's dangerous to intercept these? What's different in the case of Altitude select? Honestly it's too tedious to have to look for some more 3rd party software just to get my HOTAS altitude knob working in Starship the same way it worked in previous Black Square aircraft and all standard MSFS aircraft autopilots, surely this can't be intended?

Black Square

There is no difference between the variables you list, and the altitude select. I have treated them all the same way. I don't know why one of them is giving you trouble, because they are all implemented in exactly the same way. I'm happy to help you explore and figure it out, though!

As for them working perfectly, I almost guarantee that they are not. Setting them your way bypasses logic for mode arming and preselecting values that require the HTML events.

When I say that it's "dangerous" to program things in a certain way, I generally mean that it generates corner cases and possibly thousands of scenarios for unintended consequences that would be nearly impossible for me to catch with my beta testers. In this particular scenario, the only way that I'm aware of to intercept those events is by using the simulator's "Managed Avionics" mode, which would require me to reimplement all the functions of an autopilot, which the simulator is presently doing for me.

"B:Events" exist as an alternative to most aircraft functions, but the binding software that most people use doesn't have access to those either. Additionally, the backend of MSFS is broken in so many ways that it's hard to describe. A double-digit percentage of my code probably goes into workarounds for workarounds for bugs, poorly implemented functions, and abstractions in Asobo's code. Any time I relinquish control to their code, I end up regretting it. In almost any case, the better solution lies in keeping control within my aircraft and interfacing as directly with the user as possible.

Does that make sense? I apologize that you're finding this tedious, but if I tried to implement every convenience feature that has been recommended to me since Starship released, you would not have seen it until possibly 2027. Trust me, that's a difficult decision to make, especially for someone who cares so much about user experience. I know that's not terribly helpful to your concern, but I hope you can understand some of the compromises and calculations I must make when developing such a complex piece of software that will encounter an almost unlimited number of combinations of user hardware, input, and outputs.

Marionettework

I hate to sound like I'm second-guessing what you did, because I know better than to do that.

I'm just trying to fix my little problem (and it is a small problem, I can just set the altitude knob with my mouse in the cockpit) but as an engineer it's my duty to spend an hour shaving 1 second off a simple task I will do maybe 10 or 20 times. But if anything, maybe you can just take this opportunity to enlighten me about the aircraft and maybe even suggest some workaround.

So to be specific about what the differences are between the autopilot functions I can and cannot currently assign buttons to using the MSFS Controls Options (tested in MSFS 2020 this time):

CHP 850 HDG knob:

H:CHP_HeadingKnob_Right -> MSFS Control: INCREASE HEADING BUG
H:CHP_HeadingKnob_Left -> MSFS Control: DECREASE HEADING BUG

MSP-850A:

H:MSP_VerticalSpeed_1 -> MSFS Control: TOGGLE AUTOPILOT VS HOLD
H:MSP_AirspeedProfile_1 -> MSFS Control: TOGGLE AUTOPILOT FLIGHT LEVEL CHANGE (I think that's the one)

ALI 850A center knob:

H:ALT_VerticalSpeedKnob_Inc_1 -> MSFS Control: INCREASE AUTOPILOT REFERENCE VS
H:ALT_VerticalSpeedKnob_Dec_1 -> MSFS Control: DECREASE AUTOPILOT REFERENCE VS
H:ALT_AltitudeSelectKnob_Inc_1 -> MSFS Control expected: INCREASE AUTOPILOT REFERENCE ALTITUDE (!!!)
H:ALT_AltitudeSelectKnob_Dec_1 -> MSFS Control expected: DECREASE AUTOPILOT REFERENCE ALTITUDE (!!!)

Now for these last two, the bindings INCREASE AUTOPILOT REFERENCE ALTITUDE and DECREASE AUTOPILOT REFERENCE ALTITUDE don't invoke the variable (not sure how this works on the back end). Are you saying because for the Altitude knob/setting in particular, you had to use a different implementation than all these other autopilot controls, even though they appear on the same instrument, and thus it's not possible to have them invoked by those existing MSFS Control bindings?

Black Square

Oh, I know the obligation of an engineer all too well! I tell people that "I have a curse", whenever I'm criticized for doing such things.

Pardon me if I try to take a shortcut to the solution here, but are you basing which control inputs are working and which ones aren't based only on the responses you see in the cockpit?

If so, you're triggering "K:INCREASE AUTOPILOT REFERENCE ALTITUDE", and then you don't see a change in the selected altitude on the ALI. Is that correct? If so, it actually is working behind the scenes, but it's being masked by my altitude arming system, which ignores the simulator's internal value until it's needed. (Remember my other thread about the simulator's extraordinary number of limitations?)

Does that sound right, or am I way off the mark?

Marionettework

I am indeed basing this on whether I see the blue altitude number increase when I trigger INCREASE AUTOPILOT REFERENCE. So you’re saying this value is going somewhere behind the scenes and is not used. And unlike for those other H vars, H:ALT_AltitudeSelectKnob_Inc_1 is not actually changed by INCREASE AUTOPILOT REFERENCE. So you need some other way to talk to the sim back end to manipulate that value? Obviously I know very little about aircraft controls and I’m not one of those people who has a custom cockpit with special software running it. I would guess a few more casual HOTAS users will run into the same issue as me though. The question being “how do I make this blue altitude value there increase when I press a button on my joystick”. So far I think I’m supposed to download something called MobiFlight and mess around with it.

Black Square

That's basically correct. You might still find that you can "get along" with the autopilot in some ways, despite this limitation. Once the aircraft is on its way to a new target altitude, for instance, you should be able to adjust that value and actually see it on the display. You will likely also see similar behavior with the vertical speed and airspeed during some modes.

You're right that other users will surely run into this too, which is why it's in the FAQ in the manual. Luckily, I have found in recent years that users generally have come to expect that complex addons will require more complex control inputs, so they become acquainted with MobiFlight, SPAD, or FSUIPC. Don't get me wrong, I dislike being told "it is you that must change" just as much as the next guy, but you realize how these decisions get made when you start making the software for others to consume yourself.

Marionettework

Thank you, this is totally understandable considering Starship has all custom navigation systems. Most other aircraft use default Asobo stuff and I’m sure that’s far easier to develop. I hate to be that guy asking “why didn’t you do it this way?”

Appreciate you spending so much time here answering questions, ideally you’d be resting now and recovering from the crunch time.