Gamepad trigger-rumble and associated updates #34442
Conversation
chrisdavidmills
requested review from
wbamberg and
pepelsbey
and removed request for
a team
github-actions
bot
added
Content:WebAPI
Preview URLs (6 pages)(comment last updated: 2024-07-17 10:52:07) |
github-actions
bot
added
size/m
| @@ -3,22 +3,34 @@ title: "GamepadHapticActuator: type property" | |||
| short-title: type | |||
| slug: Web/API/GamepadHapticActuator/type | |||
| page-type: web-api-instance-property | |||
| status: | |||
| - deprecated | |||
There was a problem hiding this comment.
These days the source of truth for deprecated is BCD, which auto-fills this value and auto-adds macro calls. So unless the BCD for this property also marks it deprecated, this will get un-fixed again next time the script runs.
There was a problem hiding this comment.
Ah, good call. I've just done that.
| - `weakMagnitude` | ||
| - : Rumble intensity of the high-frequency (weak) rumble motors, normalized to the range between 0.0 and 1.0. | ||
| - `duration` {{optional_inline}} | ||
| - : The duration of the effect in milliseconds. If omitted, `duration` defaults to `0`. |
There was a problem hiding this comment.
highly subjective, but I think this is overly repetitive, and in this situation I just say:
| - : The duration of the effect in milliseconds. If omitted, `duration` defaults to `0`. | |
| - : The duration of the effect in milliseconds. | |
| Defaults to `0`. |
I wish we had a consistent way to write default values for optional items.
There was a problem hiding this comment.
Well, mine is wordier, but it is also a bit more intuitive. Saying that, I don't think it really adds much, so I've updated it to your suggestion.
There was a problem hiding this comment.
Well, mine is wordier, but it is also a bit more intuitive.
It is, and if this were the only place we document a default I would prefer it. But there are (obviously) thousands of places we document defaults, and if every one says "If omitted, thing defaults to value" then it is very repetitive: "if omitted" essentially repeats the definition of "default" every time. IMO MDN really misses a structured consistent way to represent "default", that's not just in prose at all.
|
This pull request has merge conflicts that must be resolved before it can be merged. |
| strongMagnitude: 1.0, | ||
| }); | ||
|
|
||
| gamepad.vibrationActuator.reset(); |
There was a problem hiding this comment.
Not sure if you want to await this and show the returned value? Maybe to make it crystal-clear, you could wrap the call in a setTimeout() with a delay <200ms, so you can show the "preempted" return value?
There was a problem hiding this comment.
Thanks @tomayac! I wasn't 100% sure what you meant, but I've tried to update both pages as suggested. Let me know what you think!
There was a problem hiding this comment.
In the reset() example, you await playing the effect before scheduling the timeout, so it doesn't show the effect you mean to show as per the comment. You need to flip the order. I would probably rather work with then() in both cases, resetting and playing the effect. Awaiting something in a realtime game scenario feels like a weird pattern.
There was a problem hiding this comment.
I've swapped the order as you suggested, and converted both examples to use then(). Thanks again.
Description
The Gamepad API
"trigger-rumble"haptic effect has been supported since Chrome 126 (see the ChromeStatus entry).This PR adds/updates content covering related features:
GamepadHapticActuator.typepage up-to-date.GamepadHapticActuator.effectspage.GamepadHapticActuator.reset()page."trigger-rumble"as an effect type that can be used in theGampadHapticActuator.effectsproperty."trigger-rumble"as an effect type that can be used in theGampadHapticActuator.playEffect()method.leftTriggerandrightTriggeras params that can be used in theGampadHapticActuator.playEffect()method.Motivation
Additional details
Related issues and pull requests