Unity gives no indication of which one of the four it was.
So when a controller disconnects, one of those identical names in the list disappears. If you connect four identical controllers-a fairly common scenario-then you'll get four identical names in the list and the order of the list is undefined (regardless of the player lights on the controller, for example). The problem with Unity Input is (and I've complained to Unity at length about this) the only identifiers it gives you is the names in the Input.GetJoystickNames list.
#Incontrol unity disable controller mac
Native input is only supported on Windows and Mac and can be enabled in the settings.īut if the native input module is not enabled (and I really do recommend everyone use the native module whenever possible) then InControl has to default to using Unity Input under the hood. Next, we’ll look at more advanced topics like rebinding at runtime, iterating through all the actions and bindings for user interface purposes, as well as saving and loading the complete state of an action set.Click to expand.The tldr is that InControl does (and has for a couple years) had a native input module that gets around this problem using direct access to native OS input and doesn't disconnect all controllers when one disconnects since it can properly hook into OS level events. The device is merely an optional context, however, an action set cannot be assigned more than one gamepad device. Keyboard and mouse binding sources will naturally ignore this device for the action set. The default value of null means use the current active device.
This can be overriden by explicitly setting the Device property on the action set. This can become a serious slowdown problem if you create a lot of them over the lifecycle of your application and never properly dispose of them.īy default, the device binding source will read from InputManager.ActiveDevice, the device which last provided input, which is perfect for single player games. Note: It is important to call Destroy() on your action set if you no longer need it, otherwise it will add additional updating overhead. Public class CharacterController : MonoBehaviour Īnd that’s it! We’ve defined actions for our player character and bound each action to multiple controls.
The basic actions your character has is “Move Left”, “Move Right” and “Jump”.įirst we need to create a subclass of PlayerActionSet called M圜haracterActions that defines these actions: Let’s say you have a simple platformer-style game. Let’s work through a simple example as an illustration. Actions can be bound to one or more controls represented by instances of one of the subclasses of BindingSource, although typically you would rarely, if ever, deal directly with these subclasses. Action sets can be easily saved and loaded along with their actions and bindings.Īctions are represented by instances of the PlayerAction class. They merely serve as a logical grouping of actions. Similarly, each player in a multiplayer game would likely have its own action set. An action set could be the actions for a single player, or something less specific like your user interface controls. To understand this part of the API, it helps to mentally separate actions in your game (such as “Move Left” or “Jump”) from specific controls (such as “DPad Left” or the “A” face button).Ī set of actions are represented by a subclass of the PlayerActionSet class. A solution for this problem is coming soon.įor an example, see the “Bindings” example at InControl/Examples/Bindings. Unknown devices cannot be bound since their input mappings are unknown and uncalibrated. Bindings can include mouse input, keyboard input and any of the standard or non-standard controls for supported devices. As of version 1.5.0, InControl has a new bindings API which supports binding controls to actions, allows rebinding controls at runtime and includes the ability to listen for new bindings on demand.
0 kommentar(er)
