A game about forced loneliness, made by TACStudios
tacstudios.tngl.sh
1using UnityEngine.InputSystem.LowLevel;
2
3////REVIEW: how do we handle the case where the OS may (through whatever means) recognize individual real-world users,
4//// associate a user account with each one, and recognize when a controller is passed from one user to the other?
5//// (NUI on Xbox probably gives us that scenario)
6
7namespace UnityEngine.InputSystem.Users
8{
9 /// <summary>
10 /// Indicates what type of change related to an <see cref="InputUser"/> occurred.
11 /// </summary>
12 /// <seealso cref="InputUser.onChange"/>
13 public enum InputUserChange
14 {
15 /// <summary>
16 /// A new user was added to the system.
17 /// </summary>
18 /// <seealso cref="InputUser.PerformPairingWithDevice"/>
19 Added,
20
21 /// <summary>
22 /// An existing user was removed from the user.
23 /// </summary>
24 /// <remarks>
25 /// <see cref="InputUser"/>s are only removed when explicitly requested (<see cref="InputUser.UnpairDevicesAndRemoveUser"/>).
26 /// </remarks>
27 /// <seealso cref="InputUser.UnpairDevicesAndRemoveUser"/>
28 Removed,
29
30 /// <summary>
31 /// A user has had a device assigned to it.
32 /// </summary>
33 /// <seealso cref="InputUser.PerformPairingWithDevice"/>
34 /// <seealso cref="InputUser.pairedDevices"/>
35 DevicePaired,
36
37 /// <summary>
38 /// A user has had a device removed from it.
39 /// </summary>
40 /// <remarks>
41 /// This is different from <see cref="DeviceLost"/> in that the removal is intentional. <see cref="DeviceLost"/>
42 /// instead indicates that the device was removed due to causes outside of the control of the application (such
43 /// as battery loss) whereas DeviceUnpaired indicates the device was removed from the user under the control of
44 /// the application itself.
45 /// </remarks>
46 /// <seealso cref="InputUser.UnpairDevice"/>
47 /// <seealso cref="InputUser.UnpairDevicesAndRemoveUser"/>
48 /// <seealso cref="InputUser.pairedDevices"/>
49 DeviceUnpaired,
50
51 /// <summary>
52 /// A device was removed while paired to the user.
53 /// </summary>
54 /// <remarks>
55 /// This scenario happens on battery loss, for example.
56 ///
57 /// Note that there is still a <see cref="DevicePaired"/> change sent when the device is subsequently removed
58 /// from the user.
59 /// </remarks>
60 /// <seealso cref="InputUser.pairedDevices"/>
61 /// <seealso cref="InputUser.lostDevices"/>
62 DeviceLost,
63
64 ////REVIEW: should we tie this to the specific device requirement slot in the control scheme?
65 /// <summary>
66 /// A device that was previously lost (<see cref="DeviceLost"/>) was regained by the user.
67 /// </summary>
68 /// <remarks>
69 /// This can happen, for example, when a gamepad runs out of battery and is then plugged in by wire.
70 ///
71 /// Note that a device may be permanently lost and instead be replaced by a different device.
72 /// </remarks>
73 /// <seealso cref="InputUser.lostDevices"/>
74 DeviceRegained,
75
76 ////TODO: bring documentation for these back when user management is implemented on Xbox and PS
77 AccountChanged,
78 AccountNameChanged,
79 AccountSelectionInProgress,
80 AccountSelectionCanceled,
81 AccountSelectionComplete,
82
83 ////REVIEW: send notifications about the matching status of the control scheme? maybe ControlSchemeActivated, ControlSchemeDeactivated,
84 //// and ControlSchemeChanged?
85
86 /// <summary>
87 /// A user switched to a different control scheme.
88 /// </summary>
89 /// <seealso cref="InputUser.ActivateControlScheme(string)"/>
90 /// <seealso cref="InputUser.ActivateControlScheme(InputControlScheme)"/>
91 ControlSchemeChanged,
92
93 /// <summary>
94 /// A user's bound controls have changed, either because the bindings of the user have changed (for example,
95 /// due to an override applied with <see cref="InputActionRebindingExtensions.ApplyBindingOverride(InputAction,InputBinding)"/>)
96 /// or because the controls themselves may have changed configuration (every time the device of the controls receives
97 /// an <see cref="DeviceConfigurationEvent"/>; for example, when the current keyboard layout on a <see cref="Keyboard"/>
98 /// changes which in turn modifies the <see cref="InputControl.displayName"/>s of the keys on the keyboard).
99 /// </summary>
100 ControlsChanged,
101
102 /*
103 ////TODO: this is waiting for InputUserSettings
104 /// <summary>
105 /// A setting in the user's <see cref="InputUserSettings"/> has changed.
106 /// </summary>
107 /// <remarks>
108 /// This is separate from <see cref="BindingsChanged"/> even though bindings are part of user profiles
109 /// (<see cref="InputUserSettings.customBindings"/>). The reason is that binding changes often require
110 /// </remarks>
111 SettingsChanged,
112 */
113 }
114}