The clock under every number
Every swing speed in this game, and every tuning band built on one, was read by dividing a pose that moves at the headset's frame rate by a physics step that doesn't. I measured it before changing it: about three hits in four had the two clocks more than 25% apart. Combat now reads the rendered clock, and I prefer it. Every swing speed I've measured and published here was a physics-clock reading.
In short: Every swing speed in this game, and every tuning band built on one, was read by dividing a pose that moves at the headset's frame rate by a physics step that doesn't. I measured it before changing it: about three hits in four had the two clocks more than 25% apart. Combat now reads the rendered clock, and I prefer it. Every swing speed I've measured and published here was a physics-clock reading.
Most of what I've written about combat here is numbers: a median swing, a ceiling, a percentile, a crit pool. Astra's review of the combat code named something underneath all of them, and filed it as a pressure point, not a bug.
Two clocks
The interaction SDK moves a held sword once per rendered frame, 72 times a second in these passes. The weapon measured its tip's speed in the physics step, which runs at a fixed 50 Hz: the distance the tip moved since the last step, divided by 0.02 s. The problem is that the two don't line up. Some physics steps see one rendered move, and some see two. A step that sees one reads about 0.69× the real speed, and a step that sees two reads about 1.39×. Every calibrated band in combat sits on that division: the damage ceiling, the crit pool, the haptic buzz, the flinch, the parry floor.
Changing the clock would move all of those bands at once, so before deciding anything Claude built an instrument. From then on, every landed hit logs both readings: the physics one, which combat was using, and a rendered one, taken from the tip's pose once per frame against that frame's own time. Every tenth hit logs a summary, including how many physics steps saw zero, one, or two or more rendered moves.
What pass 36 said
Pass 36 was 182 sword hits, all of them still on the physics clock. About three hits in four read more than 25% apart. For the middle 90% of hits, the physics reading ran from about 0.7× to about 1.5× of the rendered one. The step counts matched the explanation: of the physics steps with the blade in hand, 56% saw one rendered move, 43% saw two and 1% saw none, and those shares held all session.
The medians were close: 81 m/s on physics against 88 rendered, over 180 hits. That's the trap. The median said the old clock was nearly harmless. But the median isn't what the game rewards. Each hit is ranked against a pool, one at a time, and a single hit's reading could be off by about a third in either direction depending on where it fell between frames. The crit I rolled and the buzz I felt were partly set by the phase of two clocks.
The A/B
Pass 37 put the choice on the dev panel as a straight switch. I swung on the rendered clock, then switched to physics, and I knew which was which. "More consistent... felt better... I do prefer the new one." Combat reads the rendered clock by default now.
Each clock keeps its own swing history, because a pool is only meaningful against swings measured the same way. The first time the rendered clock ran it had no history, so it started from a copy of the physics clock's. Much of the rendered pool is still that seed, and will be until enough rendered swings replace it.
A bug found while checking the pools
Switching clocks in pass 37 logged two different reloaded pools, with medians of 88.5 and 83.5, and I wanted to know why. They turned out to be the two clocks' own files, as designed. But while tracing them, Claude found a real defect: when a cleave hit two bodies in the same physics step, the second body entered the swing pool as well. 7 of 150 samples in my saved pool were doubles. It now enters once per step, and the repeats are counted. A clock switch also dropped the swings since the last save, and now saves first. Neither fix has anything to feel, and neither has been worn.
The switched-off band, a third time
The same review found a band that hadn't followed the rest. Hit loudness still had a fixed ceiling of 12 m/s, while my median swing was 69 m/s on the physics clock. Nearly every hit was at full volume. That's the band that is switched off because its top sits below the median, and it's the third time I've found one in this project. Loudness is now on the same live percentile as the buzz and the lean. Pass 36: "sounded good."
What this means for older posts
Every swing speed I measured and published on this devlog before 30 September was read on the physics clock. That includes the 47 m/s median in Three readings, and each one destroyed the last, the 61 and 72 m/s in Earned, but too rare, and the 55 m/s in Affixes you can hear and feel. They're true readings of what was measured, and I'm leaving them as they are. As medians, going by pass 36, they're probably within about a tenth of what the rendered clock would have said. As single hits, like a crit on a 10 m/s swing, they carry the full error.
Still open
Changing the clock moved the median by less than a tenth. It didn't touch a bigger gap. In August I wrote down that a real sword swing peaks around 12 m/s at the tip. Two days later my median was 47, and I put that down to swinging harder once big swings paid. Both clocks now put my median at 80 to 90 m/s, which is faster than I believe a sword tip really moves. The clock doesn't explain that, and I don't know yet what does.
The cleave fix is unworn. The rendered pool still holds much of its physics seed. And the rendered clock is a better proxy, not the true speed: it's the pose the SDK wrote, on the frame's own time, which is only as good as that time.