deadzone issues

[Crozzf4d3]

i am having some problems with my joystick, the problem is that it tends to yaw slightly to the left and i don't know how to fix it, i have tried recalibrating it back defeault in logitech profiler but it has been a problem for months now. i figure all i need to do is to increase the yaw deadzone but i don't know how.
can someone please help.

[funkynutz]

Originally posted by CHA0S:

My issue is the dead zone isn't big enough on my Logitech HOTAS, so I'm drastically overshooting on my fixed beam lasers. I wish I could adjust the dead zone, then I could really thread them on target. Gimbled for now I guess.

http://i.imgur.com/X3tZeZo.png

[Draco]

Not really something that goes out of date so although starting a new thread would have been preferable:

https://i.imgur.com/sqtYh99.gif

[M00NSH0T]

i'm on my 3rd 3d extreme pro. will not buy another after this. Switching to the t.16000m after this. The sensors on the logitech sticks wear out after a couple hundred hours, and the problem you're experiencing will only get worse, until it becomes unusable. You'll have to increase the deadzone till you can no longer do fine aiming, then it's time to move on.

The t.16000 uses hall sensors, which have much longer useful lives.

[funkynutz]

Originally posted by M00NSH0T:

i'm on my 3rd 3d extreme pro. will not buy another after this. Switching to the t.16000m after this. The sensors on the logitech sticks wear out after a couple hundred hours, and the problem you're experiencing will only get worse, until it becomes unusable. You'll have to increase the deadzone till you can no longer do fine aiming, then it's time to move on.

The t.16000 uses hall sensors, which have much longer useful lives.

Been using a pair of the T16000Ms for about 1500 or 1600 hours... Starting to get a tiny bit of wobble/drift, and I've been quite rough with them... Not bad at £30 a pop...

[Salt_Extractor]

Try vJoy app

[𝟡𝟡𝟡𝕷𝕬𝖅𝕬𝕽𝖀𝕾𝟡𝟡𝟡]

Got same issue with my Hotas no way to fix it plz Frontier do something about!
There must be a ghost signal or loop what is caused somehow ingame...

[ZombieHunter]

Originally posted by 999LAZARUS999:

Got same issue with my Hotas no way to fix it plz Frontier do something about!
There must be a ghost signal or loop what is caused somehow ingame...

There is nothing wrong with the game code. What is wrong is the devices. Over time the potentiometers in the sticks are subject to wander and become floaty and won't center around any given value. This is a common problem with all pot's not just ones used in PC controllers. So volume knobs, etc can all experience this issue.

This is why all peripherals come with control panels to adjust deadzones to account for the degrading potentiometer conditions. However, you must be careful with deadzones b/c if you set them at the driver level (aka your manuf. control panel) then no game will ever be able to receive any values outside the range of what is in the control panel. It is best to leave the control panel alone and allow for all values to be sent and allow the game's in-game dead zones to account for the discrepancies.

ED has some very nice control settings to handle this. ED is probably one of the best at handling various controllers and has a myriad of settings to handle most any issue.

Note that gamepads won't have this issue on the directional pad but can have the issue on the thumbstick. Anything with a potentiometer will have this issue eventually.

https://en.wikipedia.org/wiki/Potentiometer

There are also digital potentiometers but most peripherals won't have them

Code for joystick input is very simple. Essentially you are given a max and min range and you normalize it 0 to 1.0f. Then when an input comes in, you normalize it and see where it lands on the scale and take action based on that. So if it is less than .5 +/- some fudge factor the stick is left or up and if it is greater than .5 +/- some fudge factor the stick is right or down. Same with rudder inputs. Throttle is simple min is idle and max is full throttle. You can also just use the raw values if you don't want to normalize the values. Every game does it different but the approach and result is the same.

[Laurreth]

Originally posted by ZombieHunter:

Code for joystick input is very simple.

ha. Haha. HAHAHAHAHAHAHAAAAHAohman thanks I needed that.

It's not as bad as it used to be in gameport times, but still far from great. And re the throttle thing, please tell that to the House of the Dying Sun dudes who simply gave up after several botched attempts.

[ZombieHunter]

Originally posted by Shadowdancer:

Originally posted by ZombieHunter:

Code for joystick input is very simple.

ha. Haha. HAHAHAHAHAHAHAAAAHAohman thanks I needed that.

It's not as bad as it used to be in gameport times, but still far from great. And re the throttle thing, please tell that to the House of the Dying Sun dudes who simply gave up after several botched attempts.

It 'shouldn't' be hard with modern APIs. Of course you always have wonderful manuf. who don't implement the API correctly or decide to do something that isn't compatible but those are exceptions. Even gameport code (I assume you are talking about 0x201 port code) wasn't horrible. As long as you had the user move the stick to its extents you could register min / max and compute from there. I've used DirectInput, XInput and the Windows message loop for peripherals and none of it was too difficult. Messages were ugly but still got the job done. Now coding for specific peripherals like X52, etc are a little more involved than that but still not that involved.

Also manuf. are more than willing to assist you if you are wanting you ensure your game supports their device. You could just guess and take shots in the dark or you can go to the source and get help. Nothing wrong with getting some assistance.

[𝟡𝟡𝟡𝕷𝕬𝖅𝕬𝕽𝖀𝕾𝟡𝟡𝟡]

Originally posted by ZombieHunter:

Originally posted by 999LAZARUS999:

Got same issue with my Hotas no way to fix it plz Frontier do something about!
There must be a ghost signal or loop what is caused somehow ingame...

There is nothing wrong with the game code. What is wrong is the devices. Over time the potentiometers in the sticks are subject to wander and become floaty and won't center around any given value. This is a common problem with all pot's not just ones used in PC controllers. So volume knobs, etc can all experience this issue.

This is why all peripherals come with control panels to adjust deadzones to account for the degrading potentiometer conditions. However, you must be careful with deadzones b/c if you set them at the driver level (aka your manuf. control panel) then no game will ever be able to receive any values outside the range of what is in the control panel. It is best to leave the control panel alone and allow for all values to be sent and allow the game's in-game dead zones to account for the discrepancies.

ED has some very nice control settings to handle this. ED is probably one of the best at handling various controllers and has a myriad of settings to handle most any issue.

Note that gamepads won't have this issue on the directional pad but can have the issue on the thumbstick. Anything with a potentiometer will have this issue eventually.

https://en.wikipedia.org/wiki/Potentiometer

There are also digital potentiometers but most peripherals won't have them

Code for joystick input is very simple. Essentially you are given a max and min range and you normalize it 0 to 1.0f. Then when an input comes in, you normalize it and see where it lands on the scale and take action based on that. So if it is less than .5 +/- some fudge factor the stick is left or up and if it is greater than .5 +/- some fudge factor the stick is right or down. Same with rudder inputs. Throttle is simple min is idle and max is full throttle. You can also just use the raw values if you don't want to normalize the values. Every game does it different but the approach and result is the same.

Thanks for your imput but you need more information in the order to get a propper view of the issue i think ^^.


Well my Hotas has only the standart windows 10 calibration settings and thats all about...
All my setting what belongs to the joystick was done in ED.
The Deadzone in ED works pretty good if it would working in this case.
But it simply dont!
This issue must be an issue ingame because a bunch of games even as diagnostic tools show that the joystick works as perfect as possible.
There is no issue in the deadzone at all.
The point is, it makes no diffrence / has no impact when i change the deadzone of explicit this axis from off to 100% and every % between.
So iam seriously sceptic about that the potentiometer should be the answer on this issue.
Even because the signal comes randomly while flying and if i push the joystick in the counter direction it stops turning.
It also isnt possible to provoke the loop signal (steering in to that direction) what usually would provoke an broke or miss set potentiometer.

[ZombieHunter]

If the axis is the yaw then increase the horizontal deadzone. If that doesn't work and no amount of deadzone fixes it your potentiometer is dead. Bad pot's won't just wander they will also spit out spurious values at any given time which causes games to act strange.

If the stick works in other games the only thing I can suggest is to talk to ED support. However, if there was a problem with a Logitech stick like yours and of this magnitude we would have heard about it long ago.

It is possible that the deadzone in ED is not sufficent to account for the disparity in the inputs. So for that you can go to your control panel and use the dead zone for the stick. Then use the deadzone in ED. The control panel will limit the ranges from the driver so the game will never receive those values. Then you can adjust in the game to get even more control over the values.
But if your potentiometers requires this kind of limiting of values then they need to be replaced and/or are defective. But if the stick works in other games this points to something else. It could be drivers although that is a wild shot in the dark or some other peripheral could be interfering with your game.

First step is to disable all peripherals that are not used to play ED. Disable gamepads, wheels, etc. Make sure the only inputs ED receives are from the device you want to use. If that doesn't work mess with the ED deadzones. If that doesn't work mess with the deadzones in the software that came with your peripheral. If that doesn't work then also mess with the ED deadzones. If that doesn't work I'm not sure how to fix it. All of those steps pretty much eliminate everything I can think of that would cause your issue.

My X52 has a physical problem in the cord connecting the throttle to the stick. The short causes spurious inputs to occur and can cause an uncommanded input to get stuck. Thankfully it hasn't happened in battle yet or in an asteroid field.

I hope you can resolve your issue. I feel your pain for sure.

[Laurreth]

Originally posted by ZombieHunter:

It 'shouldn't' be hard with modern APIs. Of course you always have wonderful manuf. who don't implement the API correctly or decide to do something that isn't compatible but those are exceptions

Yeah "should" is always wonderful in development. In reality, when you look at Windows, you currently don't even have a non-deprecated interface to even access joysticks. The only really supported thing is the dumbed-down XInput idiocy for XBox accessories. Even a simple task like retrieving a "friendly" name for a HID-compliant USB device requires two different libraries IIRC (mmsys and something else). Elite and many other games including Unity titles (not sure if Unity sat down and fixed their abysmal input handling at some point) will just go and do raw HID handling and DIY lots of things themselves, which is why Elite comes with a hodgepodge map of VID/PID to human readable, which is hampered by many devices popping up as different numbers when they're managed by software; for CH devices, the buttons change numbers when you do that. And then you often don't have an idea which axis does what when you go beyond a simple stick with X/Y/Z/rZ or where the buttons are. It's really cool.

[Laurreth]

Originally posted by ZombieHunter:

My X52 has a physical problem in the cord connecting the throttle to the stick. The short causes spurious inputs to occur and can cause an uncommanded input to get stuck. Thankfully it hasn't happened in battle yet or in an asteroid field.

If you're any good with a soldering iron, replace the DIN sockets with through-hole 8P8C phone sockets and connect the parts with a length of matching cable. Just put some strain relief somewhere (edit: in case it's not clear, that means hot glue ;-)). Should far outlast what's left of the stick.

[Magnus Chro]

Same issue here with my Logitech extreme 3D pro! Nothing fixes it!

[ZombieHunter]

Originally posted by Shadowdancer:

Originally posted by ZombieHunter:

It 'shouldn't' be hard with modern APIs. Of course you always have wonderful manuf. who don't implement the API correctly or decide to do something that isn't compatible but those are exceptions

Yeah "should" is always wonderful in development. In reality, when you look at Windows, you currently don't even have a non-deprecated interface to even access joysticks. The only really supported thing is the dumbed-down XInput idiocy for XBox accessories. Even a simple task like retrieving a "friendly" name for a HID-compliant USB device requires two different libraries IIRC (mmsys and something else). Elite and many other games including Unity titles (not sure if Unity sat down and fixed their abysmal input handling at some point) will just go and do raw HID handling and DIY lots of things themselves, which is why Elite comes with a hodgepodge map of VID/PID to human readable, which is hampered by many devices popping up as different numbers when they're managed by software; for CH devices, the buttons change numbers when you do that. And then you often don't have an idea which axis does what when you go beyond a simple stick with X/Y/Z/rZ or where the buttons are. It's really cool.

Retrieving the friendly name is relatively simple via the SetupAPI. Just have to get the device info set and then use IPropertyStore interface to query for the friendly name. The friendly name is in IPropertyStore::lpwsz as a WCHAR. I've been working on this exact thing the past few days. The device ID is a combination of the instance ID and the device GUID. But I will admit setup is a mess b/c you have class GUIDs, device GUIDs and other GUIDs. Microsoft admits that prior to Windows Vista and 7 that not all manufacturers adhered to the standard so there are devices that simply don't follow any type of standard and they are hard to interface with via the Win32 USB notifications and setup API. You also have devices that are multi-functional and register a lot of sub-GUIDs under the parent and you get a notification for every one of them which is a PITA.

Now querying for a specific stick or peripheral is a pain b/c you use GUIDs but those GUIDs are not unique and can change between versions of the peripheral which is not fun. Then as a developer you end up forever chasing GUIDs and just when you think you've got it, the company releases yet another version of it and along with it a new GUID. I'm still not sure how to handle this issue as it relates to a few issues I'm working on.

I am currently resolving VID and PID issues related knowing when a certain device is plugged in. It is a pain in the arse b/c I'm finding the ID's are not unique across drivers. So when the data comes in across the message loop after asking Windows for USB notifications it is hard to tell what device was plugged in.

But the GUID and VID and PID have nothing to do with handling the device input. That part is actually pretty simple. Again some peripherals don't play nice and so the final source of info is to go to the manufacturer themselves and ask. I've had to do this a few times when I simply could not get their cool little toy to cooperate with Windows or the accepted Windows way of handling input. These types of solutions suck, though, b/c at any time they could change it to some other non standard way of handling input and then your code doesn't work anymore.