Rewired - Advanced Input for Unity

Rewired's version number includes a Unity version suffix. This is very important. Rewired 1.1.43.0.U2020 is not compatible with Unity 2021. Using the wrong branch of Rewired for the version of Unity you are using is the most common reason for this issue. The only possible way Rewired could interfere with Unity's input system is through this means. It's not actually interfering, the two systems are unable to co-exist because of limitations of the Windows Raw Input API due to changes Unity made in Unity 2021.2.0f1. Rewired for Unity 2020 does not have the necessary code to communicate with Unity 2021.2.0f1 so both can co-exist and use Raw Input. I suggest you updated to Rewired 1.1.44.0.U2021.

 

Because "Disable Native Input" means Rewired is doing no native API calls whatsoever and therefore only one system is using the Windows Raw Input API -- Unity.

If you're interested in the why, read this:
https://forum.unity.com/threads/windows-mouse-raw-input-mouse-handling-broken-in-rewired.1172786/

 

Hi,
1. We are using Rewired 1.1.44.0.U2019 with Unity 2019.4.40f1
2. We are building to a Mono build.
3. We are buiding this on Mac Editor.

FYI, on Windows we are building to an IL2CPP build without any error.

 

Thanks.

I don't see any indication you explored either of the two causes I mentioned in my previous post:
https://forum.unity.com/threads/rewired-advanced-input-for-unity.270693/page-173#post-8833696

I need to know if you have looked into these before I go down into rabbit hole. There have never been any issues building on Mac before, and based on what I see in the error, the cause is very likely to be one of the things I mentioned.

Edit: I just did test builds of the Control Mapper example scene and the Touch Controls Joysticks example scene on MacOS Unity 2019.4.40f1 with no issues. Something in your project settings is causing Rewired_Editor.dll to be included in the build on MacOS. The only two possibilities I know of that could lead to this are listed in my previous post.

 

If I update, which files do I need to replace

 

Thanks for you information, we finally fixed this issue by switch to an il2cpp build.

 

https://guavaman.com/projects/rewired/docs/Updating.html

Import the new version over the old.

 

None of this makes any sense. IL2CPP is more picky about compiling than Mono. Switching to IL2CPP shouldn't have any affect. Try switching back to Mono and see if it works now. Then try deleting the Library folder. This very well could just be a problem in Unity's cache files.

 

Hi. I am using 1.1.39.2.
I am trying to use Custom Controller to emulate player input. I need to clear the user input every frame after other modules having processed the inputs. I use the following APIs,

• Custom Controller.SetButtonValueById(elementIdentifierId, value);
• Custom Controller.ClearAxisValueById
• Custom Controller.ClearButtonValueById

Code (CSharp):

1.  
2. HashSet<ActionElementMap> actionTriggered = new HashSet<ActionElementMap>();
3.  
4. void ClearInput()
5. {
6.     foreach (var actionElementMap in actionTriggered)
7.     {
8.         if (actionElementMap.elementType == ControllerElementType.Axis)
9.         {
10.             cc.ClearAxisValueById(actionElementMap.elementIdentifierId);
11.         }
12.         else
13.             cc.ClearButtonValueById(actionElementMap.elementIdentifierId);
14.     }
15.  
16.     actionTriggered.Clear();
17. }

Here comes the question.
In the product code, I use player.GetAxis(actionId) > 0 to check if this button is pressed, because this action is mapped to mouse wheels as well as keyboard keys.
To emulate the keyboard behavior, I use

SetButtonValueById

to set a button to True. Now in the custom controller, both the axis value and the button value are 1/True. After I clear the button value via ClearButtonValueById, the button value is False, but the axis value is still 1.
I want to clear the axis value as well, by using ClearAxisValueById on the exact same elementId. Then a warning pops up telling me that this is a button not axis.
How to clear the axis value of a button properly?

 

Button controller elements do not have axis values.

A Custom Controller consists of a list of Button elements and Axis elements. When you are clearing a value by id, you are clearing the value of the specific controller element of a particular type with that id. An id can only refer to one element -- either a Button or an Axis, not both. You can see the ids of each element in Rewired Input Manager Custom Controller configuration where you created the elements. They can also be exported as constants.

What you are likely referring to is the Axis value of the Action. An Action is a separate concept that exists at a higher level than controller elements (Axis and Button on the Custom Controller). Actions are virtual controller elements that combine the inputs of any number of constituent controller elements. Actions can be queried as either an Axis (float value) or a Button (bool value). An Action's value is determined by all the controller elements contributing to its value. You cannot clear the Action value. An Action's value is only determined by the values provided by the controller elements contributing to that Action.

Rewired calculates Action values once per frame at the beginning of the frame. If you are clearing the Custom Controller elements at the correct time using the ReInput.InputSourceUpdateEvent as shown in the examples, the controller element values you clear will be reflected in Action values calculated immediately after that event and before your scripts consume input. If you are clearing them arbitrarily in Update, they will not be recalculated until the next frame.

Further, since you are getting the Axis value from an Action to which you have mapped Custom Controller Button elements, Digital Axis Simulation is going to be involved. If Digital Axis Simulation is enabled for the Input Behavior Assigned to the Action, it will behave in the same way as releasing a keyboard key when you clear the Custom Controller Button value. That is, the Action's Axis value will gradually change values over time based on the Gravity and Sensitivity settings instead of instantly going from an Axis value of 1 to 0.

https://guavaman.com/projects/rewired/docs/Troubleshooting.html#digital-axis-smoothing

 

Yes I am referring to Action axis value. Thanks for the clarification.
I use InputSourceUpdateEvent to set button value, and clear the input in LateUpdate using ClearInput in my previous post. The problem persists though.

 

Oops I checked the digital axis gravity and it was zero.
I set it to a number larger than zero, and the axis value falled to 0 as expected.
Thanks again for the quick response and detailed answer. Good day!

 

What exactly is the problem that persists? The Axis value of an Action is non-zero after the only contributing input source to that Action has become zero? This can't happen unless:

1. The InputBehavior assigned to that Action has Digital Axis Simulation enabled and the contributing input source is a Button type controller element. Simulated digital axis values are calculated over time based on Gravity and Sensitivity.

2. The Custom Controller Button you are clearing is not the only contributing input source to the Action.

There is no way possible that an Action could retain a non-zero Axis value if there is no contributing input source supplying a non-zero value to that Action and Digital Axis Simulation isn't involved.

Log all the contributing input sources to that Action:
https://guavaman.com/projects/rewired/docs/HowTos.html#get-contributing-input-sources

There may be some other controller element contributing input to that Action to which you are not aware.

 

Good. You can disable Digital Axis Simulation on the Input Behavior if you're not using it.

 

Hello again. Regarding the issues we were having with the software mouse not accepting forced positions: yep, that was indeed a broken link with the input module.

However, we encountered a follow-up... I'm not going to say 'bug', but it might be a gotcha: our title screen had its own software mouse set up, and if we launched the game from that scene (or a build), our subsequent persistent Software Mouse / Standalone Input Module would not function correctly in terms of setting the position from code. As long as the Rewired Input Manager and SIM/SM install themselves into DontDestroyOnLoad from the same scene, all is well.

Probably not something that's going to catch too many people out, but thought you should know in case.

 

It is not clear to me what you are describing.

The Rewired Standalone Input Module initializes in the Awake function. That is when all setup is done. Various data from ReInput is cached at this time. The Rewired Input Manager must already be present in the scene and enabled before the Awake function is called. The Rewired Standalone Input Module is required for control over Unity UI.

Player Mouse is an additional system that can be used by the Rewired Standalone Input Module. The inspector exposes fields where you can assign Player Mouse references. When Awake is called, these references will be registered in the Rewired Standalone Input Module as mouse pointers. If these references are blank or broken at the time Awake runs in the Rewired Standalone Input Module, they of course will not be evaluated and will not control the UI.

Functions are exposed by the Rewired Standalone Input Module to register and unregister Player Mouse objects with the system if the need arises to do so at runtime.

The way the system functions is how it was designed to function. It is intended that you create a Rewired Input Manager that is initialized at the very beginning of runtime and have it persist through the life of the application. The Rewired Standalone Input Module should also be handled in the same way. Only in the most exotic cases would one ever need to destroy or replace the Rewired Input Manager or the Rewired Standalone Input Module during the application lifetime. The recommended way to handle the Rewired manager objects is to instantiate them using the Rewired Initializer as outlined in the documentation. The Rewired Initializer ensures the Rewired Input Manager is instantiated before any other script runs Awake in a scene and sets the Dont Destroy On Load Flag. Other GameObjects can be attached to the same prefab with the Rewired Input Manager such as the Rewired Standalone Input Module and Event System so these can persist through the application lifetime. Because Player Mouse is an optional dependency of the Rewired Standalone Input Module, the Player Mouse generally should also exist at the same time as the Input Module, so the Player Mouse components can also be nested in the same Prefab with the Rewired Input Manager and the Rewired Standalone Input Module.

If your use case requires that the Player Mouse not exist until some scene that loads after the Rewired Standalone Input Module is already instantiated and awake, you must manually register the Player Mouse instances with the Rewired Standalone Input Module using the function exposed for this purpose. There is no way to create an object reference to an object instance that won't exist until another scene is loaded.

 

Thank you for the explanation - I understand what you're saying and that's why I didn't describe it as a bug

Obviously you know the system inside and out and how it's intended to work. The same is not necessarily true in the same detail for people dropping the various components into scenes, and the behaviour of those components is not consistent (for completely understandable reasons).

For example: the Rewired Input Manager is designed so that you can put one in each scene you might ever want to launch from in the editor, The first one to launch installs itself in DontDestroyOnLoad and the rest bow out gracefully as and when they get loaded. This is a great feature that we leaned on heavily, and even modelled our own Persistent prefab on so that we could hit play in any scene in the game and arrive with all the player's save data and context intact rather than having to launch through the front end every time.

But the Standalone Input Manager and Software Mouse don't do that. If you have one in each potential launch scene, that's the scope of their existence. And what we found is that if this happens:

1. You launch from a scene with its own pre-hooked-up SIM and Software Mouse (so the SIM knows about the SM without calling any functions)
2. You then load a scene which installs a different pre-hooked-up SIM and Software Mouse to DontDestroyOnLoad (So this is another SIM that already has a link to its SM, and the old pair is dead and gone)

Setting the software mouse position on the last-loaded persistent SM doesn't work.

Yes, it's an edge case. But if otherwise correctly configured SIM/SM pairings aren't going to work properly when new ones replace old, it would be great if the system could alert users to that fact.

 

Actually, while it can be used that way, the documentation advises that you use the Rewired Initializer for this purpose. Using it solves many potential problems, such as the user accidentally overriding values in the Rewired Input Manager in one scene and not another. That's not possible if you use the Rewired Initializer.

It also solves the problem you're describing because it only makes sense to attach the Rewired Standalone Input Module object to the prefab instantiated by the Rewired Initializer because the Rewired Standalone Input Module depends upon the Rewired Input Manager. It also makes it impossible to link scene objects that will be destroyed on the next level load to the Rewired Components.

When a new scene is loaded, if another Rewired Input Manager already exists, the loaded Rewired Input Manager deletes its game object. It would also delete any child Input Modules or event systems in that case.

The Rewired Input Manager also sets Dont Destroy On Load on the root GameObject (that's the only object on which it can be set), so any child objects will also persist throughout the scenes. If the Input Module, Event System, and Player Mouse objects were children, everything would just work because of auto-deletion of the parent Rewired Input Manager GameObject.

The key is to be using prefabs and not be relying on in-scene links. A prefab containing the entire hierarchy of objects that you place in every scene with the Rewired Input Manager at the top level would behave very similarly to using a Rewired Initializer with the same prefab.

What you've done is create references to in-scene objects that got deleted when the next scene was loaded. This is an error. If you did this in other cases, you'd end up getting exceptions thrown by Unity for trying to access objects that have been destroyed. It just so happens it doesn't throw null reference exceptions in this case because of the component-wrapper structure of the Player Mouse system. PlayerMouse is a normal class which is optionally contained by a PlayerMouse Component wrapper so you can optionally manage it using a Unity Component on a GameObject. Unity overrides the equals operators on objects that inherit from UnityEngine.Object so that when it destroys the objects, it can report them as null even if an object reference is still held somewhere. That is not the case with normal System.Objects. The PlayerMouse object is retained by the Rewired Standalone Input Module, not the PlayerMouse Component object. Therefore, the object reference remains valid even after you deleted the containing Component wrapper by loading the scene. This is why a null reference exception is not thrown -- because the actual PlayerMouse was never deleted, only the Component wrapper. The Rewired Standalone Input Module doesn't care about the Component wrapper, only the internal PlayerMouse object which it got from the PlayerMouse Component wrapper on Awake and stored when it registered that as a mouse in the RewiredPointerInputModule. The Rewired Standalone Input Module doesn't even know these Components have been destroyed.

Ultimately, it's an error to attempt to use references to objects in the scene that have been destroyed. That's the root cause of your issue, and the best solution is to use a prefab that contains all the components that you need to test individual scenes and have it instantiated by the Rewired Initializer in every scene instead of creating links to scene objects in Components that won't be destroyed when the scene loads.

 

Hello everyone!
What would be the ReWired method for this?
Input.inputString
I'm trying to get which key was pressed from Rewired.
Thanks!

 

Rewired does not handle typing input. It only handles keyboard input for use as a controller.

You can get input directly from the keyboard like any other controller type in Rewired by accessing the controller object.

https://guavaman.com/projects/rewired/docs/HowTos.html#get-input-controller-polling

ReInput.controllers.Keyboard.GetKeyDown
https://guavaman.com/projects/rewired/docs/api-reference/html/T_Rewired_Keyboard.htm

Normally, you'd use the Player-Action system to get input instead.

Rewired does have a controller polling API that is used for key binding that watches controller elements for input and reports what was activated, but it's not appropriate for anything that has to be run continually during gameplay.

 

Hello! Thanks a lot for the reply. I will try everything this weekend and write back if needed. I'm still quite new but I have to say, Rewired saved me a LOT!
Thanks

 

Hi guavaman,

I just discovered that Unity's external keyboard support on iOS still does this weird "half a second delay key release" workaround, even though iOS 13.4 enabled a new API 3 years ago.
I fully understand that Rewired relies on Unity Input under the hood.

Do you know of any way to make keyboard input work better on iOS with Rewired?
I came across these Unity plugins made by Apple:
https://github.com/apple/unityplugins
One of them is Apple.GameController plugin, which sounds like the right thing to use.

Or is it not worth it and I should just disable keyboard for iOS platform until Unity implements GCKeyboard API?

Rewired works great and it's a pain that keyboard support is broken on iOS only because of Unity...
Thanks for all your hard work.

 

This is only true on certain platforms like iOS. The list of which platforms have native input and which don't is here:
https://guavaman.com/projects/rewired/docs/Overview.html#tested-platforms

There isn't any way to do that apart from me making and maintaining a full native input library on iOS to replace dependency on UnityEngine.Input.

 

Doesn't Rewired already allow usage of Game Controller Framework for OSX?

There are also some Unity plugins released by Apple last year for Game Controller functionality:
https://github.com/apple/unityplugins

 

Yes. Making this work for iOS would be a very large project, especially considering Apple's iOS app store requirements for building to the latest SDKs. In order to support this over time, I would have to maintain an ever-growing list of libraries built to each version of the iOS SDK that is released. And because old games can be updated even after an SDK version it was submitted with has been deprecated, I'd need to maintain support for all the old SDKs going forward, even as I may need to make changes to the library code as Rewired evolves. (While you may lock your game to a specific version of Unity and not upgrade it further, Rewired continually updates and maintains compatibility with all older versions of Unity so even old games can have the latest input updates.) This is not a burden I have ever been interested in taking on, especially because the benefits of building and maintaining a native library have been extremely minimal over what UnityEngine.Input offers.

I would not want to make Rewired have any dependencies on an optional 3rd party plugin that would likely have different versions and evolve over time, causing breaking changes. Something like that is extremely difficult to maintain.

 

I see, thanks for the in-depth explanation.

Update:
I've managed to solve the keyboard issue by hacking the iOS project code:
https://forum.unity.com/threads/ios-repeated-key-lag.1039462/#post-8870835

Not very maintainable, but should get the job done until Unity switches to GCKeyboard.

 

Hey! Thanks for this amazing asset.

I'm having an issue regarding Control Mapper & new input actions.
We're using Control Mapper for our game, and now I'm converting one of our "legacy" input features to use Rewired, so just creating the actions and adding them to appropriate categories.

The issue I'm having is that the existing saved bindings prevent the new actions from having any "default" values and they end up being empty, since the old saved controller maps don't have any information about them. The solution for this would be to change the save data prefix, which I've been versioning so far. However, whenever I do change the name, all the current players lose their bindings and have to set them up again.

Any ideas if there would be a way to preserve saved ones / update them to include the default values from the Rewired Input Manager before assigning the control maps?

 

Management of existing saved user data and trying to merge that with new developer-defined-default mappings is a very complex topic. There are no easy solutions to this problem. UserDataStore_PlayerPrefs already does very rudimentary merging default bindings of newly-created Action with existing user bindings. Anything beyond that would be up to the developer to implement a more sophisticated data management system if the out-of-the-box system does not meet the requirements. That would mean replacing UserDataStore_PlayerPrefs with a custom system.

From the documentation on UserDataStore_PlayerPrefs:

https://guavaman.com/projects/rewired/docs/UserDataStore.html#playerprefs

Limitations:

UserDataStore_PlayerPrefs is not the be-all, end-all, automatic data storage system. It has limitations. It does not fully automate everything so you can just set it and forget it. It provides an interface for you to save/load data as necessary for the needs of your game. This sometimes requires manual calls to functions to make data save or load at a particular time. Functionality beyond what is described above is up to the user to implement if desired. UserDataStore_PlayerPrefs is a minimum viable product designed for the most common use case needs and was primarily designed for Control Mapper.

PlayerPrefs itself has significant limitations and negatives, for example, it isn't possible to clear only Rewired's save data from PlayerPrefs without wiping out all other PlayerPrefs data. If this is something you anticipate needing to do for whatever reason, do not use UserDataStore_PlayerPrefs and instead implement your own extension of the UserDataStore class that saves/loads data to whatever storage system you desire so you can have more control over how data is stored and managed.

[...]

IMPORTANT: Saved XML data is not updated when you make changes to the Rewired Input Manager

UserDataStore does not manage changes between the Rewired Input Manager and data that is already saved to XML. If you make changes to the Rewired Input Manager settings such as adding new controls to a Joystick Map, these new changes will not be preserved when loading saved XML data. The only automated solutions would be to either clear the save data by clearing Player Prefs so that the Rewired Input Manager defaults are used instead or load the default maps in the Player for the any controllers that changed and save those to XML overwriting the existing saved mappings.

Management of saved user data is up to the developer. If you have special needs beyond the basic use cases, you should extend and replace the UserDataStore_PlayerPrefs component with a new UserDataStore component that meets your specific needs.

 

When I click a button with the left mouse button, the action of the left mouse button down is triggered, not the result I want. How to avoid a conflict where the mouse button is clicked triggers a left mouse button action

 

I assume you are referring to Unity UI buttons.

https://guavaman.com/projects/rewired/docs/RewiredStandaloneInputModule.html

Mouse:

DO NOT map any UI Actions to Mouse buttons or axes. This is a very common mistake and will lead to many problems. See this for more information.

-----------

If you are instead referring to mouse Actions that you have defined for other purposes in your game, Rewired's Action values are not blocked from returning value because you're using Unity UI and clicking on a button. ReInput (the core of Rewired) has no knowledge of Unity UI or any other UI or other external system you may be using that depends on ReInput. When you map an Action to controller elements, they will return value whenever that controller element returns a value.

Dealing with changing how input is processed for UI interaction isn't any different than changing how input is processed for any other mode of your game. It's up to you how to flow control input processing. You can enable / disable Controller Maps, but a better approach would be to flow control your input processing in your scripts by creating a permission management system that determines whether the value of a particular Action should be processed at that time.

https://guavaman.com/projects/rewired/docs/Actions.html

Rewired’s Purpose and Responsibilities

It is common for Rewired's Action system to be used in an unintended manner as an integral part of or in place of a separate game state management system. This is not what Rewired was designed for and not how it is intended to be used.

• Rewired’s sole purpose is to read user input.
• All “Actions” in Rewired are actually “Input Actions” and should not be used for any other purpose than to get information about the user’s intent. They should not be confused with or used as game states or actions.
• The Action “Jump” does not designate “Player is jumping,” but rather “The user wants to jump.”
• The game should implement permission and state management systems that evaluate user input and then change states. After that point, what happens is outside the responsibility of the input system.

 

Hey,

I'm trying to update rewired into an existing project, but I have an exception during runtime.

Code (CSharp):

1. Rewired: Rewired: An exception occurred during update (Update). Rewired will attempt to continue running.
2.  
3. Exception:
4. System.NotImplementedException: The method or operation is not implemented.
5.   at Rewired.Axis2DCalibration.GetCalibrated2DValue (System.Single valueRawX, System.Single valueRawY, Rewired.AxisCalibration xAxis, Rewired.AxisCalibration yAxis, Rewired.DeadZone2DType deadZoneType, Rewired.AxisSensitivity2DType sensitivityType) [0x00119] in <24a9b252dcd84531a50eca071d3c9cd4>:0
6.   at Rewired.CalibrationMap.GetCalibrated2DValue (System.Int32 xAxisIndex, System.Int32 yAxisIndex, System.Single valueRawX, System.Single valueRawY, Rewired.DeadZone2DType deadZoneType, Rewired.AxisSensitivity2DType sensitivityType) [0x00011] in <24a9b252dcd84531a50eca071d3c9cd4>:0
7.   at Rewired.Controller+Axis2D.UpubtBwoclVKnEpYQHdHwIxVgyLZ () [0x00063] in <24a9b252dcd84531a50eca071d3c9cd4>:0
8.   at Rewired.Controller+Axis2D.get_value () [0x0001f] in <24a9b252dcd84531a50eca071d3c9cd4>:0
9.   at Rewired.Controller+Axis2D.HKmEXBOMtGYkijZBmPdErwHXVruq () [0x00000] in <24a9b252dcd84531a50eca071d3c9cd4>:0
10.   at Rewired.ControllerWithAxes.OPzMeptHNTMsrWdWvslRxoVUdTujA (Rewired.UpdateLoopType ) [0x0011b] in <24a9b252dcd84531a50eca071d3c9cd4>:0
11.   at Rewired.Joystick.OPzMeptHNTMsrWdWvslRxoVUdTujA (Rewired.UpdateLoopType ) [0x00000] in <24a9b252dcd84531a50eca071d3c9cd4>:0
12.   at sQUhNuelsgdElREOuzBUnZbPDjkc.aBNtxHhzULMzbVNOykyDKzDCQgAf (Rewired.UpdateLoopType ) [0x0003c] in <24a9b252dcd84531a50eca071d3c9cd4>:0
13.   at sQUhNuelsgdElREOuzBUnZbPDjkc.sOLNzBCCbZmFXkMugfndpShqgrUP (Rewired.UpdateLoopType ) [0x0001f] in <24a9b252dcd84531a50eca071d3c9cd4>:0
14.   at Rewired.ReInput.sOLNzBCCbZmFXkMugfndpShqgrUP (Rewired.UpdateLoopType ) [0x000a7] in <24a9b252dcd84531a50eca071d3c9cd4>:0
15.   at Rewired.InputManager_Base.DoUpdate (Rewired.UpdateLoopType updateLoopType, Rewired.Config.UpdateLoopSetting updateLoopSettingBit) [0x00034] in <24a9b252dcd84531a50eca071d3c9cd4>:0
16. ------- Rewired System Info -------
17. Unity version: 2021.3.21f1
18. Rewired version: 1.1.44.0.U2021
19. Platform: Windows
20. Editor Platform: Windows
21. Using Unity input: False
22. Primary input source: RawInput
23. Use XInput: True
24. Native mouse handling: True
25. Enhanced device support: True
26.  
27. UnityEngine.Logger:LogError (string,object)
28. Rewired.Logger:LogErrorNow (object,bool)
29. Rewired.Logger:LogError (object,bool)
30. Rewired.Logger:LogError (object)
31. Rewired.InputManager_Base:dEOSZfMrSdahsbvreYeeAqIuwEad (Rewired.InputManager_Base/thzaoRJnuxVjvmKWTlrsyfNPMaxo,string,System.Exception)
32. Rewired.InputManager_Base:DoUpdate (Rewired.UpdateLoopType,Rewired.Config.UpdateLoopSetting)
33. Rewired.InputManager_Base:Update ()
34.  

It seems to be specific to my project, no problem starting with an empty project, but not sure how to look into this further.

Edit:
Found my problem. Values of DeadZone2DType are Radial = 1, Axial = 2. The below code returns true and assigns 0 to JoystickAxis2DDeadZoneType which is type of DeadZone2DType. In comparison AxisSensitivityType Multiplier = 0, Power = 1, Curve = 2, and AxisSensitivity2DType Radial = 0, Axial = 1

if (Enum.TryParse<DeadZone2DType>("0", true, out var joyDeadZoneType))
JoystickAxis2DDeadZoneType = joyDeadZoneType;

Which is by design. A me problem

 

This brings me to ask about a problem I am having with inverting the mouse axis. Using the provided Control Mapper, for any axis that I set to be inverted for the mouse the axis value is always 0.

There is no input being received from the mouse using GetAxis() for the inverted axis. All mouse axis work fine if not inverted.

 

Every time I've had someone report this type of thing in the past, it is because they have 2 Action Element Maps, not one. They are inverting one of those bindings and not the other, therefore the two bindings are applying input in opposite directions and canceling each other out.

Examine your Controller Maps at runtime using Debug Information:
https://guavaman.com/projects/rewired/docs/Troubleshooting.html#debug-information

Also useful:
https://guavaman.com/projects/rewired/docs/HowTos.html#get-contributing-input-sources

 

Thanks for the info. I do have a 2nd Category that mirrors axis controls, something I'm doing to allow more button actions on a gamepad by holding down a button and then pressing another.

I have Pitch and Pitch1. Pitch1 is not assigned any binding across all control types. This works fine for a controller/joystick, even when inverting any axis.

But the mouse works differently.

I mirrored the assignments from Pitch to Pitch1 for the mouse axis and inverts and now the mouse axis works inverted. Given that I didn't need to do this for gamepad/joystick. As the mouse behavior differs from the joystick/controller, is this a bug?

 

I am certain it is not a bug. Mouse axes are no different than any other axes except that they return delta values. There is no automatic inversion. There is something else causing this and it's going to take investigation to figure out what it is.

Viewing the Controller Maps that exist in your player live at runtime using Debug Information and not just looking at the maps you've created in the Rewired Input Manager is critical. Most people run into problems because they don't realize saved data is being loaded which overwrites their developer-defined default mappings in the Rewired Input Manager when they press Play.

I don't understand what you're saying about Pitch and Pitch 1. If Pitch 1 is not bound to anything in any Controller Maps and you're not querying for the value of Pitch one, it is irrelevant. Are you saying you started using Pitch 1 on the mouse instead of Pitch and are now querying to get the value of Pitch1? In my view, that wouldn't be a solution but side-stepping the problem because you're now using a different Action. The only things that matter are bindings to the Action which is not inverting correctly. I believe you will find two bindings, either in the same Controller Map or in two different enabled Controller Maps, that binds the Action that is not inverting.

First clear any saved user data if you are using Control Mapper or any other system that uses User Data Store:
https://guavaman.com/projects/rewired/docs/UserDataStore.html

Second, look through all the bindings in the Player at runtime using Debug Information. Look for any ActionElementMaps that bind Pitch in the mouse map and other controllers.

If you still don't find the cause, export the Rewired Input Manager data from Settings -> Tools and send me the file.

 

Hello,

I want to know how to download the pro version of the asset for unity 4.6.

 

There is no pro version of the Rewired asset. There is just one Rewired version.

You should contact support for more information on Rewired for older Unity versions.

https://guavaman.com/projects/rewired/#support

 

Hey there!

I'm using a custom remapping implementation based on the SimpleCombinedKeyboardMouseRemapping example, and although it took a bit to wrap my head around everything I finally got that all working. Now I'm currently looking into localization for input remapping. I was glad to find several csv spreadsheets with the element identifier names for everything, but one thing I noticed when looking over the mouse element identifiers specifically is that there aren't element identifiers for split axes.

This isn't really a big deal, since I figured I could just deal with that manually and add localization keys for things like mouse right, mouse up, etc. but now I'm wondering if there's something else I might be missing? The spreadsheets list Rewired version: 1.0.0.0 which is definitely not the latest version. I'm not too concerned since what's there covers pretty much everything but I figured I'd ask about it anyway.

 

The CSV files provided in the documentation are current. I didn't even make CSV files of controller elements back when Rewired was first released. The reason the file says 1.0.0.0 is because the controller definitions for keyboard and mouse and are hard-coded and have never changed since the first version of Rewired.

None of the CSV files include positive / negative descriptive element names. They probably should.

From the code:

Code (csharp):

1. new ControllerElementIdentifier(0, "Mouse Horizontal", "Mouse Right", "Mouse Left", ControllerElementType.Axis, CompoundControllerElementType.Axis2D, true),
2. new ControllerElementIdentifier(1, "Mouse Vertical", "Mouse Up", "Mouse Down", ControllerElementType.Axis, CompoundControllerElementType.Axis2D, true),
3. new ControllerElementIdentifier(2, "Mouse Wheel", "Mouse Wheel Up", "Mouse Wheel Down", ControllerElementType.Axis, CompoundControllerElementType.Axis2D, true),
4. new ControllerElementIdentifier(10, "Mouse Wheel Horizontal", "Mouse Wheel Right", "Mouse Wheel Left", ControllerElementType.Axis, CompoundControllerElementType.Axis2D, true),
5. new ControllerElementIdentifier(3, "Left Mouse Button", "", "", ControllerElementType.Button, CompoundControllerElementType.Axis2D, true),
6. new ControllerElementIdentifier(4, "Right Mouse Button", "", "", ControllerElementType.Button, CompoundControllerElementType.Axis2D, true),
7. new ControllerElementIdentifier(5, "Mouse Button 3", "", "", ControllerElementType.Button, CompoundControllerElementType.Axis2D, true),
8. new ControllerElementIdentifier(6, "Mouse Button 4", "", "", ControllerElementType.Button, CompoundControllerElementType.Axis2D, true),
9. new ControllerElementIdentifier(7, "Mouse Button 5", "", "", ControllerElementType.Button, CompoundControllerElementType.Axis2D, true),
10. new ControllerElementIdentifier(8, "Mouse Button 6", "", "", ControllerElementType.Button, CompoundControllerElementType.Axis2D, true),
11. new ControllerElementIdentifier(9, "Mouse Button 7", "", "", ControllerElementType.Button, CompoundControllerElementType.Axis2D, true)

 

I have updated all the CSV files.

https://guavaman.com/rewired/files/docs/RewiredControllersCSV.zip
https://guavaman.com/rewired/files/docs/RewiredControllerElementIdentifiersCSV.zip
https://guavaman.com/rewired/files/docs/RewiredKeyboardElementIdentifiersCSV.zip
https://guavaman.com/rewired/files/docs/RewiredMouseElementIdentifiersCSV.zip

 

Thanks for all your hard work!

 

Hi Guavaman, may I ask if there is any way to adjust the frequency of vibration for the Dualsense controller?

For the Switch, it is possible to adjust the amplitude and frequency band of the waves sent to the motors to achieve different kinds of vibration effects, and since the Switch and Dualsense are using the same kind of linear motors, I was wondering if it is possible for the Dualsense as well?

 

Hi,

Currently, for the purposes of controlling some inputs, I have effectively defined the same Element to multiple Actions. For example, I have Horizontal Move (WASD) and Horizontal Menu Move (WASD and Arrow Keys) which lets me more accurately define which Action is used for specific areas along with allowing the user to more fine-tune things if they'd like.

My question was, is there an issue doing this that I might be unaware of before I go too deep on continuing with this? I haven't run into any for what it's worth, and I know it's up to me on how I consume the Actions and what might result from that. I just wanted to double check and be sure this isn't going to cause issues for Rewired itself.

 

No. The motors only take a single 8-bit level value. I assume you're referring to using the controller in Windows.

 

You will run into conflicts when rebinding controls unless you set up conflict checking properly:
https://guavaman.com/projects/rewired/docs/HowTos.html#conflict-checking

Whether or not to even do conflict checking depends on your use case.

 

Perfect, I will make a note of this. Thank you!

 

Yes, I am referring to using the controller on Windows. I see, thank you for the information!

 

Yup, the problem was in the chair. Thanks.

 

Hi,

I am not sure if it has been reported. On the Steam Deck, the GUID returned by controllers seems to always be the Xbox 360 controller which means, I don't seem to have any way to display the proper controller input icons.
Any clue if there is a work around?

Thanks,
-Tim

 

This is not a bug. This is a limitation of Steam and XInput. See the documentation:

https://guavaman.com/projects/rewired/docs/ControllerMaps.html#xinput-devices-windows
https://guavaman.com/projects/rewired/docs/KnownIssues.html#windows-xinput-devices-use-x360-map
https://guavaman.com/projects/rewired/docs/Troubleshooting.html#steam

This applies to Windows builds and Windows builds run under Wine/Proton. Steam has always worked by creating fake XInput devices for every device it controls so the application can see it regardless of whether that application explicitly supports the Steam API or not. This is the foundation of their Steam Play, Steam Link, Steam Controller, and Steam Configured Controllers systems. It is not possible to tell anything about an XInput device beyond the fact it is a "gamepad", so there is no possible way to differentiate different controllers from each other to display different glyphs.

If you disable Use XInput and use either Raw Input or Direct Input, Steam will create fake devices for those APIs too, but again, you will not be able to tell what the actual underlying real device is to display glyphs for it if Steam is configuring that controller.

Disabling XInput will result in the following loss of features:

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.