# Kitsune momentum: stock CSS and public KSF records

Rechecked 5 October 2026 after the user questioned whether Kitsune portals should preserve momentum. **The authored stock CSS portal does preserve momentum. Three independent runners' public KSF CSS 66t full-map files instead contain zero-horizontal-speed stage arrivals, at different stage-spawn coordinates.** Those are distinct observations. The files do not identify the responsible server or exporter component, so calling the recorded behavior a proven KSF stage-plugin implementation was too strong.

No core movement, map, timer or replay behavior was changed during this review. The earlier isolated native CSS server was not restarted.

## Fresh primary records

The live [Kitsune main-map page](https://ksf.surf/maps/surf_kitsune?game=66t&mode=fw) linked three downloadable records in its top ten. Their separate replay viewers all identify CSS, the exact map, a 66.66666666666667 Hz sample rate, main zone 0 and finish type 0. The leaderboard query selects forward style. These are presented by KSF as full-map records, not individual-stage records.

| Runner / date UTC | Public file | SHA-256 | Main-run frames × .015 / published seconds |
| --- | --- | --- | --- |
| .x / 2024-09-22 | [712551 / 1726969048](https://ksf.surf/api/replays/replay_css_2000_0_712551_1726969048.rec?game=66t) | `274ad1f6486452755d3f96074357a68618308a52ff7a5f19964bd2f72a4a4aa0` | 6129 / 91.935 / 91.934898 |
| yupiter / 2020-10-05 | [525989 / 1601934267](https://ksf.surf/api/replays/replay_css_2000_0_525989_1601934267.rec?game=66t) | `2861ed10f8756751fe6e78183ce92e675aaf15dc22017b0cd82fee2e6c67d72d` | 6142 / 92.130 / 92.129570 |
| Runner 516878 / 2018-10-30 | [516878 / 1540875981](https://ksf.surf/api/replays/replay_css_2000_0_516878_1540875981.rec?game=66t) | `68483b9eb78e98f7ab126459c401cb38d8fe4d9a1ef1ffaa11e9faa0df57c1e9` | 6180 / 92.700 / 92.699333 |

The last runner's public display name is retained verbatim in the captured source metadata; the table uses the stable numeric player identifier.

A bounded check of the [linked full records page](https://ksf.surf/maps/surf_kitsune/records?game=66t&mode=fw) and its public API covered ranks 1–60. It includes runs from 2025 and 14 August 2026, but every entry newer than the .x September 2024 record has `file: null`. No newer downloadable comparison was available in that checked range. This is not a claim about every record or the current live-server configuration.

## Exact transition observations

All **24** stage transitions across the three files have this pattern:

1. A final source-stage movement sample with substantial horizontal velocity.
2. An intermediate point approximately `(0,0,1000 × previous stage)`, with angles `(0,0,0)`. Horizontal velocity remains substantial; it can change through that sample's input acceleration. In yupiter's file two X coordinates are tiny nonzero floats (`-2.7024517550189722e-36` and `6.701612680182866e-35`), so exact zero must not be assumed universally.
3. On the following frame, the fixed stage spawn below with exact velocity **`(0,0,-6)`**, pitch 0 and yaw 90 for stages 2–7, yaw 270 for stages 8–9.
4. The stage-entry bookmark one frame later, typically with velocity Z −18 and horizontal velocity from the runner's input.

| Arriving stage | Exact recorded spawn | .x spawn frame | yupiter spawn frame | 516878 spawn frame |
| --- | --- | ---: | ---: | ---: |
| 2 Orange | `(-13312,-15072,-320)` | 457 | 583 | 431 |
| 3 Yellow | `(-11264,-15072,-1600)` | 797 | 927 | 776 |
| 4 Green | `(-8192,-15072,-2848)` | 1231 | 1365 | 1217 |
| 5 Teal | `(-5120,-15072,-5312)` | 1697 | 1830 | 1687 |
| 6 Blue | `(-2048,-15072,-7776)` | 2158 | 2289 | 2151 |
| 7 Purple | `(512,-14784,-12032)` | 2680 | 2807 | 2672 |
| 8 Pink | `(8192,-512,6624)` | 3440 | 3570 | 3441 |
| 9 White | `(-15104,14928,10880)` | 4098 | 4233 | 4108 |

For a concrete exact sequence, .x's frames 455–458 contain:

| Frame | Position | Velocity |
| --- | --- | --- |
| 455 | `(-15245.607421875,-11565.146484375,442.13360595703125)` | `(-26.82639503479004,933.5990600585938,-22.006622314453125)` |
| 456 | `(0,0,1000)` | `(-26.82639503479004,933.5990600585938,-34.006622314453125)` |
| 457 | `(-13312,-15072,-320)` | `(0,0,-6)` |
| 458 | `(-13311.6953125,-15071.6689453125,-320.17999267578125)` | `(20.29926872253418,22.08935546875,-18)` |

The [machine-readable review](../fixtures/kitsune-transition-review.json) stores nine complete surrounding samples per transition, all exact binary32 values, source URLs, viewer metadata and hashes. It preserves the three original `.rec` files and matching public viewer HTML. `scripts/review-kitsune-transitions.ts` decodes them offline; `--fetch --records` refreshes the source captures.

## Stock BSP and native CSS evidence

The pinned BSP SHA-1 is `41ff082a485d5b4a306589205187bc730ca4b2ac`. Its ordinary `trigger_teleport` entities have player flag 1, no landmarks and no authored velocity-reset outputs. There are no authored destination entities at those eight intermediate `(0,0,Z)` points. Its Orange destination is `(-13312,-15216,-455)`, different from the public records' `(-13312,-15072,-320)`.

The [native CSS probe](NATIVE-CSS-TELEPORT-PROBE.md) placed a standing and a crouched player at a clean contact with Kitsune `*1`. Both arrived at the exact authored Orange destination while retaining injected velocity `(123,456,78)`. Nearby free-space controls retained the same velocity, and the source placement was checked against solid geometry. The initially contaminated portal-center placement was rejected. This is direct stock CSS evidence, not a Source SDK branch assumption.

The installed authoring metadata and [Valve's reference trigger implementation](https://github.com/ValveSoftware/source-sdk-2013/blob/b8cfb12c0e083a2ef5b2f9f9b50f3902fa034474/src/game/server/triggers.cpp#L2181) also support ordinary velocity preservation. The reference code alone would not prove behavior in CSS; the native test supplies that evidence for the tested portal.

## Replay processing and assembled-stage hypothesis

The public [ReplayViewer loader](https://github.com/crashfort/ReplayViewer/blob/0341fea8ba85fbb7c3d352b4b5ddf704a659fd4d/src/rv_load.inc#L30) reads stored bookmark and frame structures directly into arrays. It chooses a synchronization start and duration from the first start and last stop bookmarks. It does not assemble stage files or synthesize the stored intermediate points, spawns or velocity resets.

The [playback bot](https://github.com/crashfort/ReplayViewer/blob/0341fea8ba85fbb7c3d352b4b5ddf704a659fd4d/src/rv_bot.inc#L162) can teleport to recorded positions and otherwise derives playback velocity from displacement. Therefore a playback bot's measured runtime velocity is not necessarily the file's velocity field. This review decodes the file itself, avoiding that playback layer. Neither public file establishes how KSF's backend records or exports its bytes.

The full-map files retain 98–116 frames of later-stage preparation between each stage-entry stop bookmark and its next start bookmark. Their first-start-to-final-stop frame durations match the published full-map times to less than 0.0007 seconds, including that preparation. Individual-stage PR metadata differs from these full-run stage intervals. This weighs against a simple concatenation of timed WRCP clips, but cannot rule out transformations inside an unpublished recorder/exporter. Multiple runners are separate recorded performances, not independent implementations of that backend.

## What the evidence supports

- **Strong:** stock CSS Kitsune `*1` preserves velocity at the authored destination; the three public KSF CSS 66t forward files consistently show zero-horizontal-speed arrivals at different stage spawns.
- **Supported inference:** KSF's published full-map experience includes later-stage preparation after those arrivals, rather than uninterrupted momentum carried through the authored destinations.
- **Unresolved:** which server, map modification, recorder or exporter component creates the alternate transition; whether current 2026 live servers behave identically; and whether other games, tick rates, styles or server configurations differ.

The browser should describe any zero-arrival behavior as matching the reviewed KSF record profile. It should not present that behavior as the universal stock CSS teleport rule or proof of a named KSF plugin. Progression evidence also does not establish every stage-failure return's policy.