TouchControlsOptions

Optional, and that is a correction rather than a convenience. These were positional arguments and read as dependencies — a consumer who could not reach the page concluded the class needed two elements to work, and constructed two divs it never appended anywhere so the input maths would run. It does not need them: they are an output channel, written to and never read. Every touch comes from input.target, and every number this class reports is computed without either node.

So absent means the stick has no visible representation and the controls work exactly as they did, which is what a consumer drawing its own HUD, drawing none, or forbidden the page wants. stickBase takes hidden and a position; stickNub takes a transform.

The press fires on release, so this duration is the action's input latency, and a caller whose action has a grace window of its own — a platformer's coyote time — wants the two sized against each other. Set it past that window and a tap begun at the edge of a drop resolves after the body is unjumpably in the air.

The default is only-holds, and it is the fix for a real complaint from phone testing: a still thumb kept firing the primary action, so there was no way to hold position and look. A thumb placed down and held is what looking around starts with, so resolving it into a press fires the action every time somebody lines up a camera move. There is no threshold that separates "still thumb" from "about to look", because they are the same input.

A tap still fires on release, which is where the intent actually is; and the hold still reports primaryHeld, so a caller whose action has a held form — a glide, a charge — keeps it. Only the edge from a motionless press is gone.

The promotion is not a verdict, and reading it as one is what later ate the tap: a touch promoted to the hold and released quickly is still a tap, because the player's thumb did the thing a tap is. See isTapRelease.