0.9.0-preview now available

Unity Engine
,
1

0.9.0-preview is now available in the package manager. Release notes as follows.

[0.9.0-preview] - 2019-7-18

Fixed

  • Validate all parameters on public APIs.
  • Fixed an internal bug in InlinedArray.RemoveAtByMovingTailWithCapacity, which could cause data corruption.
  • Fixed Xbox controller support on macOS il2cpp.
  • Fixed issue of Xbox gamepads on Windows desktop not being able to navigate left and down in a UI.
  • Allow using InputSystem package if the XR, VR or Physics modules are disabled for smaller builds.
  • Fixed documentation landing page and table of contents.
  • Fixed tracked devices assigning pointer ids for UI pointer events correctly.
  • Adjusted some UI Elements to fit the Unity 19.3 font.
  • Fixed NullReferenceException being thrown when project changes.
  • Fixed duplicate devices showing in the “Supported Devices” popup when using a search filter.
  • Fixed an error when adding new bindings in the Input Actions editor window when a filter was applied.
  • Fixed scroll wheel handling in InputSystemUIInputModule not being smooth.
  • Fixed inconsistent ifdefs in NPad.cs for the swtich pro controller.

Actions

  • Fixed CallbackContext.control referencing the composite member control which was actually actuated for this trigger for composite bindings.
  • Generated C# wrappers for .inputactions assets are no longer placed in Assets/Assets/ folder on Windows.

Added

  • Touch support has been reworked and extended.
  • Touchscreen.touch[0..9] are now bindable from the control picker.
  • Touchscreen.primaryTouch is now a separate control which tracks the primary touch on the screen.
  • The controls Touchscreen inherits from Pointer (such as position, phase, and delta) are now tied to Touchscreen.primaryTouch and allow for Touchscreen to function as a generic Pointer (like Mouse and Pen).
  • Touchscreen.press (renamed from Touchscreen.button) is now a working, synthetic button that is down whenever at least one finger is on the screen.
  • Recording of start time and start position has been added to touches.
  • TouchControl.startPosition gives the starting position of the touch.
  • TouchControl.startTime gives the starting time of the touch.
  • Tap detection has been added to Touchscreen.
  • Tap time (i.e. time within which a press-and-release must be completed for a tap to register) corresponds to InputSettings.defaultTapTime.
  • Tap release must happen within a certain radius of first contact. This is determined by a new setting InputSettings.tapRadius.
  • TouchControl.tap is a new button control that triggers then the touch is tapped. Note that this happens instantly when a touch ends. The button will go to 1 and immediately go back to 0. This means that polling the button in Update, for example, will never trigger a tap. Either use actions to observe the button or use the Touch API from EnhancedTouch to poll taps.
  • Touchscreen.activeTouches has been removed. Use Touch.activeTouches from the new enhanced touch API instead for more reliable touch tracking.
  • Touchscreen.allTouchControls has been renamed to Touchscreen.touches.
  • A new EnhancedTouch plugin has been added which offers an enhanced Touch and Finger API to reliably track touches and fingers across updates. This obsoletes the need to manually track touch IDs and phases and gives access to individual touch history.
  • Touch can be simulated from mouse or pen input now. To enable simulation, call TouchSimulation.Enable() or put the TouchSimulation MonoBehaviour in your scene. Also, in the input debugger, you can now enable touch simulation from the “Options” dropdown.
  • Changing state has been decoupled from events. While input events are the primary means by which to trigger state changes, anyone can perform state changes manually now from anywhere.
InputState.Change(gamepad.leftStick, new Vector2(123, 234));
  • This change makes it possible to update state from state and thus synthesize input data from other input coming in.
  • A new API for recording state changes over time has been added.
var history = new InputStateHistory("<Gamepad>/leftStick");
history.StartRecording();
//...
foreach (var record in history)
Debug.Log(record);
  • Added support for generic joysticks on WebGL (which don’t use the standard gamepad mapping).
  • Added support for DualShock 3 gamepads on desktops.
  • Added support for Nintendo Switch Pro Controllers on desktops.

Actions

  • Actions now also have a polling API!
  • InputAction.triggered is true if the action was performed in the current frame.
  • InputAction.ReadValue<TValue>() yields the last value that started, performed, or cancelled (whichever came last) was called with. If the action is disabled, returns default(TValue). For InputActionType.Button type actions, returns 1.0f if triggered==true and 0.0f otherwise.
  • Generated C# wrappers for .inputactions can now placed relative to the .inputactions file by specifying a path starting with ‘./’ (e.g. ./foo/bar.cs).

Changed

  • The system no longer supports processing input in BOTH fixed and dynamic updates. Instead, a choice has to be made whether to process input before each FixedUpdate() or before each Update().
  • Rationale: the existing code that supported having both updates receive input independently still had several holes and became increasingly complex and brittle. Our solution was based on not actually processing input twice but on channeling input concurrently into both the state of both updates. Together with the fact that specific inputs have to reset (and possibly accumulate) correctly with respect to their update time slices, this became increasingly hard to do right. This, together with the fact that we’ve come to increasingly question the value of this feature, led us to removing the capability while preserving the ability to determine where input is processed.
  • NOTE: Timeslicing is NOT affected by this. You can still switch to ProcessEventInFixedUpdates and get events timesliced to individual FixedUpdate periods according to their timestamps.
  • InputSettings.UpdateMode.ProcessEventsInBothFixedAndDynamicUpdate has been removed.
  • InputSettings.UpdateMode.ProcessEventsInDynamicUpdateOnly has been renamed to InputSettings.UpdateMode.ProcessEventsInDynamicUpdate and is now the default.
  • InputSettings.UpdateMode.ProcessEventsInFixedUpdateOnly has been renamed to InputSettings.UpdateMode.ProcessEventsInFixedUpdate.
  • Added icons for PlayerInput, PlayerInputManager, InputSystemUIInputModule and MultiplayerEventSystem components.
  • Changed Keyboard IME properties (imeEnabled, imeCursorPosition) to methods (SetIMEEnabled, SetIMECursorPosition).
  • Added getters to all IInputRuntime properties.
  • Replace some GetXxx methods in our API with xxx properties.
  • Pointer.phase has been removed and PointerPhase has been renamed to TouchPhase. Phases are now specific to touch. PointerPhaseControl has been renamed to TouchPhaseControl.
  • Pointer.button has been renamed to Pointer.press and now is a control that indicates whether the pointer is in “press down” state.
  • For mouse, corresponds to left button press.
  • For pen, corresponds to tip contact.
  • For touch, corresponds to primary touch contact (i.e. whether any finger is down).
  • The state change monitor APIs (IInputStateChangeMonitor and friends) have been moved out of InputSystem into a new static class InputState in UnityEngine.Experimental.Input.LowLevel.
  • Rationale: These APIs are fairly low-level and not of general interest so having them out of InputSystem reduces the API surface visible to most users.
  • InputDeviceChange.StateChanged has been removed and is now a separate callback InputState.onChange.
  • Rationale: The other InputDeviceChange notifications are low-frequency whereas StateChanged is high-frequency. Putting them all on the same callback made adding a callback to InputSystem.onDeviceChange unnecessarily expensive.
  • IInputStateCallbackReceiver has been rewritten from scratch. Now has two simple methods OnNextUpdate and OnEvent. If implemented by a device, the device now has completely control over changing its own state. Use the InputState.Change methods to affect state changes while trigger state change monitors (e.g. for actions) correctly.
  • Simplified handling of XR input in InputSystemUIInputModule by having only one set of actions for all XR devices.
  • We now use the same hierarchical device picker in the “Add Control Scheme” popup, which is already used in the “Input Settings” window.
  • Made all IInputStateTypeInfo implementations internal, as these did not offer value to the user.
  • Made all IInputDeviceCommandInfo implementations internal, as these did not offer value to the user.
  • Removed ReadWriteArray, which was only used for making RebindingOperation.scores editable, which did not add any value.
  • Removed PrimitiveValueOrArray, as non of it’s functionality over PrimitiveValue was implemented.
  • Made all InputProcessor implementation internal, as access to these types is exposed only through text mode representations.
  • Removed CurveProcessor as it was not implemented.
  • Renamed XInputControllerOSX to a more descriptive XboxGamepadMacOS.

Actions

  • InputAction.continuous has been removed. Running logic every frame regardless of input can easily be achieved in game code.
  • The way action behavior is configured has been simplified.
  • The previous roster of toggles has been replaced with two settings:
  1. Action Type: Determines the behavior of the action. Choices are Value, Button, and PassThrough.
  2. Control Type: Determines the type of control (and implicitly the type of value) the action is looking for if the action is a Value or PassThrough action.
  • The previous Initial State Check toggle is now implicit in the action type now. Value actions perform an initial state check (i.e. trigger if their control is already actuated when the action is enabled). Other types of actions don’t.
  • The previous Pass Through toggle is now rolled into the action type.
9 Likes
2

Y’all have been busy! These all sound like great changes fixes!

1 Like
3

Just updated for the xbox controller fixes and now I have a new issue. I have 1 input set up as “Value”, “Axis” with 2 “2D Vector” bindings. 1 has W/A/S/D for the directions, the other has leftStick up/down/left/right. Without a controller plugged in, everything appears to work fine. With an xbox 360 controller plugged in, the axis inputs often get stuck. For example: I will push A (or left on the stick) to move left, and when I release I am stuck moving left. Pushing another direction will eventually reset the stick and let it begin taking input again. I have tried adding deadzones and that does not fix the problem.

This is the code I am using to hook up to the control:

playerControls.Ship.Direction.performed += ctx => spaceShipController.directionInput = ctx.ReadValue<Vector2>();
playerControls.Ship.Direction.canceled += ctx => spaceShipController.directionInput = Vector2.zero;

4765982--453158--Capture.PNG

3 Likes
4

I just updated to 0.9.0 and have a very similar problem. I have the A/S keys, left/right cursor keys, and the left/right gamepad dpad setup as 1D axes for the same action. Pressing any of the left (positive) controls will now make my ship rotate endlessly. The right (negative) controls work fine, as do all of the other bindings. Downgrading to 0.2.10 fixes the problem immediately.

1 Like
5

I’m also having issues with .canceled not working for inputs that share a binding (using Space for 2 actions). Reverting to 0.2.10 fixes that too.

6

I have the same problems with left/right directions sticking. It is possible to switch directions by holding up.

As InputAction.phase seems to not work I use ButtonControl to poll InputActions. The issue is that it triggers on several consecutive fixed updates. Next is the actual code I use inside FixedUpdate:

            for (int i = 0; i < inputAction.controls.Count; i++)
            {
                if (controls[i] is ButtonControl bc && bc.wasPressedThisFrame)
                //if (controls[i] is ButtonControl bc && bc.wasReleasedThisFrame)
                {
                    return true;
                }
            }

Reverting to 0.2.10 + Unity restart fixes both issues.

1 Like
7

Same problem here

There are currently 3 major problems:

  1. When the Xbox Controller, presumably also other Controllers, and the Keyboard are plugged in Movement Keys get Stuck. Only the positive Axis can override the current direction. (See posts above)

  2. If there are multiple callbacks in one frame, only one gets called. Even without a Controller pressing W & A and releasing them in the same moment (On the 10th try) one gets stuck and supplies Movement, while no Key is pressed. See this Thread: threads/mouse-delta-input.646606

  3. The mouse delta is “broken”. It returns wrong values, at least not the expected ones, even when setting the Input System to Update Manually and calling the Update in Update or LateUpdate. See this Thread: threads/multiple-callback-in-one-frame.710819

I really want to use the new Input Manager. Are there any updates on these problems? @dougpunity3d @Rene-Damm

With friendly Regards
Jan aka. Sonorpearl

4 Likes
8

I can’t even find the 0.9.0 version listing on the 2019.3a8’s package manager window.

9

Try to use 2019.3.0a10. It is also there on 2019.1.11f1.

1 Like
10

I upgraded to this 0.9 version.
I’m using Mouse.current.WarpCursorPosition to modify cursor position given a gamepad leftstick.
So I was able to control UI like a mouse.
However this is now broken, the UI does not seems to react to WarpCursorPosition anymore. (It did in 0.2)

Also I read mention of InputState. I can’t find such class in the API

[Solved] I added InputSystem.QueueDeltaStateEvent(Mouse.current.position, cursorPosition) which forced the UI to react

11

Any specific reason why “InputAction.continuous” was removed? Before I could handle all input similarly in code with .performed, storing and resetting after using it. Now I have to look at each input and see if it is a “triggering one”, “accumulating one” or “only last frame” , using .performed and canceled on some and resetting some after use.

7 Likes
12

Hi,

How up to date is the documentation: https://docs.unity3d.com/Packages/com.unity.inputsystem@0.9/manual/index.html?

Also, do you already know when the new input system will become the default input system in Unity?

13

As Jawsarn just said, why remove it? it makes more sense for input to be event based; of course the actual actions are ran through a fixed update and we could do the same but people don’t want a project with an input class thats complete spaghetti.
Its a little too close to the old system, except replace searching by string for a known type.

5 Likes
14

I have to agree to @Jawsarn and @Tyndareus about the “continuous” flag. It makes the code more tedious and results in more overhead if we have to implement the “continuous” behaviour in our code. Is there a chance of getting the continuous setting back?

I tried to create a custom Interaction (like the default PressInteraction before continuous was dropped), and was hoping that calling “context.PerformedAndStayPerformed()” would give a similar behaviour like “continuous”, but that did not work unfortunately…

2 Likes
15

I’m curious why the sudden version bump? Feature wise, when looking at previously posted roadmap this looks like what we would have expected 0.3 to be.

I’m personally still waiting for these items marked for 0.4:

5 Likes
16

Loving the action.triggered addition!

Was hoping the UI/UX bugs in the Action Editor would be better with such a big version number jump. Specifically things like not being able to easily reorder the actions or collapsed actions reopening after doing anything in the window still being issues kinda sucks

Also running into an issue where, after a couple directional inputs, additional directional inputs no longer register when i include gamepads. I’ll double check that it’s specifically when i include gamepads to the action, but it started when i did that.

Edit: Actually this might be the issue i’m having - https://forum.unity.com/threads/0-9-preview-fails-with-composite-action.715613/

2 Likes
17

Rebinding UI can be found in the tanks demo. Not sure about multiplayer UI.

1 Like
18

This is true i think , When i add gamepad and keyboard , this issue happens.
But when seperate gamepad and keyboard into their own control schemes , and activate one of them with InputUser it does not happen

19

Can anybody explain how to set up dynamic hold duration for a binding? I want to change the hold duration in run time.

20

I think there is no option for changing the interactions parameters in runtime. We should be able to add , remove , modify interactions of processors in runtime not just in while editing the input action assest.

Pls if someone know how to do this , help.