Rewired - Advanced Input for Unity

I do not have the latest version of RexEngine yet to see what new Actions they've added, but I've made a new integration that allows you to add your own Actions in the Inspector.

Delete Rewired/Integration/RexEngine and replace it with the contents of the attached Zip file.

You will have to add the new Actions that have been added to Rex Engine to both the Rewired Input Manager (including mapping them to something in the Keyboard and Joystick Maps) and the Rex Engine Input Manager inspector.

Edit: File removed because a newer version is posted in the next message.

 

Here is the completed new integration for Rex Engine 1.38.

Delete Rewired/Integration/RexEngine and replace it with the contents of this zip file.

 

Thanks for the really quick reply and fix!!!!

It works like a charm now!!

Is it also safe to update rewired in the future since I manually added this patch?

 

The change will be included in the next update.

 

Hey there @guavaman,
Big fan of Rewired and fairly long time user. Thanks for all your hard work and upkeep! I was wondering if you might share your thoughts on the new input system coming in Unity? What does that mean for us Rewired users? Are there any benefits of the new system that might help make Rewired even better? Any challenges ahead? Is it going to be best for us to keep using the old system within Unity in order to keep using Rewired?

Thanks!
-MH

 

Started working on saving mapping changes and noticed two things about the UserDataStore class: UserDataStore.OnControllerPreDiscconnect has an extra 'c' in "Disconnect", and the summaries for OnControllerPreDiscconnect and OnControllerDisconnect are swapped.

 

Hi,

I don't have any specific information on how the system compares to Rewired. I have not kept up with their restarts and continual changes / evolution over time.

Offhand, the first thing is their new input system is very likely going to cause problems with Rewired's native input system, especially on Windows. Various Windows input APIs have some serious limitations that make multiple systems running in the same application very problematic. Their move to multi-threaded input for the mouse will break Rewired's ability to keep Unity's input system's mouse input working while at the same time running its own native mouse input. The same may also be true for keyboard input. It will become an either/or scenario. Either Rewired works or Unity's new system works, not both. Joysticks don't appear to be a problem as of the last time I tested (a very long time ago) because they don't use Raw Input for joysticks, so the API limitations don't come into play here. Of course, that could change by the time it's released (or perhaps it has changed already.)

There are no benefits the new input system would offer to Rewired users on any desktop platform. Only on mobile platforms that don't have native libraries, specifically Android, might there be any improvements because of the ability to get more information about a controller apart from its name. That would require a completely new input source manager for their new input system on that platform and completely new controller maps for every supported controller on those platforms.

 

Thanks. I can fix the documentation issue but I can't fix the API issue. That will cause every project using UserDataStore to have a compiler error on update.

 

Oh man, all of that sounds rather terrible. I certainly hope they continue to keep the current system as well. I have no plans on *not* using Rewired, so from the sounds of it, the new system is really just bad news.

I definitely appreciate you taking the time out to give the information!

 

It's only bad in the sense that it will cause some problems and likely require I find workarounds for issues where possible or make it clear what the limitations are when no workaround is possible. I'm glad you're happy with Rewired! I plan on continuing to update it ad inifinitum. Once the new input system in released officially, I'll have to look into compatibility issues and come up with workarounds/recommendations.

 

Curious, has anyone built a JsonDotNet based serialization replacement / sub-class for UserDataStore_PlayerPrefs?

Is there somewhere easy to hook in to for writing the serialize/deserialize load/save methods, or would it look more like a full re-implementation of UserDataStore_PlayerPrefs?

 

It would be a re-implementation.

 

@bcjordan

I'm currently in the process of separating the save method from the data processing, and it seems mostly straightforward.

In a duplicate of the UserDataStore_PlayerPrefs class (which I called UserDataStoreProcessor), I simply replaced all calls to PlayerPrefs.SetString, -GetString, -HasKey, and -Save with custom SetString, GetString, HasKey, and CommitSave methods. These methods are passed along to an instance of a separate class with the following interface (called an "Interface" not because it's a C# interface, but because it's what interfaces with the storage medium):

Code (CSharp):

1. public interface IUserDataStoreInterface {
2.     void SetString (string key, string value);
3.     string GetString (string key);
4.     bool HasKey (string key);
5.     void CommitSave ();
6. }

Storing data in key-value pairs is a pretty universal concept. So, in theory, simply separating out the storage interface from the data processor should make the processor quite versatile. A class implementing that interface for PlayerPrefs would be super tiny; it would simply pass given method X along to the corresponding PlayerPrefs.X method.

You could also further separate the processor from the storage method by ripping out its key string generation code. In any case, what the UserDataStore class needs is responsibility separation rather than reimplementation.

 

Is there a way to send an action manually to Rewired? I'd like to in certain cases trigger an action without the user hitting that particular button--I can't find anything in the SDK that might let me send an action. Is this possible?

 

The only way to input values into the system is through CustomControllers:
http://guavaman.com/projects/rewired/docs/CustomControllers.html

 

UserDataStore is an abstract class that can be implemented however you choose. It has no responsibility other than providing an interface to Load/Save user data.

UserDataStore_PlayerPrefs is what you are talking about which is the implementation. Yes, this could have been broken up into multiple classes with different responsibilities, but the purpose of this class was to give everyone an out-of-the-box save/load implementation that works on all platforms, not to be a pluggable system to build your implementation on top of. (Which I have thought of doing many times, but haven't gotten around to it.)

 

Is there a way to apply sensitivity to the magnitude of an Axis2D, instead of its individual X and Y axes separately? The reason is that applying the curves individually causes a loss of magnitude the more diagonal the thumbstick position is. F.ex, at 45 deg pushing completely, with a exp^2 sensitivity if applied to magnitude it results in sqrt(0.7^2 + 0.7^2) ^2 = 1, but if applied to individual axes it results in sqrt(0.7^2^2 + 0.7^2^2) = 0.7. This causes a loss of range in input, so if it were applied to a walking input, the resulting maximum velocity range would be rhombus shaped instead of circular.

 

No.The entire Calibration system is per-axis. Calibration Map is a list of Axis Calibrations, one for each Axis. To do what you would would require significant code and structural changes. Special handling was added for dead zones to treat them differently when the mode is set to Radial where only the first Axis Calibration's dead zone applies. Something similar would have to be done here.

There is no solution to your issue at the present time apart from applying your own sensitivity after the fact on the result of the Actions.

FYI, Unknown Controllers do not even have Axis 2D's because there's no way to know two axes are part of a stick except on recognized controllers with metadata to supply that information.

 

Looking at the code, it may be fairly straightforward to implement this in the same way that radial dead zones are implemented. I'll have to look into it. It still won't work for unknown controllers, just as radial dead zones don't.

 

Hi, I've been using the trial version of Rewired just to be sure that it was indeed the correct product for me, as a newbie Unity user.

Now that I'm very pleased with Rewired, I'd like to buy it soon. My question is, what are the steps, if any, to "upgrade" from the trial version to the full version.

Thank you!

 

Awesome, thanks @OhiraKyou and @guavaman! That was super helpful advice -- took just an hour or so to extract and build one that plugs into our JSON data saving system.

Similar to your approach, I ended up creating a class UserDataStoreKeyValue.cs that extracts PlayerPrefs calls to overrideable virtual methods:

Code (CSharp):

1.  
2. #region Key Value Store Overrides
3.  
4. public virtual void SetString(string key, string value)
5. {
6.     throw new NotImplementedException();
7. }
8.  
9. public virtual string GetString(string key)
10. {
11.     throw new NotImplementedException();
12. }
13.  
14. public virtual bool HasKey(string key)
15. {
16.     throw new NotImplementedException();
17. }
18.  
19. public virtual void CommitSave()
20. {
21.     throw new NotImplementedException();
22. }
23.  
24. #endregion
25.  

Then in a subclass UserDataStoreJSON.cs (for this example edited it to be a bit generic / use a Dictionary right in the class):

Code (CSharp):

1.  
2. using System.Collections.Generic;
3. using Rewired.Data;
4.  
5. public class UserDataStoreJSON : UserDataStoreKeyValue
6. {
7.     private Dictionary<string, string> _configDictionary;
8.  
9.     public override void SetString(string key, string value)
10.     {
11.         _configDictionary[key] = value;
12.     }
13.  
14.     public override string GetString(string key)
15.     {
16.         return _configDictionary[key];
17.     }
18.  
19.     public override bool HasKey(string key)
20.     {
21.         return _configDictionary.ContainsKey(key);
22.     }
23.  
24.     public override void CommitSave()
25.     {
26.         // Trigger something that serializes & writes out _configDictionary
27.     }
28. }
29.  

Additionally, I set loadDataOnStart to false and extracted the logic inside of if (loadDataOnStart) into a public method I could call when I know the data has been deserialized.

Happy to throw up a gist with both files but since the abstracted near-carbon-copy of UserDataStore_PlayerPrefs.cs is really part of the asset I'll defer to @guavaman (& besides, would likely get out of date at some point!)

 

Just install over it. Follow these guidelines for updating Rewired.
http://guavaman.com/projects/rewired/docs/Updating.html

I'm glad you're happy with Rewired!

 

Another reason why the data processing isn't separated from the data saving with base data processing class as an overridable class is that the UserDataStore_PlayerPrefs data processing example is only one possible use case of what data you may want to save. There is no single answer to the questions of 1) what data do you want to save? 2) how do you want that data to be structured? Certain assumptions are made about what data to save, what not to save, and how to structure it in the data processing that is not necessarily applicable to all use cases.

Example: UserDataStore_PlayerPrefs saves Controller Maps, Joystick Calibration, Input Behaviors, and optionally Controller assignments. Controller Maps are saved per-Controller and/or per-Player. However, it is also possible to save Controller Maps based on the Controller Template instead, allowing you to remap gamepads, for example, and have those mappings used on any compatible gamepad you plug in after the fact. One could also add new data/features to save/load such as Controller assignment saving, which wasn't part of the original system but added later after the fact and added as an option. Other assumptions are made in UserDataStore_PlayerPrefs that, while suitable for many use cases, are also not universal such as the handling of Layouts. Or you might even want to put a "user profile" layer in there if your game supports multiple users and you want them to be able to have their own data sets. There are many reasons why the data processing part of UserDataStore_PlayerPrefs isn't in a built-in "black box" class or a boiler-plate base class that you're intended to extend. I am aware of the opportunity to provide a more flexible, pluggable framework for saving/loading user data, but this is not high on the priority list of changes at this time.

As for the contents getting out of date, yes, they will get out of date and very soon. I'm working on changes right now that will modify UserDataStore_PlayerPrefs due to some new systems I'm adding to help with Controller Map Layout management.

 

Hi,

First thanks for this great essential plugin

I'm currently still learning it for my first project, trying to get my inputs right, and I think I might have found a bug... well I'm still a noob so it might be an intended behaviour... ;p

Here is a test example:

Code (CSharp):

1. using UnityEngine;
2. using Rewired;
3.  
4. public class RewiredTest : MonoBehaviour
5. {
6.    public int playerId;
7.    private Player player;
8.  
9.    void Awake()
10.    {
11.        player = ReInput.players.GetPlayer(playerId);
12.        player.AddInputEventDelegate(OnMoveHorizontal, UpdateLoopType.Update, InputActionEventType.AxisActive, "Move Horizontal");
13.    }
14.  
15.    void OnMoveHorizontal(InputActionEventData data)
16.    {
17.        Debug.Log(data.GetAxisTimeActive());
18.    }
19.  
20.    void OnDestroy()
21.    {
22.        player.RemoveInputEventDelegate(OnMoveHorizontal);
23.    }
24. }

My problem: the first time, and only the first time the axis gets active, GetAxisTimeActive() seems to give me the time since Rewired was initialized and not the time since the axis was active, like the axis was active since launch. After that everything works as expected.

Is this a bug, is this normal?
Cheers

Edit: I'm using Unity 2018.3.6f and Rewired 1.1.23.0

 

Thanks. Yes, it's a bug. It was caused by optimizations made years ago to make Actions go inactive when not in use. Apparently nobody uses that function. I'll have to change the way time is recorded to get around this.

 

Thanks for answering so quickly, I'm glad to know it's not coming from me, I'm not sure yet if I'm going to use it but I guess it's better if it's fixed

As a side note I noticed a small typo in the documentation:
http://guavaman.com/projects/rewired/docs/HowTos.html#get-input-player-events

In the example you use the variable "p" instead of "player" in the OnDestroy() function.

Also, the "AxisActiveOrJustInactive" event used in this example is currently not documented:
http://guavaman.com/projects/rewired/docs/api-reference/html/T_Rewired_InputActionEventType.htm

And just food for thoughts: would it be interesting to have a "ButtonPressedOrJustUnpressed" equivalent?

Thanks again for your support!

 

Okay I'll fix it. Thanks.

It should be. It is documented in the code and is supposed to be exported by Sandcastle. This was added in the very last update. I have problems with Sandcastle every single time I update the API. I really wish I could throw Sandcastle out and get something better but it would break all API reference links.

I don't think this would be useful. You can use two events for that. The only reason "AxisActiveOrJustInactive" was added was there is no equivalent set of events that will give you that exact result. "AxisActiveOrJustInactive" is intended to give you information about every frame an axis is active but also tell you when it stops being active so you can process the last frame as 0. There are no "AxisJustActive" and "AxisJustInactive" events like there are "ButtonJustPressed" and "ButtonJustReleased". You can simply get events for "ButtonPressed" and "ButtonJustReleased" to do what you want. It's not my intention to provide events for every possible usage combination.

 

Thanks for the explanation

I understand, at first I thought it was like a micro-optimization kind of thing, calling just one delegate for 2 different events, then I realized it was the only way to get that "JustInactive" event.

It seems to me that it would have been more consistent if we actually had those 2 events available (in fact this is was I was expecting), any reason it's not implemented that way?

Sorry for my annoying questions, I'm still learning...

 

It probably would have been, but axes don't have "Down"/"Up" events or functions in the API. There is no player.GetAxisDown/Up as there is GetButtonDown/Up. I don't really see any use for a function to just tell you only when an axis just becomes zero or non-zero. To treat an axis like a button, you use GetButtonDown/Up, and you can then define the button activation threshold so the amount you have to move the axis to activate it can be controlled.

The event exists so you can process the axis value every frame it's non-zero, but can also do something on the frame it goes back to zero without having to be getting events for all the frames it's sitting at zero, essentially polling. For example, if you were to use this event to directly control the position of an on-screen joystick display that moves as you move the joystick, you wouldn't need anything but this event to be able to set the value of the joystick since the last frame the position becomes zero and the graphic will follow without any additional polling or value checking. The same thing could have been done with something like AxisJustActivated and AxisJustDeactivated. You would need to use at least AxisJustDeactivated and AxisActive together to achieve the same thing. I probably should have just done it like that instead.

 

Thank you very much for this clarification.

 

I'm starting to wonder if it might be a good idea to have an option to squelch the "Touch controls cannot be used with world space canvas" error. It's popping up everywhere and it's getting more and more difficult to suppress with checks, even if in reality it has no impact on the functionality of the application. My most recent frustration comes from controlling a Touch Pad inertia through code, which works fine all the way up until you click outside of the touch pad area, and errors start popping up 30 times a second. It shouldn't matter that my most recent click was in 3D space just to make a change in a variable in the 2D space.

 

I know it's not supported but Rewired fails to compile on unity 2019.1 when building for UWP. On the editor it runs fine but the created visual studio project will complain about:
Severity Code Description Project File Line Suppression State
Error C2039 'numeric_limits': is not a member of 'std' Il2CppOutputProjectl\Il2CppOutputProject\Source\il2cppOutput\Il2CppAttributes.cpp

and that's just a il2cpp for touchjoystick code
static void TouchJoystick_t7D003265D5469EE86A9E1609771F8362EE1F703D_CustomAttributesCacheGenerator__tapTimeout(CustomAttributesCache* cache)

 

Did you upgrade to 1.1.23.0?

Release notes:
- Removed Canvas.renderMode check and warning in Touch Controls due to an impossible to detect scenario involving runtime script compilation and Unity serialized data being cleared in an unpredicable order on objects before script recompilation begins causing Canvas.renderMode to report a value of World even if not set to World triggering the error warning.

 

Please report this to Unity. There's nothing in Rewired that could possibly cause this without a new IL2CPP error on their end. Touch Controls are 100% contained in the Rewired_Core.dll which is plain old .Net 3.5-compliant code with tons and tons of restrictions imposed on it due to all the myriad of inconsistencies and bugs across the platforms and versions of Unity for support for standard .Net functions. The dll is built with NetCore for UWP.

I can see from the code you posted that the problem lies in their Attribute handling. "CustomAttributesCache* cache". I cannot remove custom Attributes from Rewired because of a new IL2CPP error. They're going to have to fix this.

This error:
Error C2039 'numeric_limits': is not a member of 'std' Il2CppOutputProjectl\Il2CppOutputProject\Source\il2cppOutput\Il2CppAttributes.cpp

Indicates their Il2CppAttributes.cpp code is calling a non-existent member of the std library.

 

hi, newbie here. I can't work out how to access the properties on a touch button, ie interactable, visible etc. can't find a way to reference it. Any help appreciated.

 

I don't understand what you're asking. The properties are available in the class:
http://guavaman.com/projects/rewire...l/T_Rewired_ComponentControls_TouchButton.htm

If you are asking how to get a reference to the Touch Button component itself, you do it the same way you get a reference to any other Component in Unity. You either store an object reference in your script with a public variable and connect the reference in the inspector or you use the standard methods to get and/or find the object and call GetComponent on it. This is fundamental to using Unity.

https://unity3d.com/learn/tutorials/topics/scripting/how-communicate-between-scripts-and-gameobjects

 

sorry my bad...newbie mistake. I had the rewired using statement but forgot to include the componentcontrols namespace as well so couldn't declare a variable of type touchbutton as it didn't appear as a type...Thanks for the lightning fast reply though. next time i will have a break before asking silly questions.

 

I see. I didn't understand that was the problem you were having. Glad you figured it out.

 

Hi, I was just hoping to run to ask for some pointers on how to go about integrating more complex input behaviours for mouse and touch than we can define in the rewired editor.

So for example say on a keyboard the left and right arrows move an action axis left or right, and what I want is to the use the horizontal axis of the mouse to behave the same but only if the right mouse button is held down. In my input code for the keyboard I'm able to just call GetAxis( "Horizontal" ), but that wouldn't be enough for the mouse. Will have to add something that checks what the current input type is and then run an extra 'is right mouse button down' check like GetButton( 2 )? I just wasn't sure if I missing something and wondered if there was a streamlined way so I didn't have to write special mouse handling code. But no worries if not, am I on the right path for the approach?

Also if wanted to have a one-finger touch drag where I read the x axis movement of a touch while it's on screen so that it would feed in to the same GetAxis( "Horizontal" ), is there way to have touch gestures like this feed into the rewired input? any examples around by any chance? thanks so much!!

 

Here are the answers to your 3 questions:

Special Mousec Handling:
http://guavaman.com/projects/rewired/docs/HowTos.html#last-used-controller
http://guavaman.com/projects/rewired/docs/HowTos.html#get-contributing-input-sources
http://guavaman.com/projects/rewired/docs/HowTos.html#relative-absolute-axes

Multi-element Actions:
http://guavaman.com/projects/rewired/docs/HowTos.html#button-combos

Inputting Actions into Rewired:
http://guavaman.com/projects/rewired/docs/CustomControllers.html

 

Thank you so much, greatly appreciated!! =)

 

Hello, there is the possibility to parse short input sequences? Like double right/left for dash, things like half moons + button, let's say Street Fighter's like sequences.

 

No. Rewired does not detect gestures. That would require a complete gesture binding and recognition layer that would exist on top of the existing system. Please see the FAQ: http://guavaman.com/projects/rewired/docs/FAQ.html#gesture-bindings

 

Rewired 1.1.24.0 is now available on the Unity Asset Store.

See Updating Rewired before updating.

This update contains an important bug fix:

• Windows, Raw Input: Fixed incorrect reading of HID device path introduced in 1.1.22.0. This error caused multiple identical controllers handled by Raw Input to be identified as the same controller causing many issues with controller disconnection and device identification.

Release Notes:

1.1.24.0:

Changes:
- Updated Universal Fighting Engine integration to fix issues caused by EventSystem.current being set back to the UFE Event System instead of the Rewired Event System.
- Updated Universal Fighting Engine 2 integration to fix issues caused by EventSystem.current being set back to the UFE Event System instead of the Rewired Event System such as non-functioning touch controls due to recent changes in UFE2.
- Updated Rex Engine integration for compatibility with Rex Engine 1.38 made various changes.
- Updated PS4 support for Unity 2017 branch, 2017.4+ to replace deprecated API usage.
- Rewired Editor: Added Default Joystick Sensitivity Type option.
- Calibration.sensitivityCurve with time range of 0 to 1 instead of -1 to 1 will be mirrored for the negative pole of the axis automatically.

API Changes:
- Made PlayerSaveData constructor internal.
- Moved Joystick.hardwareTypeGuid into Controller class.
- Added Controller.deviceInstanceGuid.
- Added Keyboard.deviceInstanceGuid property.
- Added Mouse.deviceInstanceGuid property.
- Added CustomController.deviceInstanceGuid property.
- Added AxisSensitivity2DType enum.
- Added Axis2DCalibration.axisSensitivtyType property;
- Added ReInput.ConfigHelper.defaultJoystickAxis2DSensitivityType property.
- Deprecated UserDataStore.OnControllerPreDiscconnect method and changed from abstract to virtual. (Spelling error.)
- Added UserDataStore.OnControllerPreDisconnect method.

Bug Fixes:
- Fixed bug causing Player.GetAxisTimeActive, Player.GetAxisRawTimeActive to return incorrect values the first time activated.
- Windows, Raw Input: Fixed incorrect reading of HID device path introduced in 1.1.22.0. This error caused multiple identical controllers handled by Raw Input to be identified as the same controller causing many issues with controller disconnection and device identification.

 

Hi!

I'm trying to work out the best way to support more than 4 gamepads and still maintain steam controller support on PC in Steam.

After reading the docs about this (https://guavaman.com/projects/rewired/docs/BestPractices.html) it seems like disable XInput and use Direct Input however it also says that this it not recommended. What drawbacks could that cause?

Is it possible to toggle between Raw Input and Direct Input during runtime and allow users to select it in settings? If yes, how do you do that?

BTW Thanks for an awesome asset

 

Thanks, I'm glad you like Rewired!

The only way to support more than 4 Xbox-compatible controllers and the Steam Controller at the same time on Windows is to disable XInput and use Direct Input as the Best Practices page states.

Changing configuration settings at runtime:
http://guavaman.com/projects/rewired/docs/HowTos.html#changing-configuration-settings-at-runtime

Drawbacks of disabling XInput:
http://guavaman.com/projects/rewired/docs/KnownIssues.html#more-than-4-xbox-controllers

Advantages of Raw Input over Direct Input:
http://guavaman.com/projects/rewired/docs/RewiredEditor.html#settings-windows-input-source

 

Thanks for the answer.

Thanks for the extensive answer. I understand how to use ReInput.ConfigHelper to disable XInput but I currently don't see how to switch to Direct Input at runtime. Do you have any pointers how to do that?

 

This:
http://guavaman.com/projects/rewire...elper_windowsStandalonePrimaryInputSource.htm

The WindowsStandalonePrimaryInputSource enum is in the Rewired.Platforms namespace. For some reason it is not documented in the API documentation. Sandcastle, the API documentation program I use, has a lot of problems.

 

Ahhh thanks, the part that I didn't find was the Rewired.Platforms.WindowsStandalonePrimaryInputSource.DirectInput but now that you posted it everything works great. Thanks again for the fast response and help.

 

Just a little heads up I found that the interface for IDualShock4Extension was a little out of date in the documentation here:
http://guavaman.com/projects/rewired/docs/HowTos.html

Mentions ControllerExtensions.IDualShock4CommonExtension, figured that it had been refactored but thought you might like to know.