Rewired - Advanced Input for Unity

Mouse and PlayerMouse are completely different things for different purposes.

Mouse is a Controller. It inherits from the Controller class. Controller types in Rewired are Joystick, Mouse, Keyboard, and Custom Controller. Controllers are created by the system, usually have some kind of hardware device backing them, can be assigned to Players, elements are mapped to Actions through Controller Maps, etc. Read about Controllers here:
http://guavaman.com/projects/rewired/docs/Controllers.html

PlayerController and the child class PlayerMouse are built on top of the Player system creating a type of virtual controller out of a Player:
http://guavaman.com/projects/rewired/docs/PlayerControllers.html

PlayerControllers are not part of the Controller system in Rewired. They exist above the Player level, using the value of Player Actions to drive the virtual elements. The only purpose for PlayerController at this point is PlayerMouse which is only used to drive a software mouse cursor around on the screen using Action values from a Player.

 

@Kruko

The PlayMaker Action "Get Axis Vector" does not use Rewired for input. That Action gets input form Unity's input system, not Rewired. The only exception is if you have installed and are using Unity Input Override. If that is the case, you must have those "Horizontal" and "Vertical" Actions created in the Rewired Input Manager, assigned on Controller Maps that assigned to Players, etc.

The Unity Input Manager settings you are showing also have nothing to do with Rewired. Rewired does not use the "Horizontal" or "Vertical" Unity Axes for anything whatsoever. Getting input through these Unity Axes means you are getting input from UnityEngine.Input, not Rewired.

Getting the Action though the "Rewired Player Get Axis" is the correct Action to use. However, if you have not set up Rewired correctly, this is always going to give you zero values.

There are several steps to setting up input for a joystick in Rewired.

1. Create Actions.
2. Create Players.
3. Define default Joystick Maps for the Joystick in question.
4. Assign those Joystick Maps to the Player in question.
5. Set up Joystick Auto-Assignment to assign the Joystick(s) as necessary.

All of these must be done or you will get no input when you query the value of an Action from a Player.

Debug Checklist:
http://guavaman.com/projects/rewire...l#debug-information-diagnosing-input-problems

The thing that determines which joystick axis (axis 0, axis 4) corresponds to which Actions is the Joystick Maps you have created. Being an Unknown Controller, you can only map one of two ways:

1) Make a map for Unknown Controller.
2) Map controls at runtime using something like Control Mapper.

 

Hello @guavaman

Ok, i created actions, players and joystick maps with auto-assignment of the joystick. I am using overrite unity input.

Input buttons (fire) are working ok, but Axis not so well. I put a few actions on the player to see what's happening.



This is what's happening when i'm not touching any buttons at all, Raw Axis has the value of -0.99.

When i press left, i get -1 for the RewiredAxis.
When i press right, i get 0.008
When i press up, i get 1
When i press down, i get 0.008

Variables in the Get Axis 2D Raw and Get Axis 2D just stay at 0.0, 0.0 all the time.

I checked the debug, the Axis react to input, except Axis 3, which is stuck again, i don't know why.



I created the joystick map for unknown controller and mapped every axis just in case




I don't know what else should i do. I even tried assigning joystick 5 to the player since it's the unknown one, but to no avail.

When i enable unity input, it works properly, but with unity input manager of course.

 

This checklist I posted before should be able to guide you to the problem:
http://guavaman.com/projects/rewire...l#debug-information-diagnosing-input-problems

Based on what you've posted above, the problem is most likely Controller Maps. Show me the Players page for Player 0 where you assigned the Joystick Map with Category: "Default", Layout: "Default" to the Player.

The Debug Information tool where you are viewing the Controller axis list can also show you whether the Joystick is assigned to your Player or not, the list of Joystick Maps loaded in that Player, every binding on that Joystick Map, and live values of the Actions in the Player.

Checking the Joystick's Axis list is only telling you one thing -- the Joystick's axes are working at the lowest level. It's not telling you anything about the Player level which is where Action binding takes place (Controller Maps) and other processing of the values (Input Behaviors).

That checklist link I posted takes you step-by-step through all the possible failure points in the stack.

My guess is it's one of the two things:
1) The Joystick is not being assigned to your Player.
2) A compatible Joystick Map is not being loaded into your Player.

 

Hi,

I'm using rewired and everything works very well!

Now I have a doubt, I'm with walk/run mechanic in a 2D platformer.

If the player is using a Gamepad, horizontal speed is going to increase with the movement of joystick, that's working good using Player.GetAxis("Horizontal").

When the player is using keyboard, I need to use Arrows (Left/Right) for just walk and Arrows + Left Shift for run.

That mechanic is working good with the keyboard too, but my doubt is how to detect if Player is using Gamepad or Keyboard in order to use one or other logic during gameplay, I don't want to force the player to choose between using onlye Gamepad or only Keyboard.

Maybe do you have any advice in order to get the best practice to achieve this? Thanks!

 

These are the most common methods:
http://guavaman.com/projects/rewired/docs/HowTos.html#last-used-controller
http://guavaman.com/projects/rewired/docs/HowTos.html#get-contributing-input-sources

 

When using the Input Module, clicking on empty space deselects the currently selected Button, is there a way to change that behavior?

Edit: For now I've commented out line 1011 of the Input Module which seems to do the trick

Also when the mouse is no longer the active controller, I set "Allow Mouse Input" to false, but the button that the mouse was hovering remains highlighted, selecting another button doesn't solve that, is there a way to clear the selection?

Edit: I seem to have found a weird solution to this, by disabling and enabling the hovered button during the same frame, it gets rid of the highlight

 

Hello @guavaman

Thanks for the troubleshooting link, it really means a lot. I sorted things out and everything works fine now. RTFM, as usual, i just needed some clarifications.

 

No. This is the intended behavior of Unity's input system. If you want to force an object to stay enabled, you can monitor the state of EventSystem.currentSelectedGameObject and set it to some value when it goes to null.

Disabling "Allow Mouse Input" does not fire any UI events. You would have to manually set the EventSystem's selected object to null.

 

Glad you got it working.

 

Sorry for a quick follow up question: is there a how-to page explaining how to handle both mouse and joystick input as a virtual on-screen cursor position?

 

In the built-in example I saw you are using PlayerMouse.Factory.Create(); but I have a feeling it's not player-oriented, is it the recommended approach?

====

Just to clarify, I am looking at this API doc:

http://guavaman.com/projects/rewired/docs/api-reference/html/T_Rewired_PlayerMouse.htm

- I want direct (hardware) mouse input support, so I needed to set useHardwarePointerPosition to true.

- But I also want keyboard and joystick support, which means I need to setup xAxis.actionName etc.

But do I still need to detect device? Like hasMouse, hasKeyboard ? Or are they handled dynamically without me worrying?

I think PlayerMouse is basically creating a virtual mouse with the same API like Mouse, but allow us to drive it using non-mouse device like keyboard and joysticks.

====

TL;DR: I should be using PlayerMouse instead of Player, as I want all source of inputs to drive a cursor position, instead of a player giving different types of inputs.

 

The Examples section of the PlayerControllers page lists two examples that show exactly that:
http://guavaman.com/projects/rewired/docs/Examples.html#player-mouse-sprite
http://guavaman.com/projects/rewired/docs/Examples.html#player-mouse-unity-ui

This is to create the instance of the PlayerMouse. You can create the PlayerMouse via code using the Factory class or as a Component and add that to a GameObject. The examples above show both approaches.

The PlayerMouse class doesn't know anything about Controllers. All it knows about is the Player. The Player is simply the input source for the PlayerMouse. It gets its axis and button values from Action values of the Player. Those can come from anything and all the usual rules apply for Controller assignment, maps, etc. being required for input. So yes, you must have the mouse and/or keyboard assigned to the Player in order to be used by the PlayerMouse because the PlayerMouse is getting its input from the Player. Without the Controller being assigned to the Player and valid Controller Maps assigned to that Player that bind Controller elements to Actions, you will get no input.

The only exceptions is when using useHardwarePointerPosition, it uses the Mouse's screen position to move the mouse and therefore it doesn't require any Controller Maps to map the mouse's axes to Actions to drive the pointer position. But the Mouse must be assigned to the Player (Player.controllers.hasMouse == true) or it won't get that information from the Player.

The overview of PlayerController in the documentation explains the design:

Overview
A Player Controller is a form of a controller that uses a Player's Actions as the source of input for element values. Essentially, it is a controller-shaped interface for a Rewired Player. Player Controllers were primarily developed for the Player Mouse which can be used to easily create a virtual mouse pointer which can be used to interact with Unity UI using any underlying controller type. Regardless, a Player Controller could be used for any purpose you want.

Player Controllers are not equivalent to other Rewired Controllers and do not perform the same function. They do not exist unless you instantiate them, they cannot be mapped with Controller Maps, their bindings can't be saved and loaded, etc. They exist completely separately from all other Controllers in Rewired, and they are completely managed from creation to destruction by you.

To illustrate the relationship between a Player Controller's element values and the underlying Player, take for example, a Player Controller with 2 axes and 1 button. These elements could be mapped as follows:

• X Axis = Player 0, "Move Horizontal"
• Y Axis = Player 0, "Move Vertical"
• Button 1 = Player 0, "Fire"

When you get the value of "Button 1" from the Player Controller, it is equivalent to calling player.GetButton("Fire") on Player 0.

Player Controller elements may modify the values received from the Player and output a processed value. For example, for a Player Mouse, you would normally want the X and Y axes to return relative delta values like a real mouse. The Player Mouse's axes can transform absolute axis input coming from a Player into a relative delta value so the consumer of the input can be written to simply expect mouse delta values.

Do not confuse Player Controllers with Custom Controllers. They do not serve the same purpose.

 

Apologize for another question: is there a helper function that converts action name to action index? I would love to centralized all input data to PlayerMouse and get input from it, but GetButton only takes action index AFAIK (unlike Player class).

EDIT: nm, ReInput.MappingHelper.GetActionId is what I need.

If I might offer a suggestion: I would love to have a better Rewired API doc, in terms of browsing and some navigation hints. The current doc has an issue where if you don't know the specific search term, you can't find the right answer. (like if I search for button instead of action, then I won't find this GetActionId, not even on Google):



EDIT: nm, generate RewiredConsts from Rewired Editor is even better...

 

Rewired's documentation is absolutely enormous. There are the equivalent of over 600 pages of text in the main documentation of how to's, examples, and general concepts alone not including anything in the API documentation. The API documentation is also incredibly large. All this took me literally many solid months of time to write. I apologize that it isn't perfect, but at some point you just simply can't afford to spend even more time on an area of the product, especially with support taking as much time as it does. There are many, many things I would like to add to Rewired (I have a todo list that would easily take a year of solid work), but I don't have the bandwidth to do it. Improving API documentation would be one of those areas that I'd love to, but just isn't the highest priority.

That's why the How To's page exists. To help you learn conceptual things about the system which will then inform API usage. One of the first How To's topics is Important Classes which points you to a few major classes that contain the most commonly used parts of the API. ReInput.mapping is one of these, which you eventually found. The API documentation is meant to be used along side all the other information provided in the main documentation.

 

Please clarify what you mean by this. PlayerMouse does not use Action Ids for anything except setting up the Element to Player Action links when you first create the PlayerMouse. PlayerMouse.GetButton does not take an Action Id. It takes an index, which is the button index of the button on the PlayerMouse. PlayerMouse also has leftButton, rightButton, middleButton, etc. properties so you can access them by name without knowing the index. The GetButton(index) method is provided by the PlayerController base class because that's an abstract base class that is meant to provide a generic interface for all subclasses. The subclasses can provide a more type specific interface like PlayerMouse does. You can also use buttonCount and GetButton to iterate over all the buttons.

Please be aware than an Id is not an index in Rewired. It's a unique id. If you delete action id 4, then next action you create will be action id 5 leaving a gap in the ids list. This is a very important distinction. This applies to all Ids in Rewired.

 

I don't understand what you mean by this. And now I have so many questions:

==== part A ====

Say I have this line (mouse being a PlayerMouse instance):

mouse.leftButton.actionName = leftButtonAction;

What's actually happening?

- Does this take input from leftButtonAction?
- Can I access the input via mouse.GetButton?
- How can I figure out the "button index" so that I can read that input?

This whole page doesn't mention button index once:

http://guavaman.com/projects/rewired/docs/PlayerControllers.html

==== part B ====

The reason for all these: I don't want to have both a Player instance and a PlayerMouse instance.

All I want is a virtual cursor, which takes inputs from any devices (mouse, joystick, keyboard), and tells me its current position on screen, and whether its "left button" and "right button" have been pressed.

Your built-in example already show me what I need to do:

- So far mouse.screenPosition is working for me.
- BUT mouse.GetButton doesn't, it doesn't work the way Player.GetButton work.
- Your example is using button state change events to listen for inputs, I want to poll for inputs, how?
- I am aware of mouse.leftButton.justPressed/justReleased, BUT how do I know that the button is being held down (eg. what you get from GetButton)?

==== part C ====

Please just assume I understand C#, and give me the shortest answer you can think of.

No need to hand hold me on this. I can read the doc, as long as it points me to an answer.

==== part D ====

Please also assume I have setup all the mappings, layouts, actions correctly.

 

I really don't know how to explain this any better than I have already explained in the documentation and here. You're not understanding what PlayerController is and how it works in relation to Player and Actions. I will attempt to draw a diagram.

-----------------------



----------------------



------------------



As before, the Player Controller exists above the Player and uses the Player's Actions as the source of it's element values. That's why it's called a Player Controller -- It is a Controller-shaped interface for a Player. You do not query a Player Controller by getting the values of Actions from the Player Controller. That would be pointless. You do that with a Player already. A Player Controller provides an interface that looks like a Controller -- it has Buttons and Axes -- for a Player (uses Actions). You query the value of the buttons and axes on the controller, not the Actions. Those buttons and axes are fed by the Actions in the Player. Those relationships of the source of input for each element are set up when you first create the Player Controller.

No, it doesn't. That's because that page provides a conceptual overview with some basic examples showing how to move a mouse pointer. Complete examples with source code are linked at the bottom of the page.

That's not possible. PlayerMouse is not a substitute for a Player. It USES a Player as its source of input. PlayerMouse can do nothing without a Player from which to get values from. Player is the central input class in Rewired. It is not optional if you want to use the Action system. You MUST have a Player and a PlayerMouse.

The input stack looks like this:

Player Mouse
|
Player
|
Controller Map
|
Controller

You are consuming input from the Player Mouse, but it is getting input from the Player, which is in turn getting input from the Controller based on the Action mappings defined in the Controller Maps.

If your PlayerMouse maps Left Button to the Action "Submit", your Player would have Controller(s) assigned and Controller Maps that map "Submit" to some element(s) on those Controllers, and in turn the PlayerMouse's Left Button will get the value of "Submit" from the Player from whatever Controller(s) are assigned and mapped with the "Submit" Action. If you have a gamepad with X mapped to "Submit", when you press X on that gamepad, the PlayerMouse's Left Button will return true. You are getting all the benefits of the Player-Action system including controller identification, developer-defined mapping defaults, user-remappable controls, controller type agnosticism, etc., while also having a Mouse-shaped interface that can be used to drive software cursors.

The PlayerController system is designed around the Player-Action system in Rewired. You can't toss out the Player-Action system and go directly to the Controller. The Player-Action system is what is responsible for making all the complex mappings and cross-platform controller support possible. All Controller Maps you define in the Rewired Editor exist only for the Player and are used to map Controller Elements to Actions in the Player.

PlayerController exists on top of the Player-Action system to allow you to control a cursor on the screen using the Player-Action system. The source of the Player's Action values do not matter -- keyboard, mouse, joystick, virtual controller, whatever. Player is a Controller container that abstracts away the Controllers themselves allowing you to get the input values from Actions instead of the buttons/axes directly. (You are certainly free to get input values from the Controller buttons and axes directly, but you can't do it by using Action ids because Controllers do not know anything about Actions -- the Player is responsible for managing Action values through the use of Controller Maps. This is the only reason Player even exists.)

PlayerMouse then creates a virtual mouse-shaped controller that uses the Player's Action values to drive the x, y, wheel axes and the buttons. This data can then be used to move your virtual cursor around using a fixed mouse-shaped interface.

You're comparing a Player to a Controller. Player uses an Action-based interface. You query values using an Action Id. Controllers do not work that way. Controllers simply have lists of buttons and axes and you get their values by index. The Controller Maps in the Player do the job of mapping from Controller element index to Action Id so you can get all your input using the Action system in a Player. PlayerController/PlayerMouse is meant to behave like a Controller, not like the Player. You get the values from its elements like you would from any other type of controller:

// both of these do the same thing
bool leftMouseButton = playerMouse.leftMouseButton.value;
bool leftMouseButton2 = playerMouse.GetButton(0);

If you look at the PlayerMouse API reference you will see only a few methods, most of which are used to get element values via polling:

http://guavaman.com/projects/rewired/docs/api-reference/html/T_Rewired_PlayerMouse.htm

GetAxis - Gets the current Axis value
GetAxisRaw - Gets the current raw axis value.
GetButton - Gets the current value of the button.
GetButtonDown - Gets the down state of the button. Returns True only on the first frame the button was pressed.
GetButtonUp - Gets the up state of the button. Returns True only on the first frame the button was released.

These are all analogous to the exact same methods in the standard Controller class.

mouse.leftButton.value

http://guavaman.com/projects/rewired/docs/api-reference/html/T_Rewired_PlayerController_Button.htm

There is a link to the above API reference from the PlayerMouse.leftButton page.

The only time Actions are ever needed when using a PlayerController/PlayerMouse is at the initial creation time. You must define the mappings that determine which Actions in the Player each controller element retrieves its values from. After that point, you never use Action ids again because the Action ids you set upon creation are stored. After that, the buttons and axes are just lists of buttons and axes as far as your code is concerned.

 

Thx!

This quote, literally this, is all I needed to know.

Comments:

(Yes I know internally Rewired has a Player associated with actions and controller maps. I am not tossing them out.)

(Yes I know you got all these API for accessing button state, I know them before asking, after all I have read your doc and API page multiple times.)

(My issue really was: I wanted to get the input, and as we can see, PlayerMouse was setup to get that input from the Player when we setup mouse.playerId, I didn't dispute that.)

(So when I said "I don't want a Player instance", I meant I don't want to do "Player.GetButton(ActionId)", I want to do "PlayerMouse.GetButton(Index)". Because we already know which virtual button in this PlayerController maps to which Player action, after all, we defined it!)

(So, while it sounds incorrect to say "we get input from PlayerMouse instead of Player", but we know what actually happens: the source of input are from Player, but code-wise, we are calling API from PlayerMouse, aka PlayerMouse.leftButton)

(What I didn't figure out, was PlayerController.Button.value is the state of button press. Just by looking at the API page. You would think "The current value" description is obvious, but it wasn't obvious to me at the time.)

(I swear if I had source code access to PlayerController, I would have read it already, and not bother you with this.)

(Also forgive me on using "id, index, button, action" interchangeably on my previous replies, I wasn't as "precise" in terms of glossary as you were: sometimes you just to have infer the meaning from context, and not take a new user's choice of words too seriously )

Now my final suggestion on this topic:

Now that we agree PlayerController defines a list of buttons, and define some convenient properties to access some of more commonly used buttons, can you update this page:

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

With a table of button names and their corresponding button indexes? Like leftButton = 0, rightButton = 1 etc.

You might think: "Why don't you use leftButton directly instead, and not think about button index?"

To that I answer: "Because I want to know, for example, PlayerMouse.wheel, can I get it using GetAxis(Id)? If so, what's the button index?"

I am asking this, knowing that I can get it via PlayerMouse.wheel.value; But I prefer to not rely on PlayerController.MouseWheel's interface, and prefer to rely on PlayerMouse interface. Because having less knowledge and dependence on a third-party API, is a good thing

(I am assuming these button indexes don't change, so leftButton is always 0 etc.)

Thx in advance!

 

The default PlayerMouse Axis and Button indices are identical to Rewired's Mouse class which is modeled after Unity's mouse. (CSV of the bindings can be found here.) But PlayerMouse is customizable, so you can make one with as many axes and buttons as you like. You would do this by passing a PlayerMouse.Definition to the PlayerMouse.Factory.Create function when doing this from code or just change the inspector settings when using the Component version.

The underlying indices of the elements may or may not be fixed depending on what type of buttons and axes you choose to create on your PlayerMouse and what order you put them in. So no, it's not guaranteed that Axis[2] will always be the wheel. You may not even have a wheel, in which case the wheel property would return null. PlayerMouse.wheel is just the first wheel found on the mouse. You may have more than one.

If you have to account for all these possibilities, you can search the PlayerController.buttons and PlayerController.axes lists to find the index that each of the mouse element properties corresponds to.

I didn't see it before now during this discussion, but the API docs do address this to try to give you an idea of what these properties correspond to:
leftButton - The left or first button.
rightButton - The right or second button.
middleButton - The middle or third button.
xAxis - The horizontal axis or the first axis.
yAxis - The vertical axis or the [second] axis. (bug in docs says "first")

The wheel doesn't state, but it should say the first wheel.

It's not a matter of just being "precise." I wanted you to understand that the term "index" in the method signature PlayerController.GetButton(int index) was important and not interchangeable with the "id" from Action Id which you were previously trying to use in this method call. The term "index" in the Rewired API signifies a sequential index, and that's the point. Using an Action id anywhere that calls for an index would be an error and the terminology is used in such as way as to try to avoid that.

Believe me, I have to do this every single day. It's not a new concept to me. Sometimes it is difficult to understand when there are conflicting things throughout the messages (such as saying you don't want both an instance of a Player and a PlayerMouse coupled with some things from the previous posts) that lead me to the conclusion that there's a fundamental misunderstanding of the concepts. Turned out that was incorrect here.

 

Hey there,

when I import the latest Asset Store version into an empty Unity project with Unity 2017.4.22f1 on Windows (64bit) I get first these two errors:

And then a bunch of Errors related to the IExternalTools.PS4Input scripts, like these:

 

That means you're importing Rewired for 2018 into Unity 2017. Please see this:
http://guavaman.com/projects/rewire...tml#installation-problems-and-compiler-errors

 

Ah I see, thanks, only thing is, how do I download Rewired again? I only see the "Import"-Button.

 

Delete the files from your computer. The folder locations can be found here:
https://docs.unity3d.com/Manual/AssetStore.html

 

Ah, manually then, alright. Got it also downloaded by changing to the old store. Everything works fine now

 

Good. If there a way I could make this not happen or easier to manage, I would, but this is completely up to the Asset Store system in Unity.

 

Not sure if that has been asked here before, but are their plans to utilize the new input system of Unity when it is considered to be ready or would the rewriting be too much effort? Just curious.

 

At some point, I will have to, because eventually they will deprecate and remove the old one. There's a ton to deal with including remapping every single device on all platforms that use it. It will not replace the platforms that already use native input since there is no advantage to using their new system over my already native libraries. Only platforms that don't have native input will benefit like Android.

Rewired would only utilize the new backend, not their new front end systems like controller definitions and Action mapping. That's the same thing Rewired already does.

 

Hi, please correct me if I'm wrong.
Sample game with 2 types of vehicles (air, land).
I've created 4 map categories:
1. Default - actions always available (open/close menu, screenshot)
2. Menu - actions used for UI navigation
3. Land vehicles actions
4. Air vehicles actions

While I'm in menus section only 1 and 2 are enabled, after entering game I'm disabling 2 (Menu) map and enabling 3 or 4. After pressing pause (from 1) I'm enabling 2 and temporary disabling 3 or 4. Is it correct use of map categories?

To store which map was enabled before pause I'm using "GetAllMaps()" unfortunately all maps have empty "name"

 

There is no "wrong" or "right" with regard to how you choose to use Map Categories. What you are doing here is exactly what I show in the examples.

The only part that is "wrong" is trying to keep track of your current game states using the currently enabled or disabled Controller Maps. Don't do this. Track your current states in your own code and make the Controller Maps follow what your code is doing. Read this on persistent state management:
http://guavaman.com/projects/rewired/docs/HowTos.html#persistent-current-controller-map-category

ControllerMap.name is useless and never used for anything. All selection of Controller Maps should be done with the Map Category and Layout. You cannot have two Controller Maps in the same Player for the same Controller in the same Map Category and Layout.

 

surely this has been asked already, so forgive me. Rewired is complaining it hasn't been designed for 2019, do you reckon I can use it anyway?

 

Here is what the documentation says ...

http://guavaman.com/projects/rewired/docs/Troubleshooting.html#unity-alpha-beta-preview-experimental

Alpha, beta versions of Unity, experimental/preview features of Unity are not supported
Rewired does not support any alpha or beta versions of Unity or any experimental or preview features in any version of Unity. Rewired may or may not work with these versions and/or features enabled and no explicit support for them will be added.

Every major release of Unity requires a branch of Rewired built specifically for that branch. When a new major version of Unity is in alpha or beta state, there will be no version of Rewired available for this major version of Unity. Once the final version is released by Unity, a new branch of Rewired will be released for download on the Unity Asset Store.

Guavaman Enterprises does not provide support for pre-release versions of Unity or unfinalized features.

 

In addition to what @longroadhwy said, the exact message displayed in the editor is this and includes the information you're asking for. I've highlighted the relevant part in bold:

The version of Rewired installed ([Version]) was not designed for Unity [Version]. Please install Rewired for Unity [Version]

This warning does not mean that Rewired will not function, but it may not function optimally.

Some different major versions of Unity download Asset Store assets to the same folder location on disk, so if you download an asset in one version of the Unity editor, then open another version of the Unity editor and install the asset without re-downloading it, the wrong asset version will be installed. To fix this, manually re-download Rewired in the Unity Asset Store panel in this version of the Unity Editor, then install it.

If you are using a beta version of a new major version of Unity, you will have to wait until the release of the final version before a compatible version of Rewired can be uploaded to the Asset Store. When the new version is ready, it will be available through the Unity Asset Store for download as usual.

 

yep I actually read only that part, as it was showing as warning, but didn't know you weren't supporting beta versions, which explains it.

 

When Unity 2019.1 is released, I will release a new branch of Rewired that is compatible with it. There are some known issues with running Rewired 2018 in Unity 2019 which have been fixed in the code base, but it is not ready for release.

I've tried to support betas and experimental/preview features in the past. It's a nightmare of making fixes and workarounds to bugs that get fixed by the time it's out of beta. It's a huge waste of time.

 

thanks

 

Quick question:

Within an update loop, if I want to access PlayerController.Button.value multiple times (via calls like PlayerMouse.leftButton.value), is it worth caching this value myself?

Thx.

 

Profile it and see if the time it takes is enough to justify it. You could do the same with every single property or method in the API (or any API). Runtime methods that are meant for use in in-game Update loop code are designed to be as fast as realistically possible.

This is the source code:

Code (csharp):

1. public bool value { get { return selfAndParentEnabled && player != null ? player.GetButton(actionId) : false; } }

IMO, that falls under the category of premature optimization. But that's a completely subjective judgement.

 

There's a workaround for this: https://forum.unity.com/threads/cas...kes-il2cpp-compile-error.648922/#post-4347619

 

That fixes also my issue with Standalone builds for Windows with 2019.1.0b9. Thank for heads up.

 

Is there any way to setup the default controller calibration for a built-in joystick map? I see you can do this for custom controller maps but i can't figure out how to do it for the built-in controllers.

Thanks!

 

There is no calibration in a Joystick Map.

Joystick Maps are part of the Player-Action system. The Player-Action system uses Controller Maps to bind Controller Elements to Actions in a Player. This is used to determine what Controller Elements active what Actions when querying a Player for input.

Calibration Map is entirely separate from the Controller Map system. It exists at the Controller level. It is not per-Player. Each Joystick contains 1 Calibration Map with 1 Axis Calibration per Axis in the Joystick. Settings are individual to each Joystick, and each Joystick can and does frequently differ per-platform, per-input source.

The Rewired Editor does not allow you to do set or override anything with regard to Joystick hardware. It is almost entirely concerned with the Player-Action system and everything involved in that system (Actions, Controller Maps, Input Behaviors -- all of which are part of the Player Action system.) The only exception is the creation of Custom Controllers in the Rewired editor.

A system that can do what you want it to would have to allow you to override every hardware element setting on every single recognized controller type in every combination of platforms, input source(s), and even including multiple different variants of controller definitions individually. No such system exists. You cannot set custom overrides on any Joystick hardware settings in any editors in Rewired. (You could change the settings in the hardware definitions themselves but this is highly discouraged because those settings will be lost when you update Rewired.)

The only way you can override Axis Calibration settings with your own developer-defined defaults is through code by detecting the controller and overriding the existing settings. I do not recommend you do this however and allow your uses to calibrate their own controllers as they see fit. Axis calibration is a very individual, device-specific concern. Even simple wear and tear can make two identical devices require different calibration settings.

 

Well in our case I am one of the developers of clone hero a rhythm game so we have a fairly limited set of controllers, and we want to change the default axis calibration for the primary controllers people use for the game which are XInput 360 Guitars. We already modify the Xbox 360 xinput controller hardware definition file to add the guitar sub-type so it detects the xbox guitars the same way it did a while(this changed at some point during a rewired update)

We need all controllers to use a 0 - 1 axis range for the whammy bars. Is there anything else that could easily let us do this?

For now i've figured out that i can just edit the asset with the debug inspector and enable calibration and set the ranges in there. I'd certainly prefer to have a more universal way of doing this however.

 

If we can get some proper XInput Guitar hardware maps that would be awesome as well. There is one issue here though. There is different kind of xinput guitars here that can have different axis layouts. The GH:L 6-fret guitars have the guitar tilt sensor, and the whammy axis swapped if you can think of any solution for that it would be nice but i'm not hopeful knowing how xinput works...

 

Nothing should have changed. The XInput Guitar has always been detected and treated as an Xbox 360 controller. It should still be. There is a separate definition for the Wheel, but the Guitar should be detected as a gamepad. If it's not, then it's broken.

There is nothing you can possibly do but modify the controller definition or override it in code.
http://guavaman.com/projects/rewired/docs/HowTos.html#identifying-recognized-controllers
http://guavaman.com/projects/rewired/docs/HowTos.html#calibrating-controller-axes

That's not how XInput is supposed to work. There is supposed to be a single, universal layout per device type. If that's the case, then there's no solution. XInput gives you zero additional information about the device, therefore it is impossible to detect the differences between different model controllers with different layouts. The only solution to this is to let the user assign mappings and calibrate the axes themselves.

https://docs.microsoft.com/en-us/windows/desktop/xinput/xinput-and-controller-subtypes

That's the only real solution. But the above statement that different guitars have different mappings makes doing this pretty much pointless.

 

@mdsitton I will make an XInput guitar definition, but it will be based on the official mappings published by Microsoft here:
https://docs.microsoft.com/en-us/windows/desktop/xinput/xinput-and-controller-subtypes

Do you happen to know the proper calibration (and inversion) settings for this mapping?

 

I apologize if this has been addressed here (or elsewhere), but I think this is a recent issue (don't recall this happening earlier). Basically, it seems that the D-Pad on Dualshock 4 (wired or bluetooth) doesn't output any values on Mac. This is tested on Mac OS Mojave, Unity 2018.3.11f1, and Rewired 1.1.24.0.U2018. To be fair, they don't output anything on html5gamepad.com either, but I'm 99% sure this used to work (I used to always play my own game this way). Just posting here on the off chance that this actually isn't a known issue... did OS X break this? Thanks in advance.

 

So it shouldn't need any inversion, for us at least having these calibration settings works best:
axisZero: -1
axisMin: -0
axisMax: 1

 

Nothing was changed in Rewired. It's a virtual certainty OSX broke it with some kind of new driver. Thanks for letting me know. I expect this is going to be impossible to detect without adding special case OSX version checking code to the controller definition matching system.

 

This is very interesting about various xinput guitars.

(1) Are you supporting only guitars that are XBOX 360 compatible I guess?
(2) Are you also supporting rockband guitars?
(3) Are you supporting both wired and wireless variants of various guitars?