incanto 0.72.0 → 0.74.0

package/skills/incanto-3d-character.md

@@ -27,17 +27,27 @@ character rides the hover spring, not floor contact, so friction would just brak
 movement. Declare `move` (vector2) / `jump` /
 `sprint` actions in the scene input map, and call
 `engine.input.attachPointer(canvas, { lockOnClick: true })` for mouse look.
+The move vector is SCREEN space, y-down: `up` is `-y`, so in a harness
+`setActionVector('move', 0, -1)` walks the character FORWARD (away from the
+camera, -z at yaw 0) and `(0, 1)` walks it toward the camera — the guess that
+drops a first probe off the back of the map.
 
 ## Movement model (vibe-starter-3d parity)
 
 Impulse-based on the dynamic body: target speed = `maxSpeed ×
 (1 + (sprintMultiplier−1)·intensity)` where keyboard intensity is 0.6
 (any move key) or 1.0 (+sprint). Defaults: maxSpeed 2.5, sprint ×2 → walk
-≈4 m/s, sprint ≈5 m/s. `jumpVelocity` 4 (+20% at full sprint), falls get
+≈4 m/s, sprint ≈5 m/s. `jumpVelocity` 4 — and `sprintJumpMultiplier` (1.2) scales with
+the keyboard's INTENSITY, so a jump while walking is ×1.12 in velocity (+26% in height)
+and while sprinting ×1.2 (+44%): standing 0.81 u, walking 1.01, sprinting 1.16 at the
+defaults. Size a ledge against the moving jump, not the standing one; `incanto-feel`
+prints all three. Falls get
 gravityScale 2.5 with a −20 m/s terminal clamp, and a hover spring holds the
-capsule BOTTOM `floatHeight` above the ground (5-ray probe). Author the Skin
-y-offset as `-(halfHeight + radius + floatHeight)` so the feet sit at the
-capsule bottom (the example templates do this).
+capsule BOTTOM `floatHeight` above the ground (5-ray probe) — in principle; the
+spring sags about 0.13 m under gravity, so at the default `floatHeight` 0.01 the
+capsule rests ON the floor (measured: bottom −0.001 m). Author the Skin y-offset
+as `-(halfHeight + radius)` so the feet sit at the capsule bottom (the example
+templates do this; adding `floatHeight` is off by that much).
 
 ## Game feel — the props a jump needs to stop feeling broken
 
@@ -54,17 +64,34 @@ did not until now.
 | `maxJumps` | `1` | `2` = double jump. Extra jumps work in mid-air. |
 | `airControl` | `0.2` | how much ground control you keep airborne (0 = committed, 1 = full). |
 | `fallGravity` | `2.5` | gravity multiplier while falling. Higher = snappier arc. |
+| `wallJumpImpulse` | `[0, 0]` | `[away, up]` m/s — airborne and pressing INTO a wall, `jump` kicks off it: away along the wall's normal, up. Try `[6.5, 7]`. A fixed arc (the jump cut never halves it) and air control stands down for 0.18 s so the stick still pointing at the wall cannot steer the kick back into it. Emits `wallJumped(normal)`. |
+| `wallSlideSpeed` | `0` | max fall speed while pressing into a wall (`fallGravity` stands down too). Try `2`. |
 | `platformCarry` | `true` | ride whatever you are standing on. Off = the controller steers in WORLD space, so standing still on a moving floor brakes you off it (measured: 95.9% of a moving deck's travel kept, 0.0% with this off). |
 
 Every one defaults to OFF (`0` / `1`) or to the previous hard-coded constant, so
 a scene that asks for nothing behaves exactly as before.
 
+**The controller owns the wall-jump.** A kick written from a behaviour lasted
+three frames on a platformer built from the tarball: the jump cut halved its
+rise the moment the tap was released (7 → 2.2 m/s) and air control steered
+the horizontal straight back into the wall (−6.5 → 0 in three steps). Anything
+that fights the controller's own feel props has to live INSIDE them. The wall
+is found by a short static-only ray in the input direction, so the character
+must be pressing into it — a `RigidBody3D` has no `isOnWall`.
+
 ```json
 { "name": "Ctl", "type": "CharacterController3D",
   "props": { "coyoteSeconds": 0.12, "jumpBufferSeconds": 0.15,
              "jumpCutMultiplier": 0.45, "maxJumps": 2 } }
 ```
 
+All six are composed in `examples/tps-3d` (the shipped third-person starter), and
+`bunx incanto-feel` measures what they DO rather than echoing them — on that scene:
+tapped apex 0.21 u vs held 0.81 u at the default `jumpVelocity` 4 — tps-3d itself, at 5,
+measures 0.32 / 1.26 (`jumpCutMultiplier`), a double jump line
+(`maxJumps: 2`), and the coyote and buffer windows still measured with a double
+jump declared. It used to give up on both the moment `maxJumps` went above 1.
+
 **Jump reads the button EDGE.** Holding the jump key no longer re-jumps every
 frame — that auto-hop was never intended and it made coyote time incoherent (a
 held button would re-fire through the whole window).
@@ -75,6 +102,30 @@ props and the airborne animation use a stricter test: close to the support AND
 not moving upward. Without the velocity term the check is one frame stale, which
 at launch speed is ~6 cm — enough to still read as standing on the floor.
 
+### The two numbers a level is built against — composed and measured
+
+`stepHeight` (0.35) and `jumpVelocity` (4) decide what a level can ask of the player, and
+no example had set either. `tps-3d` now declares `stepHeight: 0.4` and `jumpVelocity: 5`
+and its harness asserts each by what the player can DO: walked into a 0.3 m curb it rises
+from y 0.84 to 1.14 and keeps going; walked into a 0.9 m ledge it stops at the face;
+and the same scene with `jumpVelocity` back at 4 reaches 0.81 u where 5 reaches 1.26 u.
+Read the number back from nothing — a curb you can climb is the proof.
+
+### The rig around the character — composed and measured
+
+`cameraCollision` and `platformCarry` are on by default and no example had ever set or
+measured them. `tps-3d` declares both and its harness asserts each by an effect: standing
+1.25 m in front of a wall with the boom pointing at it, the camera closes from 4.2 m to
+0.45 m; standing still on a `Lift` (a `StaticBody3D` walked by `Patrol`) for two seconds,
+the lift travels 4 m and the rider drifts under 0.25 m off it.
+
+`floatHeight` was composed too and taken back out. The hover spring holds the capsule
+bottom `floatHeight` above the ground in principle, but it SAGS about 0.13 m under gravity,
+so below that the capsule simply rests on contact and the prop changes nothing — measured
+at rest: 0.01 → y 0.839, 0.05 → 0.840, 0.3 → 1.008, 0.6 → 1.308 for a capsule whose
+contact height is 0.84. Leave it at the default and use `stepHeight` for ledges (the
+docstring's own advice: a raised `floatHeight` makes the character weightless).
+
 ## Views
 
 | view | what it does | key props |
@@ -157,6 +208,14 @@ skin.animationUpper = '$anims/attack';   // spine-up plays the attack…
 - `animationUpperLoop: true` for sustained upper loops (carry, aim, wave).
 - Works with the controller's `animations` map untouched — locomotion logic
   never learns the attack exists.
+- Composed in `examples/tps-3d`: `Shoot.fire()` sets
+  `skin.animationUpper = '$anims/shoot'` and nothing else — the run clip keeps
+  the legs, the shot rides the spine up. Measured on the CDN's
+  `mixamorig/shoot.glb` (4.03 s, 54 tracks retargeted onto `mixamorigSpine…`):
+  the layer's action is live 3 frames after the shot and still at weight 1 with
+  the base clip on `$anims/run`. While the clip GLB is still LOADING the layer
+  waits silently and starts when it lands — a shot fired in the first second of
+  a cold page plays late, not never.
 
 ## Animations without code
 
@@ -210,7 +269,11 @@ A sword in the hand, a hat on the head, sparks on a wingtip — parent them to a
   adjustments).
 - Purely VISUAL: it follows the rendered skeleton, so headless the node stays
   at its prop transform — keep hit checks range-based from the body, never
-  bone-based.
+  bone-based. The sword MESH rides the bone; the sword HITBOX is an `Area3D`
+  on the body, aimed from the skin's yaw and armed for the swing's active
+  frames — the recipe, with its numbers, is under `DamageOnContact` in
+  `incanto-gameplay-behaviors.md` ("A melee swing"). Do not parent the hitbox
+  to the skin: physics composes ancestor offsets only, so it never turns.
 - `model.boneNames()` lists every bone at runtime when you need to hunt one
   (the editor's inspector offers the same list as a dropdown on the `bone` prop).
 
@@ -320,6 +383,51 @@ This cannot be an `auditScene` warning: a scene file has no velocity, and the bu
 is a behavior writing a heading at runtime. `facingReport()` from `incanto/test`
 is the same check for your own tests.
 
+## Facing the mouse in a top-down view (twin-stick)
+
+In `quarter` view the mouse does not look, and the controller turns the skin
+toward the MOVE direction — a twin-stick game wants it toward the CURSOR. Set
+`skinPath: ""` so the controller leaves the skin alone (then drive
+`skin.animation` yourself from `movementStateChanged`), and each frame put the
+cursor on the ground and face it — `engine.toWorld(sx, sy)` is the renderer's
+ray to the y=0 plane, `null` headless, so a harness sets the aim directly:
+
+```ts
+const at = this.input.pointerPosition();
+const w = at && this.engine.toWorld?.(at.x, at.y);        // [x, y, z] | null
+const [tx, tz] = w ? [w[0], w[2]] : this.aim ?? [NaN, NaN];
+const dx = tx - player.position[0], dz = tz - player.position[2];
+if (Math.hypot(dx, dz) > 0.2) skin.rotation = [0, Math.atan2(dx, dz) * RAD2DEG, 0];
+```
+
+Measured on `examples/survivor-3d`: a cursor 10 m east is yaw 90°, and a bolt
+given `direction: [dx, 0, dz]` flies where the skin looks. Boot with
+`pointer: { lockOnClick: false }` — a locked cursor is no aim at all.
+
+## Lock-on and a dodge, in a few lines each
+
+The controller's camera yaw is a public number in radians, and the rig's
+forward is `(-sin yaw, 0, -cos yaw)` — so putting the camera behind the player
+and on the enemy is one assignment per frame, measured on `examples/melee-3d`
+(forward · toEnemy = 1.00):
+
+```ts
+const dx = enemy.position[0] - player.position[0];
+const dz = enemy.position[2] - player.position[2];
+controller.yaw = Math.atan2(-dx, -dz);       // every frame while locked
+```
+
+A dodge is a dash plus i-frames that start BEFORE the hit — `Health.protect`,
+not `invulnerableFor` (which opens only after one):
+
+```ts
+(player.behavior as Health).protect(0.35);   // immune for the roll
+body.linearVelocity = [dir[0] * 9, body.linearVelocity[1], dir[2] * 9];
+```
+
+Keep writing the velocity for the roll's frames — the controller brakes toward
+its own target speed every step, so a single impulse dies in a few frames.
+
 ## First-person weapon viewmodel + the tracer-from-the-muzzle rule
 
 A weapon VIEWMODEL is just a `MeshInstance3D`/group child of the **root** `Camera`

package/skills/incanto-assets.md

@@ -9,7 +9,8 @@ description: Where game art comes from in Incanto — the FULL built-in catalog
 > installed engine version. Sibling skills live in `node_modules/incanto/skills/`.
 
 Resolve art in this order: ① built-ins (zero setup) → ② asset MCP servers /
-known URLs → ③ art-free primitives. Never invent asset URLs.
+known URLs → ③ art-free primitives. Never invent asset URLs — `incanto-check`
+asks every remote url's server whether it exists, and a 404 is missing art.
 
 **3D characters and props are step ②, always** — the built-in catalog is 2D
 sprites, tiles, items, foliage/terrain textures and audio, with no models in it.
@@ -182,8 +183,13 @@ does not contain:
 
 That used to be a browser-only failure — visible in `assetErrors()`, which needs
 a running game and someone to look at it — and it is the single most common way
-a scene draws nothing. Remote (`https:`) and inline (`data:`) urls are left
-alone: the command cannot know, and guessing would be worse than the bug.
+a scene draws nothing. Remote (`https:`) urls are ASKED — a HEAD request with a
+four-second deadline, one per url per run — and a 404 is the same warning
+(`$avatar → https://…/base-model.glb is not found on its server (HTTP 404)`);
+a host that cannot be reached is a `note:` and never a failure, so the check
+works offline. Inline (`data:`) urls are left alone. This is the half of "never
+invent asset URLs" a server can answer: a model at a made-up CDN path passed
+every instrument except the browser before it.
 
 ## A spritesheet grid that does not fit says so
 

package/skills/incanto-behaviors-and-scripts.md

@@ -79,7 +79,7 @@ under an existing name (re-registering a different class without it → `DUPLICA
 ## What a Behavior can reach
 
 - `this.node` — the host node (cast to its type when needed)
-- `this.getNode(path)` / `this.emit(...)` / `this.on(...)` — node delegates
+- `this.getNode(path)` / `this.getNodeOrNull(path)` / `this.emit(...)` / `this.on(...)` — node delegates
 - `this.engine` / `this.input` — via the scene tree (TREE_VIOLATION if the scene isn't
   set on an Engine)
 - Engine access in `onReady` (`this.engine` / `this.rng` / `this.log`) works under
@@ -299,12 +299,36 @@ what that cost: with the `plays` rung finally counting defects,
 the player walking off the terrain and falling forever. One `Respawn` node each,
 no TypeScript, and all five are clean.
 
+## Checkpoint (built-in behaviour — move where the Respawn puts you)
+
+The second most common thing a platformer has. On an `Area3D`/`Area2D`:
+
+```json
+{ "name": "Check1", "type": "Area3D", "groups": ["checkpoint"],
+  "props": { "position": [7, 4.5, -37], "collider": { "shape": "box", "size": [3, 3, 3] } },
+  "script": { "name": "Checkpoint", "props": { "respawn": "/root/Player/Catch", "dropBelow": 0.6 } } }
+```
+
+| Prop | Default | Meaning |
+|---|---|---|
+| `respawn` | `""` (required) | node path of the `Respawn` to redirect |
+| `group` | `"player"` | who can light it (`""` = anything) |
+| `once` | `true` | light it a single time; `false` re-fires on every entry |
+| `dropBelow` | `0` | how far below the area's origin the respawn point sits, so the character lands ON the flag |
+
+Touching it sets the `Respawn`'s `to` to the checkpoint's world position and
+emits `activated(other)`; `lit` says whether it has fired. `Respawn.to` is read
+at the moment of the catch, so a checkpoint lit mid-run is where the next fall
+ends — it used to be read once at ready, which is what a platformer built from
+the tarball found. `examples/platformer-3d` has two.
+
 ## Timer (core node — never setTimeout in game logic)
 
 ```json
 { "name": "Spawner", "type": "Timer", "props": { "waitTime": 2, "autostart": true } }
 ```
-Emits `timeout` every `waitTime` s (`oneShot` for once). API: `start(time?)`, `stop()`, `running`.
+Emits `timeout` every `waitTime` s (`oneShot` for once). API: `start(time?)`, `stop()`, `running`,
+`timeLeft` (seconds to the next `timeout`, `0` when stopped — the countdown a HUD draws).
 A `waitTime` of 0 is a load error: the update guard stops a timer with no period
 on its first frame, so it would never fire and never say so.
 

package/skills/incanto-building-2d-games.md

@@ -644,3 +644,12 @@ if (!isWebGLAvailable()) showMyOwnBrowserTooOldScreen();   // ask BEFORE booting
 
 `isWebGLAvailable()` probes a throwaway canvas and never touches yours; it
 returns `false` outside a browser.
+
+## Surfaces and a chaser that walks (2D)
+
+A `StaticBody2D` carries the surface it is — `restitution 1` is a trampoline, `friction 0`
+is ice — and its value WINS the pair (see `incanto-physics-and-input.md`). A platformer's
+ground enemy is a `CharacterBody2D` with `Chase` on a child and `ground: true`, so a player
+on a platform is not met by an enemy floating up to it. platformer-2d's course past its last
+ground slab is all three, measured by its harness.
+

package/skills/incanto-building-3d-games.md

@@ -116,6 +116,9 @@ never be one node each. One instanced node draws them all at once:
   place.
   `{ "shape": "sphere", "radius": r }` / `{ "shape": "box", "size": [x,y,z] }`
   opt out into a cheaper approximation when a rough blocker is all you want.
+  The field follows its stones: replace `transforms`, move the node, or change
+  `mesh`, `size` or the `collider` spec at runtime and the hulls are rebuilt on the
+  next physics step.
 
 ### `LoftMesh3D` (smooth swept hulls — vehicle bodies, canopies)
 
@@ -142,6 +145,14 @@ saturated in sunlight: `metalness ~0.45, roughness ~0.35, clearcoat 1,
 clearcoatRoughness 0.06, envMapIntensity ~0.9` — high metalness washes the base colour
 out into the sky reflection.
 
+**A 3D node with no art draws nothing, and `incanto-check` says so.** A
+`ModelInstance3D` with no `model`, a `Sprite3D` with no `texture`, an
+`AnimatedSprite3D` with no `sheet`, an `InstancedMesh3D` with no `transforms`
+each load clean, validate, take a row in the editor's tree, and put no pixel on
+screen. The audit names them (a template on a `PrefabShelf` and a node authored
+`visible: false` are left alone) — the same rule `TileMap2D` got the day the
+tilemap example shipped a floor nobody could see.
+
 ### `Sprite3D` / `AnimatedSprite3D` (2D billboard sprites — the 2.5D look)
 A 2D image drawn as a camera-facing quad inside the 3D world (Octopath / Don't
 Starve / classic MapleStory in a 3D scene). Unlit — the art shows as-is. The
@@ -318,6 +329,40 @@ notice in a screenshot.
   (~60–80) so the box tracks the camera and contact shadows stay crisp everywhere.
 - `OmniLight3D` — `color`, `intensity` (physical units — values like 20–40 are normal),
   `range` (0 = unlimited).
+- `SpotLight3D` — a CONE that aims: a flashlight, a searchlight sweeping an arena,
+  headlights, a stage spot, a guard's torch. `color`, `intensity` (candela, physical
+  decay — see the numbers below), `range` (0 = unlimited), `coneDeg` (the FULL cone
+  angle, default 60 — a "30° beam" is 30; 0 and 180 are load errors), `penumbra`
+  (0 hard edge … 1 all falloff, default 0.3), `castShadow` + `shadowMapSize` (1024;
+  a perspective shadow from the apex — one extra render per frame per light), and
+  `lookAt` (a node path: aim at it every frame, exactly as `Camera3D.lookAt` does).
+  **It aims down its −Z like a camera**: at rest it points along −Z,
+  `rotation: [-90, 0, 0]` points it at the floor, and a headlamp on a +Z-forward
+  skin wants `rotation: [0, 180, 0]` (tilt it down with `[20, 180, 0]`).
+
+  **Intensity is candela with physical falloff**, so the number is about
+  DISTANCE: measured on tps-3d-neon's dark deck, a headlamp 2 m off the floor
+  reads well at ~500, and a searchlight 14 m up needs ~12 000 to leave a pool you
+  can see — 260 was invisible. Start ten times bigger than feels reasonable.
+
+  **Do not yaw a pitched light on the same node.** Rotation is Euler XYZ, so a
+  yaw applied to a node that already pitches −55° swings the cone sideways and,
+  at yaw 180, straight UP (measured: dir `(0, 0.82, 0.57)`). To SWEEP, put the
+  yaw on a parent pivot and the pitch on the light; to TRACK, use `lookAt`:
+
+  ```json
+  { "name": "SearchlightRig", "type": "Node3D", "props": { "position": [0, 14, 0] },
+    "script": { "name": "Oscillate", "props": { "mode": "rotation", "axis": "y", "amplitude": 70, "frequency": 0.08 } },
+    "children": [
+      { "name": "Searchlight", "type": "SpotLight3D",
+        "props": { "rotation": [-55, 0, 0], "color": "#ffe9b0", "intensity": 12000, "range": 60,
+                   "coneDeg": 24, "penumbra": 0.4, "castShadow": true } }
+    ] }
+  ```
+  ```json
+  { "name": "Tracker", "type": "SpotLight3D",
+    "props": { "position": [0, 14, 0], "intensity": 12000, "coneDeg": 20, "lookAt": "%Player" } }
+  ```
 
 ### Vegetation & water
 

package/skills/incanto-editor.md

@@ -169,6 +169,10 @@ Opens a local page (default `http://127.0.0.1:5179/`) with three panes:
   with the cursor whatever the world zoom is. (Picking used to look only at the
   world pass, so a HUD could not be selected in the viewport at all, and its
   outline was drawn wherever the game camera happened to be looking.)
+  A `HudLayer`'s DOM is drawn over the edit view but never takes the pointer
+  there — a centred pause menu used to sit exactly where the selected node's
+  gizmo is and eat the drag (a rotate ring under it never saw a pointerdown; a
+  move drag toggled Mute). Its widgets are live again in play.
   **`F` frames the SELECTED node** (its whole subtree; a light or empty node has
   no bounds, so the camera goes to it at a readable distance) — and the whole
   scene when nothing is selected, which is the Maya/Unity/Unreal meaning of the
@@ -247,7 +251,8 @@ files are formatted biome-compatibly (80-col inline-when-fits), so saving from
 the editor never breaks `pnpm lint`.
 
 Save activates only when the working scene differs from the original
-(`Ctrl/Cmd+S`); undo is `Ctrl/Cmd+Z`. Saving writes pretty-printed JSON to
+(`Ctrl/Cmd+S`); undo is `Ctrl/Cmd+Z`, and it keeps your selection whenever the
+selected node survives the undo (only undoing the add that created it deselects). Saving writes pretty-printed JSON to
 `--output` (default: the input file).
 
 ## The agent8 asset library (📚)

package/skills/incanto-environment.md

@@ -197,7 +197,12 @@ carries the heightfield as `[x, y, z, tile]` tuples (value noise; grass
 top, dirt fill, bedrock base). Reach for it when BLOCKS are the point —
 digging, building, minecraft-style games on `VoxelGrid3D` (colliders are
 the game's job: chunk trimeshes near the player, see the minecraft
-template). Options: `seed`, `size` (32 blocks), `height` (8), `water`. The
+template). Baked `voxels` land WHEN THE PROP DOES — at load, before any
+`onReady` — so a chunk builder at ready already sees them; a generator that
+also fills the grid at ready must MERGE them, because `setBlocks` replaces
+the map: `grid.setBlocks([...generated, ...grid.blocks()])`, baked blocks
+last so a baked block wins over the terrain the noise put there (the
+minecraft template's beacon tower is exactly this). Options: `seed`, `size` (32 blocks), `height` (8), `water`. The
 voxel `generateIsland` (radial dome falloff, sandy shore) also remains for
 the same use case.
 
@@ -800,7 +805,7 @@ hue reads grey.
 | prop | default | meaning |
 |---|---|---|
 | `size` | `[40, 40]` | [width, depth] meters — must be positive (load-time check) |
-| `color` | `"#2a6fbe"` | THE lake hue for `simple` (deep/surface/sky derived from it — use a vivid color); if customized it also tints the fancy ramp |
+| `color` | `"#2a6fbe"` | THE lake hue for `simple` (deep/surface/sky derived from it — use a vivid color); if customized it also tints the fancy ramp — but only the parts `colors` (or a preset) leaves unnamed: with trough, surface and peak all set it only seeds the underwater murk, and the editor's inspector says so under the field |
 | `opacity` | `0.8` | water-body density: lower = clearer (scales how much the refracted scene shows through) |
 | `waveHeight` | `0.04` | wave intensity, meters-ish (0 = mirror-flat; 0.04 = calm sea; 0.08 = the older choppier look) |
 | `waveSpeed` | `1` | animation speed multiplier |

package/skills/incanto-game-feel.md

@@ -22,10 +22,11 @@ feel of /Game/Player
   input → motion   1 frame(s)
 
   jump apex        0.262 u   (tapped)
-  held apex        0.981 u   ← size your level against THIS
+  held apex        0.981 u   (standing)
+  moving apex      1.24 u walking · 1.41 u sprinting   ← size your level against the LARGEST
   time to apex     133 ms
   airtime          267 ms
-  coyote window    100 ms
+  coyote window    117 ms
   jump buffer      150 ms
 ```
 
@@ -55,19 +56,23 @@ peak             300 u/s   ← SOMETHING ELSE moved it
 Measure feel somewhere nothing can hit you.
 
 **A character that jumps in MID-AIR has no coyote window to measure.** The probe
-lifts the body, waits, presses, and reads "vertical velocity went up" as a jump —
-so a double jump answers yes at any delay, and so does any behaviour that pushes
-the body up while `jump` is held (a glide, a jetpack, an updraft). It used to
-print `coyote window always (no window)`, which reads as the opposite of the
-truth, on two of the six shipped starters — one of which declares
-`coyoteSeconds: 0.12` five lines from its glide. It says
+lifts the body, waits, presses, and reads "going UP after the press, and sent
+there by it" as a jump —
+so a double jump (or a jetpack, an updraft) answers yes at any delay. It used to
+read "velocity CHANGED upward" instead, which a glide satisfies too: Beacon
+Isle's glide clamps a −20 m/s fall to −1.6, a +18 change, and the report called
+its coyote window `not measurable — jumps in MID-AIR` about a character that
+does not, with the buffer beside it marked suspect. Now it reads
 
 ```
-coyote window    not measurable — this character jumps in MID-AIR
-jump buffer      33 ms   (suspect — see above)
+coyote window    117 ms   (declared 120)
+jump buffer      33 ms    (declared 150)
 ```
 
-and names the declared value it cannot confirm. To measure the window, probe a
+and the 33 is true, not suspect: holding `jump` while falling IS the glide,
+so a press more than two frames before landing becomes a one-frame glide and
+the buffered jump is spent. A starter that glides on the jump button buys a
+short buffer with it. To measure the window of a true mid-air jumper, probe a
 build with the air jump off.
 
 **`jumpVelocity: 4` is not a height.** It is an impulse, and what it produces