[Alert] Xbox Controllers Axis mapping changed on Win10 since few days...

Hi
We have an issue with the Xbox controller axes since few days on Win 10 (only).
Indeed some axes mapping changed, especially :
- Triggers no more mapped on the 3th axis but on the axis 3 (left) and 6 (right)
- Dpad not anymore on 6 and 7 but on 7 and 8



We reproduced the bug on a lot of unity games using the Xbox controller, for instance :
- Level 22 (Unity 5 - released in January 29th 2016)
- Mechanic Escape (Unity 4 - released in April 15th 2014)

Here are a few threads about this (kind of) issue :
https://www.reddit.com/r/Windows10/...april_updates_kb3147458_and_kb3147461/d2080hw
http://www.neogaf.com/forum/showthread.php?t=1196485&page=4 (with a list of broken unity games)
...

On steam, the Steam Controller work fine on Win 10 with old mapping (even if emulating a XBO ctrl), so it's quite difficult to find a fix/workaround for the Xbox controller without breaking the Steam Controller support...

Do you (Unity tech team) have any news about that ?



If this can help, find some details about the drivers here.
Win 8 Xbox Controller drivers =>

Win 10 Xbox Controller drivers =>

 

Yep,
All was fine few weeks ago, especially as we had a playtest session from the April 4th to the 15th on our game (with Win8 & Win10 PC). Playtesters tried the game with keyboard/mouse; Steam controller and xbox controller and all was ok.
As you know Win 10 updates are silent so I can't tell you exactly when this "driver update" took place (sometimes you need to reboot your computer to apply the update) but it is quite recent.

 

If you want to try (especially the difference between win8 & win10) find here a small repro binary here.
Notice than using it on Win10 the binding is wrong

 

Unless this is some brand new change yet again, this has been around for several months at least on Windows 10 and it applies only to the Xbox One Controller, not X360. It also only applies to Raw Input / Direct Input and not XInput.

 

This definitely affects normal Windows 10 installs. I accounted for it in Rewired in 1.0.0.66 which I released on 8/7/2015. Microsoft's Windows 10 Xbox One HID driver changed the mappings and split the triggers into separate axes which caused other shifting. I don't know why the OP is reporting this as a new change though. Perhaps he had Windows Update disabled?

 

Hi
Thanks Guavaman for this input... But it's really weird because we had this "issue" very recently on our normal Windows 10 installs (with auto-update enabled). Maybe this Xbox One HID driver update was delayed here in France...
Anyway, we bought Rewired and created a wrapper for our input system so now we have a proactive inputs provider service for this kind of topics (Rewired ).

 

Unity, please fix this issue

 

They're going to revert the driver change?

 

Okay thanks for the update. I guess I will deal with it when it comes out. I hope they fix a couple of other major bugs I discovered with the Windows 10 driver (one that crashes the system after the device is disconnected when used with Raw Input.) Thanks!

 

I find it highly suspect that Microsoft broke this unintentionally, otherwise it would have been corrected quickly. And why is the issue not present in other engines? It seems much more likely that the Unity engine is handling the XBO controller in some way that it shouldn't. In other words, I don't think we're getting the whole story here.

 

This only affects games (or engines) that use Raw Input for these controllers. If it uses XInput, it has absolutely no effect. Unity appears to use some kind of hybrid mix of Raw Input and XInput for XInput-compatible controllers which would be the reason it is affected by this change and also the reason for some other serious problems with their XInput controller handling. See this post of mine for a more complete explanation.

I also find it hard to believe it was an accident as it actually makes the controller more usable and is a very welcome change from the crippled Raw Input / Direct Input support XInput-compatible controllers have had this whole time. For the first time ever, the triggers work as one expects they should. And without having to use XInput for this, you can use more than 4 gamepads at once. Vibration still isn't available without XInput, but otherwise, I find the new behavior much better than the old.

 

Any update to this?

 

I've had no issues since the W10 anniversary update.

 

This year I thought: finally i can use XBOX controllers to have a baseline of universal compatibility for windows and bought me a set + dongle. Then i plugged my game to win10... NOPE

Also: That is really stupid, why would you link both triggers onto the same axis? Wait, i know: Racing games... which brought us those useless Analog triggers in the first place. Ok, at least the trigger-axes appear separated later on, i think on axis 9 and 10.

Is there any other game where a Trigger is even useful and to be appreciated against a good old button with real feedback? I even heard that pro-racing-game-players don't even use the triggers for ac- and deceleration and rebind that inputs to face-buttons

I think i should stick with my rebind routine which will cost me a bit of accessibility instead of trying to cater all those different Assignments on whatever platform, so i can use any input source if the player is capable of setting it up.

 

MS addresses it here:
XInput and Direct Input

The independent triggers mapped to Unity axes 9 and 10 are obtained by XInput internally. However, because Unity does this by associating a HID device to an XInput device, it is prone to errors because there is no reliable way to associate a HID device to an XInput device id. (I don't have a link but there are several threads about triggers on one joystick registering as triggers on another joystick. This only happens with multiple XInput devices attached.)

 

Thanks for the info man, i cannot imagine the pain you have undergone to tinker up Rewired to it's current state...

I just coded a crude Unity Wrapper to quickly rebind my mandatory 2-axes and 6-keys in-game without fiddling around in a table of buttons, i am quite happy with it.

But some situations are hard like when you bind the DS4-Triggers in Bluetooth mode you get an Axis that from -1F to 1F for the Trigger but those triggers have also a button linked to them.

As soon as the DS4 starts to send its gyro-values to Unity i quit, detecting an axis input while the gyro and accelerometer rape your input detection is yet another edgecase...

 

It's been pretty much a full time job for the last 2.5 years (a lot of that time is spent on support). Desktop input hardware is seriously like the wild west. Taming it has been a serious feat.

 

Thanks for taming all of the controllers so we as Rewired users do not have to worry about fighting that battle.

For Rewired users it is like riding in the Wells Fargo Stagecoach and not having to worry about all the bad things that could happen in the wild west.

 

honestly, Unity, I'm sick of your crap.

I had the *DPAD* working perfectly in my game. It's two player so eventually I threw on another controller via bluetooth.

First of all, the axis CHANGES based on the type of controller you put in, and it also changes based on whether or not you're using that controller through bluetooth or cable--and it ALSO changes based on whether you have one or both connected!! How can you possibly ship a game confidently knowing something like that happens??!?!

I'm beyond frustrated with unity at this point. How can something as simple as a DPAD be so impossible to deal with?! And why on Earth would it change based on using Bluetooth or cable??

 

And how is it possible that an axis changed on a button that has a name that belongs to the other player, somehow effects the other player's joystick??

I have "horizontal_1" and "horizontal_-1"... horizontal_1 is supposed to only change logic (and frankly only exist in) the script for player one. And I'm ensuring player one's "horizontal_1" button has joystick1, and player 2's "horizontal_-1" button has joystick2. Imagine my surprise when editing player 1's Joystick1 axis through the gambit BECAUSE IT'S A GUESSING GAME, player two suddenly starts to move!!

HOW!!? WHY!?!?! Unity, you guys have wasted my entire day on this, and I see no end in sight!

 

Cheezes calm down man, one day wasted is NOTHING when programming Input.

Also, afaik Unity can do nothing to correctly enumerate Gamepad buttons and axes, it totally depends on the OS and hiw the manufacturer enumerates his controller axes. Nothing you can do about that except if you identify the id of the gamepad and know its OS specific enumeration.
Rewired does that i believe, but the way i do it is to make the user assign all inputs in a special assignment routine one after another with visual feedback.

 

It's such a weird way to account for things. Could have all been averted if they gave us a simple boolean "use as button", instead of dealing with random axes.

then we could just say "if dpad right button, transform.forward * speed" instead of writing topsy turvy nonsense and hoping and praying the user can even play the game right. My frustration stems from first thinking I slayed this beast, but was rudely awakened by the fact there are a whole new set of rules for 2 controllers and the way in which they get connected on both relevant joysticks.

edit: or even victim to an operating system update, like the OP noted.

 

You're expecting features that their input system has never provided because it wasn't ever intended to. Their input system is just a thin wrapper on top of what the operating system input API provides. Most operating systems and HID devices do not give you any information about "sticks" or buttons by name. They simply provide a list of numbered buttons, axes, and sometimes hats. And the mappings of those buttons almost always change on different platforms because no two OS's input systems work the same way with regard to how they expose elements on controllers.

Hardware manufacturers basically do zero standardization (apart from Xbox controller clones). The fact that a controller maps differently when connected wirelessly and wired is the hardware manufacturer's doing. I've spent the last 4.5 years standardizing a wide variety of input devices across over a dozen platforms. It's a huge job. Therefore, if Unity were to provide a system where your controller just works across platforms, they have to do what I have done and get every device in-hand, make hardware definitions that bind the disparate numbered axes and buttons to identifiable elements for every single platform and input source they want to support, match the current detected device to those definitions, then load a mapping so you can access things in a standardized way. (There are many devices this can never work for because of the aforementioned lack of standards in the hardware sector.) This is an entire additional level on top of the low-level input system that Unity's current system provides. They're doing exactly this with their new input system. For most developers who want to ship games with proper joystick support, there are other options out there like Rewired.