Rewired - Advanced Input for Unity

That's exactly what I meant! it's as if you made it or something?

Thanks so much, that's exactly what I'm looking for!

-craigz

 

Hello, I'm currently trying to implement rebindable controls on my game, and the Control Mapper component sounds promisingly easy to use. However, when attempting to reasign a key (be it keyboard or gamepad), I get the current error message: "Attempting to select while already selecting an object".

It happens at the moment I activate the "Replace" button on the key dialog. I do have another canvas with unrelated menus on them. Also, it is possible to give focus to other selectable buttons by just scrolling down past the last key row in the window, which is a separate issue.

How can I fix this(/these) problem(s)?

Thank you,

Raúl​

 

I have never heard of a "Attempting to select while already selecting an object" error before and don't even know what it is coming from. Please post a screen shot of the console message including the stack trace. This sounds like some kind of message from Unity, definitely not Rewired.

What version of Unity are you using?
What version of Rewired are you using?
Is this editor or build?
What platform?

 

This is not possible without modifying the source code of Control Mapper to change the navigation on the last buttons to do what you want. Control Mapper generates all the input mapping buttons automatically at runtime based on the current Action list and the controllers selected. The navigation system is a modified version of Unity's auto-navigation system and makes it possible to scroll the input field scroll rect by pressing up/down and highlighting the next control. There is no way to inject your own custom UI navigation targets into this without explicitly programming this into these buttons to use your navigation method instead of Rewired's auto navigation. And the reason the Done and other buttons is at the top is because making the scroll rect work correctly required that no other buttons be below it due to the way navigation works.

Control Mapper is designed to be used isolated as the only visible UI, not with other active UI elements around it.

 

I have tried to duplicate this without success in Unity 5.6.3f1, 2017.1.0f3, 2017.1.1f1, and 2017.2.0f1.rc1.

Based on this article, it appears Unity at some point added a check to their EventSystem to log an error if SetSelectedGameObject is ever called multiple times in a frame. It will ignore all calls except the first in a frame and log errors on the others. I can already see that this will cause problems if, for example, you need to clear the selection and then set it to something in the same frame. However, I am unable to reproduce any error using the Control Mapper demo scene.

 

The error pops up in both situations when I attempt to replace a control (that time it'll log "Reselecting first input" just before throwing the error) or when scrolling past the last action in the list.

I am not using the example scene and instead created a control mapper gameobject from the create > ui > rewired menu. Both the control mapper and input manager were instanced in another scene and marked as "don't destroy on load", if that matters.

 

In my game, some input actions use the same Joypad button. For example, the "use" and "reload" action both map to the -X- button on an Xbox One Controller.

I would like to know if a method exists in Rewired to use/swallow/consume Rewired.Player.GetButtonDown() input, such as the Event.current.Use() functionality in Unity, which is used to mark an input event as consumed, to avoid that later code handles that input too.

Here is an actual example where this functionality is used in my game:

• The player stands in-front of a door, his weapon is almost empty.
• Pressing -X- is used to open the door, as well as reloading his weapon, depends on context.
• The game code runs the "open door" code first, then the "reloading weapon" code.
• If the player presses -X- on the Joystick, it triggers both "open door" and "reloading weapon".

Rewired.Player.GetButtonDown() returns true for both "open door" and "reloading weapon", which is absolutely correct, because they're mapped to the same button. However, I only want to trigger "open door" and mark the bound joypad button for later code as "already used, please ignore".

I've implemented that "already used, please ignore this input" on the game-code side, which swallows Rewired.Player.GetButtonDown() for "reloading weapon".

However, I wonder if Rewired has such functionality implemented as well, since it's not a totally obscure use case?!

 

Please see this FAQ answer: http://guavaman.com/projects/rewired/docs/FAQ.html#consume-input

Rewired does not allow you to consume or modify the value of an Action manually except through the use of Custom Controllers, but even then you cannot set the value to 0 if some other hardware element has set it to non-zero.

ButtonDown/Up states are calculated based on the underlying input source that is providing it. In most cases, this is a physical button. The Down state is read from that button at the time the Action values are calculated (the beginning of the frame when Rewired runs.) The values stay fixed for the remainder of the frame.

 

The answer is in the stack trace you posted:
[ControlMapper.cs:2663] Rewired.UI.ControlMapper.ControlMapper.Close()
[OptionsMenu.cs:145] OptionsMenu:activateControlPanel()

Your OptionsMenu.cs script is telling Rewired to Close when you are performing this key action. The Close command sets the UI selection to null. The active selection must also have been set to something else in the same frame, either by Control Mapper, or your script, causing Unity to throw this exception.

So the answer would depend on what code is in OptionsMenu.activateControlPanel and why it is calling ControlMapper.Close and on what event it is calling it. If you intended to close the UI this frame, then defer your call to Close it by 1 frame using a coroutine.

 

Thanks, it absolutely makes sense. Will try this and report the results.

 

Got it working, although there's a catch:

The events of my script that were getting fired were attached to a "select" event in a separate button. It appears that while waiting for input, focus will go to other selectable UI items if present, and there's nothing preventing the focus from going off the control mapper item if you scroll past them. What I did was disable every other UI item when the controlmapper appeared, and enable them again when it closed. It's kind of a workaround but it works.

 

That is correct. Control Mapper cannot force only its own UI elements to be selectable. The navigation system is based on Unity's auto navigation and uses an algorithm to find the nearest selectable. Control Mapper disables all of its own selectables when opening a popup window by disabling its canvas groups, but it cannot disable your selectables. You would have to do that using the UI events provided by Control Mapper like onPopupWindowOpened. The system is designed to be used in isolation, not inside another active UI, and cannot work as expected automatically without manual management of your UI elements.

 

Hi
Quick question (Probably a stupid one.).

Just got your asset and wanted player 1 to be able to use a PS4,Xbox One or keyboard controls.
Keyboard and PS4 are working but the Xbox One controller won't work.
I have set up the Xbox One controller the same as the ps4 controller.
Attached image is how I linked the 2 joystick setups... I guess this is also where I made a mistake.

 

You're probably doing multiple things wrong.

1. You do not create Layouts for individual controllers. That defeats the purpose of Rewired's system that allows you to set up maps for each controller type. A single Layout can apply to any number of joystick types while still allowing you to define different mappings for each.

2. You've probably set up the Xbox One Controller map for the device labeled "Xbox One Controller" and you are probably using Windows with the default settings. Read this: http://guavaman.com/projects/rewire....html#windows-xbox-one-controller-doesnt-work

To fix this situation:

1. Delete your Layouts.
2. Create a joystick map for the Dual Analog Gamepad Template.
3. If you want a different mapping for a specific controller, just create another joystick map for that specific device. On Windows, to target Xbox One Controller with Use XInput enabled, make the map for the Xbox 360 Controller.

 

Thank you!

Everything works =)

 

Is it possible to override conflict checking on action categories, or is it only by map categories? My game has multiple playable races, and I was putting each race as a separate map category, and then within them different action categories for the different game controls such as in-game, inventory, etc. This gives the visual look that I wanted for the control mapping UI, but it doesn't let me say to ignore conflicts between in-game and inventory since different game modes.

 

No. The built-in conflict checking system only works on a Map Category basis (does map #1 need to be checked against map #2?). Action Categories are nothing more than a way to organize Actions in the editor and possibly for use in a UI like a remapping system.

 

Do you have any recommendations on how to handle it then? If I have to do each category as a map it'll probably clutter the UI up with many buttons on the top. I was trying to find where it does the conflict checking in code to see if I could modify it to suit my needs, but it appears that happens in a DLL?

 

Everything related to conflict checking is exposed in the API. Control Mapper uses these methods.

Global conflict checking methods:
http://guavaman.com/projects/rewire...t_ControllerHelper_ConflictCheckingHelper.htm

Player contflict checking methods:
http://guavaman.com/projects/rewire...r_ControllerHelper_ConflictCheckingHelper.htm

Conflict checking in Controller Map:
http://guavaman.com/projects/rewire...ntrollerMap_DoesElementAssignmentConflict.htm
http://guavaman.com/projects/rewire..._ControllerMap_ElementAssignmentConflicts.htm
http://guavaman.com/projects/rewire...ollerMap_ForEachElementAssignmentConflict.htm
http://guavaman.com/projects/rewire...ollerMap_RemoveElementAssignmentConflicts.htm

Conflict checking in Action Element Map:
http://guavaman.com/projects/rewire...tionElementMap_CheckForAssignmentConflict.htm

Global methods call down to Players which call down to Controller Maps which call down to Action Element Maps.
You won't be able to use the global or Player conflict checking methods as these are based on Map Category comparison / exclusion. You would use the methods in Controller Map and ActionElementMap.

How are you planning on enabling and disabling these bindings when you're in one mode or another, or are you just going to leave them enabled? The Controller Map category design makes it easy to enable and disable entire maps by category. If you're just making one gigantic controller map with all your Actions on it, you can enable and disable the individual bindings, but not with one line of code.

If you're making this UI yourself, it shouldn't be that difficult to show multiple controller maps in different categories as one long list making it look like it's just a single list of Actions with various categories.

 

Thanks. What I think I'll do is modify ControlMapper.HasElementAssignmentConflicts to instead of calling the bool methods, to call the methods that return the list of conflicts. From there I'll loop over them and see if the action category id the conflict is in is in a category that I want to ignore. Does that sound like an okay solution?

As to them disabling/enabling, I don't currently do anything like that in game. I have my own subscription based input system that is a wrapper around Rewired, which controls when it gets called based on the active game state.

 

I wasn't aware you were using Control Mapper for this. That being the case, the only way to do it would be to modify the source code.

The above sounds okay, but you'll also have change the handling of replacing conflicting element assignments because that will use the category-based checking system as well. That's in the OnElementAssignmentConflictReplaceConfirmed method.

While not necessary, it does speed up Rewired's processing to disable unused mappings. If you have dozens and dozens of Actions, disabling unused ones would be a significant performance improvement on mobile platforms.

 

Great, thanks. I'll keep the performance thing in mind, but so far hasn't been an issue. My game is pc only.

 

Rewired 1.1.7.7 is now live on the Unity Asset Store.

Please read Updating Rewired before updating.

Release Notes:

1.1.7.7:

Bug Fixes:
- Platform assemblies which have been disabled in the Unity inspector are no longer loaded when using the .NET 4.6 experimental backend.

1.1.7.6:

New PlayMaker Actions:
RewiredLastActiveControllerChangedEvent
RewiredCreateCustomController
RewiredDestroyCustomController
RewiredGetAnyButton
RewiredGetAnyButtonDown
RewiredGetAnyButtonUp
RewiredGetAnyButtonPrev
RewiredGetAnyButtonChanged
RewiredControllerGetLastTimeActive
RewiredControllerGetLastTimeAnyButtonPressed
RewiredControllerGetLastTimeAnyButtonChanged
RewiredControllerGetLastTimeAnyElementChanged
RewiredControllerGetAnyButton
RewiredControllerGetAnyButtonDown
RewiredControllerGetAnyButtonUp
RewiredControllerGetAnyButtonPrev
RewiredControllerGetAnyButtonChanged
RewiredControllerGetButton
RewiredControllerGetButtonDown
RewiredControllerGetButtonUp
RewiredControllerGetButtonPrev
RewiredControllerGetButtonChanged
RewiredControllerGetButtonById
RewiredControllerGetButtonDownById
RewiredControllerGetButtonUpById
RewiredControllerGetButtonPrevById
RewiredControllerGetButtonDoublePressHold
RewiredControllerGetButtonDoublePressDown
RewiredControllerGetButtonDoublePressHoldById
RewiredControllerGetButtonDoublePressDownById
RewiredControllerGetButtonTimePressed
RewiredControllerGetButtonTimeUnpressed
RewiredControllerGetButtonLastTimePressed
RewiredControllerGetButtonLastTimeUnpressed
RewiredControllerGetButtonTimePressedById
RewiredControllerGetButtonTimeUnpressedById
RewiredControllerGetButtonLastTimePressedById
RewiredControllerGetButtonLastTimeUnpressedById
RewiredControllerGetButtonIndexById
RewiredControllerGetLastTimeAnyAxisActive
RewiredControllerGetLastTimeAnyAxisChanged
RewiredControllerGetAxis
RewiredControllerGetAxisPrev
RewiredControllerGetAxisRaw
RewiredControllerGetAxisRawPrev
RewiredControllerGetAxisById
RewiredControllerGetAxisPrevById
RewiredControllerGetAxisRawById
RewiredControllerGetAxisRawPrevById
RewiredControllerGetAxis2D
RewiredControllerGetAxis2DPrev
RewiredControllerGetAxis2DRaw
RewiredControllerGetAxis2DRawPrev
RewiredControllerGetAxisLastTimeActive
RewiredControllerGetAxisLastTimeInactive
RewiredControllerGetAxisRawLastTimeActive
RewiredControllerGetAxisRawLastTimeInactive
RewiredControllerGetAxisTimeActive
RewiredControllerGetAxisTimeInactive
RewiredControllerGetAxisRawTimeActive
RewiredControllerGetAxisRawTimeInactive
RewiredControllerGetAxisLastTimeActiveById
RewiredControllerGetAxisLastTimeInactiveById
RewiredControllerGetAxisRawLastTimeActiveById
RewiredControllerGetAxisRawLastTimeInactiveById
RewiredControllerGetAxisRawTimeActiveById
RewiredControllerGetAxisRawTimeInactiveById
RewiredControllerGetAxisTimeActiveById
RewiredControllerGetAxisTimeInactiveById
RewiredControllerGetAxisIndexById

New Behavior Designer Tasks:
RewiredLastActiveControllerChangedEvent
RewiredCreateCustomController
RewiredDestroyCustomController
RewiredGetAnyButton
RewiredGetAnyButton
RewiredGetAnyButtonDown
RewiredGetAnyButtonUp
RewiredGetAnyButtonPrev
RewiredGetAnyButtonChanged
RewiredControllerGetLastTimeActive
RewiredControllerGetLastTimeAnyButtonPressed
RewiredControllerGetLastTimeAnyElementChanged
RewiredControllerGetAnyButton
RewiredControllerGetAnyButtonDown
RewiredControllerGetAnyButtonUp
RewiredControllerGetAnyButtonPrev
RewiredControllerGetAnyButtonChanged
RewiredControllerGetButton
RewiredControllerGetButtonDown
RewiredControllerGetButtonUp
RewiredControllerGetButtonPrev
RewiredControllerGetButtonChanged
RewiredControllerGetButtonById
RewiredControllerGetButtonDownById
RewiredControllerGetButtonUpById
RewiredControllerGetButtonPrevById
RewiredControllerGetButtonDoublePressHold
RewiredControllerGetButtonDoublePressDown
RewiredControllerGetButtonDoublePressHoldById
RewiredControllerGetButtonDoublePressDownById
RewiredControllerGetButtonTimePressed
RewiredControllerGetButtonTimeUnpressed
RewiredControllerGetButtonLastTimePressed
RewiredControllerGetButtonLastTimeUnpressed
RewiredControllerGetButtonTimePressedById
RewiredControllerGetButtonTimeUnpressedById
RewiredControllerGetButtonLastTimePressedById
RewiredControllerGetButtonLastTimeUnpressedById
RewiredControllerGetButtonIndexById
RewiredControllerGetLastTimeAnyAxisActive
RewiredControllerGetLastTimeAnyAxisChanged
RewiredControllerGetAxis
RewiredControllerGetAxisPrev
RewiredControllerGetAxisRaw
RewiredControllerGetAxisRawPrev
RewiredControllerGetAxisById
RewiredControllerGetAxisPrevById
RewiredControllerGetAxisRawById
RewiredControllerGetAxisRawPrevById
RewiredControllerGetAxis2D
RewiredControllerGetAxis2DPrev
RewiredControllerGetAxis2DRaw
RewiredControllerGetAxis2DRawPrev
RewiredControllerGetAxisLastTimeActive
RewiredControllerGetAxisLastTimeInactive
RewiredControllerGetAxisRawLastTimeActive
RewiredControllerGetAxisRawLastTimeInactive
RewiredControllerGetAxisTimeActive
RewiredControllerGetAxisTimeInactive
RewiredControllerGetAxisRawTimeActive
RewiredControllerGetAxisRawTimeInactive
RewiredControllerGetAxisLastTimeActiveById
RewiredControllerGetAxisLastTimeInactiveById
RewiredControllerGetAxisRawLastTimeActiveById
RewiredControllerGetAxisRawLastTimeInactiveById
RewiredControllerGetAxisRawTimeActiveById
RewiredControllerGetAxisRawTimeInactiveById
RewiredControllerGetAxisTimeActiveById
RewiredControllerGetAxisTimeInactiveById
RewiredControllerGetAxisIndexById

Bug Fixes:
- Windows Standalone, Raw Input: Fixed rare crash.

 

Bought ReWired recently and looking good for the most part. It even recognized an about 10 years old joystick that I had lying around.

I'm creating a point-and-click game. I've set up a mouse and a controller map to allow interaction with mouse and game controllers.
Questions:
1) I've added the MyCharacter.cs script (from the Quick Start doc) to a Quad gameObject to be cursor. It is moving, but it seems to moving different amounts in the Unity Editor than in the build. Is that expected or is there a way to make the two movements the same.
2) What kind of values would you recommend for the cursor movement for the game's Settings page (min, max and default values)

Thanks,

 

The MyCharacter.cs script is an example and shouldn't be used for any other purpose than learning.

There is no difference between the Unity editor and a game build.

1. How are you moving the cursor? Mouse or joystick? They're not the same. Mouse returns delta values based on the number of pixels moved since the last frame * 0.5. Joystick returns -1 to +1 absolute values. If you are using the same Action for the mouse axes and the joystick axes, you will have to check whether or not the value is absolute or relative before processing it. Use this method, this method, or this method to determine. Absolute axis values must be multiplied by Time.deltaTime. Relative delta values should not. The reason an error in this would show up differently in the editor and a build is your framerate and VSync settings.

2. It is a very common error to be using two different Rewired Input Manager configurations because of modifying an instance of a prefab. Rewired's Input Manager is a GameObject and therefore follows all the rules of GameObjects including modifying values on a prefab instance that are not reflected on the parent prefab. If you have used a prefab in multiple scenes, then edited the scene instance in one scene, the scene instance in the other scene will not inherit the changes causing you to have two different Rewired Input Manager configurations. When making a build, it is common to launch in the first intro scene but while editing in the editor you launch a different scene causing there to be two different configurations. This can affect input values if you have modified the sensitivity of an Input Behavior in one Rewired Input Manager and not the other. Apply the prefab changes or revert using the standard Unity method to get them back in sync. A very visible warning is shown in the Rewired Input Manager inspector and the Rewired Input Manager window when you are editing a Rewired Input Manager scene instance of a prefab.

3. If you are using Control Mapper or UserDataStore_PlayerPrefs and have modified some setting like sensitivity, your build and/or the editor might be loading outdated XML data. See this, the section "IMPORTANT: Saved XML data is not updated when you make changes to the Rewired Input Manager":
http://guavaman.com/projects/rewired/docs/UserDataStore.html

I don't understand what you're asking. Can you clarify?

 

Sorry if this has already been answered, but I remember a while back where Rewired wasn't working well with the experimental support for a newer .NET version. Is it safe to use Rewired with it now or should I stay on the old .NET still?

 

One of the best, and most essential assets.

 

There are many issues. The first 5 issues on the Known Issues page are .NET 4.6. Only one has been fixed by Unity so far: http://guavaman.com/projects/rewired/docs/KnownIssues.html

There are a few other bugs in 4.6 not on the Known Issues page as well. All have been thoroughly debugged and reported to Unity.

 

Thank you for your detailed reply!

I was testing with mouse only (both Unity editor and build).

Looks like the error was in my code. I'm creating a point-and-click game but using 3d perspective, hence moving my cursor gameObject and had to account for the perspective. Interestingly, my first code attempt worked good enough but the cursor moved faster in the build. After changing the code, now the cursor moves the same amount in both editor and build.

Thank you for the detailed explanation regarding the differences between different controllers (detection and displaying different glyphs). I've looked at some of the documentation before but it was a good overview of how to deal with the differences now that I have a better idea.

The controller detection code on http://guavaman.com/projects/rewired/docs/HowTos.html#last-used-controller works fine.
However, when testing a mouse in the Unity editor, the Player.GetAxisCoordinateMode method seems to return Absolute if the mouse is not moving and Relative if the mouse is moving. Is that expected? I guess that may not be the best way to check.

I'll be looking into the other aspects later (e.g. storing and transfering settings) but something came to mind: is it possible to transfer the ReWired settings from one Unity project to another "quickly" - e.g. by copying files from one project's folder to another's. Or is it better to set up everything manually?

I was wondering about changing the controller movement sensitivity range settings when other players are playing the game (build version). Similar to volume control, if the default sensitivity would be the "middle" of the range (50% volume), would you have a recommendation value for that value? Or is it something for me to test and see? Similarly, what would be the sensitivity max range value compared to default? Would 2,3 times be enough or perhaps 10 times?

Similarly, if I don't have an X-BOX/PS controller at this moment, would my Logitech Attack 3 joystick be a good way to approximate those controller's stick movement for the cursor movement if both return -1 to 1 absolute values?

 

I'm having a weird issue, not sure if bug or wrong setup:

- 'Fire' action assigned to 'Right Shoulder 2' trigger on the Dual Analog Gamepad Template
- The axis is queried with GetButtonDown and GetButton in Update, which both work fine
- GetButtonUp polled in Update will not report true, if I have 'Update' and 'FixedUpdate' enabled in the global rewired settings
- GetButtonUp works correctly again, when I disable 'FixedUpdate' and only keep 'Update' enabled in rewired settings

This seems oddly specific, and I can workaround it by either moving my code only into Update or by doing some state tracking myself, but ideally, I'd like to poll for button presses in Update and still poll some movement axis in FixedUpdate, while also using a trigger axis in Update as a button.

Does anyone else experience this issue or might there be any setting I'm missing?

 

I have an architecture question, specifically how to structure Rewired input handler scripts for use in multiple scripts, over multiple scenes. Let me explain in more detail to further clarify my question. I have the following Unity project structure, which is quite common, I would think:

1. Multiple scripts that need to perform some actions depending on input from the player.
2. Some of the scripts above are common to more than one scene, others are not.
3. So for example, let's say I have the following collection of scenes and scripts (this is all dummy data for illustration purposes):

Scene 1: Scene1Script, WeaponHandlerScript, TakeCoverScript

Scene 2: Scene2Script, WeaponHandlerScript, TakeCoverScript, SleepScript

Scene 3: Scene3Script, WeaponHandlerScript, TakeCoverScript, SleepScript

Scene1Script is responsible for horizontal and vertical character movement as well as picking up items. It requires three different inputs (two axis ones and a button).

Scene2Script handles horizontal and vertical character movement and opening doors. Also three inputs (two axis and a button).

Scene3Script handles horizontal movement, using a knife, starting fire, and drinking water. So it requires four unique inputs (one axis and three buttons).

The other scripts are self-explanatory and only require one button input each.

So with that in mind, how many Rewired input handler scripts should I have and which inputs exactly should they handle?

My first instinct was to create a an input handler script for Scene 1 that handled all three inputs, i.e. something like Scene1InputHandler. This worked fine for Scene 1, but as soon as I started working on Scene 2 I realized I had a problem. If I created another scene specific input handler, it would partially overlap with the Scene 1 input handler. At the same time I couldn't re-use Scene1InputHandler because it didn't give me the input for opening doors. One solution I thought about here was to add input handling for opening doors and sleeping to Scene1InputHandler, make it into a prefab, and re-use it in Scene 2. While that would work, it most certainly does not seem very re-usable and easily maintainable.

The problem becomes even more glaringly obvious when we get to Scene 3? What would I do there? Add inputs for using a knife, drinking water, and starting a fire to Scene1InputHandler? Definitely not. Create scene specific input handlers for Scene 1, Scene 2, and Scene 3? Still seems somehow seedy and unsatisfactory.

So then I started thinking about a software design that would be easy to re-use and maintain and one that is loosely coupled, i.e. a scene should not be tightly coupled with an input. For that matter, an input should not be tightly coupled with any particular input system, such as Rewired or the native Unity Input System. I am using Rewired now, but what if tomorrow I change my mind and start using something else? How much of the existing code base would I be able to re-use?

Then I started thinking along the lines of the SOLID principles of Object Oriented Programming. Perhaps a script specific input handlers would be better, i.e. something like Scene1ScriptInputHandler, Scene2ScriptInputHandler, Scene3ScriptInputHandler, WeaponHandlerInputHandler, TakeCoverInputHandler, and SleepScriptInput. This is a little bit better, but there is still a lot of duplication, i.e. all the scene scripts handle movement inputs, plus they all break the Single Responsibility Principle, i.e. they all have more than one responsibility. That makes this design brittle, i.e. hard to re-use.

So then I arrived at the following architecture, which I believe is superior to the previous two: small, action specific input handlers, independent of an input system (such as Rewired). It is composed of interfaces defining the handling of inputs for each action that requires an input, as well as specific implementations injected (in compliance with the Dependency Inversion Principle) only where they are needed. Here is some pseudo-code:

Code (CSharp):

1. public interface IMovementInputHandler
2. {
3.     void float HorizontalInput();
4.     void float VerticalInput();
5. }
6.  
7. public interface IDoorOpenInputHandler
8. {
9.     void bool DoorOpenButtonDown();
10. }
11.  
12. public interface IWeaponInputHandler
13. {
14.     void bool WeaponButtonDown();
15. }
16.  
17. public class RewiredMovementInputHandler : MonoBehaviour, IMovementInputHandler
18. {
19.     void float HorizontalInput()
20.     {
21.         // Get Rewired horizontal input
22.     }
23.  
24.     void float VerticalInput()
25.     {
26.         // Get Rewired vertical input
27.     }
28. }

Thoughts?

 

It's a bug and it's due to this change:

1.1.7.0:

Changes:
- Modified Action system to determine button states from underlying contributing Controllers instead of calculating button states based on previous and current frame values. This changes some behavior of ButtonUp and ButtonDown events. ButtonDown events are no longer reported when a Controller is assigned to a Player while the button is already held down. ButtonUp events are no longer reported when un-assigning a Controller, or disabling a Controller or Controller Map while a button is held down. This was done to eliminated the need for frame skipping when assigning or un-assigning Controllers or enabling/disabling Controller Maps using a button on that same Controller.

There's some very complex stuff going on in this core part of the system. Making this change affected a ton of things that had to be tested and this fell through the cracks. It will be fixed in the next update.

 

As you state, this isn't specific to Rewired, but is a general code architecture question (since you are talking about wrapping Rewired and are concerned with decoupling, reusability of code, and swapping out input systems, Rewired would be just an implementation and isn't really important to your overall concern). You would probably get better results posting this in the scripting section of the forum instead of here. When writing an input system wrapper, the interface you decide on is up to the needs of your project(s) and it can take pretty much any form you like. You can certainly do it the way you've described (which looks a lot like Unity's Event System event handler interfaces). I've posted some info here before on making an input wrapper for any input system, but it's definitely not using dependency injection, designed for reusability, etc.

The only thing I would say about your example is that I don't see any reason that RewiredMovementInputHandler has to be a MonoBehaviour unless you want to use the inspector to set up what Rewired Player and Actions are being used instead of passing them in the constructor, etc. It would be a lot easier to swap out input systems, though, if you didn't use Components and inspector variables and did the setup in code, a file, or some other more centralized manner (to avoid running from scene to scene changing out components if you change input systems.) Unless I'm just not understanding what how you intend to use the input handler script...

 

Good point there. It is more of a general code architecture question than a Rewired one.

As to inheriting from MonoBehaviour in my example input handler script, I based it on the sample input handler in the quick start guide in the Rewired documentation. I do need to be able to check for inputs every frame or so and MonoBehaviour's Update method is a good way for accomplishing that. Is there a better alternative?

 

I wasn't quite understanding what the job of the "RewiredMovementInputHandler" was. I do now. If you need to do things in Update, a MonoBehaviour is the simplest way. There are other ways to do it though without using a MonoBehaviour if you want. You could use input events instead of polling, or you could subscribe to an Update event driven off Unity's MonoBehaviour update in your non-MonoBehavior object, or call an Update function on the object from a parent MonoBehaviour object. Regardless, that wasn't the real point of why I said using an MB might not be the right approach. The real reason behind that was the structure of your MonoBehaviour, making it a Rewired-specific MonoBehaviour. This is bad because you're concerned with pluggability, so if you do it that way, you will have to go through all your GameObjects and replace the components if you change the input system in the future.

The following approach is similar in structure to your previous example but instead of implementing the input interfaces on the MonoBehaviour itself, the MonoBehaviour instead has input dependencies injected. This decouples your input handler entirely from the input system being used and allows you to swap out input systems without having to change components or any code in the input handler.

Code (csharp):

1. // Input handlers
2.  
3. public class WeaponInputHandler : MonoBehaviour {
4.  
5.     // Inject this
6.     public IInputButton inputWeaponFire { get; set; }
7.  
8.     private void Update() {
9.         if(inputWeaponFire.GetButtonDown()) {
10.             // Do something
11.         }
12.     }
13. }
14.  
15. // Interfaces
16.  
17. public interface IInputButton {
18.     bool GetButton();
19.     bool GetButtonDown();
20.     bool GetButtonUp();
21. }
22.  
23. public interface IInputAxis {
24.     float GetAxis();
25.     float GetAxisRaw();
26. }
27.  
28. public interface IInputAxis2D {
29.     float GetAxis2D();
30.     float GetAxis2DRaw();
31. }
32.  
33. // Rewired implementations
34.  
35. public class RewiredAction : IInputButton, IInputAxis {
36.  
37.     private int playerId;
38.     private int actionId;
39.  
40.     public RewiredAction(int playerId, int actionId) {
41.         this.playerId = playerId;
42.         this.actionId = actionId;
43.     }
44.  
45.     bool IInputButton.GetButton() {
46.         if(!ReInput.isReady) return false;
47.         return ReInput.players.GetPlayer(playerId).GetButton(actionId);
48.     }
49.  
50.     bool IInputButton.GetButtonDown() {
51.         if(!ReInput.isReady) return false;
52.         return ReInput.players.GetPlayer(playerId).GetButtonDown(actionId);
53.     }
54.  
55.     bool IInputButton.GetButtonUp() {
56.         if(!ReInput.isReady) return false;
57.         return ReInput.players.GetPlayer(playerId).GetButtonUp(actionId);
58.     }
59.  
60.     float IInputAxis.GetAxis() {
61.         if(!ReInput.isReady) return 0f;
62.         return ReInput.players.GetPlayer(playerId).GetAxis(actionId);
63.     }
64.  
65.     float IInputAxis.GetAxisRaw() {
66.         if(!ReInput.isReady) return 0f;
67.         return ReInput.players.GetPlayer(playerId).GetAxisRaw(actionId);
68.     }
69. }
70.  
71. public class RewiredAction2D : IInputAxis2D {
72.  
73.     private int playerId;
74.     private int actionIdX;
75.     private int actionIdY;
76.  
77.     public RewiredAction2D(int playerId, int actionIdX, int actionIdY) {
78.         this.playerId = playerId;
79.         this.actionIdX = actionIdX;
80.         this.actionIdY = actionIdY;
81.     }
82.  
83.     Vector2 IInputAxis2D.GetAxis2D() {
84.         if(!ReInput.isReady) return Vector2.zero;
85.         return ReInput.players.GetPlayer(playerId).GetAxis2D(actionIdX, actionIdY);
86.     }
87.  
88.     Vector2 IInputAxis2D.GetAxis2DRaw() {
89.         if(!ReInput.isReady) return Vector2.zero;
90.         return ReInput.players.GetPlayer(playerId).GetAxis2DRaw(actionIdX, actionIdY);
91.     }
92. }

The IInputXXX implementers need to be setup somewhere obviously. They're not MonoBehaviours so you would instantiate them in code, setting up the Rewired Player Id and Action Id, then injecting them into your input handlers. To stop using Rewired and switch to some other input system, only this setup/binding code has to be changed, not any components on any GameObjects.

The example doesn't go into making individual interfaces for every action as yours did (IInputWeaponFire, IInputWeaponReload, etc.), but you certainly could and probably would if you were using a binding/DI framework like StrangeIOC.

My previous example I linked to in my last post uses a static Input Manager singleton to achieve essentially the same result. The one negative is that each input handler has to be aware of the Input Manager singleton which makes it more coupled than this structure.

 

Hi,

I am currently working on a fighting a game and encountered a roadblock with how Unity's implemented input system works. I have posted the question on reddit, but I will mention the important parts here again:

https://www.reddit.com/r/gamedev/comments/76idmu/engine_or_framework_for_unified_frame_rate/

"For fighting games, input consistency is an absolute must, for example reading and processing the user input 60 times per second with fixed intervals between the input processing steps.

I started my game with Unity and right now, Unity's input is tied to the Update() function which means that during one Update() the input is consistent. the problem is that this would mean that input is framerate dependent and would be pretty bad if the game has lag spikes or some machines cannot run the game at full 60 fps. I read that Unity is working on a new input system that allows for framerate independent input, but it is uncertain when the input system is finished or when it will be implemented:

https://forum.unity.com/threads/welcome-new-input-system-resources-and-info-please-read.397153/
"....

My question is: Does your plugin support frame rate independent realtime input polling for the major platforms (Linux, Windows, OS X)? And if so, is it possible to consume the input in a separate thread (not the main thread Unity runs in)?

I would also be happy if you view the question on reddit and give me some recommendations about the intented implementation I want to make for my fighting game (consuming input and executing game logic in a separate thread, syncing data with Unity's main thread and rendering an interpolated state of the simulation)

 

Rewired 1.1.7.8 is now available for download for registered users. If you would like to receive early access to updates, please contact me here. The update has been submitted to the Unity Asset Store and will be available when the approve it.

Please see Updating Rewired before updating.

@Xarbrough If you would like to get this update immediately, please contact me at the link above or PM me your email address and I'll give you the link where you can download it.

Release Notes:

1.1.7.8:

Changes:
- Windows Raw Input, OSX Native, Windows UWP Native: Changes to support more HID devices with axes that have invalid HID report descriptors.
- Added workarounds in Windows, OSX, and Linux standalone platform libraries to get around a bug in the .NET 4.6 experimental backend that caused exceptions to be thrown in the Unity editor when Assembly.GetTypes is called on these libraries.
- Added workaround to get around a bug in the .NET 4.6 experimental backend preventing touch controls from working and other issues related to UnityEngine.Object null comparison.

Modified Controller Definitions:
- Xbox One Controller, Windows UWP Native, HID: Added support for Xbox One Controller on newest driver.
- Xbox 360 Controller, Windows Raw Input / Direct Input: Adjusted trigger calibration.
- Logitech F310, Logitech F710, Windows Raw Input / Direct Input: Adjusted trigger calibration.

Bug Fixes:
- Fixed bug introduced in 1.1.7.0 that caused Button Up events generated by physical axes to not work correctly when updating in Fixed Update was enabled.
- Windows UWP: Fixed bug causing HID devices to sometimes stop working after navigating away from application and resuming.

 

No, it does not. Please see this FAQ question for more details.

I was preparing the foundation for doing this for keyboard, mouse, and joysticks on Windows recently, but had to scrap the plan due to major problems related to Unity's new input system's backend. Suffice it to say that it's not possible to get Raw Input events on a separate thread without breaking Unity's input system entirely due to limitations of the Windows Raw Input API. It's not possible without being able to modify Unity's source code and only working from the outside. It would be possible using Direct Input and XInput (gamepad-only) however.

 

Thanks for the quick answer!

I guess it is not possible to implement it anytime soon, since there is not fixed date or version of Unity announced that will have the new input system implemented (although I have seen that Unity exposes some of the api already in 2017.2)

If you kindly could guide me in the right direction for my problem:

1) How difficult would it be to write a program or library (at first for one platform - probably Windows) that is able to process inputs at a fixed framerate? As you already use native input libraries for your asset, I hope you can give an estimate.
Or would it even be possible to utilize your asset with pure C# code, so that one could use your API outside of Unity, or is it too interwoven with Unity for it to be possible?

2) Do you know how other games handle this problem? Or how to tackle it in general?

I have seen that the game BrawlOut (which is similar to the game I want to make) also uses your asset for Input Management. So that means it does not really read inputs frame rate independent, although this is not really noticeable by the player. So if the architecture I have in mind is too difficult to implement, I will try to have a constant framerate for my game.

 

If all you're concerned with is reading the low-level input directly from mouse, keyboard, and a HID device, not that difficult, especially using Direct Input or XInput (Raw is somewhat of a different story for HID devices). The difficult part comes in writing all the other layers to make all this stuff work in an intuitive and flexible way (the bulk of Rewired) and also work with the massive number of devices out there.

Unfortunately, no. Rewired is very dependent on Unity, mainly for the data serialization and all the editors of that data. There are a few other dependencies like the use of a few Unity classes like Vector2, etc., but those could easily be replaced.

It would depend on the game's needs. Something like an FPS would have quite different requirements from a music timing game or a fighting game. For an FPS, it would be beneficial to retrieve the freshest mouse input state at an arbitrary time during a frame so, for example, you could process the mouse movement immediately before drawing the camera. All this would require is to have the mouse input coming in on a separate thread and being queued up, then make a call to retrieve the state and dump the queue at that moment and process it into a delta. For a music game, you would want to be able to read the entire queue of events with time stamps so you could analyze it and determine if the player's timing was accurate enough to pass. (FYI, since I see you mention 60 fps as a target, I would note that based on the experience of a customer that a music game can require much higher than 1/60th of a second input resolution.) For a competitive-sport fighting game, you would also want to be able to read the event history so you could compare, for example when player 1 pressed the button compared to player 2, etc.

The idea of separating the game simulation into its own thread sounds reasonable, but you would run into a ton of limitations in Unity such as not being able to use the physics system for collision detection because no part of the Unity API can be called by another thread. You wouldn't be able to use Unity for much except as a graphical estimation of what's happening in your simulation. Because of these issues, I don't really see the advantage of doing this on another thread versus analyzing the previous event queue on the main thread and then making a determination based on that about what happened since the last frame and what the result should be.

A constant frame rate is not as important as a consistently high frame rate. Only when the frame rate drops below a certain threshold would you start to notice that input is becoming unresponsive.

FYI, for input API's that are polling-based (XInput, Direct Input), Rewired does do multi-threaded fixed-time-step polling internally at the low level to avoid missing button presses, etc. at low frame rates. You can change the frequency of this internal update in the Rewired Input Manager -> Settings. There is currently no way to get the event queue however. (These events would have to be simulated since Rewired's Action-based system isn't giving you values directly from the underlying hardware but a combination of all contributing sources. Previous experimentation with making such data available greatly increased the CPU overhead of the entire system to a degree unacceptable for mobile devices.)

 

Wow, your answer is great!
Thank you for taking your time.

 

Sorry for the delay. I got the email notification yesterday, but I came to the forum and there was no message here. I tried refreshing several times and it was still not there so I assumed you deleted it. It appeared at some point I guess and by then other messages were posted so I didn't see it.

Yes. There is no input (value of 0) returned by the axis so the coordinate mode is irrelevant. It can't detect the coordinate mode when no input device is providing input. If non-zero, it will never mix absolute and relative values together. Relative will always override absolute.

http://guavaman.com/projects/rewired/docs/HowTos.html#copying-input-config

You will have to test based on your use case and how you are moving the cursor (pixels, relative viewport space, world space, etc.). The Input Behavior has settings for sensitivity options for various axis types: http://guavaman.com/projects/rewired/docs/InputBehaviors.html

Yes. All joysticks return a -1 to +1 absolute value unless poorly calibrated.

 

Very good reply! This is actually very similar to my design, except I did not consider the fact I don't really need a MonoBehavior-like Update method in my RewiredAction class, because the MonoBehaviour I am injecting it into already has its own, native Update.

And I do use the Zenject IoC container for my dependency injection.

 

Hey @guavaman, just had a quick question.

We're adding actions over time as we patch and update our game. We are storing player input mappings as XML strings. When we release a new patch with a new action that has a default mapping set up, we want to load the player's custom mappings, plus add the new default mapping for the default control. Been trying to figure out exactly how we might do this. Any thoughts? Currently this is how player controls are loaded:

Code (CSharp):

1. var playerInput = GameManager.Instance.CurrentPlayerInput;
2.         if (ConfigurationManager.HasKey("HWConfig_InputBehaviour"))
3.         {
4.             ReInput.mapping.GetInputBehavior(0, 0).ImportXmlString(ConfigurationManager.GetString("HWConfig_InputBehaviour"));
5.         }
6.         if (ConfigurationManager.HasKey("HWConfig_KeyboardMapping"))
7.         {
8.             GameManager.Instance.CurrentPlayerInput.controllers.maps.ClearMaps(ControllerType.Keyboard, true);
9.             playerInput.controllers.maps.AddMapFromXml<KeyboardMap>(0, ConfigurationManager.GetString("HWConfig_KeyboardMapping"));
10.         }
11.         if (ConfigurationManager.HasKey("HWConfig_MouseMapping"))
12.         {
13.             playerInput.controllers.maps.ClearMaps(ControllerType.Mouse, true);
14.             playerInput.controllers.maps.AddMapFromXml<MouseMap>(0,
15.                 ConfigurationManager.GetString("HWConfig_MouseMapping"));
16.         }

 

You have to analyze the Player's current configuration loaded by default from the Rewired Input Manager, then compare it to the saved configuration and make a determination as to whether the Action is addable or not to the current configuration. It's very possible your new Action will be mapped to a controller element which has already been mapped to something else by the user. You have to come up with some system that will either map that new Action to something else that is open, replace the conflicting mapping, or just stack it on top of the existing mapping. It would also be helpful if you also saved a list of all known Actions before so you can know which Actions are new. There's no easy way to do this and nothing built into Rewired to analyze your save data. The easiest solution is to wipe the Player's saved configuration every time you add a new Action. The easiest way is to save a data version number, then if the game's version number is higher, just don't load the data.

Look at the source code to Rewired\Assets\Rewired\Internal\Scripts\DataStorage\UserDataStore_PlayerPrefs, line 1077, AddDefaultMappingsForNewActions for an example.

 

Rewired 1.1.7.9 is available for registered users to download. If you'd like to receive early access to updates, please contact me here. The update has not been uploaded to the Unity Asset Store due to a problem which is affecting a number of asset store publishers making it impossible to upload the asset at this time. I have contacted support and will upload the update when the issue is resolved.

Please see Updating Rewired before updating.

Release Notes:

1.1.7.9:

Bug Fixes:
- OSX, Native: Fixed bug preventing Steam Controller from working the primary input source is set to Native.
- Sony DualShock 2 definition, Super Dual Box Pro variant: Fixed Select and Start mappings.

 

I just noticed 1.1.7.8 is in the unity asset store now and that you just announced 1.1.7.9. That updates just keep rolling in. Thanks for all your hard work.

Any issues with Microsoft Windows 10 Fall Creators update impacting XBOX ONE drivers?

 

Yes. In .8:
- Xbox One Controller, Windows UWP Native, HID: Added support for Xbox One Controller on newest driver.

The fun never stops.

 

The next exciting input challenge is using RailDriver and Ship Console for FPS.

 

Hi @guavaman,

I have a question regarding the licensing of Rewired. I am in a team of nine people working on our first game as a team for a class. Its a class project now but we will probably keep working on it after wards. I have one license of rewired, and we are using Bit bucket for our version control. we also are using Playmaker for some of the programing and we are going to use the Playmaker integration for rewired. I want to use rewired in our project but I want to make sure that I understand the one license per seat requirement.

If I integrate rewired into the project then everyone on the team has access to the asset and all nine team members need to use unity to design levels for the class, But I would be the only one directly using rewired. so my question is do we need to buy nine licenses or are we good with just one?