ReInput Class

Gets an object that provides access to configuration-related data.

Gets an object that contains all controller-related members.

Gets an object that provides access to glyph-related data.

Is the input system ready?

Gets an object that provides access to localization-related data.

Gets an object that contains all mapping-related members.

Gets an object that contains all player-related members.

Gets the current Rewired version number as a string.

Gets an object that provides access to time-related data. This is mostly for time comparisons for button and axis active/inactive time measurement.

Gets an object that contains all touch-related members.

Does the current platform require manual joystick identification?

Gets the UserDataStore component attached to the Rewired Input Manager if any. Use to access data saving and loading.

Is Unity (fallback) input currently being used to drive input?

Completely clears and reinitializes the Input Manager. This is equivalent to destroying the Rewired Input Manager and reinstantiating it. The current input configuration (Joystick ids, controller assignments, modified Controller Maps) will be reset. All stored references to Rewired objects (Player, Joystick, ReInput.ControllerHelper, etc.) will become invalid. All event listeners will be cleared.

This can be used to update the system state manually. Controller input values will be updated, Action values updated, button frame events reset and recalculated, and various other events triggered (controller connect / disconnect, etc.) The Manual update must be enabled in the Rewired Input Manager settings for this function to have any effect. Each time this function is called, a new input frame will begin. Input and button events will remain valid until the next input frame. Button up/down events of all types (double click, etc) and axis delta values (mouse axes, etc.) are frame values. That is, they exist for one input frame and then are cleared on the next frame. Because of this, when and how often Update is called is very important for consumers of input using the polling method. Input should be updated on a 1:1 ratio with polling consumers of input, and update should occur in the loop before input is consumed. Automatic mode allows you to choose multiple update loops and each will track frame values independently, but when using Manual update mode, it is only possible to track these values for one input update loop. This means you cannot reliably consume input in multiple loops that may update at different rates, such as consuming input in both MonoBehaviour.Update and MonoBehaviour.FixedUpdate. Calling this function immediately before consuming input will have no effect on input latency on those platforms, input sources, or devices that do not support multi-threaded input or those for which Rewired doesn't have a multi-threaded implementation. NOTE: If you are attempting to update input manually in order to reduce input latency, realize that not all platforms, input sources, or devices can be updated at an arbitrary time. WARNING: This must be called only from the main thread! WARNING: All Rewired addons (integrations, RewiredStandaloneInputModule, Control Mapper, Touch Controls, Player Mouse, etc.) require input to be calculated correctly in the MonoBehaviour.Update loop. Specifically, button up/down events, and for some, mouse axis delta values, must be available for the entire Update frame in order for these addons to read button events correctly. When you choose to manually handle updating, Rewired cannot run the normal update in the Update loop when Manual update mode is used, so these addons may not function correctly depending on when or how often you choose to update input. If you update input multiple times in a Unity frame, for example, button up/down events may be reset before the MonoBehaviour.Update is called in these various addons, causing missed button events and incorrect axis delta values. Because of this, addons may not function correctly if you choose to use manual updating. WARNING: Rewired has different dependencies for input on different platforms depending on the input sources in use and the devices in use. If the input API in use for the device in question is unable to provide new input values by the time you call ReInput.Update, there will be at least a 1-frame lag in input. This depends entirely on when you choose to update input and the specific input API in use for connected input devices. For example, if you are using this to support updating input in an ECS System that you have set to run before UnityEngine.Input's update executes, any devices on platforms that rely on UnityEngine.Input will retrieve an outdated value from UnityEngine.Input because it hasn't updated yet. Whether this is an issue is dependent on order of execution. Unity has exposed low level functionality (PlayerLoop) that allows changing execution order of various events. You must know exactly what you are doing if you intend to run the Rewired update manually any earlier than MonoBehaviour.Update.

Event triggered when a controller is conected.

Event triggered after a controller is disconnected.

Event triggered just before a controller is disconnected. You can use this event to save controller maps before the controller is removed.

Event triggered when editor begins recompiling scripts.

Event triggered after Rewired initializes. Event listeners are never cleared from this event when Rewired is shut down so you can subscribe once and receive events every time Rewired initializes.

Event triggered before all input sources are updated. Use this event to update the element values Custom Controllers.

Event triggered immediately before Rewired shuts down. Rewired objects are still valid during this event.

Event triggered after Rewired shuts down.