Rewired - Advanced Input for Unity

Hi!
I was hoping you'd be able to help me with something.

Basically I'm trying to make use of Map Categories.
Default: Contains player movement and interaction elements.
UI: Contains UI navigation elements.

I'd like to switch the Joystick Map to the "UI" category while a menu is open.
This seemed like an easy way to prevent character movement while in menus and remap the joystick to the presented menus.

I tried to do this by running the following line when the UI is opened:

Code (CSharp):

1. ReInput.players.GetPlayer(0).controllers.maps.SetMapsEnabled(true, "UI");
2. ReInput.players.GetPlayer(0).controllers.maps.SetMapsEnabled(false, "Default");

But this doesn't seem to work so I assume I don't fully understand this feature yet.
I know my EventSystem is set up correctly to work with Rewired as if I move the UI elements into the Default category they work fine.

Thanks for any help!

 

Hello Guavaman, We have all controller working on tvos (xbox, mfi, ps4) !
Thanks for your tips and sorry for my stress

 

You don't have to guess why something is not working. Look at the objects in real-time:
https://guavaman.com/projects/rewired/docs/Troubleshooting.html#debug-information

Is the UI Controller Map loaded in Player? You can see this all in real-time.
When you open the UI, does the Enabled state change on the two Controller Maps? You can also see this.

But apart from this, you will have other issues if you simply change states when you open the UI. What happens if the user unplugs the controller and plugs in a different one while he's in the UI? Your call to change maps will not have any effect on the new controller, because as the documentation states:

IMPORTANT: The above SetMapsEnabled and SetAllMapsEnabled methods are not persistent flags in Player that will set a certain category of map enabled/disabled upon loading. They are simply shortcuts for the below methods that iterate the maps currently loaded in the Player and set them enabled/disabled at the time the method is called. When new Controller Maps are loaded in the Player, either manually or when a Joystick is assigned, the newly loaded maps will be enabled/disabled based on the default enabled state settings for these maps on the Player page in the Rewired Input Manager, not based on previous calls to SetMapsEnabled. See this if you need to persistently set certain Map Categories enabled and others disabled.

I suggest you use Map Enabler for this task instead.

 

Hi Guavaman,

Thanks for making a solid plugin, it's been a real time saver for us on our current project.

I am currently experiencing a bug on Apple TV when using the Siri Remote. In our game, we want the Menu button to act as "back" when in UI screens, navigating back to the previous UI screen. Last week I was on Unity 2019.2.11f1, and pressing the Menu button worked beautifully. Now, I've just updated to Unity 2019.2.19f1, and all of a sudden it's not working anymore. It seems like this particular button press is just not being detected by Unity C# code t all. The rest of the Siri Remote behaves normally, e.g. the touch area and click is working fine. It's specifically the Menu button that suddenly stopped working. I have zero changes to the RewiredInputManager prefab or the Unity Input project settings.

Note that the Siri Remote is definitely detecting the Menu button press, as the Apple TV light blinks as normal when pressing it.

Is this an issue you've seen or heard of? Do you know of any workarounds? I am currently diving deep into the Xcode project's iPhone_Sensors.mm file to try to debug the issue, as I suspect it may be a Unity issue and not on your end. But, if you could save me some time that would be amazing. Thanks!

 

Thanks! I'm glad Rewired is working well for you.

It's a new Unity bug. See these messages on the previous page of this forum thread:

https://forum.unity.com/threads/rewired-advanced-input-for-unity.270693/page-118#post-5415174
https://forum.unity.com/threads/rewired-advanced-input-for-unity.270693/page-118#post-5416953
https://forum.unity.com/threads/rewired-advanced-input-for-unity.270693/page-118#post-5418177
https://forum.unity.com/threads/rewired-advanced-input-for-unity.270693/page-118#post-5418222
https://forum.unity.com/threads/rewired-advanced-input-for-unity.270693/page-118#post-5418231
https://forum.unity.com/threads/rewired-advanced-input-for-unity.270693/page-118#post-5418282
https://forum.unity.com/threads/rewired-advanced-input-for-unity.270693/page-118#post-5418303
https://forum.unity.com/threads/rewired-advanced-input-for-unity.270693/page-118#post-5418333

 

I'm reporting a potential bug in the Rewired Input Manager debug information in the inspector.

This happened in the Custom Controllers Touch example, but I was able to reproduce it in my own project as well.
Under the Players portion of the Debug Information, both players 1 and 2 display the debug information for the custom controller assigned to player 1. (Both the controllers under player 1 and 2 say that they are assigned to player id 0, which can't be because the controller for player 2 should be, and is, in fact, assigned to player id 1).



This is shown correctly under the Controllers portion of Debug Information.



Not 100% sure if this is a bug or I'm reading it wrong, so I'd like if this can be clarified. Thanks!

 

Yep. 1 line of code bug getting the CustomController list to display for the Player from ReInput instead of the one passed into the function. Thanks.

 

Thanks for reporting the bug. It seems like it's so recent that it hasn't appeared publicly on the Unity Issue Tracker site just yet. When it appears can you link back to it in this thread and let us know? Definitely upvoting it ASAP

 

Good news friends, I have a dirty workaround for Unity's "Siri Remote Menu Button Not Working" bug in all versions after 2019.2.17f1.

1. Open Unity, do a normal Unity build targeting tvOS platform
2. Open the Xcode project that Unity outputs once it's done building
   
3. Open iPhone_Sensors.mm
4. Scroll down to the enum JoystickButtonNumbers definition (roughly line 347, but will depend on your exact version of Unity)
5. Take BTN_PAUSE = 19, which is the source of the bug here, change its value to 0, and move it to the top of the enum values list.

The final enum code will look like this:

Code (CSharp):

1. enum JoystickButtonNumbers
2. {
3.     BTN_PAUSE = 0,
4.     BTN_DPAD_UP = 4,
5.     BTN_DPAD_RIGHT = 5,
6.     BTN_DPAD_DOWN = 6,
7.     BTN_DPAD_LEFT = 7,
8.     BTN_Y = 12,
9.     BTN_B = 13,
10.     BTN_A = 14,
11.     BTN_X = 15,
12.     BTN_L1 = 8,
13.     BTN_L2 = 10,
14.     BTN_R1 = 9,
15.     BTN_R2 = 11,
16.     BTN_L3 = 16,
17.     BTN_R3 = 17,
18.     BTN_MENU = 18,
19.     BTN_COUNT
20. };

Voila, your Menu button is now working again.

 

This isn't a dirty workaround at all. This is actually fixing their bug. Excellent find! I didn't know this information was exposed in the build.

 

tvOS/iOS game controller issue;
https://issuetracker.unity3d.com/is...joystick1button19-instead-of-joystick1button0

@Benzor nice work on the fix.

 

Hello there,

I'd previously posted some questions about that amount of stick movement the InputMapper needs to recognise a stick has been moved... which you said was 0.7 but wasn't part of InputMapper and wasn't currently changable.

I wanted to ask if this might be something that could be enhanced to be changable.... to explain why. The functionality of InputMapper is great. I'm dealing with lots of different types of controllers of which almost all of them are unknown and will use a default template. The users are typically using 4 of anyone of 32 possible axis and each one can be setup completely differently, So it's very normal for someone to plug in a controller and have all the joysticks moving incorrectly, or only 1 or 2 sticks actually doing anything. So I stick up the remap controller page it prompts them to move the stick they want for each function and all is sorted. It's a 30 second job and is really simple



The problem comes when the controller input doesn't move the stick far enough. Now I'm sure you would say "calibrate it first" which is fair, but I'm trying to avoid presenting a page with 32 axis on it and 24 buttons to let people choose which axis it is they are using and then calibrate it properly. What I want to do is be able to detect it on my remap screen so they could use the calibrate sitcks option from within that.

Essentially I'm trying hide the complexity of the remap and calibration into something friendly... a page full of axis's would scare them!

What I'd like to do is to do my normal remap and if it didn't detect any or some of the axis in it's normal 0.7 setting have the option of being able to alter that threshold in order to pick that up. I've seen controllers having a range of as little as 0.3 before any calibration

 

I understand your problem, but like you said I would say, calibrate the axis first. It is the right solution to the problem.

Controllers are a fundamental part of the Rewired system. Actions are built on top of Controllers. The Action system is not meant to replace any functionality of the underlying controller, but to utilize that underlying Controller to feed the Actions. Calibrating an Action to account for problems in the underlying Controller is an improper use in the design of the system. Denying your users the ability to calibrate their controllers properly will lead to a lot of problems.

You don't have to display buttons on a calibration page. Buttons cannot be calibrated.

You don't necessarily have to display axes on the screen for them to select. You could detect the axis they want to calibrate by having them move it. But you will also be limiting their options. For example, with your simplified system, you can't set a dead zone, invert the axis, customize the sensitivity curve, etc. All of those features are available through proper calibration.

 

Surely the user experience... as well as what you might register in game are only actions. When you have a situation where we don't know what axis or stick or anything might come from, surely the approach is to ask the user to "move the stick for <insert action here>" rather than get them to calibrate every possible axis they might have?

Users do have the ability to calibrate their controllers BTW (in the bottom of the included screenshot, there's a "calibrate" button) But why would you calibrate if your sticks and zero points were correct to begin with? Axis reversal as well as stick sensitivity is handled in my own code.

I'm not trying to be argumentative here - it just don't understand how this is an improper design of the system. If there's a problem in the underlying controller it's the fact that we don't know which axis/stick/whatever the user wants to use for an action, so surely we'd ask? Please let me know what the recommended approach should be

 

Bought Rewired a long time ago, but didn't get a chance to use it yet. I'm now using Unity's new Input System, but I gotta say... I've subscribed to this thread for a long time, and I can't believe the level of support you provide for your asset. It's incredible!

Not only responding timely over such a long period of time, but also very detailed support. Amazing job.

 

Input Mapper was designed to detect user input with the basic assumption that the controller is at least somewhat reasonably calibrated -- at the very least that is has a reasonable range of motion. Your use case of RC controllers, which were never designed for use on PC's as game controllers and therefore most apparently don't work even remotely properly out of the box, is a very niche use case. Still, this could be corrected by allowing the user to calibrate the axes before mapping, but as you stated, you don't want to do this because you're afraid of scaring the user by showing them 32 axes in a list box. While that would be the most straightforward way, if you don't want to do that way, I've suggested you could approach this in other ways such as detecting which axis the user wants to calibrate. This would require some work to implement.

1) User tries to assign input of a poorly-calibrated axis with no result.
2) Pop up a dialog that asks if the user wants to calibrate the axis.
3) Tell the user to move the axis they want to calibrate, then re-center it and press a button. Detect which axis changed in value the most by watching each axis value in the Controller.
4) Proceed with calibration.
5) Poll for assignment using Input Mapper.

If you were to have access to changing the axis polling threshold, you would have to do a similar number of steps:
1) User tries to assign input of a poorly-calibrated axis with no result.
2) Tell the user to try again. Lower the axis polling threshold, and begin polling again for assignment.
3) User makes the assignment, but can't control the game properly because of poor calibration and has to then calibrate the axis that is assigned to the Action.

If you want to automate this so poorly calibrated controllers can be calibrated immediately by the user:
4) Pop up a dialog that asks if the user wants to calibrate the axis.
5) Proceed with calibration.

The only step you skipped from the previous system is the step of detecting which axis to calibrate because you effectively detected that by using Input Mapper to detect the axis in a very badly calibrated state which you could not otherwise do.

If you simply decide to lower the axis polling threshold to some very low number like .2 or .3 to cover all these problem devices from the start so you can skip step 1, you're all but guaranteed to run into problems of accidental detection of wrong axes, especially on 2D or 3D joysticks, accidental detection of joystick re-centering as an assignment, problems with noisy joystick axes with no dead zones being continuously detected blocking further assignment, etc.

Another simpler approach would be to have the user calibrate all axes simultaneously in a single step before making assignments. You can monitor all axes on the device at the same time and record min/max values. Have the user center all elements, then move all sticks and triggers through their full range of motion. Apply those recorded calibrations before making assignments. This would not allow them to set dead zones or inversions, but it would at least ensure all axes start with a reasonable range of motion before mapping. The more I think about it, the more I would recommend this approach since it is one simple step that would work for any controller.

This is definitely a difficult problem trying to allow the user to calibrate and assign what are essentially broken joystick axes while not showing them a list of axes to calibrate and have all this happen in the fewest steps possible. I don't know if there is a perfect solution.

The reason why I was saying this is an improper use of the system is that it appears you are trying to combine the Action and the underlying Controller axis into a single entity, turning the Action into an axis that can be calibrated, etc. Improper is not the right word, but it's sufficiently different that it makes things difficult. Because of your UI design, your user cannot modify any axis settings unless they have first mapped the axis to an Action. You are using that Action mapping to determine what controller axis they are using so you can then allow them to calibrate it. To the user, it appears they are calibrating the Action (Yaw) and not the underlying axis on the controller. Your Action then ultimately becomes the axis itself. This is why your design requires that you be able to detect and map badly calibrated axes to Actions before calibration.

One comment is that this design limits the user to assigning only one axis per Action, whereas the underlying design of Rewired permits the user to make as many element assignments to that Action as they want, obviously limited by UI space. This is likely not an issue in this case though.

This is the fundamental difference between our views. That the end user should only be concerned with Actions while the entire underlying controller element concept is completely abstracted away is not how Rewired was designed. Making it appear to work that way is difficult. Actions are an abstraction, yes, and the primary way the user interacts, but they are dependent on the underlying Controller system. Controller-specific settings like calibration are set on the Controller, per Controller, and Actions consume the resulting calibrated value. The Player-Action system is an abstraction layer on top of Controllers, but it was not meant to completely replace the underlying controller system. Completely hiding the controller system with Actions even to the extent of calibration is a design choice, but not how Rewired works generally. This distinction between Actions and controller elements is visible to the user in all Rewired examples, for example, Control Mapper, where the user can set axis calibration independently of the Action mappings, the user can see the controller elements that are mapped to Actions, etc.

I'm guessing you're performing these transformations on the resulting values of the Actions. I would imagine so based on the above information. This would align with the design choice to use Actions as a representation of controller elements themselves.

Consider that a sensitivity curve applied to an Action will have very different results with different controllers. Switching controllers would then require the user to re-calibrate sensitivity. You would probably want to save this value per-controller so the user wouldn't become frustrated if they were to switching back and forth between two controllers, having to redo their sensitivity every time. And in the case you are doing that, then I would think you might as well just apply the sensitivity to the underlying axis instead of the Action because that information can be saved in the Axis Calibrations per controller with dead zones, etc. (Although dead zones on Unknown Controllers are always treated as axial dead zones because Unknown Controllers have no concept of 2D sticks from which to calculate a radial dead zone. In this case there may be a disadvantage to using the actual axis dead zone as opposed to a simulated 2D Action "stick" with dead zones calculated afterwards as you are doing...)

The same would hold true for axis inversion. The Action (Yaw) may need to be inverted for one controller and not the other due to differences in underlying hardware. Again, this value needs to be saved per-controller or the user would get frustrated if switching between controllers and being forced to re-invert the Action each time.

With all that said, I will change the system to do what you want it to do even though I don't think the change would be very useful in other circumstances. I don't know how soon I will be able to do this because of pending problems getting Unity 4.3 running again on my system due to a change Unity made to the license server that prevents me from running it. I can't publish any updates to the asset store until this is resolved, otherwise I have to skip updating Unity 4.x and I don't want to do that. Contact me privately or by email and I will send you a beta build with the changes.

 

@CurryKitten you should talk to @devotid he has been using RC Controllers for years with Rewired including Calibration and mapping. From around 2015 time frame I believe. He has few games on Steam that support RC controllers. So he would be a good person to to talk to.

Are your games going expected to go on steam also?

@devotid has RC Controllers working with Rewired for a long time with a few different games on steam. I know his RC Simulation 2.0 (uses air/land/sea vehicles) is on steam and he does put great emphasis on using RC Controllers. He seems like a perfect person who could provide a good example on how he uses RC Controllers with Rewired.

http://rcsimulation.com/game-info/

A quote from his controller section ...

 

Thanks for the help!

The one comment I would make is that devotid chose to present controller remapping using Control Mapper and therefore the user has to calibrate their axes before mapping by selecting from a list of axes. @CurryKitten stated that he doesn't want to do this, so this approach doesn't meet his needs.

 

Thanks @longroadhwy There's no real issue in supported them, and as far as most modern RC radios go, it's the case of plugging them in via USB and everything is happy. The problems are appearing based on the seemingly infinite variety of radios, or USB dongles people are managing to lay their hands on which have some odd quirks.

I'm considering putting it on Steam just from the fact that everytime I put a new alpha build up there's a number of confused posts from people who seem unclear how to download and run something... these people need things to update automagically.

As much as I'd like to keep the control axis abstracted away from the users @guavaman it seems like I'm going to have to bit the bullet and come up with some sort of "advanced controller mapper" UI should the basic one let them down, so a user can pick which axis to use manually and then calibrate based on this. Whilst the majority of users are fine and working correctly, the ones that don't seem keen to let me know about it !

 

My suggestion above would eliminate the need for this:

"Another simpler approach would be to have the user calibrate all axes simultaneously in a single step before making assignments. You can monitor all axes on the device at the same time and record min/max values. Have the user center all elements, then move all sticks and triggers through their full range of motion. Apply those recorded calibrations before making assignments. This would not allow them to set dead zones or inversions, but it would at least ensure all axes start with a reasonable range of motion before mapping. The more I think about it, the more I would recommend this approach since it is one simple step that would work for any controller."

Also, I stated that I would be making the change you are asking for.

 

Yes - I think having given it some thought, I think I like the lets-calibrate-everything-together approach. Right now I'm going to be putting multiple things in... purely because I'm having to spend a disproportionate amount of time with people who can't seem to get their controllers working.... even models which I know and have tested are plug and play.

So the calibration-everything-together should fix one set, the visualisation of all the axis should give me something I can tell them to screen capture against when there's these corner-cases I can't reproduce, but I would like to have control of the inputmapper detection threshold... so I appreciate the change.

I mostly look forward to nobody emailing me about radios not working.... so worth the effort in this iteration to do more than I need to fix things

 

After some more thorough testing, there is one additional bug that needs fixing in order for the code to be fully backwards compatible. You should also go to line ~590 ish and comment out this entire chunk:

Code (CSharp):

1. if (@available(iOS 13.0, *))
2.     {
3.         ReportJoystickButton(idx, BTN_MENU, [gamepad valueForKey: @"buttonMenu"]);
4.         ReportJoystickButton(idx, BTN_PAUSE, [gamepad valueForKey: @"buttonOptions"]);
5.     }

If you don't also comment out this code, your MFi controller left stick X-axis will not work. Apple TV Siri Remote will still work fine.

After this additional fix I've been able to have everything working flawlessly on both Siri Remote and Nimbus MFi gamepads exactly like it was before Unity's bug.

 

I don't know exactly how your UI works, but one thing I would make sure you do is allow them to explicitly select the controller to use in case multiple controllers appear on the system. This is critical to avoid common problems when people have weird drivers or mapping tools installed that create virtual devices on the system that stay always present and but provide no input.

 

Hi @guavaman I had one more bug question for you.

On Mac OSX builds, I notice that the Unity game instance will receive old inputs from a gamepad after it regains focus. Specifically, here are the steps to repro the issue:

1. Launch the Unity-built game, with a gamepad connected (e.g. PS4/Xbox One/Nimbus, etc., they all behave the same).
   
2. Navigate to any menu where a single gamepad button press will have an obvious effect (for example, when in the main menu of the game, pressing B will probably open a confirmation popup asking you if you want to quit the game).
3. Press Command-Tab so the game loses focus.
4. Press the B button on the gamepad while the game is hidden
5. Press Command-Tab to reopen the game.
6. Notice that the B button press from earlier will immediately be performed after the game regains focus.

This works for all buttons on the gamepad. This causes all kinds of fun issues like accidentally resuming the game while in a level when pressing A after Command-Tabbing out, because the pause menu will be open with "Resume" selected by default. So this is not ideal for players.

Note that this behaviour does not occur on Windows, only on OSX. I am using Rewired 1.1.26.1, Unity 2019.2.19f1, and macOS Catalina 10.15.2.

Is this a bug that you are aware of? Do you know which layer of the input stack causes it (e.g. macOSX, Unity, Rewired)? Do you know of any workarounds?

Thanks as always for your speedy replies.

 

It can only possibly be an artifact of the fact that 1) Input is retrieved from OSX IO Kit as events and are delivered to the application without regard to focus. 2) You have Unity set to not update while in the background. Rewired has received the event from IO kit, queued it, and Unity is not allowing Rewired to update itself and process said event until the application gains focus again.

I would have to add code to clear events when the application gains focus but ONLY in the case you do not have Unity set to run in background and/or block events that occur while the application is in the background. I do not know whether I would want to do this or not or what other effects this might have. Off the top of my head, I can tell you that pressing and holding any button (or having a button that is always on such as a toggle button or dial switch) while not in focus then re-focusing will result in this button not being detected if values are cleared. Another case: If I do not clear but just ignore events while out of focus, a button held down before the application loses focus and released while out of focus will remain on forever until that button is pressed again.

Event-based input APIs always have problems like this.

 

Yes - thanks. I've run into this with windows deciding odd things are joysticks and wanting to use them in game. I'm just working on the code at the moment to let a user chose the joystick he wants.

On the plus side, I changed the calibration function to do all axis at once (actually I picked an arbitrary figure of the first 8 axis) and this worked well to fix the problem of the controllers with very small range - they could be easily remapped after this. Thanks for that suggestion - was actually more straightforward than my original function

 

I am going to be changing it to discard all input events received when out of focus if Run In Background is disabled. I cannot clear events because of the above issues I mentioned. This leaves the artifacts that if a button is held, application loses focus, then released, the button will be stuck on when the application receives focus again, and if a button is pressed and held when out of focus and then the application is focused, the button will not be detected as on. There's no way around this with the event-based API, and past attempts to use the polling-based API lead to hard crashes on some controllers. This is best I can do. Note that this issue only applies when "Run in Background" is disabled.

 

Hi @guavaman !

I'm absolutely loving this asset. Its the perfect solution for our game

I am having one issue that I can't seem to find anywhere in the documentation mentioning it: The first input poll (for any of my registered actions) returns a false positive - returns true when it no input has been provided.

The repro is pretty simple, I have two objects in my scene, one is the rewired input manager, and the other an object with a monobehaviour that simple does this:

Code (CSharp):

1. private void Update()
2. {
3.             foreach(Rewired.Player player in ReInput.players.Players)
4.             {
5.                 player.GetButton(DuffinsAction.Ability1.ToString());
6.                 {
7.                     Debug.Log("Input!");
8.                 }
9.             }
10. }

I have two Players set up (0 and 1) in my rewired input manager. After I launch the scene, I see in the console two printouts:
"Input!"
"Input!"

Why is this? this seems to happen regardless of whether or not my controllers are plugged in. If this is intended for the first poll, what is the best way to step around this?

Thanks so much for your help, and again, for such a great resource!

EDIT: Actually it seems to be printing every frame! I had some other code that only made it print once... Any idea why the player would keep evaluating an input to true?

EDIT 2: honestly, I'm a moron.

player.GetButton(DuffinsAction.Ability1.ToString());

is not a dang valid if statement. I really need to take a break...

Anyways, this changes nothing...THANKS FOR THIS ASSET <3

 

Glad you're liking Rewired and that you figured out the problem, though it's not entirely clear to me whether you figured out your original problem or just the bug in your repro code.

 

Rewired 1.1.30.0 is available on the Unity Asset Store.

Please see Updating Rewired before updating.

Release Notes:

1.1.30.0:

Changes:
- Windows Standalone: Added additional workarounds to prevent Raw Input mouse and keyboard registration from being reclaimed by Unity when making various sequences of calls to display and screen settings in Unity at runtime in a build.
- Windows Standalone, Raw Input / Direct Input + Native Keyboard Handling: Changed Shift key handling to prevent issues with the wrong Shift key being activated or deactivated by Shift key events generated by Windows when shifting number pad keys.
- Windows Standalone, Raw Input / Direct Input + Native Keyboard Handling: Changed Control key handling to filter out extranneous Control key events generated by other non-Control keys when using some non-US keyboard layouts.
- Corgi Engine integration:
- Updated minimum Unity version to 5.6.7f1.
- Fixed PrefabUtility.DisconnectPrefabInstance deprecation warning message in Unity 2018.3+.
- OSX Standalone, Native: Low-level joystick events are now discarded when the application loses focus and Unity Player -> Run in Background is disabled.

API Changes:
- Added Controller.Axis.pollingDeadZone property.
- Added ReInput.ConfigHelper.defaultAbsoluteAxisPollingDeadZone property.
- Added ReInput.ConfigHelper.defaultRelativeAxisPollingDeadZone property.

Bug Fixes:
- Gamepad Template: Removed duplicate Right Trigger mapping for Xbox 360 Controller.
- Fixed error in Debug Information possibly displaying a different Custom Controller than is assigned to the Player.

 

Hello guavaman, I'm trying to run the installer again(Window->Rewired->Setup->Run Installer) in Unity 2019.3.0f6 and Rewired fails to set the execution order for the Rewired.InputManager script. I can not set it by hand either because it does not show up in the list of scripts to choose from, and I can not drag the script onto the execution order panel. Adding [DefaultExecutionOrder (-32000)] to the top of the class does not work either. Do you know if there's a way I can still run the installer?

 

There are no issues with the installer in 2019.3, therefore there must be a problem in your project. If the installer is not running, something is preventing it from doing so. Fix any compiler errors because these will prevent it from running.

Do a complete clean install:
https://guavaman.com/projects/rewired/docs/Troubleshooting.html#clean-reinstall

 

We are upgrading our project from 2019.1.4f1 to 2019.3.0f6 so that must be the cause, I will try the clean reinstall

 

I bought Rewired under my own Unity account instead of the company owner and followed the clean install guide here https://guavaman.com/projects/rewired/docs/Troubleshooting.html#clean-reinstall but I still have the same execution order problem. Do you have some more advice on how to upgrade a project from 2019.1.4f1 to 2019.3.0f6 which contains Rewired? If you need more information please let me know.

 

Rewired seems to work after installing Rewired in a new project, then adding the old project package while ignoring the rewired folder from the package. But now I see: Error: Could not load signature of Rewired.Editor.ComponentControls.TouchInteractableEditor:GenerateInteractableAnimatorContoller due to: Could not load file or assembly 'UnityEngine.UI
Not sure what this is, perhaps you do, but I'll see if I can find a solution

 

See the notice at the top of the documentation page:
https://guavaman.com/projects/rewired/docs/

This issue has been there since 2019.2 came out. Unity keeps fixing it but they've not been successful yet. It keeps reappearing. Their change to move the UI system to the package manager and then retroactively try to make it compatible with DLLs that reference it has been a big problem. There is nothing I can do to make this go away. Ignore it.

 

I really don't have any more advice. I don't know what is causing this, so I don't know what to tell you. I suggest you contact Unity about this because this issue is obviously not supposed to happen if the editor API is working properly. Something is broken in your project and I don't know what. All I can possibly think of is to delete your Library folder.

 

There are 5 things that will throw this error. Most will log something in the console with more information and not just show you this modal box:

1. The Rewired.InputManager class is not found when Rewired searches for it by reflection in all assemblies. This would indicate Unity is not loading the Assembly-csharp.dll it generates from the scripts in the project. Question: Are you using ASMDEF files in your project? Rewired searches ALL loaded assemblies to find this class specifically to be compatible with ASMDEF causing it to be compiled to a different assembly than Assembly-csharp.dll or Assembly-csharp-firstpass.dll, but this is always a potential for issues, especially if they changed something.
2. The Asset Database Guid of the InputManager.cs script does not match what it expects. This would indicate something changed the file guid. There may be another file in the project that already claimed the guid. Watch for guid warning errors when deleting and re-importing the Rewired folder.
3. Rewired_Core.dll could not be found. This is part of the base Rewired distribution and would indicate some kind of Asset Database problem if it can't find this file.
4. The Rewired.OnGUIHelper could not be found. This is part of Rewired_Core and should not be possible. This would indicate some kind of Mono error.
5. The Rewired.Initializer could not be found. This is part of Rewired_Core and should not be possible. This would indicate some kind of Mono error.

None of these errors should happen and there's nothing that be changed in this code to make the above work. Each issue indicates either a problem in the project (guids) or a problem in Unity (not finding files that are in the project, assemblies, or classes within a loaded assembly.)

You stated before that you cannot even manually add the InputManager script to the Script Execution order. If this is the case, this is obviously a Unity error that needs to be reported to them. There is nothing special about InputManager.cs. It's a normal MonoBehaviour C# script. It's Unity that isn't working, not Rewired, so they need to help you fix this.

Even if you do manage to get InputManager.cs added to the script execution order, you also need to add Rewired.OnGUIHelper (-31990) and Rewired.Initializer (-31999) to script execution order also. These classes are in Rewired_Core.dll.

 

Good day, i`m looking to try out Rewred to add it to alpha release of a product.
Need to replace Unity Input System preview 4 (just because it doesn`t have ANY key maps after build).
Can you pretty please tell me - would it be very hard to do?

 

That's a really difficult question to answer. I would have to know how you've programmed your current game, your experience level with Unity and C#, and would have to figure into it how long it would take you to learn the system.

I suggest you read the documentation and download the free trial and determine if it's easy or not for yourself:
https://guavaman.com/projects/rewired/docs/
https://guavaman.com/rewired/trial

 

Thank you for all the help it definitely helps me to find where to look for more specifically.

The other scripts were in the execution order but not the InputManager.cs Unity likely a mono error because it can not access InputManager.cs through code even though the file is there. Only InputManager_Base.cs was referenceable

 

If the InputManager class is not being loaded by Unity, Rewired won't function. It's required for runtime execution.

 

Thanks for infos, got it working allready
But i seem to have a couple of problems you could give an assistance in ?
First - i can`t seem to make a mouse work in controls mapping menu.
I mean it does work and buttons can be changed, but i`m kind of unable to click-select fields.
Second - possebly a problec coming from logitech g13 side keyboard - on start it sees unknown controller and maps it as default one, Wich is kind of weird:

 

Look at your Rewired Event System settings.

1. Make sure Allow Mouse Input If Touch Supported is enabled.
2. Disable the new input system:
   https://guavaman.com/projects/rewired/docs/KnownIssues.html#not-compatible-unity-new-input-system

There's nothing you can do about it. Rewired will only see devices as Joysticks if they identify themselves as Joysticks or Gamepads in the HID descriptor. There's no way I could possibly block devices like this apart from building a blacklist of vendor/product ids if they even give valid information at all. That's not a viable solution. This is one of many reasons why you must always give your users a way to assign and unassign joysticks and not just rely on auto assignment..

 

@guavaman
Hi, I've had Rewired for years.., today i went to test Rewired + UFE 2 and everything works fine in Unity.
But when I start the game on Mobile (Android) the joystick with the buttons is not displayed.
Do I miss something.
It only works on Mobile if I remove the beak from "Hide Touch Controls When Joistick Connected", but then it shows up everywhere in the game, meniu,...

I apologize for my bad English.

 

Tryed both - doesn`t seem to work.
I do have new input system preview4 installed, because some assets have links there and will drop errors if uninstalled, but switched to InputManager in settings:

Problem still presists - mouse buttons do work when assigned, but selection and axis are unusable in input manager.


UPD:
If i use "Open on Start" in inputManager - it recives mouse input and allows click-selection.

 

Then that can only possibly mean there is a joystick being seen by UnityEngine.Input.GetJoystickNames and therefore Rewired, hence your controls are being hidden.

 

How are you opening it otherwise?

Do you have some UI layer blocking the Control Mapper canvas catching raycasts and preventing the UI from receiving these events?

 

Had to debug by disableing component-by-component.
Problem was with sorting layers on Canvas - base setting 0 was overthrown by a backround plane from another canvas with same sorting layer.
Rised Mapper canvas sorting layer to 100 - works fine now

 

I just thought of that and edited my post above with that question right before you replied. Glad you figured it out.