reskate.input.joystick() scanned Windows' 16 winmm slots inside the plugin's call whenever no
controller was cached; on some PCs empty slots made one scan take over 50 ms, and the FPV drone
was stopped for its tick running long after switching to a radio with none plugged in. A thread
now finds the controllers (every 2 s) and reads them (250 a second) through DirectInput, only
while a plugin has asked in the last 2 s, and a call copies its last reading.
DirectInput gives the eight axes a radio sends, where winmm gave six: axes are now X, Y, Z, Rx,
Ry, Rz and the two sliders. A plugin that saved axis numbers should let players set them again.
reskate.input.joysticks() lists every controller plugged in ({device, name}), and
reskate.input.joystick(device) reads that one, so a player with a gamepad and a radio picks which
flies; with no argument it still reads the first, a radio first. The list and the device field
follow neekgate's plugin-joystick-pick branch.
### Problem
1. **Unplaced first-pose phantom spawns (`render`):**
In the 500 ms distance loop (`s.next_shown_rank`), `p.shown_wanted` is set to `everyone || !p.placed || nearest_distance(...) <= ...` so that before a peer's first pose arrives (`!p.placed`, `sampled == false`), their status reads `"Waiting for player poses."` rather than `"Further away than players are shown."`.
However, when their first pose packet arrives in `each_active_peer` (`const bool sampled = ...`), `if (sampled) p.placed = true;` flips `p.placed` to `true` while `p.shown_wanted` is still `true` from when `!p.placed` was true. Because `nearest_distance` has not yet been checked against the newly populated `p.render_pose`, `show_remote()` is immediately called on that frame for every newly-placed player on the server — spawning a full 395-bone 3D skater, 16-bone skateboard, and cosmetics for players 300–500 m across the map, only for the next 500 ms `s.next_shown_rank` pass to evaluate `nearest_distance > s.player_distance` and immediately destroy them (`remove_remote()`).
2. **Follow-camera orbit shifting the distance boundary (`nearest_distance`):**
`nearest_distance(p, local, view)` takes the nearer of `local.pose.root.position` and `view` (the camera). While `view` is needed when the camera is detached from the local skater (spectating another player across the map, replay camera, or flying a drone), during ordinary skating the follow camera orbits ~3–5 m around the local skater. Rotating the camera around the skater shifts the effective `player_distance` boundary by ~8–10 m (consuming the 15% hysteresis band at 50 m) and causes clusters of players near the boundary (such as a Spot Battle crowd) to spawn and despawn as the camera turns.
### Solution
1. When a peer's first pose transitions `p.placed` from `false` to `true` (`if (sampled && !std::exchange(p.placed, true))`), immediately update `p.shown_wanted` from `nearest_distance(p, local, view) <= s.player_distance` before evaluating `spawning` and `show_remote()`. Peers before their first pose still keep `p.shown_wanted = true` (`"Waiting for player poses."`), nearby peers still spawn on their first pose frame without waiting for the 500 ms tick, and far-away peers never phantom-spawn on arrival.
2. In `nearest_distance()`, consider `view` when `!local.ready` or when the camera is more than 12 m from `local.pose.root.position` (spectating, replay, or drone), keeping the distance radius anchored to the local skater during normal third-person follow-camera rotation.
### Verification
- Tested in-game in 44–78 player online lobbies with active Spot Battle throwdowns (`ReSkate.dll` runtime verification).
- Verified in `ReSkate.log` that far-away peers no longer trigger `creating a remote skater` / `Skater component factory` spawns on their first pose packet and that rotating the camera toward a Spot Battle huddle near the 50 m / 70 m boundary no longer triggers a spawn storm.
### Problem
In `mesh_pool::budget_of()` (`Runtime/client_tick.cpp`), the `GlobalMemoryStatusEx` check that caps the custom-map mesh streaming pool budget by the system's remaining physical RAM and page file (`min(ullAvailPhys, ullAvailPageFile) - 2 GiB`) currently runs only when `card.memory < 1 GiB` (`integrated_below`).
Under CrossOver / D3DMetal on Apple Silicon macOS (unified memory) — and on drivers/translation layers that synthesize `DedicatedVideoMemory` from host memory — `DXGI_ADAPTER_DESC1::DedicatedVideoMemory` (`card.memory`) is reported as ~75% of system RAM (`11.8 GB` on a 16 GB Mac), while `IDXGIAdapter3::QueryVideoMemoryInfo(0, DXGI_MEMORY_SEGMENT_GROUP_LOCAL)` reports a `24,248 MB` (`2 * card.memory`) local budget. Because `card.memory >= 1 GiB`, `budget_of()` skips `GlobalMemoryStatusEx` and sees `~23 GB` free, raising `MeshStreaming.PoolSize` to `2.4–3.5 GB` on custom maps (`Skate 2 Improved`, `Skate 3 Improved`, `DHS`) when the machine only has `1.5–2.5 GB` of free physical RAM and commit limit, crashing worker threads during gameplay.
### Solution
Run the `GlobalMemoryStatusEx` budget cap when `card.memory < integrated_below || result->budget > card.memory`:
- On dedicated discrete GPUs on Windows and Linux, the OS local-segment budget (`DXGI_MEMORY_SEGMENT_GROUP_LOCAL`) never exceeds the physical `DedicatedVideoMemory` on the card (`result->budget <= card.memory`), so discrete GPUs remain completely unaffected.
- On unified-memory setups where the reported local budget exceeds `card.memory` (such as D3DMetal reporting a 24 GB budget on an 11.8 GB adapter), `result->budget` is bounded by `result->usage + max(0, min(ullAvailPhys, ullAvailPageFile) - 2 GiB)`.
### Verification
- Tested in-game on a 16 GB Apple Silicon Mac (CrossOver 26.3 / D3DMetal) in 70–78 player online sessions on `Skate 2 Improved` (`2040 MB` meshes), `Skate 3 Improved` (`1277 MB` meshes), and `DHS` (`515 MB` meshes).
- Verified in `ReSkate.log` that `MeshStreaming.PoolSize` is bounded by real available RAM/commit headroom instead of the 24 GB synthetic DXGI budget, eliminating mid-session memory exhaustion crashes.
Resolve private effects only from the level-wide Game compartment and validate
their resident declarations with the same parser used by the mod merge.
Release surviving native services during world changes, check decal realm
ownership before cleanup, defer ordinary off-thread releases, and prune expired
VM handles so they return their quota. Size the temporary decal allowance from
the live count while preserving external settings changes.
Gate contact geometry behind events.physics.geometry, document the manifest
migration, and test Blood impacts through the plugin host using its own manifest.
Add regression coverage for residency, lifetime, quota and draw-budget handling.
Validation: Release builds of the runtime and plugin/effect test targets succeed.
The plugins, effect_geometry and effect_lifetime tests pass. Existing MSBuild
asset-directory dependency warnings remain; native visuals need an in-game check.
The Mods page judged a mod empty when it had no layout.toc, reskate-levels.json or parks, so a
plugin (reskate-plugin.json with an "entry"), music, objects or variants mod got the
"nothing to load" warning although the game loads it. mods::has_content now decides that from
what mod_contents lists (or variants), for the launcher and the catalogue's log note alike.
Icons came only from the Thunderstore listing, so a mod installed by hand or not yet published
showed an empty square. Without a package, the icon.png in the mod's folder is read on the icon
worker instead.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
hold_score's own publish of the "down" value goes through the UI model write hook too, and the field
was already taken, so the hook kept our value as what the game meant. Given back, the corner then
restored "down". HudWidgetActive is written again often enough that the ring and trick list came
back, but ExtraInfoStyle rarely is, so the LINE label stayed hidden for the session (Hall of Meat's
card, or any plugin hiding the corner). The hook now leaves what the game meant alone while
hold_score publishes. Not checked in the game.
Fixes#318
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A handle the game reads from without having asked HidD_GetAttributes about it is identified by
the read: a read of a Sony pad's size makes ReSkate ask the handle's vendor and product. Only reads
of 10 to 512 bytes were asked about, and a DualShock 4 over Bluetooth is read 547 bytes at a time,
so on such a handle none of the menu, gamepad filter or Dark Pop handling ran. Reads up to 547
bytes are now asked about.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Windows pads every read of a DualShock 4 over Bluetooth to that pad's longest input report, 547
bytes. The full report (0x11) inside it is 78 bytes and ends in a CRC-32, and the CRC was refreshed
only when a read was exactly 78 bytes. A report the overlay changed on such a pad (made neutral
under a menu, passed through the gamepad filter, or its D-pad hidden by Dark Pop) kept its old
CRC, and the game's reader discards a report whose CRC does not match, so the change never reached
it. The CRC now goes at offset 74, over the 0xA1 input prefix and the 74 bytes before it, in a
78-byte read or a padded 547-byte one, and the padding is left alone.
The CRC moves to playstation_report.h as refresh_playstation_bluetooth_crc, where the PlayStation
report test checks it against a separate table-driven CRC and two zlib answers, and the copy Dark
Pop kept for itself is gone.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
external_player.cpp now asks plex_web, spotify_device and youtube_music what is playing, so
dingosdk_external_player_probe (multiplayer tests, Windows) failed to link with 10 unresolved
externals. Linking those players would bring in the overlay, the log and HTTPS, so the probe gets
stubs that report them switched off and keeps reading only the Windows media session.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
grind_exit gave way to shape_launch upstream, so Enums.GrindSide becomes
Enums.Launch, the words shape_launch checks; Delete joins Enums.Key.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
skater.pose's places are worked out with the pose's scale in them (keep_children, or a joint placed
relative to another joint or the world under a scaled one), but the others were sent only rotation
and position, so such a joint landed up to a thousand times its distance away on their screens. A
place may also be far off in the parent's frame, which drew a skater's arms and head across the map
for everyone. The sent pose now carries each joint's scale (0.001 to 10), and a joint's offset from
its parent is cut to 4 m in what is sent. What the player sees locally is unchanged.
The promotion loop went through the edits in the order they were absorbed, lowest priority first,
and kept the first usable graph, so a lower pack's graph won and the higher pack's private rows
were dropped. It now looks from the highest priority down. The archive test covers two custom packs
with their own bytecode and different second programs (it runs with a game root, as the other
archive checks do).
Since the declarations were read from the applied catalogue, a file that could not be read or
parsed threw out of the whole refresh, so no mod's declared inputs applied (from launch, or after a
live apply). Each file is read on its own again: a broken one is logged with its mod and skipped,
and only a failed read of item ownership keeps the previous set.
Mods: preserve bundle-owned shader graphs alongside stock material aliases
Conflict with #363 resolved by keeping both: its native variant addition tests and the shader
selection tests in mod_merge_added_assets_tests.cpp, run from one main().
Plugins: support declared colour inputs on mod-owned board materials
Conflicts with #363 resolved by keeping both: reconcile_variant_additions beside
active_mod_sources in mod_catalog.h, and both test targets in cmake/Apps.cmake.
Add permission-gated effect handles, native surface attachments, and world lifetime cleanup. Extend physics_step with optional contact geometry and body poses. Document the generic API and validate it with self-contained plugin and geometry fixtures.
So far a plugin could only add to what the game's animation does with a joint. Now it can give the
joint its own transform, which the animation's is replaced by: its own animations, joints reused for
body parts the skater doesn't have, joints moved by a simulation in Luau, joints pinned to a point.
A joint's entry takes place = {position, rotation | angles, relative_to} and keep_children = true
(its children stay where they were); a pose takes up to 128 joints. Each frame the place is turned
into the joint's value under its real parent, the joints posed in an order that puts each after its
posed parents and the joint it is placed relative to; a pose without such an order is refused with
the reason.
Extension/Skater/pose_place.h/.cpp hold the maths, with pose_place_tests; skater_animation applies it
after a joint's offsets; plugin_api_world reads it and sorts the joints.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
merge_chunk_metadata gave such a chunk a record with no fields. The game's reader (0x41af080) takes
a record without "h64" as a "g" record and, with no "g" either, reads its guid through null
(Skate.exe+0x15b2c34: computerK-Fingerboard adds its grip texture to a game deck bundle whose list
has no record for it). The record is now an owner hash no resource has, with an empty meta, which
the game passes over.
2.1.2 left such an actor alive and forgotten. When the level went, the game released its parent
through the same pointer, took one off the byte below the parent's vtable pointer and called
through it (Skate.exe+0x2b8092f and +0x2b7fcfb, every report after the "link ... is damaged"
warning with the same bus). A link exactly one less than the parent the bus also holds at +0x48 is
now repaired before the destroy; other damage is still left alive. What shortens the link is not
known yet.
The skater sound state sent the packed material words of the surfaces under a skater as they were.
A Studio map's surfaces are appended to the root grid from slot 116 on, numbered by each install's
own set of map mods, so the same word named another surface on the other side, or a slot past the
end of its grid, and the game's material lookups (0x7111c0, 0x45e120) read past MaterialIndexMap
(Skate.exe+0x41da7b and +0x6fc93b, 240 installs in a day on 55a7342, on Tokyo 2026, Community
Center, Olay Way and other maps with their own surfaces). Those words now cross as the grid's
default, when sent and when received, so older clients sending their own numbers are covered too.
reskate.outfit.worn() is meant to list full-body costumes: it has a "Costume" slot for them, between
the head and the feet. But no costume ever reached it. With a costume on, the list came back without
it, so a plugin that goes with a costume mod could not tell whether its costume was worn. Now it is
listed like any other item: {slot = "Costume", item = "Own_Hobkin", title = "Hobkin"}.
Why: the list leaves out the body's own parts (head shape, nose, skin...) by their catalog categories,
which start with "cust" (custhead, custnoses, custbodies...) or name the body. A full-body costume's
category is "cust_fullBodyCostume", so it matched both and was dropped before its slot was looked up.
A category that names a costume is now kept; everything else is decided as before.
The rule (category to slot) moves out of worn_items.cpp into outfit_kind.h as it was, so it can be
tested without the game: outfit_kind_tests (with the plugin tests) checks clothes by their slots, the
costume, the body's own parts, and an unknown category.
Checked in the game: with a costume mod's costume on, outfit.worn() returns
Costume | Own_Hobkin | Hobkin, where it returned nothing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
skater.pose changes the skater relative to the game's animation. Some of those changes were applied
twice every third frame, so a posed skater shook in a three-frame rhythm, and their board with them.
The more a plugin changed, the worse it got: an avatar with the hips scaled and offsets on most of
the body needed workarounds in its plugin to hold still. Now every pose is applied exactly once, and
a plugin can give skater.pose the values it means.
Why: ReSkate draws a pose by writing it into the game's bone buffer just before the render, and the
game evaluates the next frame from that same buffer without overwriting all of it. Two of three
frames it resets the buffer itself; in the third the pose drawn was still there and the next pose
went on top of it. Now the game's own values go back as soon as the renderer has its copy, so the
game, the body physics and the next animation update only ever see the game's pose.
This replaces own_scale, the earlier fix for the same cause (the Filmer's forearm at 0.001 shrinking
to nothing). It covered only scale, and put it back after the game had already run on the posed
values, so rotations and offsets still doubled. The new way covers every part of every joint, for
pose, carry and reach, with nothing to track per joint and nothing to clean up after a pose ends.
Checked in the game: the avatar with the hips at 0.667 and offsets on 48 joints holds still with
only skater.pose (shoulder distance 0.117 m every frame, where it was 0.117 0.117 0.067 ...). The
Filmer 1.0.0's camcorder preview looks and measures as on main, and the skater is back to normal
after it.
Details: the renderer copies the bones in submit_render_pose (0x4c7e7a0), which the render pose
caller (0x2c20d99) calls right after render_pose with the same render data; found with a guard page
on the bone buffer that logged every access with its call stack. native_skater hooks it and, for the
render data the pose override just wrote, calls the new set_pose_override_drawn_listener.
skater_animation keeps what on_render wrote over and puts it back in on_drawn.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
AyeZeeBB