Autopilot altitude select bindings
-
The conflict could be with something else setting the altitude target via the native events, perhaps? Just an idea.
-
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.
-
Hopefully someone else with more SPAD experience will chime in, but perhaps this post, or this thread might have something to do with it?
-
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.
@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?
-
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.
-
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?
-
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?
-
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.
-
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.
-
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.
-
Thanks for understanding. It's not always an easy give-and-take between developer and user, but having great users makes it a lot easier, and I hope the same can be said of this developer. I'm always happy to answer questions! It really is something I quite enjoy about building these aircraft.
If you decide to take on these bindings with a new piece of software, please let me know if there is anything I can do to make that process easier for you!
-
Along these lines, Nick, in the Duke it was preferred to use the CWS Lvar instead of the MSFS bind or Kvar, but you had an option to enable Kvars if desired.
In Starship, there's no such option, and the MSFS Kvar seems to work fine. Does the same apply to Starship in that the Lvar is preferred, or have you yet worked more magic?
Related: CWS/Pitch sync does not control VS or IAS, only Pitch mode. While that's believable on its face, I wanted to double check since that's how you set all those things in certain APs, like the JF 146, for instance.
