Rewired - Advanced Input for Unity

My suggestions would be.

(1) Ask Logitech to support the version of Unity that is being actively developed since 4.x is not supported that would be Unity 5.x series only and do not worry about 4.x. That is Unity 5.x and more specifically 5.4.1 or later and that is only one version to support.

(2) Ask Unity racing game asset store developers like iRDS ( @rhodnius ) and RGSK ( @Intense_Gamer94 ) and other racing car game asset developers to request Logitech support an updated FFB plugin (Logitech Gaming SDK). Any other developers working on racing games should be included also. So at least that will give Logitech a better business case to make the decision to provide support for an updated force feedback (FFB) plugin via the (Logitech Gaming SDK : https://www.assetstore.unity3d.com/en/#!/content/6630).

 

I haven't looked into this myself, but does the plugin still work on Unity 4.3? If so, might it be possible to figure out what's causing the plugin not to work in 5.4? If the plugin uses extern calls to the Logitech FFB DLL, it seems it would be possible to fix as long as the issue isn't inside the native DLL itself.

Would having access to the Direct Input FFB API work? Or are you looking for something more like Logitech's implementation with pre-programmed FFB patterns you can choose from and play back? I've thought about adding the DirectInput FFB API to Rewired, which is also very similar to the OSX I/O kit FFB API as well as the Linux one (both of those were based on the Direct Input implementation.) Providing a standardized way to communicate with the low-level API would be potentially doable, but I think trying to come up with a more high-level abstraction that would work cross-platform and across various FFB device types would be a ton of work.

 

The plugin works fine 4.3 and I do not recall anyone complaining about it in 4.x. The asset store says it was uploaded with Unity 4.3.1.

 

@guavaman

It just tried the example (included in the Logitech SDK) in Unity 4.6.6_f2 and it appears to work with the G27 wheel I have.

 

I just took a look at the SDK and see that all the setup happens inside the native DLLs so there's no chance of changing how it works with relation to Direct Input, window setup, etc. which is probably where the crash is occurring.

 

Pretty sure the crash was due to the difference in properties between G29/290 and the older G25/G27.

 

I guess there were really 2 different crashes being discussed, one being a crash on stopping Play mode in the editor and one being when LogiSetPreferredControllerProperties() is called. Sorry, I looked back and see you were only having the crash with the properties and not exiting Play mode.

 

Hi @guavaman
Rewired has helped so much in getting various controller support into my game in no time at all. So first up thanks for making such an amazing plugin!

I've run into a slight hiccup which I'm hoping you might be able to shed some light on. I am using Rewired to handle Keyboard/Joystick/Mouse controls, along with a Custom Controller which I activate only when I want to handle Touch Input on mobile devices. Essentially, as soon as I detect that the touchCount is greater than 0 then I set a dummy variable in my custom controller so Rewired switches over to Custom Controller mode (detected via GetLastActiveController()).
I'm not sending constant variables through to the Custom Controller, only sending that initial dummy variable and using it as a way to let Rewired know I am using my own touch script for input now.

Using Unity Remote, all input swapping works 100%, which can be seen in the video provided.
https://dl.dropboxusercontent.com/u/38359024/Project Chicken/Input Example.mp4
As soon as I build to device however, when touching the screen it uses touch for a moment then switches and stays in Mouse mode.

My only thought is that Unity is causing the touch events to send through mouse events as well which gets picked up by Rewired, causing Rewired to think I am using both Mouse and Touch at the same time?
I have set simulateMouseWithTouches to false, and still no luck, although from what I have read it seems that only applies to click events?

Any input on this would be appreciated Whether it is something to do on Unity's side, or if there is something I am overlooking in Rewired.

Thanks!

EDIT
Should also mention that I have tried locking the cursor when in Touch mode, still no luck.

 

Thanks! I'm glad you like it!

Exactly. Rewired uses UnityEngine.Input on Android/iOS -- I assume one of this is your target platform. I know of no way of disabling mouse input in Unity. Rewired doesn't have an option for disabling the mouse.

Your best bet is either:
1. Assume there is no mouse on your target platform and consider the last controller to be touch if it's either mouse or touch, in which case you can just remove your Custom Controller.
2. Determine which controller was used last yourself instead of using Rewired's methods. Every Controller has a GetLastTimeActive method as well as various other methods for determining this.

 

Awesome, thanks for the idea.
While your first point would be a good quick workaround, unfortunately I need the differentiation between touch and mouse for onscreen prompts. And as this will also be available via Windows Universal, some people might be on a Surface tablet device and have access to both mouse and touch.
Will give option 2 a try though! Thanks

 

Currently the game supports G25, G27, G29 and Thrustmaster T500Rs (becsuase these are the wheels I own or could get my hands on.) Im rebuilding my latest FFB title from the ground up right now and will be making an "official" list of supported hardware soon. I am going to be doing a closed beta on steam in a few weeks to gather all default controller settings for the revamped title.

I did not do this on my last title and just let the customer "setup" their own controllers. That was a nightmare so I am trying to wrinkle out all the bugs for them. Apparently not everyone loves controller configuring as much as we do? hahaha

 

Everyone should love controller configuring.

That is an impressive set of wheels you have access to. Are you be using the racing game templates in Rewired or just your own "game defaults" for each specific wheel?

 

Working on remapping keyboard/controllers at runtime, I've looked at the included example but might have missed this..

I'd like to have it so player 0 uses the keyboard, and players 1, 2, and 3 use joysticks. This is doable with setting player.controllers.excludeFromControllerAutoAssignment.

My issue is if player 0 already has a controller assigned, and now chooses to use the keyboard he will receive input from both. What I'd like is to disconnect the controller from player 0, and reassign all the controllers following the new rules set from excludeFromControllerAutoAssignment.

I found ReInput.Reset(), but that resets excludeFromControllerAutoAssignment back to default.

Is there a method somewhere to disconnect all players, and then reconnect them?

 

ReInput.Reset is absolutely not the right method to use. As stated in the API docs, that resets Rewired completely, invalidating all stored Rewired objects and reinitializing all input sources.

No, there is no method to remove all joystick assignments and keyboard maps from all Players. That is not something that one would want to do in most circumstances. You can do this yourself easily if you understand Joystick and map assignment.

Joystick assignment:
http://guavaman.com/projects/rewired/docs/HowTos.html#assigning-joysticks

Map assignment:
http://guavaman.com/projects/rewired/docs/HowTos.html#managing-controller-maps-runtime

However, I would not do as you are asking and reassign all Joysticks once a Player chooses to use the keyboard. If some user has chosen to use a specific Joystick, this would remove his Joystick assignment and re-auto-assign potentially causing his Joystick assignment to change to a different Joystick.

It seems to me that the only thing you would need to do is remove the Joystick from the Player, load the Keyboard Maps into the Player, set player.controllers.excludeFromControllerAutoAssignment = true, and then auto-assign any unassigned Joysticks, not remove Joystick assignments from all the other Players.

 

@guavaman Thanks, that sounds like it should work.

How do I auto-assign all unassigned Joysticks? ReInput.controllers.AutoAssignJoystick(joystick) as shown in the link above doesn't seem to exist anymore

 

If a method in the documentation does not work in your code, then you are using an outdated version of Rewired. Update Rewired from the Asset Store and it will work. No methods have ever been removed from Rewired.

Updating Rewired

 

I'm trying to change the autoAssignJoysticks property at runtime (ReInput.configuration.autoAssignJoysticks). I am able to change it but I can't figure out how to save the setting.

Is there a way to change and save the joystick auto assign functionality at runtime?

 

What do you mean by save the setting? No changes you make at runtime can ever be saved in the Rewired Input Manager serialized data. If your goal is to create an option for the user to be able to set that variable, you will have to manage the setting manually by saving the value to some data storage system (Player Prefs, etc) and setting the value when the game starts based on that saved data.

 

Thanks for the response, I should be able to manage.

 

The problem I'm having is rewired won't remember which gamepad is assigned to which user. If I have my flightstick and xbox one controller plugged in every time I start my game I need to unassign the flight stick and reassign the xbox controller. I thought this was happening because it was automatically assigning gamepads, but since I've turned that off now it's unassigned every game.

Is there a way to remember which gamepad was assigned?

 

No there isn't. That's a much more complicated issue than it sounds like it would be, especially on PCs.

Rewired doesn't save a single bit of data on its own. If you use the UserDataStore_PlayerPrefs component, for example, if you're using Control Mapper, then that component saves controller mappings to Player Prefs, but even that does not save controller assignments.

 

Hmm.. I really want to fix this issue. Would I be able to get the names of the gamepads currently assigned (and who they are assigned to) save them in the player prefs, then when the game starts up again check the player prefs, check the gamepads plugged in, and assign them to the previous users? Or is that crazy?

 

The problem is, the controller name does not provide enough information about the controllers to do this. If more than one controller of the same type is plugged in, names won't help. System GUID's or paths (which are not available through the Rewired API) do not help either because these are not guaranteed to be the same from plug to plug or reset to reset. And when XInput is put into the mix, all bets are off because there is no way possible to determine which controller is which out of the 4 supported XInput controllers if multiple controllers are connected regardless of whether they are the same or different types. If you were to try to use the XInput id, again this is not the same from reset to reset.

 

I think to solve this issue I'll need to change how controllers are assigned to players. Instead of automatically asigning them I'll listen to which controller is used first and assign it to the player that way. That should solve the problem the player reported.

 

Yes that would be required if you are going to do manual controller assignments, which would be required to implement any kind of controller assignment persistence. Here's documentation on assigning controllers: http://guavaman.com/projects/rewired/docs/HowTos.html#assigning-joysticks

There really is no really good to do controller assignment persistence on PC platforms. You can consider using the Joystick.hardwareIdentifierString property as a means of unique identification, but as mentioned before, XInput will cause headaches.

 

Since updating Rewired, I have found there is a bunch of new controller templates for me to configure. (Which is AWESOME Thanks Guavaman). So I will just be using the default templates as a start but I will also be making a tutorial in the start of the game to show the user how to simply add a button or and axis. The templates are just a little too generic for my users. haha. I wish it were that easy. (Read to the bottom and ill explain it more clearly)

Side Note: This might help some of us Wheel/Pedal users in the Rewired Community.
I have always found that a simple GUI in the start of the game that just asks (one action at a time) what axis/button the users wants to use is the smoothest way to do it. That way everyone can setup their wheel/pedal combo the way they want. I have really always liked the way iRacing has done this. That way if you have 4 controllers plugged in you dont rely on any template. On one of my test machines I have 5 different controllers from five different manufacturers running at the same time... its silly.

a simple Example would be like this...
Game starts.... Car cannot move yet.
Gui pops up.
- What axis do you want to Steer with? (User moves wheel) (Game maps Controller 1 axis to Steering Action)
- What axis do you want to Brake with? (user moves Brakes) (Game maps Controller 2 axis to Brake Action)
- What axis do you want to Clutch with? (user moves Clutch) (Game maps Controller 2 axis to Clutch Action)
Etc...
Car can now move.

THe reasoning behind this, is that today there are 1000's of different Wheel and pedal combos. People are using X pedals with Y Company Wheels and then throw in a homemade USB Dongle Handbrake. Add in a couple button boxes and all those templates are pretty much useless. Sim Racers can have 4-5 controllers for a average rig and up to 10 on a fancy rig. Thats kind of why I feel the "Ask the user" method seems to work best.

Kevin

 

It should be noted that controller templates are developer-only. They are not for user mapping usage. When Controller Maps are loaded, they are converted from the template map to a native map for that device. The template no longer has any relationship to the runtime Controller Map that was loaded from it. The user cannot modify the developer-defined template mappings. If you were to display a list of elements on the controller for the user to map, it would not be a list of template elements -- it would be a list of elements on that specific device.

The way Rewired's templates are designed to work is this:

• The developer creates default mappings for any controllers they wish to "just work" out of the box.
• Templates are simply a shortcut to prevent the developer from having to create mappings for every supported device.
• When more devices are added to Rewired, you don't have to make mappings for those controllers if they're covered by a template you've mapped.
• Creating a mapping for the specific device will override the one created for the template.

Documentation for controller templates is here.

On the end-user side, if a controller is not recognized, simply provide way for the user to remap their controls such as Control Mapper. Those wheels/pedals that are recognized will load the default developer-defined mappings if any exist. Those that aren't recognized, the user can map.

Various combinations of pedals and wheels is rarely a problem. If the wheel is recognized, the developer default mappings will be loaded. If the pedals are recognized, those mappings will also be loaded. If one or the other isn't recognized, the user can map just that one that isn't recognized.

There's no disadvantage that I can see to using the templates or to providing developer default mappings.

In your scenario, you're basically starting from the perspective that nothing is recognized. That works, but why do that when you don't have to?

 

It works just like @guavaman mentioned in his post. ( https://forum.unity3d.com/threads/rewired-advanced-input-for-unity.270693/page-51#post-2825155 ).

As a developer the Rewired racing templates saves me a ton of time only have to map once for the racing template (as a developer) and then give the users the ability to remap everything they need with ControlMapper. Not having to worry about if the user is using Logitech (G25/G27/G29), ThrustMaster (F430/T100/T150/T300RS/T500), Saitek Farm Sim wheel or Fantec Porsche 911 Turbo S wheel is a huge blessing. Thanks to the Rewired Racing templates I can spend more time doing fun things like working with the Rewired Flight Simulation Templates.

 

The best part about the Racing Wheel Template is that it applies to both the wheels and the pedals even if they are separate devices. So if a user were to pair a T300 RS with Saitek Heavy Equipment Wheel and Pedals, it would just work without any user configuration because both are covered by the same Racing Wheel Template map.

 

Hey Guavaman,
I have a bunch of players reporting XBox One controller is no longer supported after the Win 10 Anniversary update. The game reads the controller as XBox One in the config, but the buttons and axis' never register. This is very bad as a lot of VR owners get an XBone controller with their CV1.

I have read on the troubleshooting side of your site that I should be contacting Windows for a fix, but I don't think thats very feasible. What should I be doing to get the controller working again? Can Rewired not create a separate profile for reading XBone pre and post Anniversary Update. I realize it is completely obnoxious on MS's side, but we can't take that out on the players. Otherwise, great product.

Cheers,
Ryan

 

Check your Rewired version. Windows Anniversary Update workarounds were made in 1.0.0.95. The controller generally works, but has some lingering issues as noted in the documentation. Also, are you using Use XInput?

If it were possible to fix the remaining issues, I would have done so. I put an extremely high priority on fixing issues like this, especially on controllers so prevalent as the Xbox One Controller, and even when they are underlying system/driver issues and not Rewired issues which these are. The issues described in the Known Issues page are absolutely unfixable at any level but the driver and/or XInput level. I have put in more than an entire full time month of time working on the issues surrounding the Xbox One controller trying everything under the sun to find workarounds. What I have been able to workaround has been implemented in 1.0.0.95+. Any issues remaining simply cannot be fixed by band aids at the higher level. These are things that I have no control over unfortunately as the software I develop is dependent on the underlying operating system and drivers working correctly. This really is a Microsoft issue.

 

I am on 1.0.0.104, still no luck. What am I supposed to do? Are there bootleg XB1 drivers I can tell my players to install that wont break their other games?

Most of them report that all their other games seem to work fine other than mine, which is assuming because mine is the only one using Rewired.

 

99% of games use XInput. Are you?

I can guarantee you Rewired is not the only system that has problems with Xbox One controller post Windows Anniversary Update.

 

I am not using XInput, brb.

 

Post WAU, I implemented a completely new system to read the Xbox One Controller when not using XInput because Microsoft completely broke Raw Input support (I reported this to them and sent them a repro case in a new C++ project.) If controller elements are not registering when XInput is disabled, then these devices are being locked by Windows for an unknown reason. There aren't any more workarounds possible in this area to make these devices work without XInput. (If your game is one player, increase the max controllers per player to > 1 in case the controller shows up twice, which can happen when two versions of the driver get installed simultaneously.)

The only solution would be to enable Use XInput. This is the prescribed way of working with Xbox-compatible controllers anyway. It seems like Microsoft must have only tested XInput functionality based on the many critical errors I've found when trying to use Raw Input with these devices even in the first 2015 Windows 10 driver update (including a fool-proof way of crashing the system by unplugging a controller, also reported with a repro case but they took a whole year to address it.)

 

Initial tests with XInput have the XBone controller working again. Fantastic, thanks for that suggestion.

So does that mean your "known issues" posts in regard to the XBone only apply out of XInput? I had disabled it because I had assumed I would get better compatibility, and everything was working fine up to that point. Are there any issues I should know about when running XInput before I ship a patch?

Thanks for the lighting turnaround, thanks for the product. I only echo my players frustrations, so apologies for coming at this aggressively.

 

There were many complaints about XBOX ONE Controllers failing after Windows 10 anniversary update.

http://www.eteknix.com/windows-10-update-breaks-xbox-controller-support/

http://www.pcgamesn.com/microsoft-windows-10-anniversary-update-breaks-xbox-one-controller

https://www.vrfocus.com/2016/08/ocu...th-xbox-one-controllers-due-to-win-10-update/

http://answers.microsoft.com/en-us/...y-update/3ccd95ba-a7cd-49e2-933f-75f9f5200229

There were similar problems in March 2016.

http://www.infoworld.com/article/30...ox-one-controller-forces-microsofts-hand.html

 

We also get the ThrustMaster shifter I believe also. So this is controllers for nothing and the mapping for free with the Rewired templates.

 

No, they apply with XInput as well. (If you're referring to the mapping differences between pre and post Windows AU, that only applies when using UnityEngine.Input as the input source as stated on the case in the Known Issues page.)

The other two issues stated in Known Issues occur without regard to Rewired even running. They're issues related to hot-plugging Xbox One controllers in Windows 10 post WAU.

You get worse compatibility overall when disabling XInput. Some of the disadvantages of disabling XInput are outlined here:

http://guavaman.com/projects/rewired/docs/KnownIssues.html#xinput-device-name

1. L/R triggers are treated as 1 combined axis and both cannot be pressed simultaneously without canceling each other out.
2. You lose universal XInput controller support because each XInput controller now must be specifically recognized and mapped. Any unrecognized XInput devices will be treated as Unknown Controllers.
3. Vibration is not supported without XInput enabled.
4. The Steam Controller as well as Steam Streaming and Steam Link can no longer be supported.

Not really. Saved controller layouts on XInput devices won't be loaded if you're using UserDataStore_PlayerPrefs.

I understand your frustration and your users'. It's quite frustrating for me when an underlying system (Windows, Unity, Linux, Steam, etc.) break critical things and I have to rush to find workarounds if possible. (It happens more often than is reasonable.) I know that my users will look to me for the answers to what really are problems at a deeper level. I essentially have to become an unpaid debugger for multi-billion dollar corporations without even having access to their source code. The Microsoft Xbox One controller fiasco which has been going on since the 2015 Windows 10 driver change has been a real thorn in the side and has eaten up a huge amount of time. I am relentless at trying to make Rewired work the best it possibly can, but sometimes things are just out of my hands to be able to fix. I've done my best to smooth over the problems, but I can only do so much.

 

@RedRiverStudio

Also make sure you've created maps for the Dual Analog Gamepad Template as the Xbox One Controller maps won't be loaded as explained here: http://guavaman.com/projects/rewired/docs/ControllerMaps.html#xinput-devices-windows

Oh, if your game is > 4 player, see this: http://guavaman.com/projects/rewired/docs/KnownIssues.html#more-than-4-xbox-controllers

 

I suppose this leads to another question then, if/when MS fixes the issue, will Rewired require another update or have all grounds been covered at this point?

Ah yes and NOW I remember why I didn't use XInput, my Xbox controllers are now coming up as "XInput Controllers" instead of "Xbox 360 Controller" etc. If this is an issue with label only, and has nothing to do with recognizing the default settings, then I can deal with it, but if the controllers are not actually being recognized for their model, then I am worse off then where I was before. I will test more before I jump to that conclusion though.

goddammit. I was also about to implement Vive controllers, so I doubt thats treated differently.

 

So it seems to me that a good workaround would be that if an Xbox One controller is detected, to automatically engage XInput in Rewired. Is that something I can do at runtime?

 

I can't say. They may cause other problems. It all depends on what changes they make to the drivers. You can be sure that XInput will generally work though.

This is explained here: http://guavaman.com/projects/rewired/docs/ControllerMaps.html#xinput-devices-windows

They are not recognized for their model. XInput does not have product information. It only provides an index 0-3 and a controller type enum. This has no effect on Rewired if you're using the Dual Analog Gamepad Template as described in the above link.

Vive controllers are not XInput compatible. They would be implemented through their SDK.

 

I don't see the advantage. Just so you can display the controller's name for non-Xbox One controllers?

The answer to your question:
http://guavaman.com/projects/rewired/docs/HowTos.html#changing-configuration-settings-at-runtime

 

Right, I understand, and I do and always have had the template set and available. The issue is when somebody plugs in something else that doesn't fall into the dual shock template, like a yolk or whatever. Are these still recognized as their models, bypass XInput, and load up with the existing default map? I am concerned that any controller that does not fall within a template, under XInput, will not use the maps I have carefully set up. I only bring up this concern because I don't own all the controllers, and only have a 360 and XB1 to test.

Well, yes. If literally every controller works perfectly well without XInput except XB1, and displays correctly, letting the player know their controller is supported, we can simply turn on the XInput for those controllers that require it to run, even if that one controller doesn't have a label. I would rather one controller not be recognized, than all of them.

 

XInput is only used for XInput-compatible controllers. That is, XBox controllers.

Anything that is not an Xbox-compatible gamepad will not use XInput and will be handled by Direct Input or Raw Input depending on your chosen input source. All non-XInput compatible controllers will display the correct name.

XInput is an extremely limited system designed only to support the 6-axis, 11-button, 1 D-Pad controllers made for the Xbox 360. It has no ability to support more elements which is why it is impractical for flight controllers and is not a replacement for Direct Input even though Microsoft states so.

Information on XInput can be found here:
https://msdn.microsoft.com/en-us/library/windows/desktop/ee417014(v=vs.85).aspx
https://en.wikipedia.org/wiki/DirectInput#DirectInput_vs_XInput

 

Ok, then why does it disable things like Steam Controllers? If the entire point of XInput is to support Xbox controllers, why is it even a checkbox, and not just something that works when an XInput device is detected?

I realize I am coming off as ignorant here. I don't know how or why these things work, I know it is complicated. But thats why (or why I thought) I bought Rewired, so I wouldn't have to ask these questions. If the only thing stopping an XB1 controller from working is the XInput checkbox being checked, at the expense of other, equally important controllers, then I don't understand why that hasn't been implemented as a behind the scene, automatic function. When you plug it in, the log even says its an Xbox One Controller, while the label says it's generic.

 

Because Steam's implementation is as an XInput device. It creates an XInput device to the system and everything sees it as if it's an XInput device. This was done by Steam to make their controller just work with all existing games. Steam Streaming and the Steam Link work the same way.

Because XInput has limitations such as only supporting 4 XInput devices at once. There are many 8-player games using Rewired that want to be able to support 8 XInput gamepads and the developer needs this ability to disable it. It is enabled by default.

Rewired is designed to give you every possible option to tailor it to exactly what you need. It cannot completely abstract away every single idiosyncrasy of the huge number of underlying input sources it supports.

What do you mean "at the expense of other, equally important controllers" ? This is not the case at all. Enabling XInput does not disable any other controllers. I explained above that XInput works for XInput devices and all other "legacy" non-XInput devices are handled by Raw Input / Direct Input. They both work simultaneously. In Rewired, XInput is an optional 2nd input source on top of Raw Input and Direct Input. RI/DI is the primary input source, XInput becomes an optional 2nd input source. When enabled, all XInput devices will be handled by XInput and all non-XInput devices will be handled by the primary input source. No devices are disabled by enabling XInput. You get full device names for non-XInput-compatible devices (racing wheels, flight sticks, old gamepads, etc), and every single XInput-compatible devices will also work, support vibration, have working L/R triggers when pressed simultaneously, but will not show the actual device type name.

This is a Unity message, not Rewired. There's a big long explanation to that one also. Short version: Unity tries to play tricks to figure out which XInput device matches to which HID device in Windows. It doesn't work. There are plenty of threads on this board about people having problems where they have multiple XInput controllers and Unity gets things fouled up such as one joystick's triggers activating on the wrong joystick index where another XInput device is. This is due to their attempt to match up HID device to XInput device. It's flawed in its very premise and not possible to do reliably in Windows. When using 1 XInput device, it usually works though and that's how they can show you the product name from it. Rewired does not implement that system because it's wrong and would cause more problems than it solves.

 

Ok, thanks for your patience and responses. I will try to use this info as best I can.

 

I'm using GetAnyButton to do a simple 'press any button to continue'. My problem is that just moving the mouse causes it to fire. I saw "This also applies to axes being used as buttons." however I'm not even sure I know how to use an axis as a button, so I'm pretty sure I haven't set up any axis as a button, and definitely not my mouse. I've checked Input Manager multiple times to make sure no axes are being used as buttons, and even unplugged my XBox controller. Kinda stumped what to try next. Thanks for any help.