83006 - Joystick Deadzone and sensitivity feedback

First off, 83006 seems to be a signifcant improvement for joystick users :) However, there still seem to be some oddities around the sensitivity. To check that this wasn't something to do with my drivers or joystick itself, I wrote a small application to monitor the axis readings through directInput. The video below shows the results. You can see my readings of the joystick position represented by the horizontal and vertical sliders just above and to the left of the ToH window.

The first half of the video shows maximum sensitivity. With these settings, the in-game joystick is extremely sensitive to the first very small movement of the real joystick in any direction but the sensitivity then rolls off rapidly - ie it is highly non-linear.

In the second half of the video I reduce the sensitivity significantly which leads to different behaviour. Here, small movements around the center are smooth and the the sensitivity seems to _increase_ with larger movements.

Ideally, I'd like to see a more linear response - winding down the in-game sensitivity makes it difficult to fly without large 'real joystick' movements but increasing the sensitivity makes it unnecessarily twitchy for manouvres such as hovering.

(BTW - if anyone else is interested in a copy of the app, let me know and I'll post it on my tools page.)

EmeKSLibPoE

neat tool - good job mac :)

these might be related:

mouse problem - movement speed reversed

http://dev-heaven.net/issues/4491

http://dev-heaven.net/issues/3081

http://dev-heaven.net/issues/2376

One thing we hope to soon improve is to offer a better explanation of what the sensitivity slider really does in the UI. Your axis input is raised by a power of X based on this slider. Where X is, from left to right: 3 - 1 - 1/3 (in OA this was 10 - 1- 1/10). So in the middle your curve is linear. Additional improvements are still being investigated :)

The exponencial is little bit drastic. Say the axis has 128 different positive values. Then the minimal value with the maximal sensitivity set is (1/128)^(1/3)=0.2 and in OA it was 0.62 (so minimal joy movement was considered as 60%!)

We consider to say goodbye to our lovely exponencials and use different calculus.

Say: interpolation between linear and cubic... x' = ax^3 + (1-a)x

Thanks for the answer - can we also then have a linear linear scaling factor to play with ? :) Ie

response = K* (input ^ sensitivity) ?

At the moment I'm guessing that K is automatically selected in order to ensure that the response fits within a certain limit based on the entire input range of the joystick. This isn't great if you have a joystick (like the X52) where a very wide range of mechanical movement is required to generate the full digital range since you get a choice of either the red or the blue curves below whereas I'm trying to achieve something more like the orange response.

(Maybe you should just implement a fully-fledged curve editor in the game ? I suspect a lot of the audience you are trying to appeal to will want to tweak this kind of stuff.)

Thanks for the answer - can we also then have a linear linear scaling factor to play with ? :) Ie

response = K* (input ^ sensitivity) ?

At the moment I'm guessing that K is automatically selected in order to ensure that the response fits within a certain limit based on the entire input range of the joystick. This isn't great if you have a joystick (like the X52) where a very wide range of mechanical movement is required to generate the full digital range since you get a choice of either the red or the blue curves below whereas I'm trying to achieve something more like the orange response.

The K is not automatically selected, as it is always ONE. The thing is we work with 0<=input <=1. ;)

I think we ALWAYS need to get the FULL digital range, so if the K factor to play with is provided in engine, the K>=1 should hold. The higher values would cause the higher range of mechanical joystick axis movement redundant (as the response would be always 1, ie. FULL).

Do anybody else think the K factor is important feature to force me to implement it in UI?

The K is not automatically selected, as it is always ONE. The thing is we work with 0<=input <=1

Ah - understood. Pre-scaling the input to 1 is the same thing as post-scaling the output (dynamically selecting K) though since you are always fixing the ends of your curve at (0,0) and (1,1) with an exponential scheme.

Either way you are restricted to the family of curves between the red and the blue in my picture unless you introduce additional parameters :)

*Edit* It's probably worth pointing out that the main reason to want a non-linear response with K!=1 is that, as a number of RL pilots have pointed out, the helicopter is too insensitive to joystick input. The ideal situation would be where the movements of the real-life joystick representation generated aerodynamically correct changes in the flight model and then in-game representation simply followed this 1:1. At that point, very little tweaking of sensitivity would be required and this dicussion might be moot !

Either way you are restricted to the family of curves between the red and the blue in my picture unless you introduce additional parameters :)

It is always trade-off between easy to use and full configuration power.

Slider for deadZone, slider for sensitivity, slider or editbox for multiplication factor, ... Weaker users could be scared :confused:

It is always trade-off between easy to use and full configuration power.

Slider for deadZone, slider for sensitivity, slider or editbox for multiplication factor, ... Weaker users could be scared :confused:

Weak users don't buy TakOH!:D

Sliders for deadzone and linearity curves are very much needed. And if they will be with visual reference, even weaker users will get it.

...a number of RL pilots have pointed out, the helicopter is too insensitive to joystick input.

I duno if I misunderstood.

IRL the joystick is SUPER sensitive and hardly moves in normal flight.

Of course it cannot be made this sensitive in-game as many joysticks used by players are not capable of such subtle inputs.

Would it be possible/feasible to incorporate an editable 4 point response curve?

To keep it simpler I think Pitch/Roll (X/y) could use same curve.

I duno if I misunderstood.

IRL the joystick is SUPER sensitive and hardly moves in normal flight.

Yes, that's exactly what I meant.

- In order to get the helicopter to to respond in ToH with 'default' (linear) sensitivity you need to make unrealistically large movements with your joystick.

- If you want to move the joystick 'realistically' you need to use the x^1/3 end of the sensitivity slider which means that even tiny movements result in huge response.

- With the current scheme it's very difficult to find a sensitivity value which gives you good responsiveness across a sensible movement range without ultra-twitchiness for very small movements.

Would it be possible/feasible to incorporate an editable 4 point response curve?

Agreed this would be most flexible.

---------- Post added at 04:21 PM ---------- Previous post was at 03:42 PM ----------

*Edit*

Of course it cannot be made this sensitive in-game as many joysticks used by players are not capable of such subtle inputs.

Interesting point. FWIW my X52 Pro offers 10 bit resolution (1024 discrete points) with an movement of about +/-1 inch from vertical resulting in a range of +/-64 points. As far as I can tell from what real pilots are saying, most of my flying should therefore be done using between 1/4 and 1/8th of the digital range of my joystick !

As I say, it doesn't seem possible to set up ToH to reflect this at present.

thrustmaster 1600m used here. works pretty well at 0 deadzone and around 75 sensitivity. hardly have to move it that much at all to control heli. that was the sweetspot for this joystick. 64 buck joystick that's got resolution attaining 16,000 x 16,000 values. whatever that means.

While not directly related to rotary wing aircraft, but fixed wing propeller driven WW1 planes, in the Rise of Flight forum is a nice "treatise" on response handling, comparing joysticks and real life:

About wrong elevator position" and "pitch sensitive"

Some facts are valid disregarding the vehicle (e.g. the facts about the joystick, duh :rolleyes:); what applies from the "real-life" facts or other differences that would require optional adjustments will have to be commented by our real pilots, soon-to-be instructors and the like.

I guess the discussion here can be summed up with this quote form that post:

...it is evident that we can not make each position of the PC joystick handle correspond with the position of the control column in the real cockpit exactly, without any geometrical distortions...

In the end, in a later patch they came up with a response setup described in their wiki:

Responses