When testing controller input on the Mac, it works fine from the Unity editor (and Web Player).

However, if you make a native build for Mac, controller input does not respond at all, even if calling for any joystick (as opposed to something like joystick1 ).

So far, a 64-bit build was tested. A 32-bit build was not tested yet.

Update: Bug not present in 32-bit native Mac builds. This bug affects Mac 64-bit builds and Mac Universal builds.

Hey JISyed, thanks for making such an awesome plugin. I have a blast using it for my project. I chose for your solutions since it allows for re-connecting to the same 'player' once one or more controllers are disconnected. However, I would like to have a callback function which I could use to change the amount of players for example when someone connects or pause the game if someone disconnects. I would also be able to implement this myself if I had access to the DLL. But sadly no source code is given so I think I won't be able to just yet. Now I have solved the problem by polling for a number change which is extremely ugly. I'd love to hear from you.
Greetings, Peter

In Windows, XboxCtrlrInput is relying off XInput.NET to handle controller input for Windows.

But when upgrading to Unity 5, the following exception pops up:

DllNotFoundException: XInputInterface

This error is due to an incompatiblity between Unity 5 and XInputInterface.dll, which is a library provided by XInput.NET.

Until XInput.NET becomes Unity 5 compatiable, this problem cannot be fixed.

As is, everything should still be working in Unity 4. If not, please submit a new issue.

I've spent a while now digging through all of the inputs in the InputManager and can't seem to find which parameter changes the actual right stick dead zone when using the XCI.GetAxis(). If I call Input.GetAxis() then the dead zone is accurate but there are discrepancies between which controller Input thinks is the first player and which controller XCI thinks is the first player.

Hi,

I was having problem with deazones because they are being calculated in an axial way (as explained here).

The code:

// Note: the variable "rawAxisValue" represents the value of a single axis
// Clear axis value if less than the deadzone
if(Mathf.Abs(rawAxisValue) < deadzone)
{
    finalValue = 0.0f;
}
// Remap the axis value from interval [0,1] to [deadzone,1]
else
{
    finalValue = (Mathf.Abs(rawAxisValue) * (1 - deadzone)) + deadzone;
    finalValue = finalValue * Mathf.Sign(rawAxisValue);
}

This was producing a sticky effect in the cardinal directions.

I investigated the code further and discovered that for Windows platforms the deadzone was already being applied in the XInputDotNetPure lib (with radial deadzone), so I set all the deadzones to 0 in the InputManager and now everything works OK, but I don't know what'll happen in other platforms.

Maybe the library should add radial deadzones as well, and probably a flag to let XInputDotNetPure handle the deadzones, for Windows at least (it uses constant deadzones values btw).

For some reason under osx the GetAxis on the left and right triggers return 0.5 until you press their triggers respectively.

Currently I 'hacked' around it by returning 0 in the refactorRange if the input value is 0, since the Input.GetAxis for unity returns this value.

Any idea if it's a input manager setting that needs to change or something? I'm using the one provided with the library.

More a problem with what this plugin is based on than the plugin itself but vibration in the tests I've run has spontaneously stopped being reliable. Sometimes controller vibration acts normal and responds appropriately, other times it doesn't respond at all, vibrates longer, twice as long, waits a while and then vibrates, and other variations of those. My code for handling vibration hasn't changed, and my changes to my project file haven't affected it after removing them for testing. Vibration was working perfectly before.

My theory is this is from some Microsoft update or some driver problems, buffer overflows, problems between the plugin base code and the hardware.

Another theory is my handling of vibration was sketchy to begin with and it's a miracle it worked so well. I'll be looking into this tonight. (And if this is what's happening I'll let you know here.)

I'm gonna try to fix this before June 17th, and if I don't I may omit the confusing vibration from my game for now. Thanks if you attempt to look at this with me, I'd really appreciate it.

In Windows, the Web Player does not recognize controllers connected during the game's run. 4 situations have been evaluated and none of them work:

1. If any joystick disconnects and you reconnect it.
2. If all joysticks disconnect and you reconnect them.
3. If you start the web game, then connect any controller.
4. If you connect additional controllers during the web game's run.

I suspect this is either a limitation of the Windows drivers for Xbox controllers or a limitation of the Windows' Web Player's implementation of joystick input.

The best work around is to be sure all the controllers you want to connect are connected before you start the web game, and make sure none of them disconnect.

Hi, I have installed the latest controller drive and tried the example project in Unity 2018.2.1. The input works in Unity Editor, but not working in standalone build, please check.

Hey,

The xiPrevFrameCount is initialized to 0 meaning no input is polled on the first frame when checking XInputStillInCurrFrame()(xiPrevFrameCount will be equal to current frame)

Sorry I don't have time for a pull request, I'm doing a game jam. I just hacked it to -1 and it worked fine.

Also having an IsPluggedIn method was helpful for me in XboxCtrlrInput.cs

        public static bool IsPluggedIn(int controllerNumber)
        {
            if (!XInputStillInCurrFrame())
            {
                XInputUpdateAllStates(); //XInputUpdatePaticularState(controllerNumber);
            }

            GamePadState ctrlrState = XInputGetPaticularState(controllerNumber);

            return ctrlrState.IsConnected;
        }

Cheers

I got this message, but I only have 1 XONE controller connected.
Otherwise seems to be working fine on Unity Editor with XONE controller.

The Xbox 360 controller has a player indication light which ideally tell you the controller number. Unfortunately, Unity doesn't listen to this at all.

For example, the joystick shown above says that it's connected to the computer as controller # 2. However, when testing this controller in a Unity game, it's very likely that this controller won't move player 2 (whose green in my demo scene).

From my test, it depends on an unknown order in which you plugged your controllers. I've seen controller # 2 move player 1 (the red character in my scene) when I had two controllers plugged in. Although I was testing this on Windows, I'm sure the same problem will occur on other OSs.

The best work around for this as of now is to simply ignore the player indicator light on the Xbox 360 controller when playing Unity games. Unfortunately, I'm sure this will annoy end-users.

In the latest released version, the function "IsPluggedIn" requires a parameter of type int. It would be nice if the function allowed for us to use the enum XboxController.

There is a work around where you can simply cast the enum to an int. You'd have to be careful about
"XboxController.All" though.

The axis mapping for the Xbox 360 controller using Unity is currently unknown. The only axis that works as expected are the ones on the left stick (LeftStickX and LeftStickY).

Testing on Ubuntu 13.04 using a Linux player build from Unity 4.2. Using Ubuntu's default xpad drivers, not xboxdrv drivers.

D-Pad input doesn't work as expected. Wired controller has 2 axis for D-Pad while wireless controller used 4 buttons. For wired controllers, one of the axis is swapped and the other is unknown.

Using Unity 4.2 editor on Windows having multiple Xbox controllers plugged in, both the left and right triggers on all controllers act weird.

For example, pressing the left trigger on one controller doesn't do anything, but pressing the left trigger on all connected controllers at the same time moves the left triggers in the demo.

It must be noted that I'm using Axis 9 and 10 for trigger input on Windows. I'm not using Axis 3.

This bug only occurs when getting trigger input from a particular controller when multiple controllers are plugged in. The bug is not present when only one controller is plugged in.

On Linux, a native build will not recognize wired controllers if plugged in during the program's run. 4 situations have been tested, and none of them work:

1. If any wired joystick disconnects and you reconnect it.
2. If all wired joysticks disconnect and you reconnect them.
3. If you start the Linux build, then connect any wired controller.
4. If you connect additional wired controllers during the Linux game's run.

The best workaround is to be sure all the wired controllers you want to connect are connected before you start the Linux game, and make sure none of them disconnect.

This problem does not exist for wireless controllers. That assumes that wireless controllers disconnect by means of having the battery removed. That does not assume that the wireless receiver was unplugged. If that's the problem, you will experience the same issues as for wired controllers.

"error CS1704: An assembly with the same name `XInputDotNetPure' has already been imported. Consider removing one of the references or sign the assembly
Assets/Plugins/x86/XInputDotNetPure.dll (Location of the symbol related to previous error)
Assets/Plugins/x86_64/XInputDotNetPure.dll (Location of the symbol related to previous error)

Compilation failed: 1 error(s), 0 warnings"

So i can't compile on unity 5.6 .. :/ ( i'm on windows , target plataform: Standalone windows )

I'm running Unity 5.0 and OSX 10.11.3. After installing the newest release of 360Controller I can see the controller working fine in the Preferences Pane but not in Unity. Adding the following near the initialization of the controller gives me back a '0' result. Any thoughts on what might be causing the issue?

        print (" Num plugged controllers " + XCI.GetNumPluggedCtrlrs ());

I get the following error when I try to build a windows player (both for x86 and x86_64).

error CS1704: An assembly with the same name `XInputDotNetPure' has already been imported. Consider removing one of the references or sign the assembly
Assets/Plugins/x86/XInputDotNetPure.dll (Location of the symbol related to previous error)
Assets/Plugins/x86_64/XInputDotNetPure.dll (Location of the symbol related to previous error)

Compilation failed: 1 error(s), 0 warnings

I have tried removing both from the project separately. Removing x86 allows the build, but the player doesn't pick up the connected controllers. Removing x86_64 throws a dozen errors and won't allow a build.

I have also tried selecting exclusively either x86 or x86_64 on each of the dll's in editor, however this does nothing to change the original error.

I have also tried recompiling my entire library, as suggested on unity forums discussing error CS1704, but that also has no effect.

Any help would be great.

PS. Thanks for an otherwise great plugin!

In the Unity editor and player for Windows, if a controller gets unplugged, and then you get the controller plugged back in, Unity will map the controller to a different player number.

In a test, I had two controllers plugged in, then I opened the Unity project. I ran the demo scene and controller mapping generally worked ( if you ignore the controller number indicator light, see issue #5 ). What I mean by "worked" is that there are two controllers plugged in, and one of them moves player 1 (the red character) while the other controller moves player 2 (the green character).

Now suppose I stop playing the scene, but I still have the Unity editor open. I unplug one of the controllers (in my test this controller was wired and moving player 2) and then I plug it back in, on the same USB port. Then from the editor, I play the scene again. Take note that I only have two controllers plugged in. What will happen is the controller that I "re-plugged" will no longer move player 2, but it will move player 3 (the blue character). In other words, Unity changed its mysterious internal controller mapping when I unplugged the wired controller.

Unfortunately there's no good workaround for this, except to restart Unity or the built game.

From my testing, this problem doesn't appear to exist for wireless controllers. That assumes the wireless controller was turned off by removing the battery and turned on again. It will work as expected. The problem explained above only occurs for wired controllers.

Can't find anything on getting the vibrate to work with these controllers? Am i missing something? It's driving me nuts

This is more a curiosity than a problem, since putting
int queriedNumberOfCtrlrs = XCI.GetNumPluggedCtrlrs();
inside void Start() seems to negate the effect.

But without that int, functions inside, say, if (XCI.GetButtonUp(XboxButton.Start, controller))
fire on awake.
You can test this by commenting out MovePlayer.cs's int queriedNumberOfCtrlrs related code, and then enabling the MovePlayer script in play.

If nothing else, I hope this helps someone else, since it took me a while to narrow down what was causing this to happen.

Hello,

When trying to build to Mac OS for x86 or x86_64, I get the following error:

Assets/Plugins/XboxCtrlrInput.cs(3,7): error CS0246: The type or namespace name 'XInputDotNetPure' could not be found. Are you missing an assembly reference?

The same unfound namespace error occurs for
GamePadState
ButtonState
GamePadTriggers
GamePadThumbsticks

I'm using Unity 5.5.1f1, and I'm on the latest release of XboxCtrlrInput (v1.6.2).

Thanks for any help.

I did not see it in the Docs but maybe I am missing it. If not, will there be support for vibration/rumble in the future? Huge fan of this repo, by the way..... it is a lifesaver. Unity's built in input system is not intuitive. Or can I implement vibration in a different way? Thanks.

In Linux, the input-mapping for the Xbox's D-Pad is significantly different. If the controller is wired, Linux treats the D-Pad like two axis. If the controller is wireless, Linux treats the D-Pad like four buttons.

Because XCI is looking for axis input for the D-Pad on Linux, it won't work with wireless controllers.

A fix is possible, and will be underway. I can't guarantee that the fix will be memory-efficient or that the fix will come soon.

This bug was discovered after testing Linux builds made with Unity 4.2.1 on Ubuntu 13.04 64-bit with the default xpad driver.

When testing a Linux build on Ubuntu 13.04 with whatever the default Xbox driver is, calls to XCI.GetButtonDown() are being treated like XCI.GetButton(). They use Unity's Input.GetKeyDown() and Input.GetKey() respectively.

Pressing the buttons continuously spews lasers as long as I hold those buttons down. What's suppose to happen is that I press a button down and it shoots a bullet once, and only shoots again if I press down the button again.

When using XCI on a Windows web build, getting trigger input with multiple controllers plugged in will not work properly. What might happen is that trigger input will go though only if all triggers on all controllers are pressed down, but your mileage may vary.

The reason this is a limitation and not a bug is because of the way Microsoft implemented DirectInput. It severely limits trigger input on Windows.

XInput is usually seen as the solution to this problem, except it won't work for web builds. XInput is already implemented for native builds because native builds support plugins while web players don't.

The good news is that having one controller plugged in doesn't seem to have any issues with any input, including triggers.