FIX: uum 138143 button press points for stickcontrol and vector2 add functionality#2411
Conversation
…ld used for stick controls and Vector2. Test
…at a user declared as an interaction.
|
The diff contains approximately 325,668 tokens (~977,005 characters), which exceeds the maximum limit of 150,000 tokens. Please consider splitting this PR into smaller, focused changes. 🤖 Helpful? 👍/👎 |
Codecov ReportAttention: Patch coverage is
@@ Coverage Diff @@
## develop #2411 +/- ##
===========================================
+ Coverage 78.13% 78.31% +0.18%
===========================================
Files 483 762 +279
Lines 98770 140562 +41792
===========================================
+ Hits 77169 110078 +32909
- Misses 21601 30484 +8883 Flags with carried forward coverage won't be shown. Click here to find out more.
|
Darren-Kelly-Unity
changed the title
…-stickcontrol-and-vector2-add-functionality # Conflicts: # Packages/com.unity.inputsystem/InputSystem/Runtime/Controls/InputControlExtensions.cs
ekcoh
left a comment
ekcoh
left a comment
There was a problem hiding this comment.
@Darren-Kelly-Unity Would it be possible to get rid of all the whitespace diffs on this PR? It would be much easier to review if this was corrected.
| /// </summary> | ||
| public float pressPointOrDefault => pressPoint > 0 ? pressPoint : s_GlobalDefaultButtonPressPoint; | ||
|
|
||
| float IActuationPressPoint.pressPoint => pressPoint; |
There was a problem hiding this comment.
To me it look odd that presspoint (new and previous is modelled on the control instead of on the interaction), what happens when two interactions with different press points bind to the same button?
There was a problem hiding this comment.
Confirmed this with AI but you can see in InputActionState.GetActuationPressThreshold() that:
There is an order, it is control-first for device semantics, interaction when the control does not override, then the default settings value.
AI Brief answer:
"Press threshold on the control models the physical control’s default; each binding’s interaction can still use its own press point when the control does not fix one, and separate bindings to the same button keep separate interaction state and thresholds unless the control’s own pressPoint is set, in which case that value wins for unified resolution."
There is also a longer text/ investigation done if you want to see that too?
…-stickcontrol-and-vector2-add-functionality
…-stickcontrol-and-vector2-add-functionality
… it was implicitly implemented.
2 participants
Purpose of this PR
Fixes UUM-138143 —
InputAction.IsPressed()/ in-progress style checks could fire at the wrong effective magnitude for Vector2 / stick bindings when developers setpressPointon the control or onPressInteraction, instead of honoring those thresholds consistently.Introduces
IActuationPressPoint, implements it onButtonControl,Vector2Control, and (viaVector2Control)StickControl, and threadspressPoint/pressPointOrDefaultthroughInputAction,InputActionState, andInputControlExtensionsso press-style polling matches the documented interaction defaults. AddsActuationPressPointTestsand refreshesRespondingToActions.md.Release Notes
InputAction.IsPressed()(and related press / in-progress behavior) for actions bound toVector2ControlandStickControlnow respects per-controlpressPointand bindingPressInteraction.pressPoint, aligning withButtonControland fixing incorrect early triggers when rewriting default interaction thresholds.Functional Testing status
ActuationPressPointTestsand updates inCoreTests_Actions/CoreTests_Controlscover press-point actuation paths.IsPressedbefore processed magnitude reaches the configured press threshold for vector / stick cases.Performance Testing Status
No performance impact expected: additional work is branchy float comparisons on existing control paths; no new per-frame allocations identified in scope.
Overall Product Risks
Technical Risk: 2 — Touches
InputActionStateand widely used press APIs; edge cases around magnitude, deadzones, and interactions need regression confidence.Halo Effect: 2 — Any title using
IsPressed/WasPressedThisFrameon Vector2 / stick actions may see timing changes until bindings are tuned; behavior is intended to match documentedpressPointsemantics.Class diagram
Git range analyzed:
origin/develop...HEAD(4 commits).Mermaid class diagram (GitHub)
classDiagram direction TB class IActuationPressPoint { <<interface>> +pressPoint +pressPointOrDefault } class ButtonControl { +pressPoint +pressPointOrDefault } class Vector2Control { +pressPoint +pressPointOrDefault } class StickControl { } class InputAction { +IsPressed() +WasPressedThisFrame() +WasReleasedThisFrame() } class InputActionState { } class InputControlExtensions { <<static>> } IActuationPressPoint <|.. ButtonControl IActuationPressPoint <|.. Vector2Control Vector2Control <|-- StickControl InputAction --> InputActionState : uses InputControlExtensions ..> IActuationPressPoint : pressPointOrDefaultDocumentation Impact
Changes analyzed:
origin/develop...HEAD(4 commits).User-facing: New public
IActuationPressPoint;InputActionpress-helper remarks/behavior;ButtonControl,Vector2Control,StickControldocs aroundpressPoint;RespondingToActions.mdupdated for polling vspressPoint.Documentation updates in this PR
RespondingToActions.md— ClarifiesIsPressed/ frame helpers vs interactions andpressPoint; review wording and cross-refs after merge.Follow-up (optional)
IActuationPressPointcallout in a control reference page, add a short subsection and link from Responding to Actions.Jira (fetched via MCP): Bug, In Progress, TBD priority, assignee Darren Kelly, label Input-Actions. Ticket summary: InputAction.IsPressed() and IsInProgress() triggers on wrong values when rewriting the default values of Vector2 interactions.