f1af5c9a729c91ae7970afa41ad014ff110c9ddd
All of it found from the sprite bench, and most of it was the same mistake twice: a correction applied on top of art that already handled it. THE HEADLESS BODY SHRANK. "Every headless mode shrinks the whole opponent a little" — measured, 34.0 px healthy / 33.8 arm off / 27.8 headless on all EIGHT families, a flat -18%, and the FEET shrank 16-19% with it. A body that loses its head does not get smaller feet. drawZombie carried `if (st === 2) h = 1.52` to take a head off the top, and a headless sprite is still a FULL-HEIGHT frame, because the generator draws a gushing neck stump whose blood plume fills the space the head occupied: 18.3% of z_rw2's frame sits above its shoulders against 10.7% above z_rw1's head. So the art had taken the head off, the per-frame PNG scaling had handled the height, and the override took it off a third time. Wrong on the fallback skins too (z_cw2 is a SHORTER png, which the scaling handles): its body drew at 1.30 m against the healthy 1.78 m. Gone. The HP bar and the aim mark read config.zombieH directly, so they had been floating above a shrunken body for as long as it existed; they re-align for free. THE WOUNDED BODIES WALKED BACKWARDS, and this is not bench-only — racketAI and updateBench both set face as the sign of x movement, so a match did it too. The racket is what measures it, Oliver's own test: "if this racket is facing to the right I would assume that he also walks to the right." Its string bed keys out to an enclosed hole (or is painted pale on the master), so the hoop locates itself. The healthy stride is drawn racket-RIGHT (+0.38..+0.42) and every wound stride racket-LEFT (-0.39..-0.45): THE WOUNDED BODY IS DRAWN FACING THE OTHER WAY, on the master and therefore in the reference and therefore in all seven families. One flip rule cannot serve both rows — fixing the healthy walk inverted the wound walk, which is the second thing he saw. The flip is derived from the frame name now, and only for the WALK frames (w1/w1b/w2/w2b), because they are the only ones whose orientation tracks travel: the wound forehand measures racket-right like the healthy one, and a serve or a fall puts the racket overhead where it says nothing about direction. Checked against 18 frame names including the tour-suffixed ones. AND _famref.py PINS THOSE SIDES. That branch is only correct while the art stays this way, and this is the THIRD art inconsistency this session that reached the court because nothing measured it. A re-roll that mirrors a row now fails the reference build pointing at drawZombie's artFacesRight, instead of shipping. A DEAD WRITE, found on the way: racketAI set rz.facing, and zombies render off zb.face. `facing` is the PLAYER's field and uses the OPPOSITE convention (a char flips on facing < 0, a body on face > 0), so the match opponent's turn was never driven by its chase at all — it fell through to the generic sticky-face line. THE PRONE FRAME LAY ON ITS RACKET. "The player basically levitates over the ground held by his racket." Every frame is bottom-aligned on the ground point, and in the fall3 art the lowest ink is the racket hoop thrown out beside the body — z_shw1fall3 is 249x85 with the body's underside at y67 and rows 68-84 racket, so the torso floated a fifth of the frame up. TUNE.proneSink drops it by that fraction, putting the body line where fall2 leaves its knees. The shadow made it worse and is suppressed for the whole beat: the contact ellipse is sized off DRAWN WIDTH, and a prone frame is three times wider than a standing one, so the widest darkest shadow in the game was painted under the one body not standing on it. THE FALL CARRIES THE RUN. "When the opponent runs to the ball from left to right and then falls, the player must still move to the right while falling." The velocity is INHERITED (racketAI and updateBench both record zb.vx), so a body that went down standing still does not slide and one caught at a sprint slides furthest. It was exponential decay first, which put 93% of the travel in the first two frames — "the visible slide should also extend to the 3rd and 4th frame" — and no retuning fixes that: stretch a wall-clock decay far enough to move the prone body and it creeps for the whole floor hold. So the slide is a DISTANCE BUDGET shared across the frames (TUNE.fallSlideMix), eased out within each so it still decelerates. x is set absolutely from the start, so the total cannot drift with frame rate. 0.05 / 0.22 / 0.35 / 0.11 m — the landing skids and the rise drags itself the last of the way. THE BENCH GOT A FALL BUTTON to tune all of this, and it plays the REAL beat: same FALL table, same tickMatchFall, because a bench that re-implemented the timing would be refining a second copy of it. matchReady() is skipped while the bench owns the court (it runs setupPoint and re-places the body — a match doing match things inside an art test), the walk stop stops walking during a fall, and startFall reads the table LIVE via fallLen() so tuning the numbers cannot leave the 'over' beat expiring mid-collapse. FALL is 0.06 / 0.25 / 2.0 / 0.45 after a session in the bench. fall1 and fall2 are deliberately the same pace (0.87 and 0.88 m/s of slide at a 1.54 m/s entry) so the collapse reads as one movement decelerating into the ground; the 0.07 s fall2 it replaced gave each drawn frame ~4 display frames and read as a cut. THE LENS, portrait camZ 48 -> 49. The three camera numbers are not independent: holding the near player's drawn size fixed means camF = s_player * (camZ - zMax), holding the court's on-screen depth fixed means camY = depth / (s_player - camF/camZ), so 49 gives 795 and 11.23 and horizon re-derives to 43. Far opponent 33.1 -> 33.8 px, player unchanged, court band within a pixel. One metre is deliberate: at camZ 55 the umpire is already clipped off the right edge and by 70 the court reads top-down, and it narrows the player's lateral room because xVisible clamps him to what fits. A figScale experiment that scaled every body 1.2x got further (far body 40.6 px) but is NOT in here — it needs the vertical contact constants to scale with it (ball-vs-body is gated on ball.y < 1.9, which sits just above the tallest chest at 1.856 m, so the roller man would have gone invulnerable) and Oliver reverted it pending a real playtest. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Languages
JavaScript
75.2%
Python
15.8%
HTML
7.3%
Shell
1.4%
Swift
0.2%