As you may have seen on our social media, we have new joystick features coming in the next major update. There are two major features here:
- Custom response curves
- Special (semantic) ranges for certain axis types
The first may be of general interest, while the second is almost exclusively useful to hardware makers and custom cockpit builders.
Custom response curves
For as long as I can remember, X-Plane has had a “control response” setting, which makes your controls respond non-linearly. More of your joystick’s range is mapped to the center of the your pitch/roll/yaw axis’s center, and less of the range is devoted to the extremes. This gives you fine-grained controls in the region where the controls are typically used, at the expense of more coarse controls at the limits.
In X-Plane 11, these settings live in the Control Sensitivity window (launched from the bottom of the Settings > Joystick screen), and they will continue to be there in the 11.30 update.
The problem with the existing control response setting, though, is that it applies to all joystick hardware you might plug in. You get just three values—pitch, roll, and yaw—that apply to every axis of that type, no matter the device. Moreover, if you have a different type of axis whose input you want to curve (e.g., throttle, tiller, etc.), you’re simply out of luck.
So, in 11.30, we’re adding support for setting custom curves on any axis type. When applied to a pitch, roll, or yaw axis, this will override the global control response curve; applied to other axis types, it will support new functionality not previously available.
These curves are incredibly powerful. They can do things like:
- Manually configure a null zone
- Create a smooth curve (a straightforward replacement for the old “control response” setting)
- Create really complex curves, with loads of control points, and your choice of interpolation method (linear, or one of two methods of smoothing)
But the fun doesn’t stop there!
New semantic ranges
There’s a new component to the curve editor that bears calling out explicitly.
When you’re editing a response curve for certain axis types (throttle, prop, or mixture), you’ll have the option of also configuring the ranges for certain axis-specific behaviors:
- Beta & reverse ranges for throttles
- Feather range for prop controls
- Cutoff range for mixture controls
X-Plane has always set these ranges automatically based on the aircraft model you were flying. For the first time, though, you can configure it yourself to match your hardware.
These are aimed primarily at hardware builders who have physical detents on their controls—you can make X-Plane’s idle point exactly match your throttle’s physical detent, for instance. This makes it possible to build really nice throttle-prop-mixture quadrants that play nicely with X-Plane.
If you’re a commercial hardware maker, and you’d like X-Plane to correctly configure your hardware by default for your users, you can set up both the axis & button assignments and the semantic axis ranges from the settings UI, then click the “Create Default Configuration File” button. Send the file it creates to me (my email is my first name at X-Plane.com) and I’ll get it shipping in the next release.
Hello Tyler,
Thanks for this useful feature. However, as I replied on social media, could you please consider adding the posibility of having the input of joystick axis dataref passing thru those curves?
The physical controls we use don’t drive joystick axis, but manipulate sim/joystick/yoke_pitch_ratio and friends.
In general, we get rrrrrrreal nervous when people talk about building hardware that doesn’t interface with X-Plane via the HID spec. This is a recipe for conflict and confusion, as multiple plugins might try to manipulate the same controls at the same time. Can you tell me more about your use case, and why you went this route?
Someday we may have a real interface to this, but it would be a major piece of new functionality. When Chris rewrote the _low level_ joystick support in v10.10 (building the foundation on top of which Tyler built all of the profile support, .joy file support, etc.) he set up the sim to accept multiple categories of input streams. So we can, in theory, someday allow plugins to register devices for which the plugin simply registers callbacks to provide data.
This would not be the same as just writing to the axis – you’d be creating a “physical” axis that would need to then be mapped to pitch – although your plugin could hint good defaults for configuration. But this is a major piece of work that is not started and is not on the short term road map at all.
I guess the “curve per axis” is actually “curve per axis and plane”, so one can have plane-specific curves (like the button assignments)? Will there be preset curves (like linear, sinus-like, logarithmic, exponential, etc.), and if not, will it be easy to copy the curve for one axis to another? Maybe you can show us an early screen-shot how the “curve input” looks like.
Yes, this will play nice with the per-aircraft joystick assignments as well.
We do not have an easy way to copy/share portions of a joystick config between profiles. (I consider it a bug, for instance, that calibration info is even allowed to be set on a per-aircraft basis… even worse, doing so is required under the current system.)
Fixing/improving this stuff is high on my priority list for the joystick system, but it won’t be in 11.30.
I’m adding a screenshot to the original post now…
Excellent… I guess this will allow us to have different curves for different categories (profiles) such as helicopters, propeller aircraft, jets, etc….
thanks!
Indeed!
Helly Tyler!
Thank you and the team to bring this feature!
Just a short question, and I hope I express it in English correctly :D.
Will this new system have a feature to set different values of an axis different commands or set a certain value to dataref?
This would be nice to emulate a rotary multi-switch without the need to use arduino or other more complex way of doing it.
Thank you!
We do have a way to handle rotary switches which behave like buttons under the hood… it’s not pretty, but you can use rules in your .joy file to handle this (see the section on toggle switches in the spec).
Re: triggering specific commands based on axis positions, you could theoretically combine this with the assign-commands-to-axes feature from 11.20, and hack it so that you assign up to 4 commands to arbitrary axis ranges… but the system is certainly not designed to support that, and it doesn’t make it easy.
Is this a way to handle ‘rotary encoder’s?
If not, are there any plans to support them?
I think it would be a great boon to home-builders to be able to wire two buttons of a joystick to a rotary-encoder and not need an arduino.
I have zero experience with rotary encoders myself. What’s the bug/feature request here?
Eeek – in no way an expert here – but, the basic way they work is by pressing button A and then button B at slightly different times. Something like – if A then B is pressed, then it’s ‘volume up’ but if B then A is pressed, then its ‘volume down’.
(any continuous twist-with-detents, eg digital volume, Saitek radio panel, G1000 knobs, are all rotary encoders)
For home-brew cockpits, I believe an Arduino is often used to take the timing of pressing A and B and distills them into discrete ‘volume up/down’ commands.
I don’t know if USB is viable for the A/B button on/off timings or not (I have no experience with any USB HID stuff) which is maybe why joysticks have a built-in chip.
But if a user could elect button 27 and 32 to be ‘paired for rotary encoding’ then I believe you can cut out a huge complexity of home-brew cockpits.
If timings over USB are no good for this, then we’re destined for Arduino based rotary-encoders, and they will have to re-interpret the encoder signals to send momentary ‘volume-up / volume-down’ commands (as you described above for the 3 way momentary switches).
(NB the Saitek/Logitech X55/X56 throttles have a silver rotary encoder in the little-finger position, that (must) have a chip on the joystick that takes the encoder signals and does interpret them into ‘up-button / down-button’ signals.
I know that if x-plane could understand the rotary-encoding, then I can hack joysticks with just a soldering iron, instead of needing an arduino and software and programming.
These links seem to explain them well…
https://www.allaboutcircuits.com/projects/how-to-use-a-rotary-encoder-in-a-mcu-based-project/
WIkipedia talks about the more reliable 3 switch version…
https://en.wikipedia.org/wiki/Rotary_encoder
They’re so common-place in so much equipment, maybe it’s worth supporting their encodings directly, one day…?
rotary encoders usually work by quadrature encoding.
My personal opinion is this is well below an intelligent input device, and that something else should be translating it to inc/dec signals, or mapping them to actual discrete values (so you can do acceleration or other fancies).
I think this sort of request ultimately comes from the fact that a lot of implementations of rotary encoders in simulation that I’ve seen are really poor – too slow sampling rates, etc, which cause erroneous “backspin” if you dare to turn the encoder “too fast”, or indexed encoders aren’t indexed relative to state transition boundary properly.
Yeah, I don’t see X-Plane containing a ‘native’ decoder for the low level “quadrature” encoded stream. For hardware like the GoFlight radios, the board on the GF device itself decodes the stream, keeps an 8 bit ‘count’ of current offset, and publishes the count over HID, and this seems like a more reasonable approach. So I don’t see cockpit builders who are using an Arduino and rotary encoders getting out of having to program the Arduino a bit. 🙁
Nice, I’ve missed that post.
Yet 4 commands are a small number thinking for example in the voltage selector of the Boeing 737-800. I guess I’ll use lua or xlua to achieve this 😀
Yyyyyyeah… as a home cockpit builder, I think using a plugin for something like this makes sense. I’d expect commercial hardware makers, though, to make rotary switches truly digital, though—to send individual “buttons” for each position change. (That case can be supported natively by the .joy spec.)
Hello,
sorry for the partial offtopic posting.
Reading other stuff about the upcoming 11.30 there is one statement confusing me a lot:
This is the NEW PT6 turboprop model, where the N2 is used as the compressor Ng in the real engine. This is the new model, which is more accurate and very carefully matched to real PT6 performance. This uses N2 for Ng, which makes a lot of sense, when you understand how the real engine works. As well it uses N1 for the turbine that is attached to the prop, so the N2 drives the torque, and the N1 is spun by that, just like a high-bypass turbofan engine. So, this use of N2 for the Ng makes much more sense, and the model is more accurate as well, so this is the new turboprop model that you should use.
—
In all other docu about the PT6 N1 is bound to the compressor part of the engine.
So what does “This uses N2 for Ng, which makes a lot of sense” mean?
Thank’s a lot
The PT-6 is a two-spool design: The gas generator spool has the compressor and one turbine wheel on it. Its RPM is what is indicated in the panel as Ng, “g” for “gas generator”. The second spool goes into the reduction gear which drives the propeller shaft, and it has one or two turbine wheels depending on the specific model of the PT-6. The RPM is only indirectly measured, by the prop RPM, which is some fixed reduction ratio lower than the turbine wheel RPM. The point is, there is no mechanical connection between the gas generator spool and the power turbine spool. They are coupled by the gas flow through the turbine wheels only. You can think of it as a fluid coupling, with the hot exhaust gas being the “fluid”. That means, as the gas generator spools up, it creates more RPM differential in the fluid coupling, which translates into higher torque being send to the propeller. The OLD X-Plane free turbine model ignore the fact that the two spools are independent, and treated N1 as the one and only spool in the engine (indicated in the cockpit as the Ng). The NEW X-Plane free turbine model models the spools rotating independently, with N1 being the outer spool connected to the prop through the reduction gearbox, and N2 being the inner spool for the gas generator. If you look at a schematic of a turboprop and a turbofan engine and see which is the N1 and the N2 in a turbofan, this will immediately make sense.
Thank you Philipp for your detailed answer.
I read a lot about the PT6, one of my prefered writer for that stuff is Tom Clements.
In his Book he calls N1 the RPM at the Power Site (about 40000 RPM, and N2 the RPM on the Prop Site (about 34000 RPM before the planet gearbox).
Is the definition what N1/N2 is well defined?
If Yes, who is right?
I think the confusion of Gunther stems from the fact that PT6 has N1/N2 nomenclature reversed.
In a turbofan, the hi-speed (core) shaft is N2, while the free shaft (fan) is N1. On some PT6 instead, the gas generator is labeled N1 (instead of Ng) and the free turbine/prop shaft is labeled N2 (instead of Np). E.g.: http://www.avcanada.ca/forums2/viewtopic.php?p=490884&sid=776b4cb8d7a088135e60775a95b9f9a2#p490884
This explains the apparent inconsistency. Hope this clears things up for Gunther.
Yep, that exactly is my point,
but we are talking about the PT6, so it looks like the confusion is on the X-plane developer side.
Maybe I’m wrong and “free turbine model” doesn’t stand for the PT6 only(?)
Thank you
The explanation given by X-Plane developers is actually correct. The confusion only stems from the opposite labeling of N1/N2 on PT6, compared to turbofans.
In other words, X-Plane developers refer to “N2” as the core shaft (which corresponds to the gas generator in the PT6) and to “N1” as the fan shaft (which corresponds to the free shaft in the PT6).
According to this labeling, it is correct that “N2” (core shaft in the internal XP engine model) is used for “Ng”/”N1” in the case of the PT6.
Don’t get confused by labels: when XP devs talk about “N2”, they’re simply referring to the core shaft as modeled internally by XP. It is hence correct that this core shaft (“N2”) is used to model the gas generator shaft in the PT6 (called “Ng” or, in some cases, “N1”, from which the confusion stems from).
Thank you Marco for clarification.
As long as I can follow my instructions about starting the engine (> 12% N1 etc.) all is fine 🙂
(your post didn’t have an reply button, so I replied to myself)
this is great news
so, if I understand it correctly, one could devote the first say 20% of the throttle axis to trigger reverse and use the remaining 80% for the normal throttle operation, right?
Exactly.
Thank you so much for this. IF I read this correctly, and would love to get verification that I did, this is one of the last things remaining from my FS days that I lost out on moving over to X-Plane back in the v8/9 era with FSUIPC plugin. Am I correct that I will now be able to set a cut-off zone, in other words, a dead zone like I could in FS? If so, this will mean that the potentiometer “stutter” I get in X-plane will be gone. If it’s similar in approach then will I also be able to set a dead zone on my rudder pedals that I like at the center area? Again, thanks.
That’s correct. A dead zone in the graph view just looks like a straight horizontal line. 🙂
Thanks for the great features!
Could it be used also for flaps detent ranges and trimwheel too? If not, will it be added in the future?
For flaps, prrrrrobably not? The challenge there would be: what do we do if you have, say, 3 detents set up… but the aircraft you’re flying has 5? (This isn’t an issue for the existing semantic ranges, because they fully specify all the possibilities; the only type of mismatch that can occur is if your aircraft is missing ranges specified on the joystick, in which case it’s easy to know what to do: we just ignore the ranges that don’t apply.)
Re: the trim wheel, what ranges would you want to specify? Just the center?
yeah I got the issue with missing/excessive detents but then we could ignore that as you suggested and since we could save that per aircraft, I guess it’s making it a reasonable solution/limitation.
For the trimwheel I was aiming for non-linear response mapping. I’m using saitek trimwheel which is too responsive ( and lacks the crucial precision). It’s really diminishes controllability , too far from a real c172 . So, the goal is the same 80/20, to trade at least some range for better precision, as possible with other control axes.
Ah, re: the trim wheel, yes, this will work out of the box to set a custom response curve.
Are LR going to include the option to control multiple engines with a single throttle? 4 engines and 2 joystick throttles didn’t work very well
This is on my radar, but it won’t be fixed in the near term.
Thanks!
All these features are greatly welcome. However, many simmers are still waiting for the ability to assign the same command to multiple axis without getting a warning and actually working. It’s really necessary for dual seat cockpits with dual yokes and pedals.
And the most important feature I’d like you to implement is allowing to bind commands when an inputs is “released” so one can bind a ON-OFF switch to a command for ON and to another command for OFF, ie. Landing gear UP and DOWN.
So far, both issues can be addressed with Lua scripts but I was hoping for something inside X-Plane UI
Any possibility this could be implemented soon1?
Re: multiple axes: this isn’t coming soon, but I agree it’d be nice to fix, and it’s on my radar.
Re: binding on button state transitions, this is possible already via the .joy file. This isn’t really user-facing, because the expectation is that the hardware vendor (or an industrious user willing to get their hands dirty) creates it once and correctly “describes” the hardware to X-Plane, then it “just works” forever after. See the section on toggle switches for more info on how this works.
Tyler
I’m Tom Campbell and I work with XForcePC who sell a lot of computers and associated hardware for x-plane. One of the yokes we sell is the YoKo. It’s expensive but a lot of our customers love it. One asked me a question that I think is interesting and I wonder if your new features will work this way. One the 172sp he said the YoKo is just like his real plane except for one area. When he’s landing at about 65 kts his real plane gets really sloppy and mushy. But with x-plane the feeling doesn’t seem to change. Certainly this is partly due to constant metal springs. But I was wondering if you new settings can make the response of the plane relate to its speed and flap settings that fake the yoke into feeling mushy like a real plane does while landing. Thanks!
Ooh, that’s a much harder problem… that would require specifying different response curves for different speeds, and having X-Plane interpolate between them. Possible in the future, but it’s not in the cards for 11.30.
Tyler
No problem. We’re all excited by anything that comes with 11.30. I’m especially interested in seeing what will happen to ATC but not being crazy either.
Best regards
Tom
When will implement an X-plane native autogate system ?? I think this will be very usefull and very cool for all simmers. Thanks and a hug!!
Hi Tyler,
Thank you for this great new feature!
Here is my case: I use a mini joystick in my HOTAS as a POV camera, mainly when checking runway position turning base and final at the pattern. Problem is that range of this minuscule device now is 360º horizontal and 180º vertical which is way more then I need and makes it very sensitive.
Question 1: Is this new feature allow me to set this joystick axis like 60% lower then the camera range so I could have like 200º horizontal and 90º vert range?
Question 2: If this is possible can I keep still using the mouse to get full range for POV?
Thanks
Ricardo
Yes to both!
The mouse will be unaffected by the curves you set on your joystick’s axes, so that’s easy.
To set up the joystick, you would set two custom curves (one on the x axis, one on the y), and simply set the topmost portion of each range to 60% of the max.
Ohhhhh yes, that will be sooo good, thank you
hello,
I had a longer correspondence with a Brunner engineers about the usage of the CLS-E NG FORCE FEEDBACK YOKE. For using it with my iMac27 it needs to be calibrated through the steady connection to their special Windows software (using a Win partition on iMac or permanently a second Win machine). Will it be possible to calibrate the Brunner yoke from now on (XP 11.30) using the support for setting custom curves on any axis type as you mentioned ?
Uh… without knowing why it needed to be connected to a Windows machine in the first place, I can’t say. This is the first I’ve heard of this rather bizarre setup. (I assume it’s a hack to get force feedback working? If that’s the case, then no, a custom curve won’t help.)
Force feedback that is exactly the case…. Thanks for answer !