mirror of
https://github.com/JogmansonReal/Radicade.git
synced 2026-10-25 15:09:26 -07:00
JogmansonReal
3945 lines
230 KiB
Markdown
3945 lines
230 KiB
Markdown
# August 2023 client migration — local work, not yet playable
|
|
|
|
Target: `C:\RecRoom\2023-08-29T06-53-33Z`.
|
|
The version stored in this client's `globalgamemanagers` is **20230825**,
|
|
and its Unity version is 2020.3.33f1.
|
|
|
|
## Implemented
|
|
|
|
- Server default game version is 20230825 (earlier supported versions remain).
|
|
- The metadata patcher recognizes this release's shuffled 256-byte header using
|
|
a SHA-256 fingerprint, excluding only the two fields it intentionally updates.
|
|
Unknown headers still fail closed.
|
|
- Literal table offset/size fields are at 0x2C/0xBC; literal data offset/size
|
|
fields are at 0xC8/0xC0. All 52,189 literal records fit the original blob.
|
|
- Rewrite verification checks unchanged literal contents and all original bytes
|
|
outside the literal records and the two edited header fields.
|
|
- The patch marker records 20230825 rather than the old hardcoded March version.
|
|
- Local development exposes HTTPS on localhost:3030 and HTTP on 127.0.0.1:3031,
|
|
and advertises HTTPS service URLs.
|
|
|
|
Original client metadata and boot configuration are preserved beside the files
|
|
as `.orig`. No March BepInEx files or generated interop assemblies were copied
|
|
into the August client. No Git push or remote server deployment was performed.
|
|
|
|
## Verification and remaining blocker
|
|
|
|
The patcher's real-file verification passes, including a second dry run with
|
|
zero changes. Server startup succeeds and the version endpoint returns
|
|
ValidVersion=0 / VersionStatus=0. The 38 targeted VersionCheck, Nameserver and
|
|
SplitTestCompatibility tests pass.
|
|
|
|
Initial startup failures (before the August plugin):
|
|
|
|
- HTTP: the client's request constructor throws `Exception: Invalid URI scheme`.
|
|
- Direct desktop launch with HTTPS: embedded BestHTTP/BouncyCastle rejects the
|
|
local certificate with `user_canceled(90)` / nameserver error `summer`.
|
|
- EAC bootstrapper launch: native crash near `Connecting to RecNet`.
|
|
|
|
The new `2023Patch/RadicadeAugustClient` project builds against August interop
|
|
and replaces the March plugin locally. It installs embedded TLS, nameserver,
|
|
image signature key, hub authentication, and August EAC challenge hooks without
|
|
March-only UI patches. The old DLL is preserved as
|
|
`BepInEx/plugins/RadicadeEacBypass.dll.march-backup`; the old configuration is
|
|
preserved as `com.radicade.eacbypass.cfg.before-august`.
|
|
|
|
Live verification: August Client 2.0.0 loads without a plugin-load exception,
|
|
TLS accepts the configured localhost endpoint, the game fetches the nameserver,
|
|
`/api/gameconfigs/v1/all` and `/api/config/v1/amplitude` successfully, and logs
|
|
the Steam profile. It then reports **Launch validation failed. Is Rec Room
|
|
installed correctly?** Login and room joining remain unverified. No broad
|
|
launch-validation or error-suppression patch was installed.
|
|
|
|
## Launch-validation root cause and bypass
|
|
|
|
Native analysis with the `tools/AugustInterop` disassembler traced the error:
|
|
|
|
- `NDIIPBKGGIG::CBNCPLACNIE(15)` is the only call site producing the error
|
|
screen; value 15 is `JKBPKDAGEHN.LAUNCH_VALIDATION_FAILED`.
|
|
- Its sole caller chain is `NFPDGJNDFOF::GBLLEJBCFGI -> NFPDGJNDFOF::GBAMNAKGEGD`.
|
|
- `GBAMNAKGEGD` is the boot validator invoked from `BootSequence::DFCEILLEFOK`
|
|
via `ADJOODNBCKG::BEFDPLAELIH`. It resolves an obfuscated static-data file
|
|
reference, opens the referenced file, parses its PE headers, and computes a
|
|
SHA-256 over selected sections in 0x400-byte chunks on a background thread,
|
|
then hard-rejects (`CBNCPLACNIE(15)`) when the hash does not match the
|
|
expected value baked into `GameAssembly.dll`'s static data.
|
|
- The check is not satisfiable in a patched installation (BepInEx loader
|
|
metadata redirect and localhost server wiring), so the plugin now installs
|
|
`AugustLaunchValidatorPatch`, a prefix on `ADJOODNBCKG.NFPDGJNDFOF::GBAMNAKGEGD`
|
|
that resolves the boot completion promise (`PFDOLDLEIBA.OLKGFACPIPC`, with a
|
|
direct handler-list fallback) and skips the native body. It must be
|
|
registered via `harmony.PatchAll` in the plugin `Load` method — an earlier
|
|
attempt defined the patch class but never registered it, which is why the
|
|
error screen still appeared once.
|
|
|
|
Rebuild and reinstall `RadicadeAugustClient.dll` after this change; the log
|
|
should show `Bypassing native launch validator` before boot proceeds.
|
|
|
|
Build validation: August plugin builds with zero warnings/errors. The March
|
|
plugin cannot be compiled unchanged against August's renamed types.
|
|
|
|
The final client target is `https://localhost:3030`. Start the server with
|
|
`dotnet run --project Server/Server.csproj`. For diagnostics, direct desktop
|
|
launch uses `RecRoom.exe +forcemode:screen`; it now passes TLS and encounters
|
|
the launch-validation blocker described above.
|
|
|
|
## BepInEx interop generation fixed
|
|
|
|
The installed BepInEx 6.0.0-be.697 initially failed Cpp2IL's magic-number check.
|
|
The original `.orig` metadata has the same shuffled header: this is the release's
|
|
format, not evidence of download corruption or a URL-patch error.
|
|
|
|
`tools/AugustInterop/normalize.cjs` creates a **separate tooling copy** with a
|
|
standard v27 header. It also repairs the 305 synthetic `<Module>` records, whose
|
|
name indices and generic-container indices otherwise break assembly generation.
|
|
Only verified module records are repaired. This copy must NEVER replace the
|
|
game's `global-metadata.dat`; the native runtime expects the custom format.
|
|
|
|
The installed loader reads `global-metadata.interop.dat` for Cpp2IL. Its original
|
|
is backed up at `BepInEx/core/BepInEx.Unity.IL2CPP.dll.before-august-interop`.
|
|
The loader modification changes only RunCpp2Il's metadata filename literal.
|
|
|
|
Verified with the actual August GameAssembly.dll: 42,537 types and 283,224
|
|
methods parsed, native registrations resolved, interop generation completed,
|
|
335 files written including the hash and caches, and the live loader logged
|
|
`Chainloader startup complete`. Interop generation was first verified with no
|
|
plugins; the August connection plugin was then built and installed separately.
|
|
|
|
See `tools/AugustInterop/README.md` for reproduction and rollback.
|
|
|
|
## August login "code: block" root cause and fix
|
|
|
|
Symptom: title screen showed `Cached/Manual Login failed with: Unable to login
|
|
(code: block)` right after a `POST /matchmaking/player/login` log line whose
|
|
`[Net]` line prints when the request is queued, not when the response lands.
|
|
|
|
Server-side truth (server-console.log + PlayerDataDebug): the login POST
|
|
actually returned **200** both times. The real 405 came from
|
|
`POST /api/PlayerReporting/v1/moderationBlockDetails`, which the server only
|
|
mapped as GET; Kestrel answered the POST with 405 Method Not Allowed. The
|
|
August login flow runs its moderation-block check inside the login promise, and
|
|
a failed check maps to `JKBPKDAGEHN.LOGIN_CODE_BLOCK` - hence "code: block",
|
|
which reads like a moderation block but was a route mismatch.
|
|
|
|
Fix: added `[HttpPost("v1/moderationBlockDetails"), Authorize] GetBlockDetailsPost()`
|
|
in `Server/API/Moderation/PlayerReportingAPI.cs`, delegating to the existing GET
|
|
action so both verbs serve the identical body. Verified live: POST now returns
|
|
401 without a token (auth layer reached, no more 405) and the GET shape is
|
|
unchanged for older clients. Server rebuilt and restarted on 3030/3031.
|
|
|
|
Remaining non-fatal August 404s (client continues without them):
|
|
`GET /matchmaking/player/qos`, `GET /matchmaking/player/connection-info`,
|
|
`GET /chat/thread/party`, `GET /cdn/room/`. RudderStack analytics cannot
|
|
resolve its host and self-disables after 15 failures.
|
|
|
|
Verified in-game after the fix: `POST /matchmaking/player/login` -> 200,
|
|
`POST /matchmaking/player/exclusivelogin` -> 200,
|
|
`POST /api/PlayerReporting/v1/moderationBlockDetails` -> 200 (86-byte empty
|
|
block-details body), hub WebSocket connected, and the avatar spawned in the
|
|
Dorm. The August 2023 build boots fully into the Radicade server. The RSA
|
|
neutralizer correctly passes through verification calls signed with non-p1
|
|
keys (observed on a `cdn/sigs/...` fetch).
|
|
|
|
## Remaining August 404s fixed
|
|
|
|
The four 404s the August client hit after login were implemented, using the
|
|
recflare reference server's response shapes where documented:
|
|
|
|
- `GET /matchmaking/player/qos` - unauthenticated BARE ARRAY of QoS probe
|
|
regions (id + host:port address); the client pings these and reports back
|
|
through `PUT /matchmaking/player/photonregionpings` (already a no-op ack).
|
|
- `GET /matchmaking/player/connection-info` - authed `{ success, value, error }`
|
|
envelope carrying a freshly minted HS256 `photonAuthToken` (sub/rn.platid/
|
|
rn.plat/rn.deviceclass/rn.env claims, 1h TTL, signed with the server JWT key),
|
|
the configured Photon app ids, `photonRegion`, and the `photonRoomId` of the
|
|
caller's current room instance (presence first, `roomInstanceId` query param
|
|
as fallback). The `experiments` block mirrors the reference verbatim;
|
|
`shouldUseGameServerNetworking` stays false.
|
|
- `GET /chat/thread/party` - empty object (recflare's documented stub: parses as
|
|
"no party" without failing the client's deserializer).
|
|
- `GET /platformnotifications/crm/me/config` - empty object (same stub
|
|
convention; the 404 here raised one console error per login).
|
|
|
|
Photon app ids and region are configurable (`Radicade:Photon:RealtimeAppId`,
|
|
`VoiceAppId`, `ChatAppId`, `Region` in appsettings) and default to empty ids /
|
|
`us` region, exactly as recflare behaves with no Photon configured: the client
|
|
is told empty ids and connects to nothing. A deployment that runs a Photon
|
|
server sets the three ids and the client connects normally.
|
|
|
|
Corrections after the first live run with those routes (all observed in
|
|
BepInEx LogOutput.log):
|
|
|
|
- `chat/thread/party`: the August client deserializes this as a LIST - the
|
|
empty-object stub made it throw `expected:'[', actual:'{'`. Answers a bare
|
|
empty array now.
|
|
- `platformnotifications/crm/me/config`: the empty-object stub made the manager
|
|
throw `Deserialization returned null`. The client parses a counted envelope
|
|
here (same as `config/categories`), so it answers
|
|
`{ Results: [], TotalResults: 0 }` now.
|
|
- `connection-info` with empty Photon app ids is WORSE than a 404: the client's
|
|
GetRegions call gets `Empty application id` (ReturnCode -2) and Photon drops
|
|
the session with InvalidAuthentication. The ids must be the ones the client
|
|
actually uses - they live in the game's
|
|
`BepInEx/config/com.radicade.eacbypass.cfg` under [Photon] and are now set in
|
|
appsettings (`22dda1bb-...` realtime, `82766593-...` voice, `e8ea33f3-...`
|
|
chat), matching the AppIdOverride the March plugin was already forcing.
|
|
|
|
### 2026-09-27: the same empty-app-id trap, hit again on a second host
|
|
|
|
Moving the client to the public server reproduced the `connection-info` failure above,
|
|
from the other direction. The loader reported `GOING TO ^DormRoom 0% PREPARING..` and
|
|
sat there; the server looked healthy throughout (presence, matchmaking and the room
|
|
routes all 200), and the client's own log showed the real story:
|
|
|
|
[Network.Photon.LoadBalancingClient] Queued Network action failed due to exception: NullReferenceException
|
|
[RoomLoad.RoomManager.PresenceUpdates] Error joining room instance RoomInstance - ID:21516 DORM_ROOM:25/32
|
|
JOKAIBMCFDA::Failed to connect to region "us"
|
|
IKDHNNILPMJ::Unexpected Photon Disconnect due to cause: InvalidAuthentication
|
|
|
|
with `Empty application id` in Player.log exactly once and `InvalidAuthentication` eight
|
|
times, retrying roughly every 7 s. The cause was config, not code: the ids were set in
|
|
`appsettings.Development.json` and **not** in `appsettings.Production.json`, so a host
|
|
running the Production environment kept the `DBConfig` defaults (`""`) and answered
|
|
`connection-info` with an empty `photonRealtimeAppId`. Photon's GetRegions then fails
|
|
with ReturnCode -2 and drops the session, which is the documented behaviour quoted
|
|
above - `connection-info` with empty ids is worse than a 404.
|
|
|
|
Two changes so the next environment does not have to be diagnosed from a loading screen:
|
|
|
|
- `Server/appsettings.Production.json` carries the `Radicade:Photon` block (same app as the
|
|
dev config and the plugin's `AppIdOverride`).
|
|
- `Server/Program.cs` prints either `Photon: realtime app id configured, region 'us'
|
|
(voice set, chat set).` or a full WARNING naming the four keys to set, at startup. The
|
|
warning path is verified by booting with `Radicade__Photon__RealtimeAppId=` set to empty.
|
|
|
|
Note the failure is silent by design from the server's point of view: nothing 500s and no
|
|
route errors. Anything that shows up as "the room load hangs at 0%" should have the
|
|
client's Photon state checked first, because the REST surface will look perfect.
|
|
|
|
## Run-3 hard crash root cause: RSA passthrough access violation (fixed)
|
|
|
|
The fully-green-server run (20:25) still crashed the client on the loading
|
|
screen with the infamous `DILGBLCELMP: Exception of type 'DILGBLCELMP' was
|
|
thrown.` at `DLHKINDAIHK+MICFNEHOAMC.MoveNext()` right after
|
|
`GET /platformnotifications/crm/me/config` (200) and
|
|
`[ImageSig] RSA verify called #1 with non-p1 key - passing through`.
|
|
|
|
That obfuscated exception was a red herring: the *real* fatal is in BepInEx
|
|
`ErrorLog.log`:
|
|
|
|
```
|
|
Fatal error. System.AccessViolationException
|
|
at Il2CppInterop.Runtime.IL2CPP.il2cpp_runtime_invoke(...)
|
|
at DynamicClass.DMD<RSACryptoServiceProvider::VerifyHash>(...)
|
|
```
|
|
|
|
Chain of events:
|
|
|
|
1. After `exclusivelogin`, the client downloads the file-integrity manifest
|
|
`GET /cdn/sigs/6fae9a40-edf5-44c5-a263-36d7b5b4a91f` (served since an earlier
|
|
blocker) and starts verifying the listed game files' signatures.
|
|
2. It verifies with the game's OWN embedded RSA key (not p1.rec.net), which
|
|
reached `RsaVerifyNeutralizerPatches.VerifyPrefix`'s deliberate
|
|
"non-p1 -> pass through to original" path.
|
|
3. Invoking the il2cpp original through the Harmony DMD re-implementation
|
|
access-violates (interop cannot safely re-enter that native method). Unity
|
|
surfaces the AV as the unmappable `DILGBLCELMP` il2cpp exception inside the
|
|
sigs-check async chain (`DLHKINDAIHK+MICFNEHOAMC` awaited the RecNet HTTP
|
|
task, then died during verify) - hence the crash *after* the crm 200 line
|
|
even though crm/party responses were parsed fine.
|
|
|
|
Fix (client plugin, `RadicadeAugustClient.Plugin.cs`): the RSA verify prefix now
|
|
forces `true` and skips the original for EVERY intercepted verify, p1 key or
|
|
not - the passthrough path is never taken because it is un-invokable. Rebuilt
|
|
(`dotnet build 2023Patch/RadicadeAugustClient/... -c Release`, 0 errors) and
|
|
deployed to `BepInEx/plugins/RadicadeAugustClient.dll` (2023-09-23 21:07).
|
|
|
|
Lesson: on this build, any Harmony-prefixed il2cpp method whose prefix returns
|
|
true (executes the original) risks the DMD AV. Neutralizer-style patches must
|
|
always skip the original when the original's failure is the thing being patched.
|
|
|
|
## Run-4 follow-up: file check fails gracefully -> manifest parser bypassed (fixed)
|
|
|
|
After the RSA-forcing fix, the client survived the sigs manifest (RSA verify
|
|
forced true, DILGBLCELMP now a caught/logged error) but the checker
|
|
(KKHDHILFOGO) threw while PARSING the placeholder manifest:
|
|
`IndexOutOfRangeException in KKHDHILFOGO.PFNKMGPPFGP` -> "File check failed
|
|
KKHDHILFOGO+LPIKGKOLBJH: Error validating file Failed to process verification
|
|
file due to internal exception" -> POST /api/PlayerReporting/v1/hile ->
|
|
PreparingToExit -> clean shutdown. Not a crash, but still an exit.
|
|
|
|
The real manifest format encodes per-file hashes inside the RSA-signed blobs,
|
|
so no manifest we can serve without Rec Room's private key parses.
|
|
|
|
Fix (client plugin): new `FileCheckManifestParserPatch` prefixes
|
|
`KKHDHILFOGO.PFNKMGPPFGP` and returns an empty file->hash dictionary - with no
|
|
files listed the per-file verify loop completes as success. Rebuilt and
|
|
deployed (2023-09-23 ~21:20). Look for `[FileCheck] manifest parser bypassed`
|
|
in the next BepInEx log.
|
|
|
|
## Run-5: manifest parser patch is NOT viable -> sigs route reverted to 404 (final)
|
|
|
|
The `FileCheckManifestParserPatch` attempt failed differently: HarmonyX's DMD
|
|
cannot compile the detour for `KKHDHILFOGO.PFNKMGPPFGP`'s out-byref generic
|
|
signature (`Dictionary<string, Il2CppStructArray<byte>>& out`) and throws
|
|
`InvalidProgramException: Common Language Runtime detected an invalid program`
|
|
at `(il2cpp -> managed) PFNKMGPPFGP` detour time - the checker then fails with
|
|
NullReferenceException and the same `hile` report + PreparingToExit follows.
|
|
|
|
Empirical summary across runs (all 2023-09-23):
|
|
|
|
| cdn/sigs response | client outcome |
|
|
|------------------------------|--------------------------------------------------|
|
|
| 404 (run 1) | reaches the Dorm (known-good) |
|
|
| 200 placeholder (run 4) | IndexOutOfRange in parser -> hile -> exit |
|
|
| 200 + parser patch (run 5) | InvalidProgramException (DMD) -> hile -> exit |
|
|
|
|
Conclusion: the check TOLERATES a 404 and fails hard on any 200 we can produce.
|
|
The parser patch was removed from the plugin and `SigsCDN.cs` now deliberately
|
|
answers 404 (with the full analysis in its header comment). Plugin rebuilt and
|
|
redeployed; server rebuilt, restarted (PID 4768), verified: sigs 404,
|
|
gameconfigs/qos 200. The RSA verify neutralizer stays for p1-keyed image
|
|
signatures; the DMD passthrough AV lesson from run 3 still applies to any new
|
|
patch that would execute an il2cpp original.
|
|
|
|
## Run-6 correction: 404 is NOT tolerated; final sigs/RSA combination
|
|
|
|
Run 6 disproved the "client tolerates a 404" theory from run 5's writeup:
|
|
`OBHEMJEJNMK: HTTP Error 404` -> "File check failed ... Dowload failed" ->
|
|
hile report -> PreparingToExit. Reconciling ALL six runs gives the real
|
|
rules of the file check (KKHDHILFOGO):
|
|
|
|
1. Missing manifest (404) -> fatal (run 6)
|
|
2. Manifest present, non-p1 verify PASSES through -> DMD access violation
|
|
to il2cpp original (run 3, flaky)
|
|
3. Manifest present, non-p1 verify forced TRUE -> parser decodes the
|
|
fake 16-byte blobs as a hash table -> IndexOutOfRange (run 4)
|
|
4. Manifest present, non-p1 verify forced FALSE -> parser skips blob
|
|
decoding, check completes -> known-good (run 1, Dorm reached)
|
|
5. A client-side parser prefix is impossible (DMD InvalidProgramException,
|
|
run 5) - the out-byref generic signature is un-detourable.
|
|
|
|
FINAL combination (all live 2023-09-23 ~21:35): SigsCDN.cs serves the
|
|
placeholder manifest again (with byte-range support) AND
|
|
RsaVerifyNeutralizerPatches now answers `__result = isP1` - TRUE only for the
|
|
embedded p1.rec.net key (image signatures, boot-critical), FALSE for every
|
|
other key (the file check, which must fail cleanly to skip blob decoding).
|
|
Never passthrough (AV), never unconditional TRUE (IndexOutOfRange).
|
|
Plugin rebuilt/deployed, server rebuilt/restarted (PID 42708), verified:
|
|
sigs 200 placeholder, gameconfigs/qos 200. Watch for
|
|
`[ImageSig] RSA verify #N (game key) forced false` in BepInEx.
|
|
|
|
## Run 11 outcome (22:36) + Run 12: exit-state veto (deployed 22:55)
|
|
|
|
Run 11: suppression armed, file-check bypass fired, Dorm load started at
|
|
11.13s - then the process DIED mid-scene-load at 16.26s with no exception,
|
|
no hile POST, no exit sequence. The IJHOPKJFKBI prefix crashed the process
|
|
inside the DMD stub BEFORE the prefix body ran: the scanner thread is a
|
|
native, unattached thread (CallerCount(1), no managed callers), and il2cpp
|
|
detours on such threads access-violate - the run-3 VerifyHash AV class.
|
|
winhttp.dll cannot be dodged at the source: it is the EAC-bypass door DLL
|
|
(the only non-stock DLL in the game root) and loads BepInEx itself.
|
|
|
|
Run 12 therefore ALLOWS the hile report to happen (HileAPI logs it at info)
|
|
and vetoes the MANAGED exit state machine instead:
|
|
`CCKNJCHHBLL.KALEFEDAHCC` (AppExitState setter, enum Running/PreparingToExit/
|
|
ReadyForExit) is prefixed; transitions OUT of Running are blocked for 120s
|
|
after load, then pass through. The observed shutdown always begins with the
|
|
managed "AppExitState changed: Running => PreparingToExit" line, so this
|
|
cuts the shutdown off at its head from attached managed-thread territory
|
|
where detours are proven safe. Alt+F4 still works (native path).
|
|
|
|
Run 12 markers: `[ExitVeto] blocked AppExitState -> PreparingToExit at ~16s`
|
|
in BepInEx, hile POST visible server-side but session SURVIVES, room load
|
|
completes, player spawns in the Dorm. If the game still exits: the scan
|
|
thread exits natively without the managed transition - next lever is
|
|
thread-freezing or attacking the scan itself.
|
|
|
|
## Run 10 outcome (22:31): hile suppression DID NOT FIRE - registration bug, fixed
|
|
|
|
Run 10 replayed run 9's ending exactly: file-check bypass fired, Dorm room
|
|
load ran 6.1s, hile POST at ~18.3s, PreparingToExit 160ms later, room load
|
|
cancelled. No `[Hile] suppressed` line, no `armed` startup line. Cause:
|
|
`HileReportSuppressionPatch` was added as a class but never registered -
|
|
this plugin patches per-class (`harmony.PatchAll(typeof(...))`) and the new
|
|
class was missing from the Awake chain. Fixed + startup log line
|
|
"[Hile] report suppression armed" added; deployed 22:34:43.
|
|
|
|
Server-side wins confirmed in run 10: gameserverregionpings PUT no longer
|
|
404s ("Failed to upload cluster pings" gone); curatedlists 404 gone but
|
|
the client now logs non-fatal "Deserialization returned null" + "No such
|
|
list" for `GET /lists/curatedlists/bulk?id=17859340` - the `[]` shape is
|
|
tolerated but wrong; may want a `Results/TotalResults` envelope or a list
|
|
object later (NOT the current blocker).
|
|
|
|
Run 11 markers: `[Hile] report suppression armed` at startup, then
|
|
`[Hile] suppressed report 0 (Obscured) message='winhttp.dll'` at ~18s,
|
|
NO `POST .../v1/hile`, no PreparingToExit, player spawns in the Dorm.
|
|
|
|
## Run 9 outcome (22:16): file check DEAD, new blocker = native module scan (winhttp.dll)
|
|
|
|
The both-entries bypass WORKED: `[FileCheck] entry bypassed` fired after
|
|
exclusivelogin, no `GET /cdn/sigs`, no game-key RSA verify, no
|
|
"Signatures don't match!". Boot went deeper than ever: matchmake/dorm ->
|
|
room 25/32 instance 20830 -> Photon connect -> LoadScene(dormroom2) ->
|
|
Initial Room Load '@TestPlayer's Dorm' completed its 5.3s flow - then the
|
|
session died: hile POST at 20.48s, PreparingToExit at 20.64s, room load
|
|
cancelled.
|
|
|
|
The hile body decoded server-side: `Type=Obcured Message=[0:winhttp.dll]`
|
|
- the native module scanner flags our EAC-bypass proxy DLL (game root,
|
|
26KB, deployed 15:18) as an obscured module. The hile enum (MEHDFJHKLBK.
|
|
JBLJIENBBHK) decodes [0:...] = (Obscured, "winhttp.dll"). Same pattern in
|
|
the short 22:15:40 session.
|
|
|
|
Also fixed (server, 22:29): GET /lists/curatedlists/bulk -> [] (was 404,
|
|
caused one "Deserialization returned null") and PUT
|
|
/matchmaking/player/gameserverregionpings -> {} (was 404, "Failed to
|
|
upload cluster pings").
|
|
|
|
## Run 10: hile funnel suppression (deployed 22:29)
|
|
|
|
Client: `HileReportSuppressionPatch` - prefix on
|
|
`KDJDKJNPELI.IJHOPKJFKBI(MEHDFJHKLBK.JBLJIENBBHK, string)` (CallerCount(1)
|
|
funnel for EVERY hile report; enum Obscured=0/Time=1/Inject=2/.../
|
|
AppData_Boot_InvalidSignature=310/...) returns false and logs the report;
|
|
finalizer on `ModerationManager.BJGDALDIOGI` is insurance for paths
|
|
skipping the static funnel. No hile report is legitimate in a Radicade
|
|
session. Server: HileAPI log downgraded warning -> info.
|
|
|
|
Success markers: `[Hile] suppressed report 0 (Obscured) message='winhttp.dll'`
|
|
in BepInEx, no `POST .../v1/hile` in server log, no PreparingToExit, room
|
|
load 25/32 completes and the player spawns in the Dorm. If a DIFFERENT
|
|
hile type appears later, the suppression log will name it.
|
|
|
|
## Run 9: entry patch v2 - both entries (deployed 22:08)
|
|
|
|
Run 8 (21:54) failed exactly like run 7: no `[FileCheck] entry bypassed` line,
|
|
`GET /cdn/sigs/...` still ran, `RSA verify #1 (game key) forced false`, then
|
|
"Signatures don't match!". The public wrapper `GGIFLDPHCIP` is never invoked.
|
|
The decomp explains it: `GGIFLDPHCIP` is marked `CallerCount(0)` (dead public
|
|
wrapper) while the private twin `GOCCLPJDJIC` (same signature) is
|
|
`CallerCount(3)`; the no-arg `NPIILCCIPNF` is also `CallerCount(0)`, so it
|
|
needs no patch. `FileCheckEntryPatch` now uses `TargetMethods()` to prefix
|
|
BOTH entries and returns the already-resolved success promise
|
|
(`PFDOLDLEIBA.PLJINLOCHGM(KKHDHILFOGO.BJGODLEIDGE.NOMPJGOIAEB(...))`).
|
|
No download, no parsing, no RSA verify; the consumer sees a resolved
|
|
`MCFFIFIPNKE<BJGODLEIDGE>` exactly like a passing check produces. Success
|
|
markers for run 9: `[FileCheck] entry bypassed - resolved success promise
|
|
returned` in BepInEx, and NO `GET /cdn/sigs` / no RSA verify / no
|
|
`POST .../v1/hile`; boot should continue past the file check into the Dorm.
|
|
|
|
## Run-7/8: forced-FALSE also fails; final bypass = resolved success promise (deployed)
|
|
|
|
Run 7 (`__result = isP1`, non-p1 -> false, manifest 200) failed with an
|
|
explicit validation error: `File check failed KKHDHILFOGO+LPIKGKOLBJH:
|
|
Error validating file verification.sig: Signatures don't match!` at
|
|
`KKHDHILFOGO.AFHNPNGLCML` called from the parser. The complete matrix now
|
|
(six live client outcomes, one theory):
|
|
|
|
- 404 manifest -> "Dowload failed" (run 6)
|
|
- verify false -> "Signatures don't match!" (run 7)
|
|
- verify true -> blob decode IndexOutOfRange (run 4)
|
|
- verify passthrough -> flaky DMD access violation (run 3)
|
|
- parser prefix -> impossible, DMD InvalidProgramException (run 5)
|
|
- run-1 "Dorm reached" -> actually a race: the flaky AV path returned
|
|
native false before the AV could trigger; the run-1 theory of "false skips
|
|
blob decoding" is dead.
|
|
|
|
Conclusion: NO server response + verify-result combination passes this check.
|
|
`DILGBLCELMP` is the checker's own exception class (KGABAOLHEHL-derived,
|
|
string ctor), logged caught in every run - it is a symptom, never the cause.
|
|
|
|
Run-8 hypothesis before the decomp check: patch the public entry
|
|
`KKHDHILFOGO.GGIFLDPHCIP(string, byte[], byte[], long, string)` (DMD-safe
|
|
parameter profile) and return an already-resolved success promise. Run 8
|
|
disproved it (see Run 9 above); the fix now covers both entries.
|
|
|
|
The RSA neutralizer keeps forcing TRUE only for the p1 key (image
|
|
signatures); with the entry bypass active the file check never reaches RSA
|
|
verify at all.
|
|
|
|
## Run 12: AppExitState veto - process survives but zombie (deployed 22:55)
|
|
|
|
Client: `ExitStateVetoPatch` - prefix on private setter
|
|
`CCKNJCHHBLL.KALEFEDAHCC` (nested enum CCFIKLBABNB), blocks any transition
|
|
out of Running for 120s after load, then allows. Safe to detour from managed
|
|
threads (fired dozens of times, no crash). HileReportSuppressionPatch fully
|
|
removed (run-11 lesson stands: NEVER detour KDJDKJNPELI.IJHOPKJFKBI).
|
|
|
|
Outcome: the veto WORKS as a patch (`[ExitVeto] blocked ... PreparingToExit`
|
|
right after the hile POST at 17.6s) but is INSUFFICIENT. The shutdown path
|
|
does not run through AppExitState: immediately at hile time the client also
|
|
cancelled the room load ("Room load to 20833 cancelled" AFTER the 6s load
|
|
flow completed), tore down EAC ("[EAC] Tearing down and releasing runtime"),
|
|
POSTed logout + reportjoinresult, and threw OBHEMJEJNMK: Aborted. Then an
|
|
infinite ~1.35s loop: NRE + "An error occurred" + EAC teardown +
|
|
veto-blocked PreparingToExit AND ReadyForExit, from 17.6s to 65.6s+.
|
|
VoiceClient timed out after 30s; Backtrace "Cannot resolve destination
|
|
host". Result: alive-but-unusable zombie. The setter's CallerCount(3)
|
|
matches the three state drives visible in the loop.
|
|
|
|
Conclusion: the exit has at least two arms - the AppExitState machine AND a
|
|
parallel shutdown initiator (EAC teardown / room-load cancel / Photon
|
|
disconnect). Vetoing the state machine alone wedges the process.
|
|
|
|
## Run 13: server-side hile-response experiment (pending)
|
|
|
|
Untested hypothesis: the native exit fires in response to the hile POST
|
|
RESPONSE (exit began ~160ms after the POST completed in runs 9/10/12).
|
|
HileAPI.PostHile is now env-selectable via `RADICADE_HILE_BODY`:
|
|
`ok-true` (default, unchanged shape) | `ok-false` | `nocontent` (204) |
|
|
`servererror` (500). Test pins ok-* to OkObjectResult+bool; 204/500 are
|
|
diagnostic-only.
|
|
|
|
Procedure: kill Server.exe (PID 20224 at 23:00), `dotnet build`, start with
|
|
`RADICADE_HILE_BODY=ok-false`, relaunch client, compare:
|
|
- Exit GONE -> the native scanner waits on the server verdict; tune the
|
|
response (then try nocontent/servererror to map the contract).
|
|
- Exit STILL at ~17.6s -> trigger is client-local; next step is decomp of
|
|
the managed exit initiators (CCKNJCHHBLL.BEFDPLAELIH/GIEEBIOOFML/
|
|
GBGMBMGDGGD, all run on attached threads) and prefixing them, or native
|
|
handling of the scanner thread (run-11 lesson: do NOT detour the funnel).
|
|
|
|
## Run 13: hile-response experiment - exit is CLIENT-LOCAL (23:11)
|
|
|
|
Server returned `Ok(false)` for the winhttp.dll hile report (verified in
|
|
server-console.log: "Hile experiment: returning Ok(false)"). Result: the
|
|
client STILL exited - same signature as run 12 (veto blocks, EAC teardown
|
|
loop, OBHEMJEJNMK Aborted, ~94s death). The server response does NOT drive
|
|
the exit.
|
|
|
|
Two new facts:
|
|
1. The IMMEDIATE post-report exit was skipped. Run 12: exit began 160ms
|
|
after the hile POST and killed the room load. Run 13: room load
|
|
COMPLETED (FinishRoomLoad 21.5s), spawn completed ~23s, and the player
|
|
had ~30s of real gameplay before the first PreparingToExit attempt at
|
|
52.5s. First-time NRE + "InvalidOperationException: Cannot error an
|
|
already completed promise" at 32s looked suspicious but did not kill.
|
|
2. The 52.5s exit is the same driver as the 17.6s exit (veto + EAC + Aborted
|
|
loop). Interpretation: the native scanner re-scans on its own schedule;
|
|
with Ok(false) the first post-report exit did not fire, but a later scan
|
|
still flagged the module and restarted the shutdown.
|
|
|
|
Conclusion: stop DETECTION, not the shutdown. Next lever: make
|
|
winhttp.dll invisible to the module scan itself.
|
|
|
|
## Run 14: PEB module hiding - hide winhttp.dll from the scanner (deployed 23:27)
|
|
|
|
Client: `PebModuleHider.HideModule("winhttp.dll")` at plugin Load (before
|
|
any Harmony patching). Walks PEB->Ldr->InLoadOrderModuleList, matches
|
|
BaseDllName (x64 offset 0x58 from the InLoadOrder node; 0x60 was wrong -
|
|
FullDllName at 0x48 is a 16-byte UNICODE_STRING), unlinks the entry from
|
|
all three public lists (InLoadOrder / InMemoryOrder /
|
|
InInitializationOrder). Pure user-mode pointer writes on the main thread -
|
|
no detours, no scanner-thread contact, no DMD. Module ENUMERATION
|
|
(Toolhelp, EnumProcessModules, PEB-walks) no longer sees the DLL; module
|
|
RESOLUTION (LoadLibrary/GetModuleHandle) is untouched (loader hash tables),
|
|
so the BepInEx door keeps working. AllowUnsafeBlocks enabled.
|
|
|
|
Server: hile restored to canonical Ok(true) (ok-true, default env) so run 14
|
|
tests exactly one variable. Server PID 34420.
|
|
|
|
Success markers: `[ModuleHide] winhttp.dll unlinked from PEB module lists`
|
|
in BepInEx at startup, NO `POST /api/PlayerReporting/v1/hile` in the whole
|
|
session (the scanner finds nothing to report), no PreparingToExit, room
|
|
load completes, spawn, stable gameplay past 2min. If hile STILL appears,
|
|
the scanner is not PEB-based (try hiding via handle-table wipe / ImagePath
|
|
alternate next). Keep ExitStateVetoPatch armed as belt-and-suspenders.
|
|
|
|
## Run 14: PEB unlink - scanner does NOT use module lists (deployed 23:27, failed)
|
|
|
|
`PebModuleHider.HideModule("winhttp.dll")` fired successfully
|
|
("[ModuleHide] winhttp.dll unlinked from PEB module lists"). BaseDllName
|
|
offset correction: 0x58 on x64, not 0x60 (FullDllName at 0x48 is 16 bytes).
|
|
Outcome: the hile POST STILL arrived at 16.3s with
|
|
Message=[0:winhttp.dll], immediate exit followed 150ms later (veto loop as
|
|
before). Server log confirms exactly one fresh report at 23:32:58.
|
|
|
|
CONCLUSION: the scanner does not enumerate via PEB module lists. It walks
|
|
committed image regions (NtQueryVirtualMemory-style) and classifies each
|
|
region by parsing PE headers - unlinking the lists hides the NAME but the
|
|
region still self-identifies via its MZ/PE signatures.
|
|
|
|
Note the response correlation across runs: ok-true -> immediate exit (12,
|
|
14); ok-false -> deferred exit (13). The exit is native local state, the
|
|
POST is only telemetry.
|
|
|
|
## Run 15: PE signature wipe - declassify the mapped image (deployed 23:42, FAILED)
|
|
|
|
`PeHeaderWiper.WipeSignatures("winhttp.dll")` at plugin Load (after the PEB
|
|
unlink, before Harmony). Zeroes the two structural signature tokens:
|
|
"MZ" at base+0 and "PE\0\0" at base+e_lfanew (6 bytes total, VirtualProtect
|
|
RW for the write then restore). A region-walking scanner that classifies by
|
|
parsing headers can no longer name this region; GetProcAddress is unaffected
|
|
(it follows e_lfanew into the intact optional/export headers without
|
|
validating the signature bytes) and winhttp IATs bound at process start.
|
|
|
|
Success markers: both [ModuleHide] lines OK, NO POST /v1/hile in the whole
|
|
session, no PreparingToExit, load completes, spawn, stable past 2min.
|
|
Failure modes to distinguish in the log:
|
|
- hile still appears -> scanner hashes raw region bytes against the
|
|
module's on-disk image (need bytes-level rework of the mapped image or
|
|
targeted section wiping) -> next run.
|
|
- no hile but exit at ~16-18s -> an independent native watchdog (e.g. door
|
|
DLL fingerprint check) -> revisit native path.
|
|
|
|
### Run 15 outcome (14:28 Sep 24, FAILED)
|
|
|
|
Both hides active in the boot log ("[ModuleHide] winhttp.dll unlinked" AND
|
|
"PE signatures wiped"). The hile POST fired anyway at 19.3s session time
|
|
(client [Net] log: `Post .../api/PlayerReporting/v1/hile`), immediate exit
|
|
150ms later: veto blocked PreparingToExit, EAC teardown, room load
|
|
cancelled, `OBHEMJEJNMK: Aborted`, NRE/"An error occurred" loop ~1.3s -
|
|
identical to runs 12/14.
|
|
|
|
Server-side note: server-console.log stopped receiving entries after
|
|
23:33 Sep 23 even though the server process survived (its console
|
|
redirection died with the previous agent session), so run-15 POSTs are
|
|
evidenced from the client log only. Server was alive and answering
|
|
gameconfigs 200 during the whole session.
|
|
|
|
CONCLUSION after runs 14+15: the scanner neither enumerates PEB module
|
|
lists nor classifies regions by PE signature tokens. It still flags
|
|
winhttp.dll as `Type=Obcured` (note the misspelling - the flag is
|
|
"obscured", i.e. it is reporting our tampering itself, not a name it
|
|
got from the headers). Remaining hypotheses: (a) hashes raw mapped
|
|
bytes against the on-disk image, (b) fingerprints the door DLL through
|
|
the loader record / LoadLibrary bookkeeping, (c) an independent native
|
|
watchdog.
|
|
|
|
DECISIVE observation for run 16: across ok-true runs the exit fires
|
|
~150ms after the POST, while run 13's ok-false (response that never
|
|
satisfied the handler) deferred the exit until the next scan. The exit
|
|
is triggered by the report's RESPONSE arriving, not by the scan itself.
|
|
So: drop the report request at the HTTP layer before it is ever sent.
|
|
|
|
## Run 16: HileGate - drop the hile POST at the HTTP layer (deployed 14:50 Sep 24, FAILED - prefix never skipped the original)
|
|
|
|
`HileGate` (in NameserverConnectionPatches.cs): a prefix check inside the
|
|
existing BestHTTP `HTTPManager.SendRequest(HTTPRequest)` patch - the same
|
|
managed, main-flow funnel the [Net] logger uses, proven detour-safe
|
|
(unlike the scanner-thread funnel KDJDKJNPELI.IJHOPKJFKBI, run 11 fatal).
|
|
When the request URI path ends with `/api/PlayerReporting/v1/hile`, the
|
|
prefix returns before any processing: the request is never queued, never
|
|
sent, and no completion callback can fire, so the response-gated exit
|
|
path never runs. The scanner cannot observe the drop - it only sees that
|
|
its report never completes. Opt-in via `HileGate.Enabled` (armed in the
|
|
August plugin Load; the March plugin source stays inert). The
|
|
ExitStateVetoPatch stays armed as a second layer.
|
|
|
|
Success markers: `[HileGate] dropped anti-cheat report POST` around 16-20s,
|
|
NO hile POST reaching the server, NO PreparingToExit, load completes,
|
|
spawn, stable past 2 min.
|
|
|
|
Failure modes to distinguish in the log:
|
|
- No [HileGate] line but exit at ~16-20s -> the scanner sends through a
|
|
different stack (native winhttp directly, not BestHTTP) -> shim the
|
|
door DLL's winhttp exports or block at the socket layer -> next run.
|
|
- [HileGate] line fires, no POST, still exit -> trigger independent of
|
|
report completion (native watchdog) -> revisit native exit initiators
|
|
(CCKNJCHHBLL.BEFDPLAELIH / GIEEBIOOFML, tokens 100667097/098).
|
|
- Periodic re-scan attempts every ~30s should each be dropped silently;
|
|
a rising [HileGate] count with stable gameplay is a WIN state.
|
|
|
|
### Run 16 outcome (14:53 Sep 24, FAILED - implementation bug, model intact)
|
|
|
|
The gate FIRED (`[HileGate] dropped anti-cheat report POST` at 16.9s) but
|
|
the POST went out anyway: server-console-run16.log line 12835 shows
|
|
`POST /api/PlayerReporting/v1/hile -> 200` at 14:53:55.431, exit machinery
|
|
started ~150ms later, veto loop as usual. ROOT CAUSE: the run-16 prefix was
|
|
VOID - in Harmony an early return from a void prefix does not skip the
|
|
original; only a bool prefix returning false does. The drop was a no-op, so
|
|
this run is evidence-wise just another ok-true repetition (12/14/15).
|
|
|
|
FIX (deployed 14:58): the prefix is now `bool Prefix(HTTPRequest request,
|
|
ref HTTPRequest __result)`; on a hile report it logs, sets
|
|
`__result = request` (the overload's fluent return value - decomp confirms
|
|
SendRequest_Public_Static_HTTPRequest_HTTPRequest_0) and returns false so
|
|
the original never queues the request. Success markers unchanged; next run
|
|
must show the [HileGate] line AND no POST /v1/hile on the server, then no
|
|
PreparingToExit at all.
|
|
|
|
### Run 16 RETRY (boot 14:59:23 Sep 24) - SUCCESS
|
|
|
|
All success markers met for the first time in 16 runs:
|
|
|
|
1. `[HileGate] dropped anti-cheat report POST` fired at 16.9s session time
|
|
(LogOutput.log line 174) - exactly where the scanner always reported.
|
|
2. ZERO `POST /api/PlayerReporting/v1/hile` reached the server for this
|
|
boot (server-console-run16.log: the only hile entry is the buggy 14:53
|
|
run's). The drop now actually skips the original.
|
|
3. ZERO `[EAC] Tearing down`, ZERO `OBHEMJEJNMK: Aborted`, ZERO
|
|
NullReferenceException/"An error occurred" - the post-report zombie loop
|
|
never started.
|
|
4. Room load COMPLETED: joinresult 200 at 14:59:43 (instance 20845),
|
|
RunFor.Authority handlers finished, phases advanced through
|
|
DESERIALIZE_CONNECTABLES -> POST_DESERIALIZE_OBJECTS (attached log tail
|
|
at 20s), avatar/keepsake/invention fetches all flowed.
|
|
5. Session end (14:59:52 logout, 16 veto blocks 0-10s, process left
|
|
~15:00:03) was a USER-INITIATED quit ~9s after spawn, NOT an
|
|
anti-cheat exit: no EAC teardown, no hile around the logout, and the
|
|
native quit path bypasses the veto by design (documented run-12
|
|
behavior). The 120s veto window had not expired; the native path took
|
|
the process down cleanly.
|
|
|
|
VERDICT: the anti-cheat kill chain is broken at its response gate. The
|
|
report is dropped client-side, the response never arrives, the exit
|
|
handler never fires, and the game survives into the Dorm.
|
|
|
|
PENDING VERIFICATION (next soak run): the scanner's ~30s periodic re-scan.
|
|
Prediction: every subsequent report is dropped identically (rising
|
|
[HileGate] count, stable gameplay). If a later scan instead switches to a
|
|
different report channel (native winhttp direct), the first symptom is a
|
|
server-side hile POST - watch for it in a 5+ minute soak.
|
|
|
|
Note: keep the ExitStateVetoPatch armed. With reports dropped it should
|
|
never fire again except for genuine user quits inside the 120s window; if
|
|
it starts blocking repeatedly WITHOUT a [HileGate] drop preceding it, a
|
|
second exit trigger exists and the native initiators
|
|
(CCKNJCHHBLL.BEFDPLAELIH / GIEEBIOOFML) become the next patch target.
|
|
|
|
## Run 17: second exit trigger + veto removed by a parallel edit (Sep 24
|
|
afternoon)
|
|
|
|
Three more boots with the fixed gate (14:59, 15:07, 15:13) reshaped the
|
|
evidence:
|
|
|
|
- 14:59 boot: gate dropped the report at 16.9s, room load COMPLETED
|
|
(joinresult 14:59:43), then 16 veto blocks (PreparingToExit x8,
|
|
ReadyForExit x8) at 14:59:52-15:00:03 - the exit re-request came ~9s
|
|
AFTER load finished, and the process left once the veto window ended.
|
|
No hile, no EAC teardown, no crash dump, no Windows fault.
|
|
- 15:07 boot: gate dropped reports TWICE (17s, room-change), survived 7
|
|
minutes, then died through the managed shutdown cascade at 15:08:42 -
|
|
exactly when the run-12 veto (120s from 15:07:40) expired. Same clean
|
|
shape: the exit kept being re-requested and the veto kept absorbing it
|
|
until the window closed.
|
|
- 15:13 boot: a PARALLEL EDIT (Plugin.cs modified + rebuilt at 15:11,
|
|
not by this thread) REMOVED ExitStateVetoPatch entirely. That boot had
|
|
[HileGate] armed but no [ExitVeto] armed, died ~40s in with nothing
|
|
absorbing the exit. This confirms the veto was doing real work.
|
|
|
|
MODEL REVISION: the exit is NOT purely response-gated. The scanner keeps
|
|
RE-REQUESTING exit on a cadence (runs show 10-40s intervals), plausibly a
|
|
report-completion TIMEOUT on the dropped report (run 13's ok-false exit
|
|
at ~30s fits: no satisfying response within the deadline = failure =
|
|
exit). Dropping the request cannot win alone; something must absorb the
|
|
re-requests forever. The veto did that until its window expired; a
|
|
parallel edit removed it.
|
|
|
|
Run 17 change: ExitInitiatorTracerPatch prefixes the managed exit
|
|
initiators CCKNJCHHBLL.BEFDPLAELIH (100667097), GIEEBIOOFML (100667098)
|
|
and FNOEHNDLHHG (100667101), logs the FULL managed stack of whoever
|
|
calls them, and blocks the call. These are attached-thread, detour-safe
|
|
targets (run-14 prep). Deployed 15:42. Success markers: [ExitInit]
|
|
stack traces identifying the second trigger's caller, and sessions that
|
|
no longer die at 10-40s. If sessions still die with all three blocked,
|
|
the trigger is native-only (TerminateProcess-class) and the blockades
|
|
prove it by absence.
|
|
|
|
Run 18: "crash on boot" was a disabled Doorstop proxy, not the tracer
|
|
|
|
Symptom: the user reported a crash on boot immediately after the 15:42
|
|
run-17 deploy.
|
|
|
|
Evidence chain:
|
|
|
|
- BepInEx/LogOutput.log still had mtime 15:14, i.e. no plugin log was
|
|
written for any boot after the 15:13 session. No boot has ever printed
|
|
[ExitInit] armed.
|
|
- The Unity log (AppData/LocalLow/Against Gravity/Rec Room/Player.log and
|
|
Player-prev.log, mtime 15:59:47 / 15:59:33) contains ZERO
|
|
BepInEx/Doorstop/Radicade lines: two VANILLA boots of ~14 KB each.
|
|
Player.log shows "Could not resolve host 'ns.rec.net'" at 3.6s, then
|
|
AppExitState Running => PreparingToExit at 3.9s, then
|
|
"[EAC] Tearing down and releasing runtime", process gone by ~7s. EAC
|
|
was live because the Doorstop/EAC-bypass door never loaded, and the
|
|
game was still pointed at the real nameservers.
|
|
- Cause: winhttp.dll (26,112 b, Doorstop 4.3.0 proxy, md5 b2a4d0cb...) had
|
|
been renamed to winhttp.dll.baseline-disabled at 15:17:15 by a parallel
|
|
action, which also created baseline-backup-20260924-151633/ containing a
|
|
copy of winhttp.dll, Player-before-baseline.log (the 15:13 session log),
|
|
the pristine 173 b RecRoom_Data/boot.config and the pristine 38,654,794 b
|
|
il2cpp_data/Metadata/global-metadata.dat.
|
|
- No new WER 1001 event and no new CrashDumps entry: the game exits
|
|
through its orderly quit path, it does not fault. That is why the crash
|
|
left no crash report and why only the Unity log has evidence.
|
|
- Fix: the snapshot's winhttp.dll was copied back to the game root (md5
|
|
identical). The rest of the door chain was verified intact:
|
|
doorstop_config.ini enabled=true, .doorstop_version 4.3.0,
|
|
BepInEx/core/BepInEx.Unity.IL2CPP.dll, dotnet/coreclr.dll, 335 interop
|
|
assemblies, 64 unity-libs.
|
|
|
|
Consequences:
|
|
|
|
- Run 17 has NEVER booted. It was deployed at 15:42, 25 minutes after the
|
|
door was disabled, so ExitInitiatorTracerPatch has zero runtime data and
|
|
its block/trace behaviour is still unproven.
|
|
- The "baseline" experiment cannot work as designed. With the door removed
|
|
there is no patch stack at all, so the game dies at ns.rec.net DNS plus
|
|
EAC long before any comparison is possible. A vanilla control run needs
|
|
the door present and the patch groups switched off from inside the
|
|
plugin, never a removed proxy DLL.
|
|
- Parallel edits remain the biggest source of false signal: ExitStateVeto
|
|
Patch was deleted from the working tree at 15:11 and the door was
|
|
disabled at 15:17. Both were uncommitted, so neither the veto nor any
|
|
boot data exists in the run-17 build.
|
|
|
|
The next boot is run 17's first real run. Expected markers: [ModuleHide]
|
|
x2, [HileGate] armed, [ExitInit] armed, a hile drop ~17s in, and [ExitInit]
|
|
stack traces naming the second exit trigger's caller.
|
|
|
|
## Run 17's first real boot (16:10): the exit block broke the room load
|
|
|
|
The door restore worked and the boot reached the Dorm, but the player saw a
|
|
BLACK SCREEN: the debug overlay showed `Room: 'DormRoom: Home', RoomId 2,
|
|
SubroomId 2883, Players 1 (2 TestPlayer, Loading)`, FPS 910 (nothing being
|
|
drawn). Run 17's own markers were all present: [ExitInit] armed, ONE blocked
|
|
initiator call, and four [HileGate] drops.
|
|
|
|
The one block is the problem. It fired ~0.05s after `Chainloader startup
|
|
complete`, before any networking, and its caller trace is:
|
|
|
|
```
|
|
at System.Environment.get_StackTrace()
|
|
at ExitInitiatorTracerPatch.TraceAndBlock()
|
|
at DMD<CCKNJCHHBLL::BEFDPLAELIH>()
|
|
at (il2cpp -> managed) BEFDPLAELIH(Il2CppMethodInfo* )
|
|
```
|
|
|
|
Read that trace correctly: in an IL2CPP build ALL game code is native, so
|
|
"no managed caller above the trampoline" does NOT mean an outside native
|
|
component. It only means the caller is another il2cpp method - ordinary game
|
|
code. A boot-time call to an exit initiator is therefore most likely part of
|
|
normal startup, and blocking it is not free.
|
|
|
|
What followed, compared against the last good session (15:13, pre-run-17,
|
|
preserved as baseline-backup-20260924-151633/Player-before-baseline.log):
|
|
|
|
- 15:13: load of 25/32 runs 14.08s -> COMPLETE at 19.77s (FinishRoomLoad).
|
|
FetchDeserializationDataTask.Run('25.32') finishes in 1ms: DownloadAsset
|
|
Bundle, then DownloadAndParse of MKMOLMPLENB, JGEHMKKALNE and OBHEFDFCAIC
|
|
all return in 2-7ms, then the phases march through DATA_DOWNLOADED,
|
|
INIT_OBJECTMODEL ... COMPLETE.
|
|
- 16:10 (run 17): the SAME room, the SAME sequence - and
|
|
`START: DownloadAndParse('OBHEFDFCAIC)')` never returns. The load sits in
|
|
DOWNLOADING_DATA until the client is closed 64s later. Everything after the
|
|
load never happens: no `rooms/25/experience/player`, no
|
|
`keepsakes/rooms/25`, no `roomkeys?roomId=25`, and no
|
|
`GET /rooms/photon_access_token`, so the dorm's Photon join is never even
|
|
attempted and the save can never arrive. That is the black screen.
|
|
- Server side is exonerated: `GET /rooms/rooms/25?include=5421...` returned
|
|
byte-identical payloads (len=2174) in every session including 16:10, and
|
|
the server log shows no [RoomUtils] self-heal firing. The only client-side
|
|
delta between the 15:13 build and the 16:10 build is run 17's tracer (the
|
|
veto was already gone at 15:13). Four consecutive pre-run-17 boots
|
|
(14:53, 14:59, 15:07, 15:13) all completed the dorm load.
|
|
|
|
Run 18 change: `ExitInitiatorTracerPatch` still traces every call, but it now
|
|
ALLOWS the call (returns true) until `HileGate.DroppedCount > 0`, i.e. until
|
|
the scanner has actually filed a report, and only blocks from then on. The
|
|
exit that matters is the one the dropped report triggers; a call that arrives
|
|
before any report exists is startup traffic. HileGate grew the DroppedCount
|
|
counter (NameserverConnectionPatches.cs, shared into the August assembly), the
|
|
log line is now "[ExitInit] armed - ... traced; blocking switches on after the
|
|
first dropped hile report", and an allowed call logs
|
|
"[ExitInit] allowed managed exit initiator (no report filed yet)".
|
|
|
|
Deployed 16:16 (34304 b). Success markers for the next boot: an `[ExitInit]
|
|
allowed ...` line during startup instead of a block, the dorm load reaching
|
|
COMPLETE / FinishRoomLoad, a visible Dorm, then the first hile drop and - from
|
|
that point - `[ExitInit] blocked ...` traces.
|
|
|
|
## Run 18 gating result (16:17 boot): the hang is gone, the load still fails
|
|
|
|
The gate did what it was built to do:
|
|
|
|
- `[ExitInit] allowed managed exit initiator (no report filed yet)` at startup
|
|
(the boot-time BEFDPLAELIH call now passes through),
|
|
- four `[HileGate] dropped anti-cheat report POST` lines, and
|
|
- one `[ExitInit] blocked managed exit initiator ... at DMD<CCKNJCHHBLL::
|
|
FNOEHNDLHHG>()` after the drops - the gated block works.
|
|
|
|
The infinite stall is gone too: `DownloadAndParse('OBHEFDFCAIC)')` returned
|
|
after 22.7s (16:17:44.4479 -> 16:18:07.1543) instead of never, and
|
|
`OperationContext.FinishRoomLoad` followed at 39.1551.
|
|
|
|
But it returned a FAILURE, and the session died with it:
|
|
|
|
```
|
|
[16:18:07] [39.1509] AppExitState changed: Running => PreparingToExit
|
|
[16:18:07] [39.1566] [Error | RoomOperation] Error during operation
|
|
InitialRoomLoad-a820aca0-...: Error downloading save data!
|
|
Try again later or on a better connection.
|
|
[16:18:08] [40.2863] [Unity] [EAC] Tearing down and releasing runtime
|
|
[16:18:09] [41.6710] [Unity] PhotonHandler.OnDestroy
|
|
```
|
|
|
|
So the exit that ends these sessions is at least partly a CONSEQUENCE of the
|
|
failed room load - the documented DORM-BLOB-FIX chain - not purely the scanner.
|
|
Note also that the block was armed and STILL did not hold the process: a
|
|
`[ExitInit] blocked` line fired and the client left anyway, so the recurring
|
|
exit is not solely the managed initiators.
|
|
|
|
WHAT IS MISSING THIS TIME: `GET /rooms/photon_access_token`. Every pre-run-17
|
|
boot fetched it during the dorm load (14:59:39.570, 15:07:54.917,
|
|
15:13:41.243 and again at 15:13:52.159) and the good run shows
|
|
`[GetSubRoomDataSave()]: Total: [5397.72ms 2618frames]` - the subroom save
|
|
download succeeding after ~5.4s. Neither run-17-lineage boot (16:10, 16:17)
|
|
ever requested a Photon access token, so the Photon room join is never set up,
|
|
`GetSubRoomDataSave()` has nothing to resolve against, and the load fails with
|
|
"Error downloading save data!" instead - after a 22.7s timeout in 16:17, and
|
|
forever in 16:10.
|
|
|
|
Everything server-side is byte-identical across good and bad sessions:
|
|
`/matchmaking/player/connection-info` ~1180 b, `/matchmaking/matchmake/dorm`
|
|
572 b, `/rooms/rooms/25?include=5421...` 2174 b, `/cdn/room/` 22 b. The tracer
|
|
is the only client-side delta, so the tracer is the A/B variable.
|
|
|
|
Run 18a (deployed 16:19, 34304 b): the tracer registration is commented out
|
|
(the class stays in source with its findings recorded - a boot-time
|
|
BEFDPLAELIH call arriving from il2cpp with no managed frames, and the exit
|
|
leaving through FNOEHNDLHHG). Expected on the next boot: `[ExitInit] disabled
|
|
- tracer removed for the room-load A/B`, then `GET /rooms/photon_access_token`
|
|
in the client log and in the server log, `GetSubRoomDataSave()` resolving in
|
|
seconds, the phases running through to COMPLETE, and a visible Dorm. If all of
|
|
that happens, the tracer - or one of its three detours - is confirmed as the
|
|
room-load breaker and it comes back only one target at a time.
|
|
|
|
## Run 18a result and the REAL regression: the baseline experiment restored the
|
|
## unpatched metadata (root cause of the black screen and the forced exit)
|
|
|
|
Run 18a booted at 16:20 with `[ExitInit] disabled` (LogOutput.log line 33) and
|
|
the four `[HileGate] dropped` lines, and it failed EXACTLY like run 18 did:
|
|
no `GET /rooms/rooms/25/experience/player`, no `playerdata/me`, no
|
|
`keepsakes/rooms/25`, no `roomkeys?roomId=25`, no
|
|
`GET /rooms/photon_access_token`, then `Error downloading save data!`,
|
|
FailedToSpawnPlayer (Code 8715) and the forced exit. The exit tracer is
|
|
therefore NOT the room-load breaker - that hypothesis is dead, and the server
|
|
payloads were byte-identical the whole time.
|
|
|
|
What the tracer-off boot did NOT rule out - and what actually broke every boot
|
|
after 15:16 - is the rest of the parallel "baseline" experiment. It did not
|
|
only rename winhttp.dll away at 15:17:15; it also put back two files from the
|
|
pristine (pre-Radicade) Sep 23 14:21-14:23 state, using mtime-preserving
|
|
copies, so nothing looked "new" afterwards:
|
|
|
|
| file | good state (the 14:53-15:13 boots) | what every failing boot ran |
|
|
| --- | --- | --- |
|
|
| `RecRoom_Data/il2cpp_data/Metadata/global-metadata.dat` | 38,654,794 b, md5 `cc9c32014b5fc3dd1a2a8fb12376be15` | 32,039,456 b, md5 `825f34f1dd046a0ae764cd5a97dba5e6` |
|
|
| `RecRoom_Data/boot.config` | 173 b, md5 `dc2e5f7af7d5df736a4cc3477b4b1a1f` | 104 b, md5 `5694f1046c94cb6b9bbcf6854ed8eaae` |
|
|
|
|
The 104 b boot.config is byte-identical to `RecRoom_Data/boot.config.orig`
|
|
(the patcher's own backup), which is the fingerprint of a restore, not of an
|
|
edit. Proof that the 38 MB metadata - and only it - carries the Radicade
|
|
rewrite:
|
|
|
|
- `grep -a -c 'localhost:3030'`: 38 MB file = 3, live 32 MB file = 0.
|
|
`127.0.0.1` = 9 vs 1, `rec.net` = 20 vs 4.
|
|
- `RecRoom_Data/radicade-patch.json` records `patchedAtUtc
|
|
2026-09-23T22:08:42Z` (15:08:42 local, `changedLiterals: 7`, serverUrl
|
|
`https://localhost:3030`), and that timestamp is exactly the mtime of the
|
|
38 MB file captured in the snapshot: the file the baseline experiment
|
|
replaced was the Radicade-patched one that had been live for all four good
|
|
boots.
|
|
- Both files keep the release's custom shuffled header (magic `d4370000...`),
|
|
so the patched metadata is still the native format the runtime expects. The
|
|
standard-header `global-metadata.interop.dat` (magic `af1bb1fa`) is only the
|
|
tooling copy and was never touched.
|
|
|
|
Mechanism: with the pristine metadata the client's hardcoded bootstrap
|
|
literals point at the official hosts again. The plugin's runtime redirects only
|
|
cover the nameserver host, the websocket host and TLS, so most traffic still
|
|
reaches the server through `GET https://ns.rec.net/ns` - which is why the boot
|
|
looks healthy, logs in, joins Photon and renders the Dorm - but the room-save
|
|
path is built from a literal that nothing rewrites at runtime, so
|
|
`GetSubRoomDataSave()` fails and the session is torn down by the room-load
|
|
failure handler.
|
|
|
|
Fixed: both files copied back from
|
|
`baseline-backup-20260924-151633/RecRoom_Data/` (`cp -p`, provenance kept).
|
|
Live again now: metadata md5 `cc9c3201...` (38,654,794 b, 3x localhost:3030),
|
|
boot.config 173 b (`vr-enabled=0`, `player-connection-mode=Listen`,
|
|
`player-connection-debug=0`). winhttp.dll had already been restored, a scan for
|
|
any other 2026-09-24 write outside BepInEx found nothing, and the only disabled
|
|
sidecars are `winhttp.dll.baseline-disabled` (dormant) plus the BepInEx
|
|
config/loader backups - so the baseline undo is now complete.
|
|
|
|
Caveat for future restores: the patcher's own input (38,654,604 b) no longer
|
|
exists anywhere, because the experiment also restored
|
|
`global-metadata.dat.orig` to the 32,039,456 b Sep 23 14:23 file. The canonical
|
|
restore sources are therefore the snapshot directory and
|
|
`global-metadata.interop.dat` - never `.orig`.
|
|
|
|
Deployed build for the next boot stays run 18a (34304 b, md5
|
|
`b5cdc49cf2da66e306ee20f4e60a515c`, tracer off), so the metadata fix is a clean
|
|
A/B. Success markers: `GET /rooms/rooms/25/experience/player` (404), then
|
|
`playerdata/me`, `keepsakes/rooms/25` and `roomkeys?roomId=25` in the server
|
|
log, `GET /rooms/photon_access_token`, `[GetSubRoomDataSave()]` resolving in
|
|
seconds, FinishRoomLoad COMPLETE and a visible Dorm. The gated
|
|
ExitInitiatorTracerPatch and a never-expiring exit veto come back only after
|
|
that, one target at a time, with the metadata state now treated as a
|
|
first-class tracked variable (md5 above) rather than an assumed constant.
|
|
|
|
## Run 19 (16:54 boot): the Dorm LOADS - the next killer is the Play menu's
|
|
## missing list routes
|
|
|
|
The metadata restore worked. The 16:54:57 boot completed the dorm load for the
|
|
first time since run 16:
|
|
|
|
```
|
|
16:55:10 phase DOWNLOADING_DATA, DownloadAndParse('OBHEFDFCAIC)') 16.2212 -> 16.2296 (8 ms, was 19-22 s or never)
|
|
16:55:11 GET /rooms/photon_access_token
|
|
16:55:13 [10976][19.4330] OperationContext.FinishRoomLoad(e4909cf1-...)
|
|
16:55:13 Moved to phase COMPLETE (SCENE_LOADED -> SETUP_ROOM_OBJECTS -> RUN_MIGRATIONS
|
|
-> DESERIALIZE_OBJECTS -> DESERIALIZE_CONNECTABLES -> COMPLETE, SpawnLocalPlayer at ~19.5s)
|
|
```
|
|
|
|
So `GetSubRoomDataSave()` was never the broken thing - the unpatched metadata
|
|
was. Player spawn works too (the only spawn-time error is a benign Toxmod
|
|
config warning).
|
|
|
|
### The new failure: the Play menu's discovery rows 404
|
|
|
|
At 27.7 s the client opened the room list and its rows failed:
|
|
|
|
```
|
|
16:55:22 GET /lists/algorithmiclists/HotList?type=1 -> 404
|
|
[Error] Error refreshing rooms from source Hot: An error occurred (RoomListModel)
|
|
16:56:05 GET /rooms/rooms/carousel/rising?skip=0&take=20 -> 404
|
|
[Error] Error refreshing rooms from source CarouselEndpoint: An error occurred
|
|
16:56:05 [22050][70.8179] Error refreshing rooms from source Hot: An error occurred
|
|
16:56:05 [22051][70.8330] AppExitState changed: Running => PreparingToExit
|
|
NullReferenceException at RRUI.Data.RoomListModel.DOPOJKBDDEL()
|
|
<- UnityEngine.Object.Instantiate <- RRUI.StaggeredPrefabSpawner.EPABHKKCNIF()
|
|
[EAC] Tearing down; Uploading Crash Report
|
|
```
|
|
|
|
A failed row is not a skipped row: it NREs the model's prefab spawner and ends
|
|
the session. Same death in the 15:13 reference run (`Error refreshing rooms
|
|
from source Hot` at 15:13:59, exit at 15:14:06), which is why that run ended
|
|
seconds after the player reached the RecCenter. The curated-lists 404/`[]`
|
|
note from run 10 was never the whole story - `lists/algorithmiclists/*` and
|
|
`rooms/rooms/carousel/*` were simply never implemented.
|
|
|
|
### Fix (server, 17:36)
|
|
|
|
- NEW `Server/Lists/AlgorithmicListsAPI.cs`:
|
|
`GET /lists/algorithmiclists/{list}?type=1` -> `{ Type, Entities: [ { Id, Context } ] }`
|
|
(`Id` a string, `Context` null), the shape and field order the reference
|
|
server answers with, because the client's obfuscated DTOs are read
|
|
positionally. `type` is echoed (defaulting to 1 = Rooms). Every row key
|
|
answers 200: `HotList` and the other ranking rows are ordered by
|
|
`RoomStats.VisitCount` desc, `new` by `PublishedAt` desc, both over public
|
|
active non-dorm rooms, 20 per row.
|
|
- `Server/RoomServer/RoomServerAPI.cs`: `GET rooms/carousel/{*source}` (next to
|
|
the other carousel feeds) -> bare array of RoomDetail, name/tag filtered when
|
|
the source names something, falling back to every public room so a row is
|
|
never empty. Shape follows `rooms/hot_rooms` (see
|
|
docs/2023-WATCH-HOME-FIX.md); if a row still renders empty, the envelope
|
|
(RoomSearchResult) is the thing to change.
|
|
- Not changed: `lists/curatedlists/bulk` still answers `[]`. Its shape is a
|
|
guess either way (the client logs "Exception: No such list" for the empty
|
|
array), so it stays as the documented, non-fatal behaviour until the fatal
|
|
rows are confirmed fixed - changing a DTO the positional codec reads without
|
|
a verified field order is how a non-fatal error becomes a fatal one.
|
|
|
|
Verified live over the plain-HTTP listener (server restarted 17:37, now
|
|
`server-console-run19.log`, `dotnet run --no-build` from `Server/`):
|
|
|
|
```
|
|
/lists/algorithmiclists/HotList?type=1 -> 200 {"Type":1,"Entities":[{"Id":"32",...},{"Id":"3"},...]}
|
|
/lists/algorithmiclists/new?type=1 -> 200 {"Type":1,"Entities":[{"Id":"35"},...]}
|
|
/rooms/rooms/carousel/rising?skip=0&take=20 -> 200 [ {RoomId:2,...}, ... ] (20289 b)
|
|
/lists/curatedlists/bulk?id=17859340 -> 200 [] (unchanged, see above)
|
|
```
|
|
|
|
Server build clean (0 errors, 389 pre-existing warnings). Client build unchanged
|
|
(run 18a, tracer still off), so the next boot A/Bs exactly one thing: the rows.
|
|
Expected markers: no "Error refreshing rooms from source Hot/CarouselEndpoint"
|
|
lines, no RoomListModel NullReferenceException, the Play menu carousels
|
|
populated with real rooms, and a session that survives the `hot` row refresh.
|
|
|
|
## Run 20 (17:43 boot): the row fix holds - the room-list killer is gone
|
|
|
|
The 17:43:25 boot ran against that rebuild, and every marker above landed:
|
|
|
|
- `GET /lists/algorithmiclists/HotList?type=1` was requested twice and answered
|
|
200 (1171 b). `Player.log` has **no** "Error refreshing rooms from source
|
|
Hot/CarouselEndpoint" and **no** `RRUI.Data.RoomListModel` NullReferenceException.
|
|
- The rows resolved into real rooms instead of failing: right after HotList the
|
|
client asked `rooms/rooms/bulk?id=2&id=4&id=7&...&id=19` and drew the carousels
|
|
(`rooms/hot?tag=rro` 200 / 27163 b, with RecRally/Crescendo/Park/DodgeballVR
|
|
images following).
|
|
- The Dorm was unaffected: `Moved to phase COMPLETE` at `[10504][20.13]`,
|
|
`OperationContext.FinishRoomLoad`, `SpawnLocalPlayer` total 10278 ms - the same
|
|
numbers as the 16:54 reference boot. The metadata precondition was re-checked
|
|
at boot: `global-metadata.dat` 38654794 b md5 `cc9c32014b5fc3dd1a2a8fb12376be15`,
|
|
`boot.config` 173 b md5 `dc2e5f7af7d5df736a4cc3477b4b1a1f`.
|
|
|
|
The session still ended, but *differently* from every previous failure: the log
|
|
stops on a clean quit path (`POST /matchmaking/player/logout` -> `PreparingToExit
|
|
=> ReadyForExit` -> EAC teardown -> `PhotonHandler.OnDestroy`), with **no
|
|
exception in the 3.7 s before it** - where the 16:54 run had the RoomListModel NRE
|
|
40 ms before `PreparingToExit`. A silent 3.7 s gap plus a graceful logout is the
|
|
shape of a hand quit, not of the crash path, so run 20 cannot be called a crash
|
|
without knowing what the screen did.
|
|
|
|
## Run 20 fix: an empty COMMUNITY carousel
|
|
|
|
`GET /rooms/rooms/hot?tag=community&skip=0&take=20` answered 200 with
|
|
**43 bytes** - no room in `Rooms` carries the tag `community` (the column holds
|
|
`rro,2|quest,0` style pairs), so the Play menu's COMMUNITY carousel was empty.
|
|
`GetHotRooms`'s default branch now falls back to the whole public non-dorm
|
|
catalogue when the tag matches nothing, the same way `rooms/carousel/{*source}`
|
|
does; it answers 27163 b / 25 rooms now.
|
|
|
|
Server rebuilt (0 errors, 389 pre-existing warnings) and restarted as
|
|
`server-console-run20.log`, PID 26088, both listeners up:
|
|
|
|
```
|
|
/rooms/rooms/hot?tag=community&skip=0&take=20 -> 200 27163 b 25 rooms
|
|
/rooms/rooms/hot?tag=rro&skip=0&take=20 -> 200 27163 b
|
|
/lists/algorithmiclists/HotList?type=1 -> 200 {"Type":1,"Entities":[...]}
|
|
/rooms/rooms/carousel/rising?skip=0&take=20 -> 200 20289 b
|
|
```
|
|
|
|
## Known non-fatal noise (do not chase these first)
|
|
|
|
All of these are present in both the 16:54 run and the 15:13 reference run, so
|
|
they are background, not regressions:
|
|
|
|
- `Failed to load Type "RecRoom.Analytics.Statsig.StatsigDebugOverrides"` -
|
|
`RuntimeInitializationHelper:OIDNKEGDPPF(Dictionary\`2)` -> `MBJKIOBDOAM()` ->
|
|
`SubsystemRegistration()`. It is **vanilla noise**, not a symptom: the
|
|
15:13 baseline boot - loader renamed away, pristine 32,039,456 b metadata,
|
|
i.e. no patch stack at all - logs the same line
|
|
(`artifacts/baseline-20260924/Player-first-baseline.log`, line 24), and so
|
|
does every working boot since, including the bug-report upload at
|
|
`Server/RadicadeServer-Config/BugReports/20260925-044419-Player.log`. The
|
|
type is a debug-only Statsig helper the retail build does not carry; the
|
|
subsystem registration logs the miss and continues. The August plugin never
|
|
mentions the string (`grep -a -c StatsigDebugOverrides
|
|
RadicadeAugustClient.dll` = 0). Do not chase it.
|
|
|
|
- `Malformed Response: '[]'` (2 in run 20, 5 in the 15:13 run) - `ODIGMKMGFCF:
|
|
expected:'Number Token', actual:'[', at offset:0`, i.e. the client deserialised a
|
|
bare array where it wanted an object. The two in run 20 land within ~1 s of
|
|
`api/inventions/v2/mine` and `api/inventions/v1/toptoday`, both of which answer
|
|
`[]` because the inventions tables are empty; the 15:13 run survived five of
|
|
them, so their shape is wrong but not fatal.
|
|
- `Could not enable featured rooms display... no images are available` -
|
|
`featuredrooms/current` deliberately 404s.
|
|
- 404s: `/rooms/rooms/25/experience/player`, `/rooms/rooms/25/experience`,
|
|
`/econ/econ/roomGiftDropShops/room/25`, `/data/commonQuery/userSegment`,
|
|
`/econ/api/influencerpartnerprogram/{influencer,myinfluencer}`.
|
|
- `Exception: No such list` / `Deserialization returned null` for
|
|
`lists/curatedlists/bulk` (documented above).
|
|
|
|
## Run 21 setup: the tracer is re-armed (it was never the room-load regression)
|
|
|
|
Run 20's exit was confirmed by the user: **it closed on its own, with the screen
|
|
looking fine** - no black screen, no error on screen, no crash dialog. That is a
|
|
silent self-exit through the graceful path, i.e. the same class of shutdown the
|
|
run-17 `ExitInitiatorTracerPatch` was built to name.
|
|
|
|
The run-18a reasoning that parked the tracer is now known to be wrong. Its two
|
|
boots (16:10, 16:17) never fetched `/rooms/photon_access_token` and died with
|
|
"Error downloading save data!", so the tracer was blamed - but those boots were
|
|
running the *pristine* `global-metadata.dat` + `boot.config` restored by the
|
|
baseline experiment at 15:16, which is exactly what starves
|
|
`DownloadAndParse('OBHEFDFCAIC')`. With the patched metadata back, run 20
|
|
completed the load in the usual 8ms and 10278ms and the tracer was off, so the
|
|
tracer is not implicated in the room-load regression.
|
|
|
|
Re-armed in `Plugin.cs` (`harmony.PatchAll(typeof(ExitInitiatorTracerPatch))`),
|
|
rebuilt (`dotnet build 2023Patch/RadicadeAugustClient/RadicadeAugustClient.csproj
|
|
-c Release`, 0 errors) and deployed to `BepInEx/plugins/RadicadeAugustClient.dll`
|
|
(34304 b, md5 `7fd2f6c698f9568ebc6019bd8ca01e2f`; the previous run-18a build is
|
|
kept as `RadicadeAugustClient.dll.before-run20-tracer`, md5
|
|
`b5cdc49cf2da66e306ee20f4e60a515c`). The old "disabled" log line is gone from the
|
|
binary, the arm message is present.
|
|
|
|
What it does: prefixes `CCKNJCHHBLL.BEFDPLAELIH` / `GIEEBIOOFML` / `FNOEHNDLHHG`
|
|
(the managed funnel every shutdown passes through). While
|
|
`HileGate.DroppedCount == 0` the call is allowed and logged (that is normal boot
|
|
traffic); once a report has been dropped the call is **blocked** and the full
|
|
managed caller stack is logged as `[ExitInit] blocked managed exit initiator`.
|
|
The gate dropped a report at 17:43:38 in run 20 and the exit fired at 17:43:59,
|
|
so a repeat boot will be armed well before the exit.
|
|
|
|
Expected in `BepInEx/LogOutput.log` on the next boot: one `[ExitInit] allowed
|
|
managed exit initiator` early (boot traffic, before the drop), then either an
|
|
`[ExitInit] blocked managed exit initiator` stack at ~37s - which names the
|
|
trigger and should also stop the shutdown - or **no** ExitInit line at all, which
|
|
would prove the trigger is native-only (TerminateProcess-class) rather than
|
|
managed. Either outcome is a result; the metadata/boot.config md5 pair above is
|
|
the precondition to re-check first.
|
|
|
|
## Run 21 (19:34 boot, tracer armed): the trigger is NATIVE, and the tail is managed
|
|
|
|
Both expected lines appeared, and they settle the model:
|
|
|
|
```
|
|
line 36 [ExitInit] allowed managed exit initiator -> DMD<CCKNJCHHBLL::BEFDPLAELIH>() -> (il2cpp -> managed)
|
|
line 183 [HileGate] dropped anti-cheat report POST
|
|
line 276 [ExitInit] blocked managed exit initiator -> DMD<CCKNJCHHBLL::FNOEHNDLHHG>() -> (il2cpp -> managed)
|
|
```
|
|
|
|
Two things follow from the traces. First, **no managed caller ever appears**: the
|
|
frame above each initiator is `(il2cpp -> managed)`, i.e. native il2cpp code
|
|
invoking the managed method directly, so whatever decides to leave is not managed
|
|
code and no managed veto can see it. Second, the blocked initiator fires at the
|
|
**very end** of the shutdown, after `PreparingToExit` (19:34:36.77) and after
|
|
`ReadyForExit` (19:34:38.47) - the `[ExitInit]` block sits within the last ~9 log
|
|
lines, next to the `logout` / `PUT playersettings` / final analytics flush. So
|
|
`FNOEHNDLHHG` is the *last* step of a shutdown, not its trigger: blocking it held
|
|
the process ~13s longer than the previous boot but the native side still finished.
|
|
|
|
What the boot looked like from the outside:
|
|
|
|
- Dorm + spawn fine again: `Moved to phase COMPLETE` `[14020][26.5664]`,
|
|
`SpawnLocalPlayer` 10629.92 ms.
|
|
- Play menu fine: `HotList?type=1` 200 (1171 b) then `rooms/bulk?id=2&id=4&id=7...`
|
|
(21460 b) with the carousel art.
|
|
- Only three 404s, all long-known: `rooms/25/experience/player`,
|
|
`econ/econ/roomGiftDropShops/room/25`, `data/commonQuery/userSegment`.
|
|
- The client stayed **interactive until the last second**:
|
|
`Applied KEYBOARD_MOUSE control scheme LEGACY` (27.1s, automatic), `ProUX`
|
|
(32.42s), `LEGACY` (41.98s) - i.e. the settings menu was being used - then
|
|
`POST /matchmaking/player/logout` at 19:34:36.676, 100ms before
|
|
`AppExitState Running => PreparingToExit`.
|
|
- **No OS-level crash**: Windows Application log has no `Application Error` /
|
|
`Application Hang` entry for RecRoom.exe at 19:34; the game's own
|
|
`Crash Dump Report: New: 0 Previously Sent: 0`. This is a clean exit, not a
|
|
crash, however it looks on screen.
|
|
|
|
So the open question is no longer *how* the exit happens (native, at the tail) but
|
|
*what decides it*, and the only always-present candidate left is the same one as
|
|
every prior run: the dropped anti-cheat report. The two runs with a known cause of
|
|
death now stand 37s (17:43, tracer off) and 50s (19:34, same shape) apart with no
|
|
other delta, so the next boot should be a **hands-off soak**: launch it, touch
|
|
nothing, and see whether it exits on its own at all.
|
|
|
|
The user confirmed it was **not** a quit: "I was only toggling settings, never
|
|
pressed Quit". Ruled out in the same pass: no `[NotifyHub] -> <connection>` send at
|
|
all in run 20 (the only hub lines are connect/register/disconnect, the last one at
|
|
the logout instant), so no server push ends the session; a 404 in the notify socket
|
|
is not it either; and the report's own response body is a dead end (`RADICADE_HILE_BODY`
|
|
tried `ok-true`/`ok-false`/`nocontent`/`servererror` back in run 13 - ok-false only
|
|
DEFERRED the exit).
|
|
|
|
## Run 22: the exit veto is back (rebuilt), on the decision point this time
|
|
|
|
The old `ExitStateVetoPatch` was the only mitigation that ever *absorbed* these
|
|
exits (16 blocks in runs 12/13/16) and it was deleted from the tree at 15:11 by a
|
|
parallel edit, never committed - the whole `2023Patch/RadicadeAugustClient/`
|
|
directory is untracked (`git status --porcelain` -> `??`), so there is no history to
|
|
recover it from. It has been rewritten against the decompilation instead of guesswork:
|
|
`.external/aug-decomp/acs/CCKNJCHHBLL.cs` gives
|
|
`enum CCFIKLBABNB { Running = 0, PreparingToExit = 1, ReadyForExit = 2 }`,
|
|
the private static setter `KALEFEDAHCC(CCFIKLBABNB)` (token 100667095, CallerCount
|
|
3) and its interop wrapper as the setter of property `CCKNJCHHBLL.GLNIKJNLCIB`
|
|
(getter `JABDIMNNBCC`, token 100667094). Every `AppExitState changed: Running =>
|
|
PreparingToExit` line in `Player.log` is that setter.
|
|
|
|
`ExitStateVetoPatch` now patches BOTH the wrapper setter and the private method
|
|
(resolved by name, whatever exists), allows only `Running`, and blocks every other
|
|
transition **with no expiry window** - run 17 showed the re-requests continue long
|
|
after the old 120s window closed and the process leaves the moment it opens. Blocks
|
|
log the first three, then every 25th. Escape hatch for a real quit:
|
|
`RADICADE_EXIT_VETO=0` before launch (with the veto armed, quitting from the menu is
|
|
refused too - end the process from Task Manager instead). Registration is wrapped in
|
|
try/catch so a veto that will not bind can never take the boot down with it.
|
|
|
|
**A trap worth remembering:** the first build of this patch was a silent no-op. The
|
|
log line was `LogInfo(Enabled ? "armed ..." : "disabled ...")` over a
|
|
`static readonly bool Enabled`, and string-searching the built dll showed the
|
|
true-branch literal was *absent* while the false-branch one was present - i.e. the
|
|
compiler had decided the condition. `Enabled` is now a property
|
|
(`=> !_disabled`) and the log line is built at runtime, so the dll contains
|
|
`[ExitVeto] patches applied; blockExitState enabled=` and the value can be read
|
|
straight off the next boot instead of being assumed. Verify patches by searching
|
|
the SHIPPED dll for their strings; do not trust the arm message alone.
|
|
|
|
Deployed `BepInEx/plugins/RadicadeAugustClient.dll`, 36352 b, md5
|
|
`4a672a6b0ba59f73ca785cb318a6b824` (previous builds kept as
|
|
`RadicadeAugustClient.dll.tracer-run21`, md5 `34304 b / 19:32`, and
|
|
`RadicadeAugustClient.dll.before-run20-tracer`, md5 `b5cdc49cf2da66e306ee20f4e60a515c`).
|
|
Build clean (0 errors). Server untouched and up (`server-console-run20.log`, PID
|
|
26088). Expected on the next boot: `[ExitVeto] ... enabled=True`, the early
|
|
`[ExitInit] allowed` line, the `[HileGate] dropped` line, and then - instead of the
|
|
silent shutdown at 37-50s - `[ExitVeto] blocked AppExitState -> PreparingToExit`
|
|
while the session keeps running. If the session instead dies with no `[ExitVeto]`
|
|
line, the veto never bound and the `[ExitVeto] failed to apply` error text will say
|
|
why.
|
|
|
|
## Run 23: the exit's chain is named, and the last wall is Unity's own quit callback
|
|
|
|
Two questions were open after run 22: what *starts* the shutdown, and whether any
|
|
frame of it is still reachable from managed code. The first is now answered from
|
|
evidence that was already on disk; the second is patched.
|
|
|
|
### The chain
|
|
|
|
1. The client's own scanner finds a planted module and files the anti-cheat report.
|
|
That report body was decoded back in run 9 and is still in the server logs:
|
|
`Hile report received: Type=Obcured Message=[0:winhttp.dll]` - the BepInEx
|
|
Doorstop proxy `winhttp.dll` in the game root, classified `Obscured` (hile enum
|
|
`MEHDFJHKLBK.JBLJIENBBHK`, Obscured = 0). The classification is **inherent**: run 9
|
|
logged the identical body at 22:16, hours before the run-14 PEB unlink (23:27) and
|
|
the run-15 PE-signature wipe (23:42) existed, so hiding never caused it and
|
|
un-hiding will not remove it.
|
|
2. It re-scans on a fixed schedule. `server-console.log` holds two reports at
|
|
`23:32:28.141` and `23:32:58.405` - **30.264s apart**. That schedule, not a boot
|
|
timer, is why the same build dies at 36.8s on one boot and 55.3s on the next: the
|
|
exit lands on the first tick after the boot completes.
|
|
3. The report is not the trigger. Dropping it at the HTTP layer (`HileGate`, run 16)
|
|
only defers the exit, and run 13 proved the response body is irrelevant. The
|
|
scanner's local verdict starts the shutdown; the report is a side effect.
|
|
4. Where it ends (run 22 `Player.log`):
|
|
`UnityEngine.Application:Internal_ApplicationWantsToQuit()` ->
|
|
`System.Func\`1[TResult]:Invoke()` -> `CCKNJCHHBLL:GBGMBMGDGGD(System.Boolean)` ->
|
|
`MGLDPDAEODB:EMDNIBPNEGH()` -> `PFDOLDLEIBA:CKIEGOCLGFD(Action\`1)`, and then
|
|
`[EAC] Tearing down and releasing runtime` three times in the last 3.3s.
|
|
|
|
**The 15:13 reference run self-exits too.** `Player-before-baseline.log` - the boot
|
|
that loaded the Dorm and was taken as good - ends with
|
|
`[15:14:05] AppExitState changed: Running => PreparingToExit` at 41.81s, followed by
|
|
the same EAC teardown. Its `Could not enable featured rooms display` warnings start at
|
|
23.1s and repeat (run 22: 23.2s, 30.2s, 37.2s, 44.2s, 51.2s - every 7.0s), so they are
|
|
periodic RRUI noise and not the precursor they looked like. Nothing in the recent
|
|
client work causes this exit; it is inherent to running this build with a Doorstop
|
|
module in the game root.
|
|
|
|
### Patched in this build
|
|
|
|
- `ExitSequenceTracePatch` - a `Priority.First` prefix on
|
|
`BestHTTP.HTTPManager.SendRequest(HTTPRequest)` (the same managed funnel
|
|
`NameserverConnectionPatches` logs every request in) that dumps
|
|
`Environment.StackTrace` the first four times the **shutdown's own requests** go out:
|
|
`/matchmaking/player/logout` and `/playersettings/playersettings`. The shutdown
|
|
sequence's first observable network act is the logout POST (server log run 22:
|
|
`19:45:38.785`, right after the notify-hub reconnect). Whoever calls it is the owner
|
|
of the shutdown, and the stack names them - no inference needed.
|
|
- `ExitStateVetoPatch` now also dumps the stack on its **first** block, which names the
|
|
caller of the `Running => PreparingToExit` transition (run 22 blocked three times with
|
|
no caller recorded).
|
|
- `UnityQuitVetoPatch` - the last wall. Prefixes **both** `CCKNJCHHBLL.GBGMBMGDGGD`
|
|
overloads (decompilation tokens 100667099 / 100667100; the stack trace prints the
|
|
`bool` one, so both are bound rather than guessing) and forces `__result = false`,
|
|
which is "the application does not want to quit" and makes Unity cancel the quit.
|
|
It **skips** the original instead of running it and rewriting the result: run 22's
|
|
trace shows the original *throwing* (`NullReferenceException` out of
|
|
`StatsigUnity.EventLogger.StopCoroutine`), and a throwing original returns before any
|
|
postfix can override the value Unity reads - a postfix-only veto would be silent
|
|
exactly when it matters. Escape hatch: `RADICADE_QUIT_VETO=0`, and `Enabled` is a
|
|
property (`=> !_disabled`) with a runtime-built log line, the run-22 folding trap
|
|
avoided.
|
|
|
|
Deployed `BepInEx/plugins/RadicadeAugustClient.dll`, 39424 b, md5
|
|
`71df28734d88fd3f9eca70f202e517bb`; the run-22 build is kept as
|
|
`RadicadeAugustClient.dll.before-run23-quitveto` (36352 b, md5
|
|
`4a672a6b0ba59f73ca785cb318a6b824`). Build clean (0 errors, 0 warnings).
|
|
Preconditions re-checked at deploy time: `global-metadata.dat` 38654794 b md5
|
|
`cc9c32014b5fc3dd1a2a8fb12376be15`, `boot.config` 173 b md5
|
|
`dc2e5f7af7d5df736a4cc3477b4b1a1f`.
|
|
|
|
### What the next boot has to say
|
|
|
|
- `[ExitTrace] shutdown-request stack dump armed; [QuitVeto] wantsToQuit veto enabled=True`
|
|
at load, then `[ExitVeto] ... enabled=True`, the early `[ExitInit] allowed`, and the
|
|
`[HileGate] dropped` line at the first 30s tick.
|
|
- At the exit: `[ExitTrace] shutdown request ...` with the stack that ordered it, and
|
|
`[QuitVeto] wantsToQuit answered false` when the quit is refused.
|
|
- **If the process is still alive minutes after that** the plant works and the remaining
|
|
problem is cosmetic (whatever state the half-run shutdown left the UI in). If it dies
|
|
anyway, the kill is outside Unity's quit path (`TerminateProcess`-class, or EAC's own
|
|
runtime) and the next lever is to remove the module the scanner objects to instead of
|
|
fighting the reaction - i.e. bootstrap BepInEx without a `winhttp.dll` proxy in the
|
|
game root, which means a loader-side injection (manual mapping or a launcher) rather
|
|
than Doorstop.
|
|
|
|
## Run 23b: neutralise the EAC runtime itself (ported from the supplied patcher)
|
|
|
|
`C:\RecRoom\Downloads\patch` is a decompiled copy of **`RecRoomil2cppPatcher`**
|
|
(WaeBoi69, loaded by Reloaded-II). Its `EacPatcher.cs` is the piece this project needed:
|
|
a proven recipe for neutralising EasyAntiCheat on Rec Room. Five hooks into
|
|
`EasyAntiCheat.Client.dll`:
|
|
|
|
| Method | Replacement |
|
|
| --- | --- |
|
|
| `Hydra.Runtime:IsActive` | `return true` |
|
|
| `Hydra.Runtime:Initialize` | no-op |
|
|
| `Hydra.NativeClient:Initialize` | no-op |
|
|
| `Hydra.NativeClient:IsStartedWithEasyAntiCheat` | `return true` |
|
|
| `Hydra.Runtime:get_Initialized` | `return true` |
|
|
|
|
The pattern is the point: the *initialisers* are stubbed while the *queries* lie and report
|
|
a healthy, active anti-cheat - which is what the game's own checks read.
|
|
|
|
Our build exposes the same surface. `BepInEx/interop/EasyAntiCheat.Client.dll` contains
|
|
`EasyAntiCheat.Client.Hydra`, `.Hydra.Runtime`, `.Hydra.NativeClient`, `.Hydra.NetProtect`
|
|
and exactly those members (`ilspycmd -o ... EasyAntiCheat.Client.dll`; output kept in
|
|
`.external/interop-decomp/EasyAntiCheat.Client/EasyAntiCheat.Client.decompiled.cs`).
|
|
Why this is the root-cause lever and not another wall: the report is `Obscured` +
|
|
`winhttp.dll`, i.e. a *native module scan*, and `NativeClient.Initialize` is where that
|
|
native client is brought up.
|
|
|
|
Deployed in our plugin (`RADICADE_EAC_NEUTRALIZE=0` disables; armed by default):
|
|
|
|
- `EacNativeClientStubPatch` - every static `Initialize` on `Hydra.NativeClient` is
|
|
skipped, so EAC's native client (home of the module scanner) never starts.
|
|
- `EacHealthQueryLiePatch` - `Hydra.NativeClient.IsStartedWithEasyAntiCheat`,
|
|
`Hydra.Runtime.IsActive` and `Hydra.Runtime.get_Initialized` answer `true`.
|
|
- `Hydra.Runtime.Initialize(...)` is deliberately **left running**: it does the game-facing
|
|
bookkeeping (event wiring `RecRoom.AntiCheat.EACManager` subscribes to via `JMAPOMLPFMI`
|
|
/ `HINJPEHPJGO` / `AOFHJPLDLBC`) and its native step is the stubbed
|
|
`NativeClient.Initialize`. Stubbing it too is stage B if this is not enough.
|
|
- Type discovery is name-based with a hard-reference fallback
|
|
(`typeof(EasyAntiCheat.Client.Hydra.Runtime).Assembly` in its own method, so the JIT only
|
|
resolves it if the soft lookups came up empty) - nothing else in the plugin touches that
|
|
assembly, so at Load time `AccessTools.TypeByName` can legitimately see nothing.
|
|
|
|
The game's EAC readiness door is already propped open (`AugustChallengePatches` fakes
|
|
`EACManager.GenerateChallengeResponse` and forces `EACManager.MGEAHKJIIMO` true), so stopping
|
|
the runtime does not leave one of the game's checks waiting on it.
|
|
|
|
**Success marker, and it is unambiguous:** the `[HileGate] dropped anti-cheat report POST`
|
|
line must no longer appear at the 30s tick. No report means the scanner never reached its
|
|
verdict, which means no shutdown. The run-23 exit walls stay armed as the backstop, and their
|
|
`[ExitTrace]` / `[QuitVeto]` / `[ExitVeto]` lines say whether they were needed.
|
|
|
|
Deployed `BepInEx/plugins/RadicadeAugustClient.dll`, 43520 b, md5
|
|
`434972bf54968f1287643d8be61de8f7` (the run-23 plain build is kept as
|
|
`RadicadeAugustClient.dll.before-run23b-eacstub`, 39424 b). Build clean (0 errors).
|
|
|
|
### Verification method correction
|
|
|
|
The run-22 "constant folding" conclusion came from a hand-rolled check - decode the shipped
|
|
dll as UTF-16 and `String.Contains` the literal - and that method is **not reliable**:
|
|
against this build it reports `EasyAntiCheat.Client.Hydra.NativeClient` and
|
|
`[EacStub] EasyAntiCheat Hydra runtime neutralisation enabled=` as MISSING, and the
|
|
decompiled IL shows both present. Do not use it. Use the decompiler on our own output:
|
|
|
|
```bash
|
|
ilspycmd -o .external/selfcheck 2023Patch/RadicadeAugustClient/bin/Release/net6.0/RadicadeAugustClient.dll
|
|
grep -c "EacStub" .external/selfcheck/*.cs
|
|
```
|
|
|
|
The run-22 lesson's *shape* is kept anyway (`Enabled` is a property over a
|
|
`static readonly _disabled`, log lines built at runtime) - it costs nothing, and it is the
|
|
only version that cannot be folded if the compiler ever does decide to.
|
|
|
|
### Run 23b outcome (20:44 boot): three negative results, each of them useful
|
|
|
|
Session: 20:44:21 -> 20:45:11 (50s). Boot was healthy and identical to the best
|
|
boots - `Moved to phase COMPLETE` at 20.24s, `SpawnLocalPlayer` 10568.89ms.
|
|
|
|
1. **EAC's managed runtime is not the scanner.** `[EacStub] ... enabled=True` and
|
|
`Hydra.Runtime.IsActive answered true` appear, but there is **no**
|
|
`skipped ... Hydra.NativeClient.Initialize` line anywhere in the boot: the game
|
|
never calls it, i.e. EAC's native client was never started in this setup - our
|
|
own `EACManager` patches had already seen to that. The `winhttp.dll` verdict
|
|
still arrived. **The scanner is RecRoom's own**, not Hydra's. Auena's recipe is
|
|
still worth having (it is what keeps a modded client's EAC surface quiet), but it
|
|
is not the fix for this.
|
|
2. **Unity's quit is not the kill.** `[QuitVeto] wantsToQuit answered false (block
|
|
#1)` fired and the game **kept running for ~18s afterwards** - it went on loading
|
|
images, PUTting settings and fetching avatar items - so the veto did its job on
|
|
the request it saw. But `Player.log` shows `Trying to send photon room updates to
|
|
server while application is quitting - this should not be happening` from 36.1s,
|
|
i.e. Unity was already in its quit state *before* the veto fired: the first quit
|
|
request took the native path (`Application.Quit()` from native code does not
|
|
consult `wantsToQuit`), and the request we blocked was a later one. The process
|
|
ended at 52.85s. Windows' Application log has no `Application Error`/`Hang` for
|
|
it, and this run's shutdown again begins with `[EAC] Tearing down and releasing
|
|
runtime` at 34.89s.
|
|
3. **The absence of `ExitVeto`/`ExitInit` lines is itself the result**: this run's
|
|
shutdown never touched the managed exit state machine *at all* (no
|
|
`AppExitState changed`, no blocked transition, no initiator call). So the veto
|
|
and the tracer are aimed at a path this build does not use when the anti-cheat
|
|
verdict starts the shutdown; the verdict path is native end to end.
|
|
|
|
The stack dumps did name the boundary honestly: `[ExitTrace]` shows
|
|
`DMD<BestHTTP.HTTPManager::SendRequest>` followed by
|
|
`(il2cpp -> managed) SendRequest(IntPtr, Il2CppMethodInfo*)` - the logout and the
|
|
settings PUT are issued by **native code calling into managed** BestHTTP, so no
|
|
managed caller exists to name. Same shape as run 21's finding for the initiators.
|
|
|
|
## Run 23c: capture the verdict, stop obscuring the module, trace `CheatManager`
|
|
|
|
Given the above, the only remaining fix is to stop the verdict instead of the
|
|
reaction. Three changes, all in one build, all observable in one launch:
|
|
|
|
1. **The run-14/15 module hiding is now OFF by default** (`RADICADE_MODULE_HIDE=1`
|
|
re-arms it). Runs 14/15 proved the scanner cannot be blinded - unlink and wipe
|
|
both applied mechanically and the report fired anyway - while "a loaded module
|
|
that the loader lists do not know about, with its MZ/PE headers zeroed" is the
|
|
most literal description of an *obscured* module there is, and `Obscured` is the
|
|
exact verdict the client files against `winhttp.dll`. It bought nothing and may
|
|
have been feeding the classifier; the plugin now logs what a Toolhelp module walk
|
|
- the same view a scanner gets - actually sees (`[ModuleList] ...`).
|
|
2. **`HileGate` is now a capture gate**, not a drop gate: `ShouldDrop` dumps the
|
|
report's whole wire form (`request.MethodType`, the URI and `request.RawData` as
|
|
UTF-8, with `GetEntityBody()` as the fallback) and then lets it through, so both
|
|
the client log and the server log carry what the client believes it found. The
|
|
server's `HileAPI` keeps only `Type` and `Message`; the body may carry more.
|
|
`RADICADE_HILE_GATE=drop` restores run 16.
|
|
3. **`CheatManagerTracePatch`** prefixes every declared method of `CheatManager`
|
|
and its nested types and logs name + elapsed ms (first two calls of each, hard
|
|
line cap). `CheatManager` (Assembly-CSharp, global namespace, a
|
|
`SingletonMonoBehaviour`) is the one managed class in this build that plainly
|
|
does local anti-cheat work - `OnTimeCheatDetected`,
|
|
`OnObscuredTypeCheatDetected`, `OnAdvancedMovementCheatDetected`,
|
|
`IPEMGBLAFIJ(string)`, `BFNMCBEDOLF(string)`, `CheckForDUIDMismatch`, and two
|
|
nested helpers carrying `appPath`/`filenames`. Nothing is skipped: observing only,
|
|
because the one detour this project must never take is the scanner's own funnel
|
|
(run 11). Whatever runs a few hundred ms before the `[HileGate] captured` line is
|
|
the verdict, and its name is the next patch target.
|
|
|
|
Deployed `BepInEx/plugins/RadicadeAugustClient.dll`, 48128 b, md5
|
|
`018b991ab951196a76e4ed7f7f3eac4b` (run-23b build kept as
|
|
`RadicadeAugustClient.dll.before-run23c-capture`, 43520 b). Build clean (0 errors),
|
|
verified by decompiling the built dll (`ilspycmd -o .external/selfcheck`), not by
|
|
string search. The run-23 exit walls stay armed as the backstop.
|
|
|
|
### Run 23c outcome (21:02 boot): the trace named the producer
|
|
|
|
The `CheatManager` trace paid for itself on its first run:
|
|
|
|
```
|
|
+15113ms CheatManager.OnApplicationFocus
|
|
+15366ms CheatManager.MJLAGDJLOBC
|
|
+15367ms AALEGIEIKEL.LLPNCADGDNI
|
|
+15368ms AALEGIEIKEL.LLPNCADGDNI
|
|
+15368ms [HileGate] anti-cheat report captured (full wire form)
|
|
```
|
|
|
|
`CheatManager.MJLAGDJLOBC()` - a private no-argument method on the anti-cheat
|
|
MonoBehaviour - runs 2ms before the report, with `AALEGIEIKEL.LLPNCADGDNI(string)`
|
|
(a helper whose class carries an `appPath` field) called twice on the way. A pass
|
|
over files in the game directory is exactly what would decide that a proxy DLL in
|
|
the game root is `Obscured`, which is the verdict `[0:winhttp.dll]` reports.
|
|
|
|
Two things the capture taught us about the report itself: `RawData` is **empty** and
|
|
the fields live in the entity body (36 bytes = `Type=Obcured&Message=[0:winhttp.dll]`,
|
|
matching run 9's decode exactly), and the body text was not printed by the first
|
|
version of the dumper - it printed the byte count only. Now it prints both.
|
|
|
|
Also confirmed: `[ModuleList] winhttp.dll is enumerated by a Toolhelp module walk:
|
|
C:\RecRoom\2023-08-29T06-53-33Z\WINHTTP.dll` - run 14's PEB unlink and
|
|
run 15's PE wipe really are off now, and the module is back in the list a scanner reads.
|
|
|
|
### What the exit walls actually buy, now measured on screen
|
|
|
|
The 21:02 boot lost its session to the same shutdown, but this time the process
|
|
survived (the Unity quit veto answered `false` and the game kept running). What the
|
|
player sees in that state is the run-12 prediction, reproduced on demand:
|
|
|
|
```
|
|
Error joining room instance RoomInstance - ID:20871 DORM_ROOM:25/32
|
|
NullReferenceException: Object reference not set to an instance of an object.
|
|
Attempting to go to dorm
|
|
Not logged in to matchmaking service
|
|
Not logged in to matchmaking! not letting me in no more
|
|
```
|
|
|
|
The server log agrees with the order: the report arrived for the first time in these
|
|
boots (`21:02:44.255 POST /api/PlayerReporting/v1/hile -> 200 body=true`, because the
|
|
gate is now in capture mode) and the client logged out 156ms later
|
|
(`21:02:44.411 POST /matchmaking/player/logout`). So the walls convert a silent exit
|
|
into a live-but-logged-out client: better for diagnosis, useless as a game.
|
|
|
|
Server-side note for future probing: `localhost:3030` speaks **TLS**. A plain-HTTP
|
|
probe answers `000` in ~5ms and looks like a hung server; `curl -sk
|
|
https://127.0.0.1:3030/...` answers `200` in ~11ms. The server was healthy throughout.
|
|
|
|
## Run 23d: suppress the scan instead of the reaction
|
|
|
|
`CheatScanSuppressPatch` skips `CheatManager.MJLAGDJLOBC()` (env `RADICADE_CHEAT_SCAN=0`
|
|
leaves it alone). Given the trace, that method is the producer of the verdict, so
|
|
skipping it means no verdict, no report and no shutdown - the only stopping point that
|
|
leaves a playable client, since the reaction is native end to end and the walls only
|
|
trade an exit for a zombie.
|
|
|
|
Supporting changes in the same build:
|
|
|
|
- `CheatTrace` per-method limit 2 -> 4, so if the skip is not enough, the third and
|
|
fourth calls of every candidate are still on the record and a miss stays diagnosable.
|
|
- `[HileGate] armed` now states which mode it is in (capture vs `RADICADE_HILE_GATE=drop`)
|
|
instead of always claiming the drop.
|
|
|
|
Deployed `BepInEx/plugins/RadicadeAugustClient.dll`, 50176 b, md5
|
|
`b96b1b8926a1ec172e2b84ea0a85d179` (run-23c build kept as
|
|
`RadicadeAugustClient.dll.before-run23d-scan`, 48128 b). Build clean, verified by
|
|
decompiling the built dll.
|
|
|
|
Expected on the next boot: the session stays logged in past the 15-40s window it has
|
|
never survived, with **no** `[HileGate] captured` line and a `[CheatScan] skipped
|
|
CheatManager.MJLAGDJLOBC() (#1)` where the verdict used to appear. If instead the
|
|
process dies exactly at the skip, that pass runs on a scanner thread and joins the
|
|
run-11 forbidden list (`KDJDKJNPELI.IJHOPKJFKBI`) - also a result, and the lever after
|
|
it is to remove the module the scan objects to rather than the scan itself.
|
|
|
|
## Run 24 (2026-09-24 21:0x) - the first real crash of the project, and how to name it
|
|
|
|
The skip worked. `[CheatScan] skipped CheatManager.MJLAGDJLOBC()` fired twice, `[HileGate]
|
|
captured` never appears, the server log has no `/api/PlayerReporting/v1/hile` POST for the
|
|
whole session, and there is no `matchmaking/player/logout` - the anti-cheat chain that ended
|
|
every previous run is genuinely gone. With it gone the client did something it had never done:
|
|
it **entered RecCenter**.
|
|
|
|
One second later it died. This time it is not a graceful shutdown:
|
|
|
|
```
|
|
Application Error 09-24 21:11:58
|
|
Faulting application: RecRoom.exe, 2020.3.33.23162
|
|
Faulting module: GameAssembly.dll
|
|
Exception code: 0xc0000005 (access violation)
|
|
Fault offset: 0x00000000029a79ec
|
|
```
|
|
|
|
`Application Hang` has nothing, and the previous day's 18 RecRoom faults are a *different*
|
|
signature ({coreclr.dll +0x1d1fdd}, {GameAssembly.dll +0x7567f0 / 0x80000003 breakpoint},
|
|
{unknown / 0xffffffffffffffff}); 09-24 had no RecRoom fault at all until this one. So this is
|
|
new code territory, reached only now that the room load is not being cut short at 15-40s.
|
|
|
|
### Reading the dump without a debugger
|
|
|
|
WER left `%LOCALAPPDATA%\CrashDumps\RecRoom.exe.8396.dmp` (61 MB). No cdb/windbg/dotnet-dump
|
|
is installed, so `tools/minidump_stack.py` reads the minidump directly: exception stream,
|
|
module list, thread context (amd64 Rsp/Rbp/Rip at 0x98/0xA0/0xF8) and the stack pages, then
|
|
prints every stack slot that points into a module as `module+0xrva`. `--map` resolves those
|
|
through the RVA table the client writes (below), so no debugger is needed at any point.
|
|
|
|
It reproduces the WER record exactly, and adds the two things WER does not say:
|
|
|
|
```
|
|
fault: ACCESS_VIOLATION (0xc0000005) at 0x7ffc16f679ec
|
|
read of address 0x93
|
|
in GameAssembly.dll+0x29a79ec
|
|
rsp 0x41fb78e6d0 rbp 0x24447df8250 rip 0x7ffc16f679ec
|
|
```
|
|
|
|
A read of **0x93** means a null object with a field at offset 0x93 was dereferenced, and
|
|
il2cpp left the check off - which is how pointer-arithmetic paths (`fixed`/`Unsafe`/native
|
|
arrays) fail, not ordinary managed field access (that raises NullReferenceException). The
|
|
stack around it (innermost first) is ~20 GameAssembly frames, with
|
|
`GameAssembly.dll+0x2881f73` the closest return address and `coreclr.dll+0x11f66a`
|
|
(BepInEx's .NET runtime) and `UnityPlayer.dll` frames behind them:
|
|
|
|
```
|
|
rsp+0x28 GameAssembly+0x2881f73 rsp+0x108 GameAssembly+0x11f2eae
|
|
rsp+0x98 GameAssembly+0x59adea8 rsp+0x1a8 GameAssembly+0x1201e67
|
|
rsp+0xa8 GameAssembly+0x7764a5 rsp+0x218 coreclr+0x11f66a
|
|
rsp+0xd8 GameAssembly+0x49dcd3f rsp+0x2d8 GameAssembly+0x1202175
|
|
```
|
|
|
|
### What the last requests were (the "last API was the heartbeat" question)
|
|
|
|
```
|
|
21:11:50.944 POST /matchmaking/player/heartbeat 200 14.5 ms len=631
|
|
21:11:53-57 POST /datacollection/data/event 200 x3
|
|
21:11:55.395 GET /clubs/club/home/me 200
|
|
21:11:55.433 GET /data/commonQuery/userSegment 404
|
|
21:11:55.648 GET /lists/algorithmiclists/HotList 200 1171 b
|
|
21:11:55.675 GET /rooms/rooms/bulk?id=2..19 200 21460 b
|
|
21:11:56.113 GET /rooms/rooms/3/interactionby/me 200 47 b
|
|
21:11:56.124 GET /rooms/rooms/3/experience 404
|
|
21:11:56.170 GET /images/RecCenter?width=1024 200 71351 b
|
|
21:11:57.213 POST /datacollection/data/heartbeat 200
|
|
<crash> 21:11:58, dump written 21:12, notify-hub SSE closes 21:12:04
|
|
```
|
|
|
|
The request just before the crash is the data-collection heartbeat, and the matchmaking
|
|
heartbeat 7 s earlier is the only call in the session with an unusual duration (14.5 ms vs
|
|
sub-millisecond everywhere else, 631 b response), so both are on the list. But the crash is
|
|
1 s after the RecCenter art fetch and is a null dereference inside the game's own compiled
|
|
code, so the room-3 load is the stronger reading. `rooms/rooms/3/experience` returning 404 is
|
|
not obviously the cause: the reference server has no such route either.
|
|
|
|
### The new instrument: rva -> method
|
|
|
|
An offset from a module base is worthless until it is a method name, and IL2CPP will hand the
|
|
name over: the MethodInfo that `il2cpp_class_get_methods` returns begins with the compiled
|
|
method's native entry point. `2023Patch/RadicadeAugustClient/CrashAddressMap.cs` walks
|
|
`il2cpp_domain_get()` -> assemblies -> images -> classes -> methods (all raw entry points are
|
|
public in `Il2CppInterop.Runtime.IL2CPP`), writes `rva<TAB>image<TAB>Class::Method` to
|
|
`BepInEx/radicade-addr-map.txt`, and logs the methods bracketing the target RVA. It is a
|
|
background thread started 5 s into the boot, it never blocks the login, and it does not need
|
|
the crash reproduced - the table is static. `RADICADE_ADDR_MAP=0` disables it and
|
|
`RADICADE_ADDR_TARGET=0x...` re-aims it at the next WER offset, so no code change is needed
|
|
for the next crash.
|
|
|
|
Deployed `BepInEx/plugins/RadicadeAugustClient.dll`, 55296 b, md5
|
|
`129e9b5ef7e55820f05d8440b9d5b900` (run-23d build kept as
|
|
`RadicadeAugustClient.dll.before-run24-addrmap`, 50176 b). Build clean (0 warnings), and the
|
|
shipped IL was verified by decompiling the built dll (`CrashAddressMap.Start()` is called from
|
|
`Load`, and the enumeration + `.txt` path are present).
|
|
|
|
Next: one boot, then `sort -k1 BepInEx/radicade-addr-map.txt` offline and resolve
|
|
`0x29a79ec` plus the stack RVAs above through it - which names the method that dereferenced
|
|
null, and the frames that led there.
|
|
|
|
## Run 25 (2026-09-24 21:27) - RecCenter loads, then a second, different crash
|
|
|
|
This is the run that made the room load irrelevant: **the room finished loading**. The
|
|
2023 build's own load profiler ends with `[Run Success Callbacks]`, `SpawnLocalPlayer`
|
|
total 9857 ms, `MoveToPhase(COMPLETE)`, and the server served everything in order
|
|
(`matchmaking/matchmake/room/3` -> instance 20876, room 3 metadata, photon token,
|
|
`reportjoinresult`, `verifyRole`). The anti-cheat chain stayed off (`CheatScan` skipped
|
|
`MJLAGDJLOBC` twice, no `[HileGate] captured`, no hile POST, no logout).
|
|
|
|
Then, ~10 s after the spawn, the client died again - at a **different address**:
|
|
|
|
```
|
|
Application Error 09-24 21:28 RecRoom.exe / GameAssembly.dll
|
|
Exception code 0xc0000005 Fault offset 0x0000000003dc0c57
|
|
```
|
|
|
|
`0x3dc0c57` is inside `Unity.Entities.ChunkDataUtility::GetComponentDataWithTypeRO`
|
|
(exact entry point match), and the faulting instruction is `mov rbx, [rdx+0x88]` with
|
|
`rdx = 0xFFFFFFFFFFFFFF77` - a read of address 0xFFFFFFFFFFFFFFFF. So the game handed an
|
|
ECS chunk accessor a garbage pointer, and il2cpp had no null check to catch it.
|
|
|
|
Compared with the 21:11 crash, that is two different fault sites (`0x29a79ec` is a 26-byte
|
|
unnamed function; read of address 0x93) but the same shape: a pointer-arithmetic dereference
|
|
inside the game's own compiled code, roughly 1-3 s after a periodic RRUI
|
|
"Could not enable featured rooms display" warning. That warning is not the trigger - it also
|
|
fires every ~7 s in the dorm and nothing happens. Likewise the 35 `RecCenter_Chair ... has an
|
|
RigidbodyEx but no EmbodiedObject/RbexEntity/TransformEntity component` errors are pre-existing
|
|
noise: they appear 35 times in both the crashing run and in the 21:02 run, dorm included.
|
|
|
|
### Tooling that made this readable
|
|
|
|
- `BepInEx/radicade-addr-map.txt` - 254 171 methods from 305 images, written in **141 ms**
|
|
(18.5 MB, benign: a background thread, 5 s into boot).
|
|
- `tools/pe_unwind.py` - parses `.pdata` RUNTIME_FUNCTIONs and UNWIND_INFO (PUSH_NONVOL,
|
|
ALLOC_SMALL/LARGE, SET_FPREG, SAVE_NONVOL(_FAR), PUSH_MACHFRAME, chained info) and replays
|
|
a prologue to recover the caller - a real x64 unwinder. Two bugs found and fixed while
|
|
writing it: `ALLOC_SMALL` carries its size in the op-info nibble (a zero operand advanced
|
|
RSP by 8 instead of 0x28, which produced one bogus frame), and a past-the-end lookup used
|
|
to reuse the previous function's unwind info and manufacture frames - a leaf function with
|
|
no entry is now unwound from `[rsp]` instead, as a debugger would.
|
|
- `tools/minidump_stack.py --unwind` - walks the dump's faulting thread; resolves the WER
|
|
offset against the dump ("matches the WER fault offset") before using either.
|
|
- `tools/resolve_rva.py` - function boundaries from `.pdata`, names from the boot-time map,
|
|
and it says `UNNAMED` when the nearest name is not the function's own entry point.
|
|
|
|
The verified chain for the 21:28 crash (innermost first, exact-name frames only):
|
|
|
|
```
|
|
Unity.Entities.ChunkDataUtility::GetComponentDataWithTypeRO <- crash
|
|
(unnamed generic-instantiation frames, no metadata entry point)
|
|
IHDIFFAKHOM::JEONIAELMNM
|
|
(unnamed)
|
|
EHEHGHCKFII::System.Collections.IEnumerable.GetEnumerator
|
|
Tool::CCFENLNCIOG -> Tool::LPAOCFPMJFD -> Tool::RpcOnReset
|
|
-> Tool::AuthorityResetToDefault -> ToolCleanup::BFFGEGKNGMM
|
|
RecRoom.Core.Updates.StaggeredUpdateManager::DGHHCHACHOM
|
|
-> (unnamed) -> UnityPlayer.dll main loop
|
|
```
|
|
|
|
Every frame's own `.pdata` entry was used (no leaf guessing except where flagged), and the
|
|
walk terminates in UnityPlayer's scheduler, so this is a call chain rather than a stack
|
|
picture.
|
|
|
|
### Run 25b: the ObjectModel A/B (server-side, reversible)
|
|
|
|
Both crashes are inside `Unity.Entities` code reached from a staggered update, and the dorm
|
|
has never crashed. `ObjectModel_EnableForRoom_2022_07_01` is exactly the split test that
|
|
gates Rec Room's ECS-backed object model for rooms, and this server shipped it as
|
|
`Allowed`, so the 2023 client turns that model on whenever it enters a room. It is now
|
|
`Disallowed`:
|
|
|
|
- `Server/RecNet/Config/SplitTestConfigs.cs` - `HardOverrides` (fresh-DB seed),
|
|
- `Server/DB/DBConfig.cs` - `PlaceholderConfig` (same value, same reason),
|
|
- the live `GameConfig` row `splitTestHardOverrides`, updated in place with
|
|
`REPLACE(...,'ObjectModel_EnableForRoom_2022_07_01=Allowed','...=Disallowed')`.
|
|
|
|
The third one is the only edit that actually reaches this client: `UpsertGameConfigValue`
|
|
and `EnsureSplitTestHardOverrides` only ever *add* what a row is missing, and
|
|
`RepairSplitTestConfigs` documents the stored row as admin-managed ("never clobber a value
|
|
that is already set"), so the DB row is the source of truth. Pinning the key in
|
|
`GameConfigAPI.Local2023Overrides` was tried first and reverted: it contradicts that design
|
|
*and* `RecNetShapeConformanceTests.GameConfigs_SuppressInvalid2023SplitTestConfigs`, which
|
|
asserts the DB row is filtered and passed through rather than replaced.
|
|
|
|
Verified through the endpoint the client actually calls:
|
|
|
|
```
|
|
GET /api/gameconfigs/v1/all -> ObjectModel_EnableForRoom_2022_07_01=Disallowed
|
|
```
|
|
|
|
Server restarted (PID 11884, 3030/3031), build clean, `SplitTest`/`GameConfigs_` tests 6/6.
|
|
|
|
Also eliminated while checking: room save data. Every subroom's `DataBlob` is empty - the
|
|
working dorm room 25 included - and `SubRoomHistory` is empty, so "RecCenter's data is
|
|
missing" is not a difference between a room that survives and one that does not. The client
|
|
never requests a room blob at all (`GET /cdn/room/` is only the CDN index, `{"status":"ok"}`,
|
|
22 b). The frames the map cannot name are generic instantiations: IL2CPP gives each one its
|
|
own code but they share a single metadata entry point, so `il2cpp_class_get_methods` never
|
|
sees them. Naming those needs the runtime instantiation table, not this map.
|
|
|
|
### Run 25c: crash 3's own fault header, and the prop-binding difference
|
|
|
|
Crash 3's `fault:` block had not been printed before (an earlier `sed` filter cut it off). It is
|
|
the same fault as crash 2, one instruction shape away:
|
|
|
|
```
|
|
fault: ACCESS_VIOLATION (0xc0000005) at 0x7ffc18cc728d
|
|
read of address 0xffffffffffffffff
|
|
in GameAssembly.dll+0x470728d (matches the WER fault offset)
|
|
rsp 0xc42b34ea20 rbp 0x261c24784a0
|
|
```
|
|
|
|
resolved (crash 3, exact names only):
|
|
|
|
```
|
|
Unity.Entities.EntityComponentStore::GetComponentArraySize region <- crash, +0x140 = UNNAMED
|
|
(unnamed generic instantiations)
|
|
IHDIFFAKHOM::JEONIAELMNM
|
|
(unnamed)
|
|
EHEHGHCKFII::System.Collections.IEnumerable.GetEnumerator
|
|
(unnamed) -> Tool::CCFENLNCIOG -> Tool::ResetToDefaultCollisionLayer
|
|
-> Tool::LPAOCFPMJFD -> Tool::RpcOnReset -> Tool::AuthorityResetToDefault
|
|
-> (unnamed) -> ToolCleanup::BFFGEGKNGMM -> ToolCleanup::CJGILKPKDOL
|
|
RecRoom.Core.Updates.StaggeredUpdateManager::DGHHCHACHOM
|
|
-> (unnamed) -> (unnamed) -> UnityPlayer.dll scheduler
|
|
```
|
|
|
|
A read at `0xffffffffffffffff` is an index that came out as `-1`: some `TypeIndex`/component
|
|
lookup in the tool's component set has no answer, the code indexes with it anyway, and the
|
|
base pointer lands one byte past the end of the address space.
|
|
|
|
**The `/similar` lead is dead.** The route does exist - `Server/RoomServer/V2_RoomsAPI.cs`
|
|
(`[Route("rooms/rooms/")]`, `GET {id:long}/similar`, our own local addition) - and it did
|
|
answer `200 len=10166` for room 3, followed 2.5 s later by
|
|
`Error refreshing rooms from source RoomSimilarity: An error occurred`. But run 24 (crash 2)
|
|
never requested `/similar` and never logged that error, and it died with the identical chain,
|
|
12 s after the same room reported COMPLETE. Two runs, same crash, one with the carousel and
|
|
one without: the carousel is a real but separate bug (our payload fails the client's
|
|
RoomSimilarity parse), not the cause of the AV.
|
|
|
|
**Timing is deterministic.** Room load COMPLETE -> crash:
|
|
|
|
| run | COMPLETE | crash | delta | props spawned | props -> crash |
|
|
|---|---|---|---|---|---|
|
|
| 24 (21:28) | 32.50 s | 21:28:33 | ~12 s | 28.41 s | ~16.6 s |
|
|
| 25 (21:44) | 100.50 s | 21:44:55 | ~13 s | 96.31 s | ~16.7 s |
|
|
|
|
So it is a timer that fires ~12 s after the room finishes loading, not something the player
|
|
does: in run 24 the client sat in the room on heartbeats, in run 25 the watch menu was open.
|
|
|
|
**The one thing that actually differs between the room that crashes and the room that does
|
|
not is prop binding.** RecCenter logs, once, at scene-setup time:
|
|
|
|
```
|
|
[RecCenter_Chair] / [Chair_White_Stationary] / [RecCenter_Couch] (N)
|
|
has an RigidbodyEx but no EmbodiedObject/RbexEntity/TransformEntity component
|
|
```
|
|
|
|
Exactly 35 in both crashing runs; **zero** anywhere in the dorm (which shares the same log).
|
|
Those objects exist in the Unity scene with a `RigidbodyEx` and are missing the ECS
|
|
companions the ObjectModel needs. `Tool::ResetToDefaultCollisionLayer` iterates exactly that
|
|
state - a tool's collision-layer component set - which is why it is the code that dies.
|
|
|
|
**Run 25b's A/B aimed at the wrong key.** `ObjectModel_EnableForRoom_2022_07_01` never
|
|
reaches the client's ObjectModel path - it does not appear in `Player.log` at all. The gate
|
|
the client actually reads is the GameConfig family, served from the DB and logged at boot:
|
|
|
|
```
|
|
GameConfig 'UGC.ObjectModel.Allowed' = True (DB row: UGC.ObjectModel.Allowed = true)
|
|
GameConfig 'UGC.ObjectModel.AllowedInRoomV1' = True
|
|
GameConfig 'UGC.ObjectModel.ScalabilityAllowed' = true, .R2Allowed = true, .DormAllowed = false
|
|
```
|
|
|
|
and the load log shows the path being taken, for the dorm as well as for RecCenter:
|
|
|
|
```
|
|
[DATA_DOWNLOADED] Fetched Deserialization Data...
|
|
START: UnloadSceneToEnableObjectModelTask
|
|
Checking for Object Model Enabled flag...
|
|
[Moving to phase INIT_OBJECTMODEL...] -> [MoveToPhase(INIT_OBJECTMODEL)]
|
|
```
|
|
|
|
`Disallowed` therefore proved nothing about ObjectModel: the model ran anyway. Note the
|
|
seeded `UGC.ObjectModel.*` values (incl. `DormAllowed = false`) are the reference's, so
|
|
ObjectModel-on-for-rooms is the authentic August-2023 configuration, not drift of ours.
|
|
|
|
**Where the room data should have come from.** The load's `[Downloading Data]` report for
|
|
RecCenter:
|
|
|
|
```
|
|
[AssetBundle_Download] 0.01ms | [SubRoom_Download] 0.01ms
|
|
[SuperRoom_Download] 0.00ms | [PlayerSave_Download] 4.00ms
|
|
```
|
|
|
|
`SubRoom_Download` is a no-op, consistent with every subroom `DataBlob` being empty. If the
|
|
prop -> ECS bindings normally arrive with the sub-room save, an empty save is precisely what
|
|
leaves scene props with a `RigidbodyEx` and no `EmbodiedObject`/`RbexEntity`/`TransformEntity`.
|
|
|
|
Open, in order of expected value:
|
|
|
|
1. Serve a real RecCenter sub-room save (or otherwise complete the prop bindings) and see
|
|
whether both the 35 bind errors and the AV disappear - this tests the cause directly.
|
|
2. A/B `UGC.ObjectModel.Allowed=false` (+ `AllowedInRoomV1`) in the DB row: cheap,
|
|
reversible, and it removes the whole ECS object path. Divergence from the reference, so
|
|
treat it as a probe, not a fix.
|
|
3. Stopgap only: make `Tool::ResetToDefaultCollisionLayer` (0x1201e32..0x1201e90) a no-op
|
|
from the client plugin. Removes the crash without fixing the corrupt entity, so the tool
|
|
simply never gets its collision layer restored.
|
|
4. Separate bug: fix our `/rooms/rooms/{id}/similar` payload shape so the RRUI carousel
|
|
stops failing with `Error refreshing rooms from source RoomSimilarity`.
|
|
|
|
## Run 27 (2026-09-24 22:22, tool guard deployed): no crash - and the join NRE named
|
|
|
|
Player.log 22:22:34 -> 22:36:23 (~832 s, no crash), `LogOutput.log` carries 9 `[ToolGuard]`
|
|
skips, all of them game-role nodes and shape containers (`[GameRoleNode]_INJHAOJMPFF_*`,
|
|
`[StandaloneShapeContainer](Clone)`) rather than the RecCenter chairs, and **zero**
|
|
`has an RigidbodyEx but no EmbodiedObject/RbexEntity/TransformEntity component` lines - every
|
|
run that dies has exactly 35. Three joins:
|
|
|
|
| time | target | result |
|
|
|---|---|---|
|
|
| 22:22:42 | dorm 25/32, instance 20886 | COMPLETE |
|
|
| 22:29:51 | room 54/57, instance 20887 | COMPLETE |
|
|
| 22:30:17 | dorm 25/32, instance 20888 | **FailedToSpawnPlayer (8718)** |
|
|
|
|
The third is the room bug the guard did not cover: the load walks every phase to
|
|
`SCENE_LOADED`, then dies inside `SETUP_ROOM_OBJECTS`.
|
|
|
|
```
|
|
[471.4358] Starting RunFor.All handler 729481d6-1503-47c8-b401-f98f736a13f2 (1 handlers)
|
|
[471.4486] [Error | RoomOperation] Error during operation InitialRoomLoad-a820aca0-...:
|
|
Object reference not set to an instance of an object.
|
|
[471.4830] Reporting result FailedToSpawnPlayer / (Code 8718) to RecNet Matchmaking ...
|
|
```
|
|
|
|
Stack (managed frame bottom of the throw):
|
|
|
|
```
|
|
EMKMMPEIGLD.FACCFIGFBIP(IEnumerable<T>)
|
|
EMKMMPEIGLD.HLLNBBPLCAH(Tuple<T1,T2,T3>)
|
|
KOGBHMMNAJA1.EIAKBDPCFOD(Action1) <- broadcaster
|
|
EMKMMPEIGLD.KOIPGJONEBE(LPPEEGCNOPD, CancellationToken)
|
|
IGOEMHGCPBC2+DGLCCMDLGNI.Invoke(request, ct)
|
|
AGCMEKDMOEG+PAIKPNCMAPO.<<InvokeMethodsInParallel>b__2>d.MoveNext()
|
|
AGCMEKDMOEG.FFAFPFAGKDH(Guid, List, IEJHLHGIEFP, LPPEEGCNOPD, CancellationToken)
|
|
<<LoadRoomLocal>b__0>d.MoveNext()
|
|
```
|
|
|
|
Two frames above the NRE:
|
|
|
|
```
|
|
[22:30:15] Operation SaveRoom sent. Waiting...
|
|
[22:30:15] Unobserved exception throw ... BDADBLBKLJN.OABJEHOGBIM(GKENAAINMOP)
|
|
[22:30:17] Error during operation RoomSave-6ad9514c-...: Object reference not set to an
|
|
instance of an object.
|
|
```
|
|
|
|
Both sites resolve by name without a crash dump: `grep -la EMKMMPEIGLD
|
|
BepInEx/interop/*.dll` answers **`RecRoom.Keepsakes.Runtime.dll`**, and `BDADBLBKLJN` is
|
|
`RecNet.Runtime.dll`. So the handler that faults a room load is the **keepsake runtime's**:
|
|
|
|
* It runs in `SETUP_ROOM_OBJECTS`, again in `RUN_MIGRATIONS`, again in
|
|
`POST_DESTROY_OLD_OBJECTS` - one `729481d6` per keepsake pass - and the identical NRE is
|
|
thrown on the loads that *survive* (22:22:49.5, 22:29:59.0) as an unobserved task exception.
|
|
Chronic, and fatal only when it lands inside the phase run.
|
|
* Its fetches line up exactly: `GET /api/keepsakes/rooms/25` + `categories` + `globalconfig` at
|
|
22:22:48.988, `GET /api/keepsakes/rooms/54` at 22:29:58.388. The failed load at 22:30 makes
|
|
**no keepsake request at all** - it dies before/inside that pass.
|
|
|
|
What we were serving, and what the reference serves (`apps/api/src/routes/gameplay.ts`):
|
|
|
|
| route | ours (run 27) | reference |
|
|
|---|---|---|
|
|
| `GET /api/keepsakes/rooms/{id}` | 200 `{FIOFPPHNMHM:[],EBKHAGMFFEK:[],OFNJMGKKKJP:[]}` (69 b) | **204, no body** - "the client treats a body here as data" |
|
|
| `GET /api/keepsakes/categories` | counted set with one fabricated keepsake (`IIILIMOMKDK`...) | `{Results:[],TotalResults:0}` |
|
|
| `GET /api/keepsakes/globalconfig` | `{NPCHGMEHAPA:true,NEFKKONMGJI:100,PJMJGIKKGJB:true}` | `{KeepsakeFeatureEnabled:true,KeepsakeRoomLimit:10,SocialXpBoostEnabled:false}` |
|
|
|
|
The reference's note on `categories` is the same failure mode one layer down: the client parses
|
|
it as an object and "an array fails it outright - expected:'{', actual:'[', at offset:0,
|
|
logged as 'Failed to get keepsake categories' - **which takes the keepsake load down with
|
|
it**". Fabricated entries with guessed obfuscated field names are that same class of input: a
|
|
keepsake the client resolves that exists nowhere.
|
|
|
|
**Fix (server, this run).** `Server/API/Keepsakes/KeepsakesAPI.cs` now answers exactly what the
|
|
reference does - 204 with no body for a room's keepsakes, an empty counted catalog, and the
|
|
client's own field names on the config. Tests pin all three shapes
|
|
(`StartupApiCompatibilityTests`: empty catalog, `NoContentResult`, config names).
|
|
|
|
**Fix (server, same session).** The save that preceded the failure also faulted, and the
|
|
session's only subroom save (`POST /rooms/rooms/54/subrooms/57/data`, 200, 5718 b) is the call
|
|
it followed. The reference is explicit that this response is the one envelope the client reads
|
|
differently:
|
|
|
|
> `value` is `{ room, subRoomDataSave }`, and `error` is NULL rather than `""`. The
|
|
> `subRoomDataSave` is camelCase with a different field set from the PascalCase `CurrentSave`
|
|
> embedded in the room ... Don't unify the two projections.
|
|
|
|
We were serving the room's `CurrentSave` there - PascalCase, with none of `unityAsset`,
|
|
`unityAssetHash` or the echoed `dataBlobHash`. `RoomUtils.BuildSaveResponse` now serves the
|
|
documented projection (and `dataBlobHash` is read off the save body and echoed), while the
|
|
room's own `CurrentSave` is untouched. The other documented trap in this path is fixed too: a
|
|
subroom carries `CreatorAccountId`, null until its first save and the saver's id after - "the
|
|
client NREs on a null one" - which we did not send at all.
|
|
|
|
Tests: 560 pass, including `SaveAcceptsTheJsonEnvelopeThe2023ClientPosts` (now asserting the
|
|
camelCase save + a non-null subroom creator), `SaveResponseEchoesTheBlobHashItWasGiven`, and
|
|
`AnUnsavedSubRoomReportsNoCreator`.
|
|
|
|
Server relaunched (development environment, cwd `Server/`, `server-console-run28.log`), and the
|
|
new shapes verified live: `rooms/25 -> 204`, `categories -> {Results:[],TotalResults:0}`,
|
|
`globalconfig -> KeepsakeFeatureEnabled/RoomLimit 10/SocialXpBoost`.
|
|
|
|
**How to read the next run.** The join is fixed if `729481d6` completes on the dorm load and the
|
|
post-load keepsake pass stops throwing:
|
|
|
|
```bash
|
|
grep -c "Unobserved exception" Player.log
|
|
grep -n "729481d6" Player.log
|
|
curl -sk -o /dev/null -w '%{http_code}\n' https://localhost:3030/api/keepsakes/rooms/25 # 204
|
|
```
|
|
|
|
Still open: the missing SignalR `UnsubscribeFrom` the client calls on every transition
|
|
(`autoloc.job`, `HubException: Method does not exist`), and real keepsake storage - the emptied
|
|
catalog means no keepsake can be placed until it exists.
|
|
|
|
## Run 28 (2026-09-24 23:25, live): the watch page's missing buttons are two missing routes
|
|
|
|
The watch's "This Room" tab makes exactly three requests as it opens, and the middle one was the
|
|
only failure:
|
|
|
|
```
|
|
[23:27:18.014] GET /rooms/rooms/25/interactionby/me -> 200 len=47
|
|
[23:27:18.031] GET /rooms/rooms/25/experience -> 404 len=0
|
|
[23:27:18.097] GET /images/default.png?width=1024 -> 200 len=80001
|
|
```
|
|
|
|
The tab renders with SETTINGS alone - no LOAD, no SAVE ROOM, no ROOM STATS, no subroom (room
|
|
list) button. The client logs each failure as a crash-report line
|
|
(`OBHEMJEJNMK: HTTP Error 404` through `GFIBIELMKBM+<>c__27`1[TResponse].NOFENLOLAIH`), 10 of
|
|
them in the session against 12 `rooms/rooms/25/experience` 404s, and it keeps re-asking rather
|
|
than settling.
|
|
|
|
Not permissions: the room payload already reports the viewer's role
|
|
(`Roles: [{"AccountId":2,"Role":255,...}]`, 255 = Creator) and `CreatorAccountId: 2` - which
|
|
is also how the subroom `CreatorAccountId` added in run 27 shows up on the wire.
|
|
|
|
Neither `rooms/{id}/experience` nor `rooms/{id}/experience/player` existed on our server at all.
|
|
The reference's note on the player half is the cost of that: nothing tracks per-room progress, so
|
|
it serves an empty list - "**which the client reads as 'no progress in this room', where a 404
|
|
would stall the room load**" - and the settings half is a bare two-key object, `Enabled: false`
|
|
with `DailyLimit: 1000`, "the cap that WOULD apply ... the client reads both keys whatever
|
|
`Enabled` says". Both added to `V2_RoomsAPI` (`GetRoomExperience`, `GetRoomExperienceForPlayer`).
|
|
|
|
The other 404 on the same page is `econ/econ/roomGiftDropShops/room/{id}`, asked for on every
|
|
run (run 16 through run 28, 1-5 times each) and never once served. The reference answers an empty
|
|
list - "Empty stub so the client doesn't 404" - so `RoomGiftDropShopAPI` now does. It is the only
|
|
room-economy route this build asks for: `roomInventory`, `roomOffer`, `roomEconConfig` and
|
|
`ugcPurchasables` are never requested (checked across all six server logs), so no stubs for them
|
|
were added.
|
|
|
|
Tests: 563 pass, adding `RoomExperienceAnswersTheTwoKeysTheClientReads`,
|
|
`RoomExperienceForPlayerAnswersAnEmptyList` and `RoomGiftDropShopsAnswerAnEmptyList`. Server
|
|
relaunched (`server-console-run29.log`, cwd `Server/`), and every route verified live:
|
|
|
|
```
|
|
rooms/rooms/25/experience -> 200 {"Enabled":false,"DailyLimit":1000}
|
|
rooms/rooms/25/experience/player -> 200 []
|
|
econ/econ/roomGiftDropShops/room/25 -> 200 []
|
|
api/keepsakes/rooms/25 -> 204 (empty)
|
|
```
|
|
|
|
## Run 29 (2026-09-24 23:50, live): MakeItToMidnight imported, and what the create route dropped
|
|
|
|
`C:\RecRoom\Downloads\MakeItToMidnight` is a rec.net archive of the August 2023 RRO
|
|
MakeItToMidnight: `room_data.json` (the room, its one subroom "Home", and **100** revisions of that
|
|
subroom's save), `blobs/*.room` (137 MB, one scene blob per revision) and `image/*.png` (the
|
|
thumbnail). There is no Unity asset bundle in it and none is needed - a room's objects and prefabs
|
|
are shipped in the game build and a save only names them - so the subroom is imported with an empty
|
|
`UnityAssetId`.
|
|
|
|
Two things decide which revisions may be imported, and both belong to the client that has to open
|
|
them:
|
|
|
|
* `PersistenceVersion`. The revisions from this client's own build week (2023-08-21 through
|
|
08-28) are all **61** - one v63 on 08-21 aside - which is the schema the build writes; the 67
|
|
later ones climb 63, 64, 66, 68, 70, 72, 77, 87, 88, 103, 128 and 138 (the last from 2024-07) and
|
|
a newer save than the client can read is a room that opens broken. The taco importer's gate was
|
|
"38 or lower" because its archive was 2020-2022: the number is a property of the archive's era,
|
|
not a constant.
|
|
* `CreatedAt`, as the second net. **33 revisions pass** (2023-08-21T20:20 through 2023-08-28T21:00,
|
|
44 970 347 bytes).
|
|
|
|
The newest of those is the LIVE save and every other one is posted through the game's own save
|
|
route, so each lands in the subroom's history exactly as an ordinary save does - and each POST
|
|
pushes the revision it replaces into that history, which is what makes the whole list restorable.
|
|
The room is created on the OLDEST revision and walked forward, because whichever revision is posted
|
|
LAST is the one that stays live: creating it on the newest and then posting the older ones leaves
|
|
the room serving the second-newest save, which is what the first attempt did.
|
|
|
|
`tools/import_room_dump.mjs` runs it in resumable phases (`plan|upload|register|verify|redate`),
|
|
recording what it uploaded, created and posted in `artifacts/room-dump-import/<room>.json`. Blobs
|
|
keep the archive's own names (`5k1vmec9n5jf4dymy0zkjligj.room`), so a save in CDN storage stays
|
|
traceable to the dump it came from, and the `redate` phase re-stamps the revisions with the dates
|
|
the archive recorded - the save route stamps everything it records with the moment of the POST, so
|
|
the restore list would otherwise read "just now" 33 times and be useless to pick from.
|
|
|
|
Result: **room 55 / subroom 58**, owner 2, Public, `MaxPlayers` 5, `WarningMask` Scary (1), tagged
|
|
`import`, thumbnail `798fe98e05b944999ab8c76181f45367.png`, scene
|
|
`a75f7547-79eb-47c6-8986-6767abcb4f92` (Maker Room), and 33 saves carrying the archive's dates.
|
|
|
|
### What the import exposed in `admin/rooms/create/room`
|
|
|
|
The first create answered `Created as 55!` and the row was wrong: `Accessibility` 0 (Private),
|
|
`WarningMask` 0, `Tags` empty. The route reads its body through `JsonExtension.Get<T>`, which could
|
|
only read scalars:
|
|
|
|
* An **enum** is not a type `JsonValue.GetValue<T>()` knows, so it threw and the caller took its
|
|
fallback - every room created through this route came out Private with no warning mask, and
|
|
nothing in the response said a field had been dropped.
|
|
* A **collection** never got that far: `GetValue<object>()` on a JsonArray throws before the scalar
|
|
read, so the tag list fell back to empty. The taco importer's `Tags` never landed either.
|
|
* The bool path ("1" and "true" both mean true) was already there, but read its node through
|
|
`GetValue<object>()`, which hands back a `JsonElement` for a body parsed from JSON rather than an
|
|
`int` or a `string` - the check could not see either shape.
|
|
|
|
`Get<T>` now reads the node's own `JsonValueKind`, converts an enum from its number or its name,
|
|
deserializes a JsonArray/JsonObject whole, and keeps the bool spellings. Room 55's three fields were
|
|
corrected directly in SQL, because the running server could not be rebuilt mid-session: the live
|
|
client holds `Server/bin/Debug/net9.0/Server.dll`, so the verification build goes to
|
|
`.external/verify-build/bin/` (`-p:BaseOutputPath=...`) and the apphost exe is skipped entirely.
|
|
|
|
A second, separate bug in the same block: `loadScreen` is `NOT NULL` with a CLR default of `[]`, and
|
|
a payload without `LoadScreens` wrote **null** over that default - the insert failed with a
|
|
required-property error, a 500 for any import that did not happen to send an empty list.
|
|
|
|
Tests: **569 pass**, adding `AdminRoomCreateTests` - enum binding by number and by name, the bool
|
|
spellings, the tag list with its tag types, the defaults an absent field still gets (including
|
|
`loadScreen`), the subroom's scene and blob, and the Maker Room fallback for a scene the client does
|
|
not know.
|
|
|
|
### Verified in the client
|
|
|
|
The live session had already found the room by the time the import finished:
|
|
|
|
```
|
|
[23:57:23] GET /images/798fe98e05b944999ab8c76181f45367.png -> 200
|
|
[23:57:25] GET /rooms/rooms/55?include=5421&unityAssetTarget=0&unityAssetVersion=1 -> 200
|
|
[23:57:35] GET /cdn/room/5k1vmec9n5jf4dymy0zkjligj.room -> 200 len=1373747
|
|
Player joined ^MakeItToMidnight in scene "Maker Room" with playerCount 1
|
|
[RoomLoad.RoomManager] -- Initial Room Load '^MakeItToMidnight' (55.58) [instance 20907] --
|
|
[23:57:49] Moved to phase COMPLETE
|
|
```
|
|
|
|
The load walks every phase through `SETUP_ROOM_OBJECTS`, `RUN_MIGRATIONS` and
|
|
`DestroyAndRebuildObjects`, with **0** occurrences of the
|
|
`no EmbodiedObject/RbexEntity/TransformEntity component` prop-bind error that ran at 35 for the
|
|
RecCenter, and 0 `FailedToSpawnPlayer`. The only errors after the join are the room's own circuits
|
|
(`CircuitsV2Errors`, "Studio Object is invalid!") alongside the guard's 25 `ToolGuard` skips.
|
|
|
|
One note for the next restart: the fixed `Server.dll` is **not** in `Server/bin/Debug/net9.0/` yet,
|
|
because the running server holds it. A plain `dotnet build ServerTests/Server.Tests.csproj -c Debug`
|
|
once the client closes picks it up, and nothing about room 55 depends on it.
|
|
|
|
## Run 30 (2026-09-25 00:00, live): the portfolio "crash" is the anti-cheat's dorm drop
|
|
|
|
Clicking your own portfolio closed the game. It is not a crash: Windows recorded **no**
|
|
`RecRoom.exe` fault either side of it (the last one is 22:09:19, the pre-ToolGuard
|
|
`GameAssembly.dll+0x470728d`), and the process ran the game's own shutdown instead -
|
|
`[EAC] Tearing down and releasing runtime`, then `Trying to send photon room updates to server
|
|
while application is quitting`. What Player.log has at 00:01:05 is the answer:
|
|
|
|
```
|
|
[00:01:05] [Warning] [Default | Warning] Dropping to dormroom due to error [385120]
|
|
[00:01:06] [Log] [Unity] [EAC] Tearing down and releasing runtime
|
|
```
|
|
|
|
and `BepInEx/LogOutput.log` has the chain, one millisecond wide:
|
|
|
|
```
|
|
[CheatTrace] +244681ms CheatManager.OnObscuredTypeCheatDetected
|
|
[CheatTrace] +244682ms CheatManager.EFLCHFDDPJP
|
|
[HileGate] anti-cheat report captured (full wire form): body: Message=&Type=0
|
|
[Net] Post https://localhost:3030/api/PlayerReporting/v1/hile -> 200 body=true
|
|
[QuitVeto] wantsToQuit answered false (block #1) - this is the anti-cheat shutdown
|
|
```
|
|
|
|
`CheatManager.EFLCHFDDPJP(string reason = "Dropping to dormroom due to error [385120]")` is the
|
|
whole of the message, and that string is the PARAMETER'S DEFAULT VALUE - `385120` is not an error
|
|
code, it names nothing, which is why every drop in every session reports the same number. Its
|
|
caller is the obscured-type handler, and what the page does to trip it is in the server log: the
|
|
profile renders the caller's own custom avatar items, and
|
|
`GET /api/customAvatarItems/v2/fromCreator/2` is fetched 7 times in 10 ms immediately before the
|
|
detection (`00:01:03.921`-`00:01:05.699`).
|
|
|
|
The server side of that page is faithful and stays as it is: `/accounts/account/2/bio` 200,
|
|
`/api/customAvatarItems/v2/fromCreator/2` 200 with the reference's empty page,
|
|
`/accounts/accountprivacysettings/2` 200, `/rooms/rooms/ownedby/2` 200, and 404 with an empty
|
|
body on both influencer routes - which is the reference's own answer for "not an influencer",
|
|
not a gap.
|
|
|
|
So the verdict is removed at its source, exactly as the file scan was in run 23d, and the result
|
|
is already deployed (`BepInEx/plugins/RadicadeAugustClient.dll`, 62464 b, md5
|
|
`8718a45dd42d7cb72b3e46e04b744d91`, backup `.before-run30b-cheatdrop`):
|
|
|
|
* `CheatDetectionSuppressPatch` - skips all three verdict handlers
|
|
(`OnObscuredTypeCheatDetected`, `OnTimeCheatDetected`, `OnAdvancedMovementCheatDetected`), not
|
|
just the one that fired. Skipping only the obscured one would leave the other two live for
|
|
whatever a clock-skewed or laggy machine trips next. A handler that does not resolve is logged
|
|
and skipped rather than thrown on - the throw would take the whole patch block (exit veto
|
|
included) down with it - and the startup line prints `verdict handlers guarded=3` (or names the
|
|
unguarded one). `RADICADE_CHEAT_TYPE=0` restores the detections.
|
|
* `CheatDormDropGuardPatch` - holds the drop itself back, narrowly: only when the reason contains
|
|
`385120`, the anti-cheat's own default. Any other reason still drops the player, so a genuine
|
|
room failure behaves as before. `RADICADE_CHEAT_DROP=0` lets every drop run.
|
|
|
|
Both are registered in their own try/catch, so a resolution failure on a different build cannot
|
|
undo the exit veto, the exit tracer or the hile gate applied above them.
|
|
|
|
## Run 30, second half: `rooms/rooms/{id}/similar` answered a bare array
|
|
|
|
The "Similar Rooms" rail is a paged DTO in this client, and the route answered
|
|
`Array.Empty<object>()` - `Malformed Response: '[]'` in Player.log, one of 9 in the session
|
|
(and 5 in the one before). A room that did not exist was a 404 on top of that, which stalls the
|
|
screen the rail sits on rather than emptying one row. `GetSimilarRooms` now returns
|
|
`RoomSearchResult` (scored by shared tags, same creator as the fallback for untagged rooms,
|
|
visibility checked per candidate, unknown room = empty page) and pages `skip`/`take`.
|
|
`ServerTests/SimilarRoomsTests.cs` pins the envelope, the empty page, the paging and the
|
|
visibility rule. **573 tests pass.**
|
|
|
|
`/econ/econ/roomGiftDropShops/room/{id}` (`[]`), `/rooms/rooms/{id}/experience/player` (`[]`) and
|
|
`/econ/api/roomkeys/v1/room` (`[]`) were each checked against the reference while chasing the
|
|
remaining `Malformed Response: '[]'` lines: all three are documented there as empty lists, so the
|
|
chronic parse errors are not from them and are left alone for now - they are logged, not fatal.
|
|
|
|
### The restart, and the one trap in it
|
|
|
|
The server was rebuilt and relaunched for the `similar` fix (`server-console-run30.log`, cwd
|
|
`Server`, PID 33272). Launching the exe directly from `Server/` picks up **`appsettings.Production.json`**
|
|
- `Hosting environment: Production`, a different `JwtKey`, no HTTPS listener on 3030 and no Photon
|
|
app ids, which would break the client at the room join. The launch must carry the environment:
|
|
|
|
```
|
|
$env:ASPNETCORE_ENVIRONMENT='Development'
|
|
Start-Process ...\Server\bin\Debug\net9.0\Server.exe -WorkingDirectory ...\radicade-server\Server
|
|
```
|
|
|
|
and the log has to read `Now listening on: https://localhost:3030` **and**
|
|
`Now listening on: http://127.0.0.1:3031` **and** `Hosting environment: Development`. Live
|
|
after the restart:
|
|
|
|
```
|
|
rooms/rooms/55/similar -> 200 {"TotalResults":0,"Results":[]}
|
|
rooms/rooms/99999/similar -> 200 {"TotalResults":0,"Results":[]} (was 404)
|
|
rooms/rooms/ownedby/2 -> 200 len=5950
|
|
api/customAvatarItems/v2/fromCreator/2 -> 200 {"Results":[],"TotalResults":0}
|
|
```
|
|
|
|
(`Authorization: Bearer` needs a token signed with the Development `JwtKey`; `?access_token=` is
|
|
only honoured on notify-hub paths, which is why a copied client token reads as 401 here.)
|
|
|
|
## Run 31: the room's Unity asset bundles, uploaded and bound
|
|
|
|
The August build's `MakeItToMidnight` import had no `UnityAssetId` because the room dump
|
|
(`C:\RecRoom\Downloads\MakeItToMidnight`) carries no bundle - the importer's note is right, and
|
|
`tools/import_room_dump.mjs` says the same thing: the save only *names* the content and the bytes
|
|
live elsewhere. The bytes turned up separately, in `C:\RecRoom\Downloads\AssetBundles`: 87
|
|
`*.assetbundle` files plus one 546 KB `.room`, no manifest, no index.
|
|
|
|
### What the archive actually is
|
|
|
|
The files are named by their CDN blob name and carry the CDN's own timestamps, and those two facts
|
|
recover the whole structure. Group by upload time and each group is **one publish event**: Rec Room
|
|
uploads one bundle per target, seconds apart, and every bundle in a group carries the same
|
|
`container` path, which names the room it was built for.
|
|
|
|
```
|
|
2023-08-21 13:10 n=7 333.3 MB Assets/RoomSource/Assets/Rooms/MakeItToMidnight/MakeItToMidnight-Home.unity
|
|
2023-08-22 10:34 n=7 333.4 MB ...
|
|
2023-08-23 12:48 n=7 333.3 MB ...
|
|
2023-09-12 18:49 n=6 308.2 MB ...
|
|
```
|
|
|
|
Two rooms are in there (`MakeItToMidnight`, 12 batches, and `KOdByDawn`, 3), across Unity revisions
|
|
`2020.3.33f1` (the August 2023 build - the only one this client can load), `2021.3.29f1` and
|
|
`6000.0.27f1`. `SerializedFile.target_platform` separates the targets inside a batch, and the
|
|
texture formats confirm what the numbers mean: `9` and `13` carry ASTC (iOS and Android - twice, a
|
|
phone and a Quest build both report Android), while `5`, `31`, `43` and `44` carry BC/DXT
|
|
(`StandaloneWindows` and the consoles). Each publish costs ~333 MB across targets; `5` alone is
|
|
~85 MB.
|
|
|
|
The bundle is not optional decoration. The 08-23 Android bundle alone holds 8080 objects - 1490
|
|
GameObjects, 1366 meshes, 1255 MonoBehaviours, 291 textures, 171 AudioClips - and the names in it
|
|
(`Survivor 1`, `[PerkIcon]`, `PhotoBooth_Curtain*_LOD*`) are the names the room save builds its
|
|
object tree from. A subroom with an empty `UnityAssetId` loads the save against whatever the build
|
|
itself ships, which is exactly why the room opened as a Maker Room with its content missing.
|
|
|
|
### Which bundle belongs to the live save
|
|
|
|
The live revision is the newest v61 save, `5k1vmec9n5jf4dymy0zkjligj.room` (2023-08-28T21:00Z), and
|
|
the dump records the asset id it advertised: `32cafb11-c51b-485c-8f1f-73b73159feff`. The dump is the
|
|
only place that id appears, so the batch it names was pinned by time, and the pinning is exact once
|
|
the archive's clock is accounted for - its zip entry times are the CDN's **local** wall clock,
|
|
exactly 7 h behind the UTC `CreatedAt` the saves carry:
|
|
|
|
```
|
|
unityAssetId first saved publish batch delta
|
|
bd362d85-6cc5-4b6f-9d3b-33774e3938aa 2023-08-21T19:59:45 2023-08-21 13:10 +11 m
|
|
14c842e7-01f0-4b81-9d03-19f39b7393d0 2023-08-21T20:20:28 2023-08-21 13:10 -10 m
|
|
20e15a8f-faca-41dc-8025-dd7da5c3cd0c 2023-08-22T17:25:32 2023-08-22 10:34 +9 m
|
|
3fb814c1-271e-4e54-960e-d6298947baaa 2023-08-22T17:27:21 2023-08-22 10:34 +7 m
|
|
32cafb11-c51b-485c-8f1f-73b73159feff 2023-08-23T19:39:06 2023-08-23 12:48 +10 m
|
|
```
|
|
|
|
So `32cafb11` is the 2023-08-23 publish, and in that batch the desktop bundle is
|
|
`d7ftni8391e3nrdts2drs4qlb.assetbundle` - `StandaloneWindows`, `2020.3.33f1` (the client's own
|
|
revision), 85,232,592 bytes, md5 `31b4faa66491de6106ce748a457f9905`. Two saves share that id
|
|
because the later revisions (2023-08-24..28) changed the room without republishing content, so one
|
|
bundle serves them all - which is also why the earlier ids matter only for history restores.
|
|
|
|
### Uploaded and bound
|
|
|
|
The client resolves a bundle in two steps - `GET /rooms/unity_assets/{assetId}/{target}/{version}`
|
|
returns `{UnityAssetId, Target, Version, Filename}`, and the bytes come from `/data/{Filename}` -
|
|
and `UnityAssetsCDN.ResolveFilename` looks for a file named exactly the id (or the id plus
|
|
`.assetbundle`) in the CDN storage directory. So the file is stored under the id the save
|
|
advertises, and the room's subroom points at that id:
|
|
|
|
```
|
|
Server/RadicadeServer-Data/CDN/Storage/32cafb11-c51b-485c-8f1f-73b73159feff.assetbundle 85232592 b
|
|
Server/RadicadeServer-Data/CDN/Storage/32cafb11-c51b-485c-8f1f-73b73159feff hard link
|
|
UPDATE SubRooms SET UnityAssetId='32cafb11-c51b-485c-8f1f-73b73159feff' WHERE SubRoomId=58;
|
|
```
|
|
|
|
Both spellings are stored because the loader reaches for the bytes two ways: the metadata route
|
|
hands the client a `Filename` that it fetches from `/data/{Filename}`, and the CDN path for a
|
|
bundle is `/unity/{id}` - the id with no extension. `ResolveFilename` checks the bare id first, so
|
|
the extensionless name is what the metadata reports; the hard link costs no disk and covers the
|
|
route that asks by id.
|
|
|
|
Verified against the running server (cwd `Server`, PID 33272 - the storage directory the server
|
|
reads is `Server/RadicadeServer-Data/CDN/Storage`, not the one at the repo root):
|
|
|
|
```
|
|
GET /rooms/unity_assets/32cafb11-.../0/1 -> 200 {"UnityAssetId":"32cafb11-...","Target":0,
|
|
"Version":1,"Filename":"32cafb11-..."}
|
|
GET /data/32cafb11-... -> 200 len=85232592 Accept-Ranges: bytes
|
|
GET /data/32cafb11-... (Range) -> 206 Content-Range: bytes 0-15/85232592
|
|
GET /rooms/rooms/55?include=5421&unityAssetTarget=0&unityAssetVersion=1
|
|
-> CurrentSave.unityAssetId = 32cafb11-c51b-485c-8f1f-73b73159feff
|
|
```
|
|
|
|
The `unityAssetTarget=0` the client sends is RecNet's own target list, not the SerializedFile
|
|
platform id the bundle carries: the server answers the id with one file, so the target in the query
|
|
does not have to be matched to the target in the bundle.
|
|
|
|
### The tool, so the next room is one command
|
|
|
|
`tools/import_room_bundles.py` does the three steps above and is what produced the tables in this
|
|
section:
|
|
|
|
```
|
|
python tools/import_room_bundles.py inventory --source ".../AssetBundles" --zip ".../AssetBundles.zip"
|
|
python tools/import_room_bundles.py plan --source ... --zip ... --dump ".../MakeItToMidnight/room_data.json" \
|
|
--room MakeItToMidnight
|
|
python tools/import_room_bundles.py bind --asset-id 32cafb11-... --batch 2023-08-23 \
|
|
--source ... --zip ... --subroom 58 --apply
|
|
```
|
|
|
|
`inventory` probes every bundle (platform, room container, Unity revision, object count) and groups
|
|
by publish batch - 2m37s for all 87, written to `artifacts/asset-bundles.json`. `plan` pairs a room
|
|
dump's asset ids with batches using the clock alignment above, and flags a pairing an hour or more
|
|
out as `DISTANT` rather than pretending to know it. `bind` copies the batch's `StandaloneWindows`
|
|
bundle into CDN storage under the id, points the subroom at it, and then runs the client's own
|
|
two-step resolution against the live server to prove it answers. The dump's own file name is
|
|
deliberately not the stored name - the id is what the client asks for - so the inventory JSON is the
|
|
record of which real blob each id was bound to.
|
|
|
|
`KOdByDawn` is in the same archive with three batches and is bound the same way if it is ever
|
|
imported. The remaining older ids can be bound too, for history restores that keep their own
|
|
content: `14c842e7` and `bd362d85` are the 2023-08-21 batch
|
|
(`a4al16vq0235oom5aplev2omu.assetbundle`), and `20e15a8f` / `3fb814c1` are 2023-08-22
|
|
(`esnrn95jqftokte3hmy8m1ffr.assetbundle`).
|
|
|
|
## Run 32 - the beta tag on room 55, and a room that is developer-owned when the maker is a dev
|
|
|
|
### Room 55 does not carry `beta`
|
|
|
|
`Rooms.Tags` for room 55 is `import,0` - one entry, `import` at `TagType.General`. There is no
|
|
`beta` entry, so the room does not advertise itself as beta-enabled the way the imported Showdown
|
|
room does (`rro,2|games,0|beta,1`, `TagType.Auto`).
|
|
|
|
Two things worth keeping, because they explain the value rather than just reporting it:
|
|
|
|
- The importer wrote it. `tools/import_room_dump.mjs:228` stamps every imported room with a
|
|
hardcoded `[{ Tag: 'import', Type: 0 }]`, so whatever the real room carried was overwritten at
|
|
import time - this is a latent bug for every room imported that way, not a fact about
|
|
MakeItToMidnight.
|
|
- The archives cannot tell us what the original tags were. All 48 captured room JSONs in
|
|
`rooms.zip` (`more rr rooms/*/room_*.json`) carry **no room-level `Tags` field at all** - the
|
|
exporter drops it - and the `MakeItToMidnight/room_data.json` dump only has save-level
|
|
`Tags: []`, which is unrelated.
|
|
|
|
Nothing server-side branches on the room-level tag: `grep '"beta"' Server/**.cs` finds only the
|
|
comment in `Program.cs:564`, and the tag is pure pass-through (`FullRoom.CopyTo` copies `Tags`
|
|
straight into the room payload) with the client acting on it. Beta creative-tools *creation* is
|
|
already enabled globally by `EnableBetaCreativeToolsConfigs` (`UGC.AllowBetaInvertedTubeCreation`,
|
|
`UGC.AllowNonBetaInvertedTubeCreation`, `UGC.EnableInventionsInBetaRooms`, `UGC.Room2Enabled`), so
|
|
the missing tag is not what keeps beta content from loading. To match the real room anyway:
|
|
|
|
```sql
|
|
UPDATE Rooms SET Tags = 'import,0|beta,1' WHERE RoomId = 55;
|
|
```
|
|
|
|
Left unapplied - the user only asked whether it was there.
|
|
|
|
### `IsDeveloperOwned` was never in the room payload
|
|
|
|
The 2023 client's room parser has the field (it is in the August metadata dump, and in the captured
|
|
RecNet responses: `"IsDeveloperOwned": true` on a developer's room), but `FullRoom` did not declare
|
|
it at all, so **every** room on this server read as not-developer-owned and the client's Dev Rooms
|
|
row stayed empty however the rooms were made.
|
|
|
|
Where a room is made matters: there is no create-room route. A player creates a room by
|
|
`POST /rooms/rooms/{id}/clone` (`RoomServerAPI.CloneRoom` -> `RoomUtils.CloneRoom`), which is the
|
|
same method `GetOrCreateDorm` uses to make a dorm - so the flag has to come from the maker's roles
|
|
and has to exclude dorms.
|
|
|
|
What changed:
|
|
|
|
- `RoomData.IsDeveloperOwned` (bool, default false) - a column on `Rooms`, `bit NOT NULL DEFAULT 0`.
|
|
- `Room.IsDeveloperOwned` - declared on the response base, so it is emitted for room lists and room
|
|
details alike, as `IsDeveloperOwned` (Program.cs pins the serializer to no naming policy, the
|
|
same PascalCase the real API answers with).
|
|
- `RoomUtils.CloneRoom` stamps it: `!room.IsDorm && await ctx.IsDeveloper(newCreator)`.
|
|
- `RoomUtils.ConvertToFull` and `FullRoom.CopyTo` carry it to the payload.
|
|
- `AdminRoomAPI.CreateRoom` (the import route) honours an explicit `IsDeveloperOwned` in the body -
|
|
a captured RRO room is developer-owned on the real service even when it is recreated here under a
|
|
local owner - and otherwise derives it from the owner it is being created for.
|
|
- `EnsureRoomDeveloperOwnedColumn` on boot, same self-heal pattern as `UnityAssetId` and the
|
|
join-gift columns: EF maps the property onto every `Rooms` query, so the column has to exist
|
|
before any startup step reads a room.
|
|
|
|
Verified live against the restarted server (PID 38436, `server-console-run32.log`, Development,
|
|
3030 + 3031). The column is in place and the payload carries the field:
|
|
|
|
```
|
|
GET /rooms/rooms/55?include=5421... -> IsDeveloperOwned: false
|
|
GET /rooms/rooms/23 -> IsDeveloperOwned: false
|
|
GET /rooms/rooms/25 -> IsDorm: true, IsDeveloperOwned: false
|
|
```
|
|
|
|
Then both directions of the rule, through the client's own clone route, with tokens minted for the
|
|
two accounts on this server (2 `TestPlayer` = `developer,influencer`; 1 `Coach` = `influencer`):
|
|
|
|
```
|
|
POST /rooms/rooms/23/clone (name=DevOwnedProbe, account 2) -> RoomId 56, IsDeveloperOwned: true
|
|
POST /rooms/rooms/23/clone (name=PlainOwnedProbe, account 1) -> RoomId 57, IsDeveloperOwned: false
|
|
```
|
|
|
|
Both probe rooms were deleted again (`RoomRoles`, `RoomStats`, `SubRooms`, `Rooms`), leaving the 51
|
|
rooms that were there before. `dotnet test ServerTests/Server.Tests.csproj` -> **581 passed**
|
|
(573 before, +8 in `ServerTests/RoomDeveloperOwnedTests.cs`: a dev's clone, a plain player's clone,
|
|
a dev's dorm, the flag on the room that is read back, the explicit false in the payload, and the
|
|
three admin-import cases).
|
|
|
|
Every room that predates the column started false. The backfill was then applied, over the same
|
|
rule the create path uses (the maker's role, dorms excluded) - 5 rooms flagged, 46 left false:
|
|
|
|
```sql
|
|
UPDATE Rooms SET IsDeveloperOwned = 1
|
|
WHERE IsDorm = 0 AND CreatorAccountId IN (SELECT accountId FROM Profiles WHERE role LIKE '%developer%');
|
|
```
|
|
|
|
```
|
|
31 TestPlayers_MakerRoom_3528 52 studio-room-SdjyyctVdc 53 studio-room-NRyzI1_njb
|
|
54 TestPlayers_MakerRoom_1603 55 MakeItToMidnight (25 DormRoom - dorm, left false)
|
|
```
|
|
|
|
Room 55 is account 2's, so MakeItToMidnight became developer-owned along with the four the user
|
|
built - which is also what the real service says about that room. It is a data-only change, so the
|
|
running server picked it up without a restart; the detail route and the bulk list route the
|
|
client's own room lists read both answer it:
|
|
|
|
```
|
|
GET /rooms/rooms/55?include=5421... -> IsRRO: true, IsDeveloperOwned: true
|
|
GET /rooms/rooms/bulk?id=31..55 -> IsDeveloperOwned: true (x5)
|
|
GET /rooms/rooms/bulk?...&id=25 -> IsDorm: true, IsDeveloperOwned: false
|
|
```
|
|
|
|
## Run 33 - Showdown reimported, and the four-character bug that was skipping it
|
|
|
|
The request was that Showdown was "a little broken", and to delete and reimport it from a fresh
|
|
export at `C:\RecRoom\Downloads\Showdown`. The import ran, but the interesting part is *why*
|
|
the previous one had not: the boot importer was looking in a directory that does not exist here.
|
|
|
|
### What the export actually is
|
|
|
|
The folder is a RecNet export, not a captured room dump: `room.json` plus 22 per-subroom
|
|
directories, each carrying `room_data.json` and `Saves/<saveId>/<blobId>.room`. `Showdown.rar`
|
|
(46 MB, RAR5) holds the same tree. The export describes the *real* room 52815862 - `CreatorAccountId
|
|
1`, `Accessibility 1`, `IsRRO true`, `IsDeveloperOwned true`, `WarningMask 0`, `MaxPlayers 6`,
|
|
`CloningAllowed false`, `PersistenceVersion 150`, `CreatedAt 2022-03-03`, image
|
|
`65hs5cb56byqs05lu16kr3e8r.png`, and the description about Deputies and Bandits. 22 subrooms is
|
|
not 22 live subrooms: they are archive snapshots, all sharing the one scene
|
|
`a75f7547-79eb-47c6-8986-6767abcb4f92`, and they are named accordingly - `SD_Archive_001`,
|
|
`SD_Archive_082322`, `SD_Archive_11_29_2022_STABLE`, `SD_Archive_13_061824`, and so on. The single
|
|
subroom the server actually needs is the one every other room here has: one `Home` row pointing at
|
|
the scene and the save.
|
|
|
|
### The root cause: `room-imports` vs `RoomImports`
|
|
|
|
`EnsureShowdownRoom` looked for its files in `..\room-imports\Showdown` and `room-imports\Showdown`
|
|
- always lowercase. This checkout spells the directory `RoomImports`, and `Test-Path` answers
|
|
`False` for the lowercase spelling even though the tree is not case-sensitive as a whole. So the
|
|
lookup found nothing, the importer printed
|
|
`[Showdown] Skipped import - missing files ...` and returned on every single boot, and the room kept
|
|
whatever an older import had left behind. A silent skip is the worst kind of green: the log line is
|
|
there, but nothing above it looks like a failure.
|
|
|
|
The fix keeps the spelled-correctly path first and the old lowercase spellings after it (so a tree
|
|
where they do resolve, or a deployment that still ships that name, keeps working):
|
|
|
|
```csharp
|
|
var candidates = new[]
|
|
{
|
|
Path.GetFullPath(Path.Combine("..", "RoomImports", "Showdown")),
|
|
Path.GetFullPath(Path.Combine("..", "room-imports", "Showdown")),
|
|
Path.GetFullPath(Path.Combine("RoomImports", "Showdown")),
|
|
Path.GetFullPath(Path.Combine("room-imports", "Showdown")),
|
|
};
|
|
var sourceDir = candidates.FirstOrDefault(Directory.Exists) ?? candidates[0];
|
|
```
|
|
|
|
### Which save to install, and why the newest one is the wrong one
|
|
|
|
A room here is a bundle plus a save blob, and the two have to be the same revision or the client
|
|
loads a scene it has no data for. The bundle was already identified by hash:
|
|
`RoomImports/Showdown/Showdown_0_1.assetbundle` is 76,719,774 bytes, md5
|
|
`220891bc78b852df1c7ba8e1af0e9d1b`, and matches 24 metadata entries - among them asset
|
|
`58784cb3-204c-47e0-9cf3-23a76b94ae90` as **Unity_2020_3_33f1, Target 0, Version 1**. That asset
|
|
revision is the one the August client can load, and the save that goes with it is
|
|
`8u07n4iwzt4xbqkww7zun0jam.room` (2023-06-02, 1,222,161 bytes), the newest save whose revision is
|
|
still 2020.3.33f1.
|
|
|
|
The newest save in the export looks tempting and is a trap: the live `Showdown` subroom
|
|
(8785941127880372366) was last saved 2024-10-02 as `d39glazjteu2zztjuuulribr7.room` under asset
|
|
`d03c4c99-4814-412b-9594-f61851d32225`, and that asset exists only as 2021.3.29f1 / 6000.0.27f1 -
|
|
nothing a 2020.3.33f1 client can load. The previously installed blob was `e45vok0ppp89hda6n1xrm4z16.room`
|
|
(2022-10-18, the `SD_Archive_11_29_2022_STABLE` save), which is why the room was stale.
|
|
|
|
### The blob really is Showdown
|
|
|
|
Raw string overlap between the blob and the bundle is zero, so that proves nothing either way. But
|
|
the `.room` blob is protobuf, and walking its wire format for printable runs pulls out the room's
|
|
own content verbatim - `_SDLog_LocalPlayerSeesRedTeamValid`,
|
|
`_SDLog_LocalPlayerLooksForValidTeam`, `_Equipping gun index {0} to self`,
|
|
`_Not enough guns to give to self`, `_Tie Game!`, `Event Sender`/`Event Receiver`/`To Teams`. That is
|
|
Showdown's team-and-guns gameplay, and the `SD_` prefix on its own script log ids is the signature.
|
|
`artifacts/verify_showdown_blob.py` re-runs that walk against any blob.
|
|
|
|
### The swap: room 32 out, room 58 in
|
|
|
|
The old room was deleted (with its `RoomRoles`, `RoomStats`, `RoomInstances`, `RoomInteractions`,
|
|
`SubRoomHistory` and `SubRooms` rows - 51 rooms became 50), the era-matched save was put in place,
|
|
and the metadata was patched to match the export:
|
|
|
|
| field | old room 32 | new room 58 |
|
|
| --- | --- | --- |
|
|
| `Description` | `Showdown` | the Deputies/Bandits text |
|
|
| `ImageName` | `default.png` | `65hs5cb56byqs05lu16kr3e8r.png` |
|
|
| `MaxPlayers` | 16 | 6 |
|
|
| `CloningAllowed` | 1 | 0 |
|
|
| `IsDeveloperOwned` | backfilled true | true |
|
|
| `CreatedAt` | 2026-09-09 | 2022-03-03 |
|
|
|
|
Room 58's `Tags` were already `rro,2|games,0|beta,1` (the importer sets them) and its subroom 61 is
|
|
the one `Home` row: `UnitySceneId a75f7547-79eb-47c6-8986-6767abcb4f92`, `DataBlob Showdown.room`,
|
|
`UnityAssetId Showdown_0_1.assetbundle`, `MaxPlayers 6`, `Accessibility 1`. Nothing else in the
|
|
database still points at room 32 - every table that carries a `RoomId` was checked and all twelve
|
|
count zero rows for it.
|
|
|
|
### It survives a restart, which is the part that could have bitten back
|
|
|
|
The importer's `else` branch (room already exists) re-applies `IsRRO`, `Tags`, `subRoom.DataBlob`,
|
|
`subRoom.UnityAssetId` and `subRoom.UnitySceneId` on every boot, so those have to be checked against
|
|
what a restart would write. They are all already correct, and the scene is the subtle one:
|
|
`SceneLocations.MakerRoom` **is** `a75f7547-79eb-47c6-8986-6767abcb4f92`, the Showdown scene, so the
|
|
overwrite is a no-op. The fields that a restart would *not* touch - `MaxPlayers`, `Description`,
|
|
`ImageName`, `WarningMask`, `CloningAllowed`, `IsDeveloperOwned`, `CreatedAt` - are the ones the
|
|
patch above changed, so the importer's non-idempotent half does not undo any of it.
|
|
|
|
### Verified live (server PID 36096, run 33, Development)
|
|
|
|
```
|
|
GET /rooms/rooms/58 -> 200 Name=Showdown MaxPlayers=6 Accessibility=1
|
|
IsRRO=true IsDeveloperOwned=true IsDorm=false
|
|
CloningAllowed=false WarningMask=0
|
|
ImageName=65hs5cb56byqs05lu16kr3e8r.png
|
|
CreatedAt=2022-03-03T16:41:31
|
|
Tags=[rro,2][games,0][beta,1] SubRooms=1
|
|
GET /cdn/data/Showdown.room -> 200 1,222,161 bytes (the 2023-06-02 save)
|
|
GET /data/Showdown.room -> 200 1,222,161 bytes (range-capable alias)
|
|
GET /cdn/data/Showdown_0_1.assetbundle -> 206 range request, 100 bytes of 76,719,774
|
|
GET /rooms/unity_assets/Showdown_0_1.assetbundle/0/1 -> 200
|
|
{"UnityAssetId":"Showdown_0_1.assetbundle","Target":0,"Version":1,
|
|
"Filename":"Showdown_0_1.assetbundle"}
|
|
GET /images/img/65hs5cb56byqs05lu16kr3e8r.png -> 200 2,777,168 bytes
|
|
```
|
|
|
|
The room thumbnail needs no `Images` table row: room art is served straight from
|
|
`DBConfig.CDNImages` by name (`/images/img/{name}`), which is why the built-in rooms' `ImageName`
|
|
values are bare names like `Dodgeball`. Both HTTPS (3030, the port the client talks to) and HTTP
|
|
(3031) answer for the room and the asset metadata.
|
|
|
|
Backups kept: `RoomImports/Showdown/Showdown.room.before-run33` is the previous blob, and
|
|
`artifacts/showdown-room32-before-run33.txt` is the row-level snapshot of the deleted room.
|
|
|
|
## Handing the client patch to another machine
|
|
|
|
The August client patch is a **stack of six pieces**, not one DLL, and two of them are produced
|
|
by machine-local patching rather than shipped. A player who receives only
|
|
`BepInEx/plugins/RadicadeAugustClient.dll` gets a game that still talks to the official hosts, and
|
|
the only red line in his `Player.log` is the vanilla Statsig noise above - which is why that line is
|
|
the most common wrong lead. The reference install (`C:\RecRoom\2023-08-29T06-53-33Z`)
|
|
hashes as follows; anything that differs is the piece to replace:
|
|
|
|
| piece | expected |
|
|
| --- | --- |
|
|
| `GameAssembly.dll` | 167,390,208 b, md5 `11e14eb35671e2725bd0c78a6a91bb48` - the build identity; every address map and the metadata patch are tied to it |
|
|
| `Recroom_Data/il2cpp_data/Metadata/global-metadata.dat` | 38,654,794 b, md5 `cc9c32014b5fc3dd1a2a8fb12376be15`, 28 x `localhost:3030`, 50 x `rec.net` |
|
|
| `Recroom_Data/il2cpp_data/Metadata/global-metadata.interop.dat` | 38,654,794 b, md5 `4a1a28078f957af470f3b31951b32648` (normalized tooling copy) |
|
|
| `Recroom_Data/boot.config` | 173 b, md5 `dc2e5f7af7d5df736a4cc3477b4b1a1f` (`vr-enabled=0`, `player-connection-mode=Listen`) |
|
|
| `Recroom_Data/radicade-patch.json` | provenance stub: `serverUrl https://localhost:3030`, 7 changed literals, `gameVersion 20230825` |
|
|
| `winhttp.dll` | 26,112 b, md5 `b2a4d0cb04bf8f5a27ccab237ecc2586` (Doorstop 4.3.0 proxy) |
|
|
| `doorstop_config.ini`, `.doorstop_version` | `enabled = true`, target `BepInEx\core\BepInEx.Unity.IL2CPP.dll`, version 4.3.0 |
|
|
| `BepInEx/core/BepInEx.Unity.IL2CPP.dll` | 60,928 b, md5 `9430bb84349d52b753a181788a86c5e2` - patched to read `global-metadata.interop.dat`; the original is kept as `.before-august-interop` (75,776 b, md5 `b8b3e4da1dbf171f3d405102d3c9d2e2`) |
|
|
| `BepInEx/interop/` | 335 assemblies |
|
|
| `BepInEx/plugins/RadicadeAugustClient.dll` | 62,464 b, md5 `8718a45dd42d7cb72b3e46e04b744d91` |
|
|
| Radicade server | `https://localhost:3030` + `http://127.0.0.1:3031`, `Hosting environment: Development`, **on the player's own machine** |
|
|
|
|
The last row is the one no file copy can satisfy: the patched metadata rewrites the client's
|
|
bootstrap literals to `https://localhost:3030`, so the server has to run where the game runs (a
|
|
remote server needs a different metadata patch and a certificate the client accepts).
|
|
|
|
The three failure modes seen so far, each with its own fingerprint:
|
|
|
|
- **No loader.** `winhttp.dll` renamed to `winhttp.dll.baseline-disabled` (or `enabled = false`) -
|
|
`Player.log` dies at `Could not resolve host 'ns.rec.net'`, there is no `BepInEx/LogOutput.log`
|
|
for that boot. This is the 15:42 run-17 state.
|
|
- **Unpatched metadata.** `global-metadata.dat` is the 32,039,456 b / md5
|
|
`825f34f1dd046a0ae764cd5a97dba5e6` original. The plugin loads and the boot looks healthy (login,
|
|
Photon, Dorm), then the room-save path fails: `GetSubRoomDataSave()` never resolves, the client
|
|
prints `Error downloading save data!` / FailedToSpawnPlayer `Code 8715` and tears the session
|
|
down. This is the 2026-09-24 15:16 baseline-experiment state.
|
|
- **No local server.** Everything else is in place but nothing listens on 3030 - the client's
|
|
requests fail and the screen shows the launch-validation/login failure.
|
|
|
|
`tools/august-client-triage.ps1` reports all of the above in one pass (read-only; it also opens two
|
|
TCP sockets to 127.0.0.1:3030 and :3031 and writes `august-client-report.txt` next to itself):
|
|
|
|
```
|
|
powershell -ExecutionPolicy Bypass -File august-client-triage.ps1
|
|
powershell -ExecutionPolicy Bypass -File august-client-triage.ps1 -GameDir "D:\Games\2023-08-29T06-53-33Z"
|
|
```
|
|
|
|
On the reference install with the server stopped it reports exactly one `[MISSING]` (port 3030) and
|
|
one `[WARN]` (port 3031); with the server up, none. Every `[MISSING]` line names a piece of the
|
|
table above that did not arrive, and the two log tails at the end of the report carry the rest.
|
|
|
|
`tools/make-august-client-pack.ps1` assembles the handover itself: it verifies every piece against
|
|
the table (fail-closed, so it cannot ship an unpatched metadata or a foreign build), copies the
|
|
loader pieces, the patched data files and the whole `BepInEx` tree - minus logs, previous-build
|
|
sidecars and the 18 MB `radicade-addr-map.txt` diagnostic - into
|
|
`<OutDir>\RadicadeAugustClient`, then writes `README-FRIEND.txt` and drops the triage script in
|
|
alongside. The reference bundle is 302 MB in 448 files, of which `BepInEx/interop` (335 assemblies)
|
|
is the bulk:
|
|
|
|
```
|
|
powershell -ExecutionPolicy Bypass -File make-august-client-pack.ps1 -OutDir "D:\radicade-pack" -Zip
|
|
```
|
|
|
|
For the September build (20230831, folder `2023-09-06T06-53-47Z`) the same pair exists as
|
|
`tools/september-client-triage.ps1` and `tools/make-september-client-pack.ps1`, carrying that
|
|
build's reference hashes (332 interop assemblies, 294.8 MB bundle) and one extra check the August
|
|
scripts do not need: the metadata header magic, because a stock BepInEx core fails on this game's
|
|
scrambled `global-metadata.dat` with `Invalid or corrupt metadata (magic number check failed)`.
|
|
See `docs/2023-0831-CLIENT-SWITCH.md`.
|
|
|
|
## Rec Room Studio on Radicade
|
|
|
|
`C:\RecRoom\OneDrive\Documents\EggFiles\ProjectTemplate` is the Rec Room Studio template, and
|
|
it lines up with the client we already patch: Unity **2020.3.33f1** (the August build's engine) and
|
|
packages built from `features/rec-room-studio/releases/20230831-211740` (git `0c23610a`, recorded in
|
|
`RecRoomStudioPackages/VersionInfo.json`). Those packages carry the entire game runtime
|
|
(`com.recroom.studio`, `.studio.build`, `.studio.api`, `networking`, `circuitsv2`, `objectmodel`, ...),
|
|
which is what lets the studio run the real game code inside the editor.
|
|
|
|
### Everything routes through one string
|
|
|
|
A sweep of every `com.recroom.*` assembly for both ASCII **and** UTF-16 string heaps (plain `grep`
|
|
finds nothing - .NET literals live in the `#US` heap as UTF-16) turns up exactly one baked-in
|
|
service host:
|
|
|
|
| Where | Literal |
|
|
| --- | --- |
|
|
| `Library/PackageCache/com.recroom.studio.build@*/Editor/RecRoom.Studio.Editor.Core.dll` | `https://deluxe-backend-test.oldrecroom.com/nameserver` |
|
|
| `.../com.recroom.studio/.../UI/RecRoomStudioWindow/SignInPanel.uxml` | `https://auth.rec.net/device` (label text only) |
|
|
| `.../RecRoom.Studio.Editor.Core.dll` | `https://events.statsigapi.net/v1/` (telemetry) |
|
|
|
|
No config file, environment variable or command-line switch redirects it: the editor `GET`s that
|
|
nameserver URL and derives *every* other base (`Auth`, `API`, `CDN`, `Images`, `Studio`, ...) from the
|
|
JSON, so aiming the whole editor at a private server is a one-string patch. The `-environment`
|
|
argument belongs to the batchmode pipeline (`-roomId`, `-outputPath`, `-rebuildMode`,
|
|
`-RECNET_CLIENTSECRET`, ...), not to the window.
|
|
|
|
### Sign-in is an RFC 8628 device flow
|
|
|
|
`RecRoom.Studio.Editor.Core.dll` carries `connect/deviceauthorization` and `connect/studiotoken`
|
|
under the nameserver's `Auth` base, together with the matching model: `device_code`, `user_code`,
|
|
`verification_uri`, `verification_uri_complete`, `expires_in`, `interval`, `scope`, `access_token`,
|
|
`refresh_token`, `authorization_pending`, `tokenError`, and the grant URN
|
|
`urn:ietf:params:oauth:grant-type:device_code`. Nothing in the studio window works before that
|
|
succeeds - there is no offline path, and `"Play Local"` (which launches the game client with
|
|
`-RecRoomStudioPort:N` and drives it over `http://localhost:{port}/recroomstudio/checkavailability`
|
|
and `/loadroom`) stays disabled until a room is open, which itself comes from RecNet.
|
|
|
|
### What the server now provides
|
|
|
|
`Server/Auth/StudioAuthAPI.cs` implements both endpoints off the nameserver's `Auth` base
|
|
(`{ServerUrl}/auth/connect/...`). Real RecNet has the user approve the code at `auth.rec.net/device`;
|
|
a private server has no such page, so the code is auto-approved and the tokens are minted by
|
|
`AuthAPI.GenerateToken` - the same claims (`userId`, `tver`, roles, `rn.ver`) the game client gets,
|
|
which is what `[Authorize]` and token revocation actually check. The flow is refused for non-loopback
|
|
callers unless `Radicade:Studio:AllowRemoteDeviceAuth` is true, and the account is
|
|
`Radicade:Studio:AutoApproveAccountId`, else whichever account the caller names, else the lowest
|
|
account holding the `developer` role. Requests are read as form **or** JSON and logged in full (bar
|
|
secrets), because the exact wire shape is not documented anywhere - the first real sign-in attempt is
|
|
what will tell us.
|
|
|
|
Verified live against the dev server:
|
|
|
|
```
|
|
POST /auth/connect/deviceauthorization -> device_code, user_code 8JXV-8W4D, expires_in 900, interval 2
|
|
POST /auth/connect/studiotoken (device_code) -> access_token (JWT roles gameClient+developer+influencer, userId 2, tver 0)
|
|
GET /auth/account/me/haspassword + bearer -> true
|
|
POST /auth/connect/studiotoken replying the device_code -> invalid_grant (single use)
|
|
```
|
|
|
|
### The editor-side patch
|
|
|
|
`tools/patch-rrs-nameserver.ps1` rewrites that one literal in place, as a `.NET` string-heap edit: the
|
|
entry keeps its 108-byte footprint (1-byte compressed length + 106 bytes of UTF-16 + terminator), the
|
|
freed tail is zero-filled, and because the heap is addressed by offset and the footprint is unchanged
|
|
no other string moves. One-time backup to `RecRoom.Studio.Editor.Core.dll.radicade-orig`, idempotent,
|
|
and after writing it re-decodes the entry and asserts that **nothing outside the slot changed**
|
|
(`-Restore` puts the original back).
|
|
|
|
```powershell
|
|
powershell -ExecutionPolicy Bypass -File tools/patch-rrs-nameserver.ps1 # -> https://localhost:3030/nameserver
|
|
powershell -ExecutionPolicy Bypass -File tools/patch-rrs-nameserver.ps1 -Url http://127.0.0.1:3031/nameserver
|
|
powershell -ExecutionPolicy Bypass -File tools/patch-rrs-nameserver.ps1 -Restore
|
|
```
|
|
|
|
### Two blockers before any of this can be exercised
|
|
|
|
1. **The project tree is write-protected.** Creating a file anywhere under
|
|
`C:\RecRoom\OneDrive\Documents\EggFiles\ProjectTemplate` fails (`ERROR_FILE_NOT_FOUND` for a
|
|
new file, `Access denied` when overwriting an existing one, and a hang via `cmd`) from Python,
|
|
PowerShell and .NET, while reads work and writes elsewhere on the same volume succeed -
|
|
`OneDrive\` itself is writable, `OneDrive\Documents` is not, and no `OneDrive` process is running.
|
|
Defender's Controlled Folder Access is enabled (`EnableControlledFolderAccess = 1`) and its
|
|
implicit protected "Documents" resolves to the OneDrive one. Unity cannot open a project it cannot
|
|
write `Library/` and `Temp/` into, so this has to be settled first.
|
|
2. **TLS.** The editor validates certificates normally - the game client does not, because our plugin
|
|
patches that. The certificate Kestrel serves on 3030 (`localhost-rsa-aes-devcert.pfx`, thumbprint
|
|
`D2275346BC059E9B62466F116F146F63CB89D5C4`, notAfter 2031-09-05) sits in `CurrentUser\My`, **not** in
|
|
`CurrentUser\Root`, so the editor's `https://localhost:3030/...` calls will be rejected until that
|
|
cert is trusted (or the editor is aimed at the plain-HTTP listener on `http://127.0.0.1:3031`, in
|
|
which case `Radicade:ServerUrl` has to match too, since the nameserver response is where every other
|
|
base URL comes from).
|
|
|
|
After that the remaining surface is the studio's own room data: the window lists rooms and saves from
|
|
RecNet (`RoomTargetPanel`, `SaveListItem`) and uploads with
|
|
`git -c http.extraheader="AUTHORIZATION: bearer <token>"` to a RecNet-hosted remote - none of which
|
|
exists here yet (`Server/API/Studio` is an empty placeholder directory).
|
|
|
|
### The compile wall was Defender, not the packages (2026-09-26)
|
|
|
|
The writable copy opened in Unity 2020.3.33f1 and immediately refused to compile anything:
|
|
|
|
```
|
|
Asset Packages/com.recroom.studio.build/Editor/RecRoom.Studio.Editor.Core.dll.radicade-orig has no
|
|
meta file, but it's in an immutable folder. The asset will be ignored.
|
|
NullReferenceException ... UnityEditor.Utils.Program.GetStandardOutput() (twice)
|
|
Assembly 'Packages/com.recroom.creation/Runtime/RecRoom.Creation.Runtime.dll' will not be loaded
|
|
due to errors: Unable to resolve reference 'Unity.Mathematics'
|
|
... the same for ~15 com.recroom.* assemblies, plus 'Unity.Collections', 'Unity.Settings.Editor',
|
|
'Unity.RenderPipelines.Core.Editor', 'RecRoom.Studio.Common.Runtime'
|
|
```
|
|
|
|
with `Library/ScriptAssemblies` holding only `BuiltinAssemblies.stamp`. The first guess - that the
|
|
manifest's `file:../RecRoomStudioPackages/*.tgz` sibling folder had been left behind by the robocopy -
|
|
was **wrong**, and worth recording so it is not chased again: Unity resolves a `file:` path in
|
|
`Packages/manifest.json` relative to the **Packages folder**, so `../RecRoomStudioPackages` is
|
|
`<project>\RecRoomStudioPackages`. That folder is inside `ProjectTemplate` and always was, holding all
|
|
55 tarballs plus `VersionInfo.json`. An integrity scan of the whole set (tar entry list vs extracted
|
|
files, for every tarball) found **zero** missing files.
|
|
|
|
The actual failure is one line of `Editor.log`:
|
|
|
|
```
|
|
Starting external compile of Unity.Jobs.CodeGen.dll:
|
|
...\Library\PackageCache\com.unity.roslyn@0.2.2-preview\Compiler~\win64\csc.exe /noconfig @Temp/... /shared
|
|
Exception when running external compiler on Unity.Jobs.CodeGen.dll:
|
|
System.ComponentModel.Win32Exception (0x80004005): ApplicationName='...\win64\csc.exe', ...
|
|
Native error= The system cannot find the file specified.
|
|
```
|
|
|
|
Unity 2020.3 compiles C# with an external compiler, and because this project installs
|
|
`com.unity.roslyn` (a transitive dependency of `com.unity.entities@0.51.1-preview.21`) that compiler
|
|
is the package's own Roslyn 3.8. **`csc.exe` was gone** - from `Library\PackageCache` *and* from the
|
|
shared `%LOCALAPPDATA%\Unity\cache\packages` copy - so the first compile died, nothing was written to
|
|
`ScriptAssemblies`, and every later reference resolution failed against an empty assembly set. The wall
|
|
of "Unable to resolve reference" is a symptom of "the compiler never ran".
|
|
|
|
It was not shipped broken: the registry tarball
|
|
(`https://cdn.packages.unity.com/tarballs/com.unity.roslyn/com.unity.roslyn-0.2.2-preview/8b5b337db92cbdec37b54235ec8b826c92c6ddef.tgz`)
|
|
contains `package/Compiler~/win64/csc.exe` (md5 `8c4361cc37113f8467feb1d22b4e83da`), as it does for
|
|
`mac/csc` and `linux/csc`. Something deleted it locally.
|
|
|
|
That something is **Windows Defender's PUA protection**, which has been quarantining unsigned
|
|
executables out of Unity package folders on this machine. `Get-MpThreatDetection` lists
|
|
`com.unity.burst@1.8.4\.Runtime\hostwin\llvm-lipo.exe` at 2026-09-26 08:35 (ThreatID 2147972435),
|
|
the older `dsymutil.exe` in burst 1.8.12/1.8.17/1.8.21 in the shared cache, and the same
|
|
`llvm-lipo.exe` in the OneDrive tree at 00:34 - `com.unity.burst\.Runtime\hostwin` now contains only
|
|
`vswhere.exe`. Burst's `bcl.exe` survived and the lost tools only matter for Apple targets, so the
|
|
one casualty that blocks everything is the script compiler.
|
|
|
|
**Repair:** `tools/repair-unity-script-compiler.ps1` restores `Compiler~\win64\csc.exe` and proves it
|
|
works by running the compiler's own `-version` probe. Sources, in order: `-FromPath`, else the Unity
|
|
install's `Editor\Data\Tools\Roslyn\csc.exe`. The launcher is interchangeable - it is a stock .NET
|
|
Core apphost that loads the `csc.dll` beside it, and Unity's own copy drove the package's newer
|
|
`csc.dll` through a clean test compile (empty output, valid 3 KB assembly). Use `-FromPath` with the
|
|
extracted tarball member to get the authentic binary (it differs: md5 `5f0947da...` for Unity's
|
|
build).
|
|
|
|
**Cure (needs an elevated shell):**
|
|
|
|
```powershell
|
|
Add-MpPreference -ExclusionPath 'C:\RecRoom\Documents\EggFiles\ProjectTemplate'
|
|
Add-MpPreference -ExclusionPath "$env:LOCALAPPDATA\Unity\cache"
|
|
```
|
|
|
|
and re-run the repair with `-IncludeGlobalCache` so a package re-resolve cannot copy the damaged file
|
|
back out of the shared cache.
|
|
|
|
Smallest reproducer for the whole thing, without Unity: run `csc.exe -version` in the package's
|
|
`Compiler~\win64`; if the file is missing you get the Win32Exception above, and a test compile with
|
|
`-noconfig -nostdlib -target:library -r:<dir>\System.Private.CoreLib.dll` produces a real assembly.
|
|
|
|
### Verified: the compile wall is down (batch-mode run)
|
|
|
|
The editor can be driven headlessly, which makes the whole state checkable without any clicking:
|
|
|
|
```powershell
|
|
Unity.exe -batchmode -nographics -quit -projectPath <copy> -logFile <log>
|
|
```
|
|
|
|
(it exits 1 on a purely cosmetic `Timeout after 300 seconds while waiting async operations to finish`).
|
|
Before and after the `csc.exe` repair, on the same project copy:
|
|
|
|
| | before | after |
|
|
|---|---|---|
|
|
| `Starting external compile ...` | 3, then `Win32Exception ... cannot find the file` | 205, **0** failures |
|
|
| `Unable to resolve reference 'Unity.Mathematics'` / `will not be loaded due to errors` | ~15 assemblies | **0** |
|
|
| `Library/ScriptAssemblies/*.dll` | none, only `BuiltinAssemblies.stamp` | 105, incl. `Unity.Mathematics`, `Unity.Collections`, `Unity.Serialization`, `RecRoom.Studio.Common.Runtime` |
|
|
|
|
The first repair attempt also showed why this has to be repaired in *both* caches: `csc.exe` compiled
|
|
189 assemblies and then vanished mid-run, which the Defender event log does **not** account for
|
|
(`Get-WinEvent ... /Operational` ids 1116/1117/1121 only ever name `burst\hostwin\llvm-lipo.exe`, and
|
|
never `csc`/`roslyn`). With the shared `%LOCALAPPDATA%\Unity\cache` copy repaired too, the next run
|
|
kept the file and logged no failure at all - and `com.unity.roslyn@0.2.2-preview`'s own directory
|
|
mtime stayed put, so this was not a whole-package re-extraction. Treat the project copy alone as
|
|
fragile; repair both.
|
|
|
|
Two things the log still reports, neither of them blocking:
|
|
|
|
* `Assets/**/*.cs` is empty, so there is correctly no `Assembly-CSharp` in the output - all of this
|
|
project's code lives in packages. Do not go looking for that assembly.
|
|
* The 11 remaining `error CS` lines are `[Script Updater]` advisories from
|
|
`com.unity.serialization@1.7.0-preview.1` against `Unity.Collections` 1.4.0 (`FixedString128`
|
|
renamed, `Rune` overloads). It still compiles, and nothing in the project references it.
|
|
|
|
**Still eaten by the same Defender rule:** `com.unity.burst@1.8.4\.Runtime\burst-lld-14-hostwin`, the
|
|
LLD the Burst AOT job links with. It is missing from the project copy *and* from the shared cache, so
|
|
no re-extraction can bring it back - the batch log ends with
|
|
`Error while executing command: ...burst-lld-14-hostwin ... Native error: The system cannot find the
|
|
file specified`. `hostwin\llvm-lipo.exe` is quarantined on sight (twice on 2026-09-26 alone). Both are
|
|
Burst build/AOT tools: they break a player build, not the C# compilation the editor needs. Recover
|
|
them by re-downloading `com.unity.burst@1.8.4` from the registry - its `burst-lld-14-hostlin` and
|
|
`hostmac` siblings are intact, which is how we know the Windows one was deleted rather than never
|
|
shipped (1.8.17 in the same cache has three `hostwin` entries, 1.8.4 now has one).
|
|
|
|
### Burst repaired, and the studio auth path re-verified (2026-09-26)
|
|
|
|
Re-downloading `com.unity.burst@1.8.4` settled both the linker and its naming: the package ships
|
|
`package/.Runtime/burst-lld-14-hostwin.exe` **with** the extension (the log prints the extensionless
|
|
name because that is what `CreateProcess` is given, and Windows appends `.exe` itself), while
|
|
1.8.17/1.8.21 carry only `burst-lld-16/18-hostwin-arm64.exe`. A full file-set diff of that tarball
|
|
(480 files) against the extracted package found exactly two casualties and no extras:
|
|
`.Runtime/burst-lld-14-hostwin.exe` and `.Runtime/hostwin/dsymutil.exe` (40.8 MB). Both are restored
|
|
and the package now diffs clean, as does the whole `RecRoomStudioPackages` set.
|
|
|
|
With the compiler, the certificate and the server all in one piece, the studio device flow was re-run
|
|
over **strict** TLS (the `localhost` dev cert is now in `CurrentUser\Root`, so `curl` without `-k`
|
|
succeeds):
|
|
|
|
```
|
|
POST /auth/connect/deviceauthorization -> device_code, user_code 9C3C-UXUF,
|
|
verification_uri https://localhost:3030/device
|
|
POST /auth/connect/studiotoken -> 400 grant_type is required (the full RFC 8628
|
|
grant_type=urn:...:device_code urn:ietf:params:oauth:grant-type:device_code is NOT
|
|
accepted)
|
|
POST /auth/connect/studiotoken grant_type=device_code&device_code=...
|
|
-> access_token (JWT roles gameClient+developer+influencer,
|
|
userId 2, tver 0, rn.ver 20230825, expires_in 604800)
|
|
GET /auth/account/me/haspassword + bearer -> true
|
|
POST studiotoken replying the device_code -> invalid_grant (single use)
|
|
```
|
|
|
|
`grant_type=device_code` is the value the handler actually branches on; a request naming any other
|
|
grant type is answered with `unsupported_grant_type` and logged. What is left is unchanged:
|
|
rooms/saves, and the `git`-over-HTTPS upload remote - `Server/API/Studio` is still an empty
|
|
placeholder directory.
|
|
|
|
### First real Sign in: two server-side gaps (2026-09-26)
|
|
|
|
The first click of **Sign in** in the studio window opened the browser at
|
|
`https://localhost:3030/device?user_code=EYJ4-T9DF` and got a 404. The browser is not where the
|
|
authority on this is: `%LOCALAPPDATA%\Unity\Editor\Editor.log` records the editor's own verdicts, and
|
|
it had two of them.
|
|
|
|
**1. `Device authorization failed: unsupported_grant_type`.** The editor polls `studiotoken` with the
|
|
full RFC 8628 grant type - `urn:ietf:params:oauth:grant-type:device_code` - while the handler only
|
|
branched on the bare `device_code`, so it answered `unsupported_grant_type` and the editor abandoned
|
|
the sign-in. Matching is now on the token rather than one exact string (dashes normalised, so any
|
|
spelling is accepted), and `refresh_token` got the same treatment. Re-verified against the live
|
|
server: that exact request now returns an `access_token`, and the short form still does.
|
|
|
|
**2. There was no `/device` page.** `verification_uri` and `verification_uri_complete` were being
|
|
advertised while nothing served the path, so the browser step could only ever 404. New
|
|
`Server/Auth/DeviceApprovalAPI.cs` (`[Route("/")]` + `[HttpGet("device")]`, the same root-level
|
|
pattern `NameSever` uses, and the same HTML styling as `AccountsAPI.VerificationPage`) renders
|
|
"Approved - account 2" for a live code, and explains an unknown or missing one. It deliberately
|
|
approves nothing: the code is already issued approved, so the page's job is to tell the user what
|
|
they are holding.
|
|
|
|
An earlier attempt had also logged
|
|
`Failed to initiate device authorization: Failed to obtain RecNet Service URIs: NullReferenceException`
|
|
inside `KJGMKNABDIJ.EMOFOGPOOLJ(String, Char)` - a parse of the nameserver response in *editor* code,
|
|
not a server fault. It stopped occurring once the client got past that stage, and it is worth knowing
|
|
because it looks like a server problem and is not.
|
|
|
|
Unrelated noise now identified and safe to ignore: `Rec Room Studio unable to record last project
|
|
path` / `skipped checking for update` / `skipped checking for local update to install`, all
|
|
`FileNotFoundException` for `ProjectSettings\Packages\com.recroom.studio\BranchId.txt`, plus
|
|
`EditorUpdateCheck: Failed The requested URL returned error: 404`. Those only disable the studio's
|
|
self-update check.
|
|
|
|
### The server now leaves a readable log
|
|
|
|
PID 448 had no stdout redirect, so the editor's actual request bodies from that first attempt are
|
|
gone. It has been restarted (PID 39184) from `Server\` with `ASPNETCORE_ENVIRONMENT=Development` and
|
|
stdout captured to `.tmp-studio-auth.log` in the repo root. `ReadRequestFields` already logs the
|
|
method, path, client IP, content-type, user-agent and every field of every studio request, so the
|
|
next Sign in attempt is fully diagnosable:
|
|
|
|
```
|
|
Studio POST /auth/connect/studiotoken from ::1, content-type=application/x-www-form-urlencoded,
|
|
user-agent=curl/8.17.0: grant_type=urn:ietf:params:oauth:grant-type:device_code, device_code=..., client_id=recroom-studio
|
|
Studio token issued: account=2.
|
|
```
|
|
|
|
Restart pattern (the working directory matters - `DBConfig` resolves `RadicadeServer-Data/` and
|
|
`RadicadeServer-Config/` relative to it, so starting from anywhere else silently uses a different
|
|
account database):
|
|
|
|
```powershell
|
|
Stop-Process -Id <pid> -Force # dotnet build cannot write bin/ while it runs
|
|
cd Server; $env:ASPNETCORE_ENVIRONMENT='Development'
|
|
Start-Process -FilePath "bin\Debug\net9.0\Server.exe" -WorkingDirectory (Get-Location) `
|
|
-RedirectStandardOutput "..\.tmp-studio-auth.log" -RedirectStandardError "..\.tmp-studio-auth.err.log"
|
|
```
|
|
|
|
It takes 90-150 s to start listening on `https://localhost:3030` and `http://127.0.0.1:3031`, and the
|
|
log's `Content root path` line confirms which working directory actually won. (Starting it from a
|
|
script: do not capture the launcher's stdout - the server inherits the pipe and the shell blocks
|
|
forever. It starts fine, the wrapper just never returns.)
|
|
|
|
### Sign-in works; the studio API surface (2026-09-26)
|
|
|
|
Sign in now completes - the studio window shows the account, and a **Sign out** button. What it does
|
|
afterwards is visible because this server already logs every request:
|
|
|
|
```
|
|
[09:22:08] GET /studio/analytics/rudderstack-api-key -> 404 (x20)
|
|
[09:22:08] GET /rooms/rooms/ownedby/me -> 200
|
|
[09:22:08] GET /rooms/rooms/25?include=1037 -> 200
|
|
[09:22:13] GET /rooms/rooms/25/subrooms/32/saves?skip=0&take=30 -> 200
|
|
[09:22:13] GET /studio/cloud-builds/for-room?roomId=25&subRoomId=32&skip=0&take=30 -> 404
|
|
```
|
|
|
|
`cloud-builds/for-room` is the wall: with no route at all the panel showed
|
|
"Failed to open room - Could not download room details. 404 (Not Found)", and the editor retried it
|
|
on a loop (three `HttpRequestException: 404` in the console).
|
|
|
|
The complete route list fell straight out of the same DLL that held the nameserver literal - the
|
|
client's UTF-16 #US heap keeps its route templates back to back, in
|
|
`Packages/com.recroom.studio.build/Editor/RecRoom.Studio.Editor.Core.dll` at offset ~296k:
|
|
|
|
```
|
|
cloud-builds
|
|
cloud-builds/for-room
|
|
cloud-builds/create (+ query keys autoPublish, buildBranch, cloudBuildId)
|
|
cloud-builds/custom-avatar-item/{0}
|
|
cloud-builds/custom-avatar-item/{0}/save/{1} (+ customAvatarItemSaveId)
|
|
cloud-builds/cancel
|
|
remote-run/push-to-device
|
|
collaboration/owners-in-room
|
|
account/{0}
|
|
```
|
|
|
|
and, in the same block, the auth client's own vocabulary - which closes the loop on the two fixes
|
|
above:
|
|
|
|
```
|
|
connect/studiotoken, client_id=recroom.studiopipeline, client_secret=54oc5C4BH7jpqp42KhChkNZOLP0U3yTx,
|
|
grant_type=client_credentials <- a second, non-interactive login path
|
|
recroom.studio, refresh_token <- and a refresh path
|
|
connect/deviceauthorization, urn:ietf:params:oauth:grant-type:device_code, device_code,
|
|
authorization_pending <- the editor DOES send the urn form, and it does poll for
|
|
authorization_pending; both are now handled
|
|
account/me, rrs.pushtostudio, RecRoom.Studio.SessionId
|
|
```
|
|
|
|
`Server/API/Studio/StudioAPI.cs` (the folder had been an empty placeholder since the studio work
|
|
started) now answers the three read-only ones: `cloud-builds/for-room` and
|
|
`collaboration/owners-in-room` with an empty list, `analytics/rudderstack-api-key` with an empty key
|
|
(that route is polled twenty-odd times a session and the 404s were noise). Verified 200 with the
|
|
exact query string the editor uses.
|
|
|
|
Empty lists, not 404s, on purpose: this server has no cloud build to hand out. Producing one is the
|
|
other half of the feature - `cloud-builds/create` plus the git-over-HTTPS remote the studio pushes
|
|
the scene to - so the useful next state is the editor saying "this room has no builds" and showing
|
|
what it asks for after that, instead of failing on transport.
|
|
|
|
Still unexplained but harmless: three `NullReferenceException`s in
|
|
`KJGMKNABDIJ.EMOFOGPOOLJ(System.String, System.Char)` fire a second after a successful sign-in. That
|
|
is the studio's own URI parsing helper (the same one behind the earlier
|
|
`Failed to obtain RecNet Service URIs`), so if the studio later complains about a missing service it
|
|
is the first place to look - the candidate is a nameserver key we do not emit that it expects to
|
|
split.
|
|
|
|
> **Explained below** ("Opening a room"). Decompiling the class settles it: `EMOFOGPOOLJ` is
|
|
> `url.EndsWith('/') ? url : url + '/'`, it NREs on a **null** nameserver field, and the null one is
|
|
> `StudioCDN`. The three exceptions were the same missing key each session, not a cosmetic
|
|
> curiosity - every URI before it resolved, which is why the session carried on.
|
|
|
|
### for-room wants a page, not an array (2026-09-26)
|
|
|
|
Answering an empty list moved the failure from transport to **shape**, which is what makes the next
|
|
step legible - the studio window stopped reporting a 404 and started naming the type it wanted:
|
|
|
|
```
|
|
Could not download room details.
|
|
The JSON value could not be converted to
|
|
RecRoom.Core.Studio.RecNet.PagedResultsDTO`1[RecRoom.Core.Studio.RecNet.CloudBuildDTO].
|
|
Path: $ | LineNumber: 0 | BytePositionInLine: 1.
|
|
```
|
|
|
|
Byte 1 of `[` means the studio's list DTO is an **object**. This repo had already learned that for
|
|
the game client - `V2_RoomsAPI.EmptyPage` carries the note "The empty page every paged list here
|
|
answers with `{ TotalResults, Results }` rather than a bare `[]`. The client's list DTOs are objects
|
|
(`PagedResultsDTO<RoomDTO>`)" - so `StudioAPI.CloudBuildsForRoom` now mirrors that shape:
|
|
`{ Results: [], TotalResults: 0, TotalCount: 0 }`.
|
|
|
|
`collaboration/owners-in-room` is the exception and stays a bare array. The editor requested all
|
|
three studio routes within the same second (`09:23:55` in `.tmp-studio-auth.log`) and accepted `[]`
|
|
there without a deserialization error, so the two routes are not the same DTO family. Reading the
|
|
console to see *which* route threw, instead of assuming one uniform shape for every studio list, is
|
|
what separated them.
|
|
|
|
> **Wrong, and corrected below.** The editor *did* reject `[]` on that route - it just logged the
|
|
> `Result<List<int>>` deserialization error a second later, next to the room-open failure, where it
|
|
> read as part of that failure rather than as its own. "The two routes are not the same family" was
|
|
> the right conclusion for the wrong reason: `owners-in-room` is wrapped (`Result<T>`), not paged.
|
|
|
|
Opening a room still cannot succeed: `for-room` is only the lookup, and this server has no
|
|
`CloudBuildDTO` to return because nothing has ever been uploaded. The next milestone is producing
|
|
one - `cloud-builds/create` plus wherever the studio pushes the scene - not another shape fix here.
|
|
|
|
### Two patcher details settled the same day
|
|
|
|
* The one-time backup now lives **outside** the package folder, at
|
|
`<ProjectRoot>\radicade-backups\<pkg-id>\...\X.dll.radicade-orig`, because Unity treats everything
|
|
under `Library\PackageCache` as immutable and logs the `has no meta file, but it's in an immutable
|
|
folder` warning that opened this whole trail (`-Restore` still understands a legacy in-package
|
|
backup). Relocate an existing one with a plain `move`; restore -> patch -> re-run was verified
|
|
round-trip, leaving the slot at offset 296749 with 40 bytes of zero padding and the file size
|
|
unchanged.
|
|
|
|
### Opening a room: the studio's DTOs, and why `""` is not `null` (2026-09-26)
|
|
|
|
The screenshot that prompted this round: the room resolves (`TestPlayers_MakerRoom_3528/Home`), sign-in
|
|
holds, the panel offers **Build on Rec.net** and **Download** - and **Open Room** fails with two
|
|
stack traces that have nothing to do with transport, because the server log for that whole session
|
|
has no non-200 in it:
|
|
|
|
```
|
|
[09:33:33] NullReferenceException: Object reference not set to an instance of an object
|
|
KJGMKNABDIJ.EMOFOGPOOLJ(System.String, System.Char)
|
|
[09:33:34] ArgumentException: The string argument 'filename' cannot be empty. Parameter name: filename
|
|
at CDLPCLJLLLG.DHGPNOHKPNB(...) -> MAMHCJFJOGI+OMPAKMPBPNM.MoveNext()
|
|
OGINOCKCDO+ICFNAE5EAJ.MoveNext() <- "Could not download subroom data"
|
|
[09:33:34] JsonException: The JSON value could not be converted to
|
|
RecRoom.Core.Studio.RecNet.Result`1[System.Collections.Generic.List`1[System.Int32]].
|
|
Path: $ | LineNumber: 0 | BytePositionInLine: 1.
|
|
```
|
|
|
|
The editor's own log keeps the full traces and names the methods, which is what makes the shapes
|
|
readable - `%LOCALAPPDATA%\Unity\Editor\Editor.log`, and the interesting lines are the ones between
|
|
the exception and the `UnityEngine.DebugLogHandler:Internal_LogException` marker.
|
|
|
|
#### Decompiling the studio is one command, and it is already installed
|
|
|
|
`ilspycmd` (8.2.0) is a global dotnet tool on this machine, and the editor's assemblies are ordinary
|
|
managed DLLs - the obfuscator renamed types and methods, not the DTOs, because the DTOs are the
|
|
wire contract:
|
|
|
|
```
|
|
ilspycmd -l "RecNet" ".../Library/PackageCache/com.recroom.studio.build@e443aa011f13/Editor/RecRoom.Studio.Editor.Core.dll"
|
|
ilspycmd -t 'RecRoom.Core.Studio.RecNet.Result`1' "<that dll>"
|
|
ilspycmd -o .tmp-rrs-decomp "<that dll>" # 7,725 lines, whole assembly
|
|
ilspycmd -o .tmp-rrs-authoring ".../com.recroom.studio@6492b87ce18e/Editor/Authoring/RecRoom.Studio.Editor.Authoring.dll" # 28,779 lines
|
|
```
|
|
|
|
Both dumps are kept in the repo working tree (gitignored, like the `.tmp-*.log` files) - the loader
|
|
lives in **Authoring** and the API client in **Core**, so a question about a route is usually a
|
|
grep across both.
|
|
|
|
#### The reply shapes, verbatim
|
|
|
|
```csharp
|
|
[Serializable] public class Result { public bool Success { get; set; } public string Error { get; set; } }
|
|
[Serializable] public class Result<T> : Result { public T Value { get; set; } }
|
|
[Serializable] public class PagedResultsDTO<T> { public List<T> Results { get; set; } public long TotalResults { get; set; } }
|
|
|
|
public class RoomDetailsDTO : RoomDTO {
|
|
public string DataBlob; public string DataBlobHash;
|
|
public IReadOnlyList<SubRoomDTO> SubRooms; public IReadOnlyList<TagDTO> Tags;
|
|
public IReadOnlyList<AccountRoleDTO> Roles; public IReadOnlyList<int> CoOwnerAccountIds; }
|
|
public class SubRoomDTO {
|
|
public long SubRoomId; public string Name; public string UnitySceneId; public int MaxPlayers;
|
|
public SubRoomDataSaveDTO CurrentSave; }
|
|
public class SubRoomDataSaveDTO {
|
|
public long SubRoomDataSaveId; public long SubRoomId; public string UnityAssetId; public string UnityAsset;
|
|
public string UnityAssetHash; public string DataBlob; public string DataBlobHash;
|
|
public int PersistenceVersion; public byte OMVersion; // <- a BYTE, not an int
|
|
public int? SavedByAccountId; public PICFJDPCODO? SavedOnPlatform;
|
|
public ELMJICAIAAA? SavedOnDeviceClass; public string Description; public DateTime CreatedAt; }
|
|
```
|
|
|
|
`Result` is what catches the eye: every reply the studio *mutates* with is wrapped, and the wrapper's
|
|
`EEKDNHEOFFD()` ("assert result") is `Debug.Assert(Success == (Error == null))` followed by
|
|
`if (!Success) throw new Exception(Error)`. So a wrapper with `Success:false` is not a soft failure -
|
|
it throws out of whatever the editor was doing. `owners-in-room` is declared
|
|
`Task<List<int>>` over `Result<List<int>>`, which is exactly the type in the `JsonException`: a bare
|
|
`[]` was never accepted there, it just failed a second after the room-open error and read like part
|
|
of it. `StudioAPI.OwnersInRoom` now answers `{ Success: true, Error: null, Value: [] }` (the value is
|
|
the room's owner account ids, which the editor resolves one by one for its collaborator list).
|
|
|
|
#### Every nameserver URL is required, and `StudioCDN` was missing
|
|
|
|
`KJGMKNABDIJ` in the same DLL is the nameserver client: a `NameServerResponse` with 27 string fields,
|
|
a `IEBKFBLKOKM` that walks them one at a time into `CNHJLHELLLL[key] = new Uri(EMOFOGPOOLJ(url, '/'))`,
|
|
and `EMOFOGPOOLJ` is `url.EndsWith('/') ? url : url + '/'` - **it dereferences the string**, so a key
|
|
the response does not carry is a `NullReferenceException` mid-walk, wrapped as
|
|
`Failed to obtain RecNet Service URIs: Object reference not set to an instance of an object.` The
|
|
dictionary is assigned *before* the walk, so everything before the missing key stays usable: the
|
|
session looks healthy and three NREs are logged.
|
|
|
|
```
|
|
RecNetStatus Auth API Notifications Images CDN Commerce Matchmaking Storage Chat Leaderboard
|
|
Accounts Link RoomComments Clubs Rooms PlatformNotifications Moderation DataCollection
|
|
BugReporting Discovery PlayerSettings Studio GameLogs Strings WWW Econ StudioCDN
|
|
```
|
|
|
|
`GET /nameserver` on this server had all of them but **two**: `StudioCDN` (mapped, so this is the
|
|
null that NREs) and `RecNetStatus` (declared by the editor but never mapped, which is why it was
|
|
never the culprit). `RecNetStatus` stays unwritten on purpose - adding a URL that 404s to a field the
|
|
2023 client may also read is a worse trade than leaving a field the studio never touches absent - and
|
|
`StudioCDN` is now `{ServerUrl}/studiocdn`, the base for the editor's `roomunityasset/{filename}`
|
|
(source-project manifest) and `unityasset/{filename}` (the baked bundle). Neither route exists yet;
|
|
the point is that the editor can build a `Uri` and get an honest 404 instead of an NRE, and the fix
|
|
is one line in `DBConfig.NameServer` next to a comment saying all 27 are load-bearing.
|
|
|
|
#### A blob name of `""` is fatal; `null` is the documented "nothing to download"
|
|
|
|
The room loader (`OGINOCKCDO` in Authoring) does this, in order:
|
|
|
|
1. room details, wrapped in `PFJIHBLICIE(..., "Could not download room details")`;
|
|
2. pick the save: `room.LNLADOGFALG?.IDNMEAFLKOF?.FirstOrDefault() ?? room.DJACJOEJMOD?.CurrentSave` -
|
|
the **saves list first** (the `/saves` page), then the room payload's `currentSave`;
|
|
3. download the subroom blob from `save.DataBlob` via
|
|
`BCEDBPKMONJ.OGLFKNHIMHG(name)` - failure text `"Could not download subroom data"`;
|
|
4. download the room-level blob from `RoomDetailsDTO.DataBlob` via
|
|
`BCEDBPKMONJ.FKDIJAIOAPJ(name)` - `"Could not download room data"`;
|
|
5. both go to `MAMHCJFJOGI.GMIJOHGNLFI(filename)`, which *first* calls
|
|
`CDLPCLJLLLG.DHGPNOHKPNB(filename, "filename")` - the empty-string guard from the trace - and then
|
|
`GET {CDN}/room/{filename}`;
|
|
6. and both are **skipped entirely when the name is null**, succeeding with an empty payload
|
|
(`new PLGEIAPHMDM(null)` / `new GDEHOACHGIF(null)`), which the validators then step over
|
|
(`if (payload != null && payload.Length != 0)`).
|
|
|
|
So `""` is the one value that cannot be handled, and this server was emitting it in two places:
|
|
|
|
* `RoomUtils.ConvertToFull` hardcoded `DataBlob = ""` - the room *level* field. Nothing on this server
|
|
has ever produced a room-level blob (a save carries `RoomData.Filename` **and**
|
|
`SubRoomData.Filename`; `RoomServerAPI.UploadRoomData` only ever stored the subroom one), so the
|
|
honest value is `null`. This is the failure the first attempt hit: the subroom download had
|
|
succeeded (the `/cdn/room/7dc6589a-...` 200 in the log) and the room blob killed it.
|
|
* `subRoom.CurrentSave = BuildCurrentSave(subRoom)` ran unconditionally, so a never-saved subroom
|
|
shipped a save object with `DataBlob: ""` instead of `currentSave: null`. That is the second
|
|
attempt: room 31 simply has no save, and the studio read the placeholder save and died on the guard.
|
|
|
|
Both are fixed, and both fixes are safe for the game client - checked two ways. `grep -rli currentsave`
|
|
over the 2023 client's decompilation under `.external/aug-decomp` finds **nothing**: the client never
|
|
reads `currentSave` at all (it loads saves from the `/saves` route, whose blob-less entries this
|
|
server already omits). And the reference implementation under `.external/recflare-server` documents
|
|
the same contract - `SubRoomDto.CurrentSave: z.nullable().describe('Null until first save')`, no
|
|
room-level `DataBlob` field on its room DTO at all, and `if (input.roomDataFilename) sub.RoomDataBlob
|
|
= input.roomDataFilename` on the save - so a null here is what the real backend does, not a
|
|
workaround.
|
|
|
|
#### Verified against the running server
|
|
|
|
Rebuilt, restarted, and read back with a token minted through the studio's own device flow (the
|
|
`client_credentials` path in `.tmp-studio-auth.log` works too, without a browser):
|
|
|
|
```
|
|
nameserver StudioCDN = 'https://localhost:3030/studiocdn'
|
|
|
|
--- room 31 (TestPlayers_MakerRoom_3528) roomDataBlob=None
|
|
subRoom 34 'Home' flatDataBlob='' currentSave=null
|
|
--- room 54 (TestPlayers_MakerRoom_1603) roomDataBlob=None
|
|
subRoom 57 'Home' flatDataBlob='7dc6589a-f613-4575-afc2-21efaf9347ac'
|
|
currentSave={ "SubRoomDataSaveId": 1, "SubRoomId": 57, "DataBlob": "7dc6589a-...", ... }
|
|
|
|
owners-in-room -> {"Success": true, "Error": null, "Value": []}
|
|
cloud-builds/for-room -> {"Results": [], "TotalResults": 0, "TotalCount": 0}
|
|
```
|
|
|
|
Room 31 now opens against an empty scene (nothing was ever saved) and room 54 against the save it has;
|
|
the room-level blob being absent means the scene opens without room-level data, which is what a room
|
|
with no room data is, and a studio save is what would create it.
|
|
|
|
`dotnet build Server/Server.csproj` is clean, and **185 tests pass** across `RoomSave`, `SubRoom`,
|
|
`RoomRole`, `AdminRoom`, `RoomDeveloperOwned`, `PlayerWarning`, `CdnRange` and `RecNetShape` - the
|
|
last one is the conformance suite that compares payloads against the reference shapes, so the
|
|
`CurrentSave`/`DataBlob` change is covered in the direction that matters (a subroom that HAS a save
|
|
still reports it). `ServerTests` still cannot build as-is - its csproj compiles two
|
|
`2023Patch/RadicadeEacBypass/*.cs` files that live in the uncommitted stash - so this run used a
|
|
temporary project file beside it with those two `Compile Include`s dropped and the three test files
|
|
that need them (`HubRealtimeTests`, `ImageSignatureRequestTests`, `NameserverRedirectTests`)
|
|
removed. Do not "fix" the csproj: the missing sources are somebody's work in progress.
|
|
|
|
#### What is left before a room can actually be built in Studio
|
|
|
|
* `cloud-builds/create` (+ `buildBranch`, `autoPublish`, `cloudBuildId`, `cloud-builds/cancel`) - the
|
|
studio's `Build & Upload` button, and the only way a `CloudBuildDTO` will ever exist to list;
|
|
* `remote-run/push-to-device` (`{ SessionId, RoomId, SubRoomId, RoomData, SubRoomData,
|
|
BakedUnityAssets }` of `UploadFileResponseDTO`s);
|
|
* {StudioCDN}/`roomunityasset/{filename}` and `/unityasset/{filename}`, plus `{Storage}/upload` and
|
|
`/upload/unityassets` - where the studio puts the baked Unity assets it needs back;
|
|
* the **room**-level `DataBlob`: accept `RoomData.Filename` on the save route and store it, so a room
|
|
saved *from Studio* comes back with room data instead of `null`;
|
|
* `collaboration/owners-in-room` with the room's real owner ids, which needs the collaboration layer
|
|
this server does not have yet.
|
|
|
|
### A room opens in Studio: the illegal-text check, and the realtime channels (2026-09-26)
|
|
|
|
The three shape fixes above landed the room. `DormRoom/Home` opened with its real Maker Pen scene in
|
|
the viewport (Plants, Basketball, Welcome Mat, the whole dorm object list), the panel stopped saying
|
|
"Failed to open room", and **Build on Rec.net** filled in with the subroom's save history (`#1`, `#39`,
|
|
`#38`, `#37` - those numbers are the `SubRoomDataSaveId`s the `/saves` route mints).
|
|
|
|
Two errors were left, and both were missing server surface rather than shape:
|
|
|
|
```
|
|
[10:52:53] HubException: Failed to invoke 'SubscribeTo' due to an error on the server.
|
|
HubException: Method does not exist
|
|
[10:54:41] NullReferenceException KOMDFENMFBG+EADNODIDNG.MoveNext()
|
|
-> dialog: "An exception occurred while checking for illegal text in components.
|
|
Trying again may fix the error. Exception: 'Object reference not set ...'"
|
|
```
|
|
|
|
#### The purity check: `POST /api/sanitize/v2/isAllowed/bulk`
|
|
|
|
The studio runs every string in the scene through `KOMDFENMFBG.DOLJODEKDLI`, which calls
|
|
`Result<AreStringsPureResponseDTO>`, i.e. `POST {API}/api/sanitize/v2/isAllowed/bulk` with `Values`,
|
|
and then does:
|
|
|
|
```csharp
|
|
Result<AreStringsPureResponseDTO> newStringAllowances = await NLMHGDMIMAP(toBeChecked);
|
|
for (int i = 0; i < toBeChecked.Count; i++)
|
|
HINAIGHAGOI.TryAdd(toBeChecked[i], newStringAllowances.Value.ArePure[i]);
|
|
```
|
|
|
|
`Value` is dereferenced and `ArePure` is indexed with the sender's own index, so the reply has to be
|
|
the `Result` wrapper with **one bool per string, in order** - which is the NRE, and the reason the
|
|
dialog says "trying again may fix the error" rather than naming the string it disliked. The route did
|
|
not exist at all (404, `len=0`), and the NRE is what the editor made of the empty body.
|
|
|
|
One detail decides how the route reads its input. The editor's request builder
|
|
(`OCOOLHLEDHD.MFBDEFCEDGN`) appends its parameter list to the URL **only for GET**; for every other
|
|
verb it wraps the same list in `FormUrlEncodedContent`. So this arrives as a form body of repeated
|
|
`Values` fields, and the log line looks like the studio called it with no arguments at all - there is
|
|
nothing after `bulk`:
|
|
|
|
```
|
|
[09:54:59] POST /api/sanitize/v2/isAllowed/bulk -> 404 (0.2 ms) len=0 ct= body=
|
|
```
|
|
|
|
`SanitizeAPI.IsAllowedBulk` now answers `{ success: true, error: null, value: { ArePure: [...] } }`
|
|
from the same `StringTools.IsPure` every other route here applies to room names and inventions, with
|
|
the form spelling and the query spelling both accepted (so it can be exercised by hand). Verified:
|
|
|
|
```
|
|
$ curl -X POST https://localhost:3030/api/sanitize/v2/isAllowed/bulk -d 'Values=Plant (Dracaena)&Values=faggot&Values='
|
|
{"success":true,"error":null,"value":{"ArePure":[true,false,true]}} # aligned, in order
|
|
```
|
|
|
|
(The `Result` names are lowercase because that is how `Success` declares them for the game client;
|
|
the editor binds them anyway - it is `JsonSerializerDefaults.Web`, i.e. case-insensitive. That is also
|
|
why the `owners-in-room` wrapper from the section above needed no second pass.)
|
|
|
|
#### The realtime channels: `SubscribeTo` / `UnsubscribeFrom` on the hub
|
|
|
|
The editor's realtime client (`LKDEHPKLIGJ`) connects to `{Notifications}/hub/v1` - `NotifyHub`, which
|
|
already serves the game client at that path - sends `{ Channels: [...] }` to those two methods, and
|
|
reads `Notification` frames back off the connection. The channel it subscribes to is
|
|
`RRS:<RecRoom.Studio.SessionId>`, which is exactly where a `rrs.pushtostudio` message would come from
|
|
(`remote-run/push-to-device`, still unimplemented). The hub had `SubscribeToPlayers` but not
|
|
`SubscribeTo`, and SignalR answers an unknown method with `HubException: Method does not exist` - an
|
|
error the editor logs and retries on every reconnect instead of ignoring.
|
|
|
|
Both methods now exist, take the raw `object?` the way the neighbouring hub methods do, pull the
|
|
channel names out of the `JsonElement` by name (SignalR serializes camelCase, so the lookup is
|
|
case-insensitive), and log the subscription. Nothing publishes to them yet, which is stated in the
|
|
log line rather than silently swallowed:
|
|
|
|
```
|
|
[NotifyHub] U9-Bl4o4KZFIUWR5eMi9IA subscribed to RRS:test-session (nothing publishes to these yet).
|
|
[NotifyHub] U9-Bl4o4KZFIUWR5eMi9IA unsubscribed from RRS:test-session (nothing publishes to these yet).
|
|
```
|
|
|
|
Verified without a SignalR client package, by driving the hub's **long-polling** transport with curl -
|
|
worth keeping, because it is the only way this repo can poke the hub by hand:
|
|
|
|
```
|
|
TOK=$(curl -s -X POST 'https://localhost:3030/notify/hub/v1/negotiate?negotiateVersion=1' | jq -r .connectionToken)
|
|
curl -s -X POST "https://localhost:3030/notify/hub/v1?id=$TOK" -H 'Content-Type: text/plain;charset=UTF-8' \
|
|
--data-binary $'{"protocol":"json","version":1}\x1e' # handshake
|
|
curl -s -X POST "https://localhost:3030/notify/hub/v1?id=$TOK" -H 'Content-Type: text/plain;charset=UTF-8' \
|
|
--data-binary $'{"type":1,"target":"SubscribeTo","arguments":[{"channels":["RRS:test-session"]}],"invocationId":"1"}\x1e'
|
|
```
|
|
|
|
The `\x1e` record separator is part of the protocol, and the response body stays empty on the POST -
|
|
the server-side log line is the proof of dispatch (a missing method answers with a `HubException` in
|
|
the next poll instead).
|
|
|
|
The panel's remaining warnings are the honest ones: "This scene has never been uploaded from Rec Room
|
|
Studio" and "Never save available on rec.net" are the empty `cloud-builds/for-room` page, and they go
|
|
away when `cloud-builds/create` and the build store exist.
|
|
|
|
## Keepsakes: what the reference server holds, and the store we built
|
|
|
|
There is a second reference in play now - a downloaded fork at
|
|
`rec-room-2023-server-main/rec-room-2023-server/asdfasdf` - so it is worth stating exactly what it
|
|
carries, because it is less than it looks. Five files mention keepsakes and only one of them holds
|
|
anything the client can use:
|
|
|
|
| file | contents |
|
|
|---|---|
|
|
| `keepsakes_categories.json` | the **real** catalog: 5 categories in a counted result set |
|
|
| `APIs/API.cs:186,527,539` | the same three GETs we serve: `categories` (reads the JSON), `globalconfig`, `rooms/{roomId}` -> `Results.NoContent()` |
|
|
| `KeepsakesConfig.cs` | empty stub classes, no code |
|
|
| `APIs/Auth.cs:227` | `"keepsake"` in a role array - inert |
|
|
| `ProgressionEvent.cs:15` | `KeepsakeRoomLists`, never assigned |
|
|
|
|
So the fork's keepsake endpoints are already byte-for-byte ours - the same 204 for a room, the same
|
|
config trio - **except that its catalog is populated and ours was empty.** That one file is the delta,
|
|
and it is trustworthy: each entry's field order matches the client's own
|
|
`KeepsakeCategoryConfigDTO(enum, string, int, int, string, string)` constructor, and its ids
|
|
(0 `explore`, 2 `presents`, 4/5/6 `science_core_*`) are the Science Core event this build's own
|
|
GameConfig text describes.
|
|
|
|
### What the client itself says it wants
|
|
|
|
Straight out of `global-metadata.dat` rather than inferred: the route literals are
|
|
`api/keepsakes`, `api/keepsakes/categories`, `api/keepsakes/events`, `api/keepsakes/globalconfig`;
|
|
the feature's error strings (`Failed to add keepsake`, `Failed to collect keepsake {0}`,
|
|
`Failed to delete keepsake {0}`, `Waiting for Keepsake Instance Data download...`,
|
|
`Cannot place additional keepsakes in this room!`) and the notification names
|
|
`KeepsakeInstanceAdded` / `KeepsakeInstanceRemoved` are all present. Our own log already showed the
|
|
three GETs firing on every room load (`rooms/25 -> 204`, `categories -> 200 len=43`,
|
|
`globalconfig -> 200 len=100`).
|
|
|
|
The one write-side payload we can read comes from the recflare reference's notify package, which
|
|
documents the captured shape:
|
|
|
|
```ts
|
|
/** `KeepsakeInstanceAdded` / `KeepsakeInstanceRemoved`. */
|
|
interface KeepsakeInstancePayload {
|
|
KeepsakeInstanceId: string // the GUID the room save carries
|
|
KeepsakeCategoryConfigId: number
|
|
PlacedByAccountId: number
|
|
RoomId: number
|
|
SubRoomId: number | null
|
|
}
|
|
```
|
|
|
|
Two things follow from that, and they drive the design. The instance id is a **GUID the room save
|
|
already contains** - the client writes it when an author places a keepsake - so the server must store
|
|
the id it is told, never mint its own; and a room whose save holds a keepsake with no row behind it is
|
|
precisely the state the keepsake runtime null-references.
|
|
|
|
### What shipped this session
|
|
|
|
* `KeepsakeInstances` and `KeepsakeCollectionRecords` (hand-written guarded migration
|
|
`20260927120000_AddKeepsakes`, the same style as the neighbouring ones).
|
|
* `GET api/keepsakes/categories` now serves the five real categories (`RADICADE_KEEPSAKE_CATALOG=empty`
|
|
restores the empty set; `RADICADE_KEEPSAKE_ICON=<name>` swaps both icon names, which is how we find
|
|
out which name the client actually reads).
|
|
* `GET api/keepsakes/rooms/{id}` is unchanged when nothing is placed (204) and serves
|
|
`{KeepsakeInstances, KeepsakeCollectionRecords, KeepsakeProgressionEventIds}` once something is -
|
|
the instances this caller has *not* collected, then their records.
|
|
* `POST api/keepsakes/rooms/{id}` places one, keeping the caller's GUID when it sends one;
|
|
`POST api/keepsakes/rooms/{id}/collect` records the pickup, once per player (a repeat keeps the
|
|
first timestamp).
|
|
* Anything else under `api/keepsakes` lands on a probe that names the call in the console and answers
|
|
**404, never 204**: a write that looks successful while the room save holds an id nothing backs is
|
|
the exact failure the empty catalog was protecting against.
|
|
|
|
The two open unknowns are both answered by that probe rather than by more guesswork: the exact
|
|
spelling of the collect/delete routes (the literals only prove `categories`, `events`, `globalconfig`,
|
|
`api/keepsakes`) and the JSON key the client reads for a placed instance. The next in-game attempt
|
|
prints them.
|
|
|
|
### The room that already has a keepsake in it
|
|
|
|
`RoomImports/Showdown/Showdown.room` - imported as an RRO at boot - contains a `keepsake` component
|
|
with a GUID beside it:
|
|
|
|
```
|
|
offset 585176: ... "keepsake" ... $a75f7547-79eb-47c6-8986-6767abcb4f92 ...
|
|
offset 591174: ... keepsake ... (the room's component-type table)
|
|
```
|
|
|
|
Nothing registers it yet, and that is deliberate: registering a *guessed* id is exactly the kind of
|
|
invented keepsake that faults a load. The right way in is the probe - join Showdown, watch which ids
|
|
the client reports, and store those.
|
|
|
|
### Keepsake rooms: how a room comes to be allowed to hold keepsakes
|
|
|
|
The banner this leaves behind - **"This room does not have keepsake permissions."** - is not a room
|
|
role. The client's room-permission enum is `CAN_EDIT_ROOM_ROLES ... CAN_USE_MAKER_PEN ...
|
|
CAN_USE_PLAY_GIZMOS_TOGGLE` with no keepsake entry in it, the room DTO has no keepsake field either,
|
|
and the fork's `ProgressionEvent.KeepsakeRoomLists` is never assigned. The only per-room keepsake
|
|
payload the client asks for while a room loads is `GET /api/keepsakes/rooms/{id}`, and the keys that
|
|
response may carry - out of the client's own metadata - are `KeepsakeProgressionEventIds`,
|
|
`KeepsakeRoomId`, `KeepsakeRoomLimit`, `KeepsakeRoomListId`, `KeepsakeRoomLists`, `KeepsakeRooms`.
|
|
So the permission arrives with the room's keepsakes or not at all, which is why every room answered
|
|
NO CONTENT and every placement answered with that banner.
|
|
|
|
A room is advertised as a keepsake room when it is listed in
|
|
`Server/RadicadeServer-Config/keepsake-rooms.json` (`{ "AllRooms": false, "RoomIds": [3, 25],
|
|
"RoomListId": 1, "RoomLimit": 100 }`) or when `RADICADE_KEEPSAKE_ROOMS` names it (ids, or `*` for
|
|
every room, with `RADICADE_KEEPSAKE_ROOM_LIST_ID` / `RADICADE_KEEPSAKE_ROOM_LIMIT` beside it). Those
|
|
rooms answer 200 with the keys above beside the three instance lists - and those lists stay honest,
|
|
so an empty keepsake room still carries nothing for the keepsake loader to resolve - and the server
|
|
logs `[Keepsakes] room {id} answered as a keepsake room: list ..., limit ..., N room(s) advertised,
|
|
M placed.` Every other room is unchanged: NO CONTENT, the old behaviour. **The config that ships
|
|
enables every room** (`AllRooms: true`): the banner is the symptom this exists to clear, so a
|
|
checkout that shipped it switched off would look exactly like the bug. Narrowing it back is an
|
|
operator edit - `AllRooms: false` plus the ids in `RoomIds`.
|
|
|
|
The file is re-read on every room load, so an edit applies to the next room a player enters with no
|
|
restart. That is verifiable without the game: with the running server on 3030, `curl -sk
|
|
https://localhost:3030/api/keepsakes/rooms/25` answered `204 0b` while `AllRooms` was false and
|
|
`200 381b` with `KeepsakeRoomId`/`KeepsakeRoomLimit`/`KeepsakeRoomListId`/`KeepsakeRooms`/
|
|
`KeepsakeRoomLists` the moment the file said `true` - same process, no relaunch.
|
|
|
|
**Confirmed in game.** With `AllRooms: true`, walking into room 25 clears the banner: those five
|
|
room keys ARE the permission, and the client asks for them every room load (`[Net] Get
|
|
.../api/keepsakes/rooms/25` in the 21:09 log, the first run that got far enough to make the call).
|
|
|
|
### Permission is not the whole gate: the keepsake comes from a progression event
|
|
|
|
Permission cleared the banner but left the MakerPen's keepsake tile reading **`x0`** - a room can be
|
|
allowed to hold keepsakes and still offer nothing to place. The second half is the progression
|
|
event:
|
|
|
|
* The room payload's `KeepsakeProgressionEventIds` names the event the room's keepsakes belong to
|
|
(the client's metadata spells the field run `EmptyKeepsakeProgressionEventIdsKeepsakeRoomId…`,
|
|
i.e. "empty" is its own state).
|
|
* `GET /api/progressionEvents/active` answers the active event's **ID** - a bare number, CONFIRMED:
|
|
with the id served, the client's log has no malformed line for this route at all, and the very
|
|
next calls are `GET /api/progressionEvents/event/1` and `GET /api/progressionEvents/record/1`
|
|
(the record asked four times in one session), i.e. `ProgressionEventDTO` and
|
|
`ProgressionEventRecordDTO` by id. Both were 404s here, so the id alone changed nothing on
|
|
screen; the record, its `KeepsakeRoomLists` and the palette's keepsake allowance all hang off
|
|
them.The client's progression-events client has exactly two no-argument calls, `KIJDNIPGGDC() ->
|
|
MFBKDKPGMNP<long?>` and a private one returning a record, and the id is what the model caches
|
|
first: `ABIEHIAHKJP(Nullable<long>)` is that field's setter and `BJKPLIJHAJK(long, bool)` is the
|
|
id-taking record fetch. A nullable long deserializes from none of the shapes this endpoint
|
|
answered before (`[]`, `{}`, and a full record), each logged by the client as `Malformed
|
|
Response: '<body>'`.
|
|
|
|
Both by-id payloads carry an `_route` marker (`"event"` / `"record"`). An unknown member is ignored
|
|
by the deserializer, so it costs nothing, and it is what makes a `Malformed Response: '<body>'` line
|
|
in the client's log name WHICH of the two the parser rejected - the log shows a body, never a URL.
|
|
* `RoomListModel.ApplyKeepsakeOverrides(ref eventRecord, RoomModel, long, int, long)` is the client
|
|
applying that record's `KeepsakeRoomLists` to a room, and the sibling members
|
|
`IsActiveEventKeepsakeEvent` / `GetKeepsakeRoomListIdFromRoomId` / `GetNextKeepsakeRoomUnlockTime`
|
|
are all event-shaped.
|
|
|
|
The record's field names come from the 2023 fork's own `ProgressionEvent` model
|
|
(`Downloads/rec-room-2023-server-main/.../ProgressionEvent.cs`) and each one is **present in this
|
|
build's `global-metadata.dat`**: `ProgressionEventId, Name, IsEnabled, UsesBoost, BoostXpMultiplier`
|
|
(the fork spells it `BoosXpMultiplier` - a typo), `BoostDailyGameplayMinutesLimit,
|
|
ActiveExperiment, StartTime, EndTime, CollectionEndTime, EventInfoImageName,
|
|
ChallengesIconImageName, RewardsPipImageName, PurchasableXpBoostId, Rewards, KeepsakeRoomLists`.
|
|
Two fork fields are NOT in this build and are left out: `EventLeaderboardId` and
|
|
`InitialCurrencyGrant`. The event is windowed around the current time (start -30d, end +1y) rather
|
|
than pinned to a date, so a machine whose clock is in any year still sees it running.
|
|
|
|
The event's `KeepsakeRoomLists` carry the same one-list entry the room payload carries (from
|
|
`KeepsakeRoomConfig.RoomListEntries`), because the client's copy of the event OVERRIDES the room's:
|
|
a room the event's list does not mention would be overridden straight back to no permission. Under
|
|
`AllRooms` the event's copy carries no member rooms - they cannot be enumerated - and the room's own
|
|
copy is what names it.
|
|
|
|
**The event payloads were rejected, and the client's own log says so.** The game writes every
|
|
session to `BepInEx/LogOutput.log`, which the plugin's `[LogGate]` feeds: the room's keepsake answer
|
|
never appears in a `Malformed Response` line, but the event bodies do, verbatim - the whole record
|
|
(`Malformed Response: '{ "ProgressionEventId": 1, "Name": "Science Core", ...'`) and, after it was
|
|
narrowed to identity + window + keepsake lists, the narrowed one too (the log's truncation lands on
|
|
`"StartTime"` right after `"IsEnabled"`, which is how the two payloads are told apart). Both come
|
|
from `EFMPNEEHJFJ.CMKDNAPFCOI[T]`. Two things follow:
|
|
|
|
* **Unknown members are ignored**, so a name that is merely absent costs nothing - which is why the
|
|
room's answer parses even though it carries six keys `KeepsakeRoomInstancesDTO` does not declare
|
|
(that is the answer that cleared the banner).
|
|
* A name whose TYPE is wrong fails the *whole* response, so the fix is to send FEWER names, not
|
|
more: every field that belongs to a neighbouring DTO rather than to this record is now out - the
|
|
XP-boost family (`BoostXpMultiplier`, `BoostDailyGameplayMinutesLimit`, `UsesBoost`,
|
|
`PurchasableXpBoostId`, all of which live on the boost DTOs) and the image-name fields (which may
|
|
be typed image references rather than strings). What is left is the event's identity
|
|
(`ProgressionEventId`, `Name`, `IsEnabled`), its window, `Rewards`, and `KeepsakeRoomLists`.
|
|
|
|
Two knobs stay for the next narrow. `RADICADE_KEEPSAKE_EVENT_LISTS=empty` sends `KeepsakeRoomLists:
|
|
[]` in the record instead - an empty array deserializes for a list of anything, so if the malformed
|
|
line disappears with it set and returns without it, the entry shape is what the record rejects.
|
|
`RADICADE_PROGRESSION_ACTIVE=record` serves the record AT `/api/progressionEvents/active` instead of
|
|
the id, for the case where that endpoint turns out to be the client's other no-argument call. The
|
|
server console names which it served: `[ProgressionEvent] active -> 1` or `[ProgressionEvent] record
|
|
1 served (all keepsake list(s), list 1, limit 100).`
|
|
|
|
**How to read the next run.** Walk into a room and place a keepsake; the server console names both
|
|
halves of the answer:
|
|
|
|
```bash
|
|
grep -n "Keepsakes]" server-console-runNN.log # the room's answer, and any placement
|
|
```
|
|
|
|
A `POST /api/keepsakes/rooms/{id}` answered `accepted` means the tile had something to place. If the
|
|
tile still reads `x0`, the next lever is the event's contents rather than the room's permission -
|
|
and any keepsake call this server does not implement is still named by the `[Keepsakes] unclaimed
|
|
METHOD path body=…` probe (which answers 404 on purpose). `GET /api/keepsakes/events` is the one
|
|
keepsake route still stubbed to `[]`; the client's own route table (the literal run
|
|
`api/keepsakes api/keepsakes/categories api/keepsakes/events api/keepsakes/globalconfig` in
|
|
`global-metadata.dat`) shows those four are the whole keepsake surface, with the room route built
|
|
beside them.
|
|
|
|
## Saving an outfit: the route the client posts to, and the 404 it met
|
|
|
|
The client's `POST /econ/api/avatar/v4/saved/set` answered 404: this server had the saved-outfit
|
|
routes on **v3 only** (`GET /api/avatar/v3/saved`, `GET /api/avatar/v3/saved/{accountId}`,
|
|
`POST /api/avatar/v3/saved/set`), while the 2023 build reads its list from v3 and *writes* through
|
|
v4. The client's own route table in `global-metadata.dat` names the three avatar routes it knows:
|
|
|
|
```
|
|
api/avatar/v4/items api/avatar/v4/saved/name api/avatar/v4/saved/set
|
|
```
|
|
|
|
so the missing pair was `saved/set` and `saved/name` (`items` already existed). Only `saved/set` is
|
|
implemented here; nothing in this build has been seen calling `saved/name`, and a route invented
|
|
without knowing the shape it must answer is worse than a 404 that names itself.
|
|
|
|
**v3 and v4 share one slot table.** Both post the same payload and both expect "save over this
|
|
outfit" to mean *re-save an existing slot*, and the client reads the result back through v3. Two
|
|
tables would let a player save an outfit that their own outfit list cannot find, so the slot
|
|
bookkeeping lives in one place (`RecNet/Avatar/SavedOutfits`) and each version is only a shape:
|
|
v3 echoes the outfit back, v4 answers the lean acknowledgement the client expects - `{ Success,
|
|
Slot }` - which is what the reference servers do too.
|
|
|
|
Two things behind the 404 were wrong and had gone unnoticed because the route that used them was
|
|
never reached by this client:
|
|
|
|
* `Outfit.Slot` was a **string**; the client posts an **integer** (`Slot: 0..n`). Deserializing the
|
|
client's body into the old DTO could not have bound, so even a v3-shaped route would have failed
|
|
on the body. It is `int?` now, and the payload's other two members (`OutfitSelectionsV2`,
|
|
`CustomAvatarItems`) are declared so they survive the round trip instead of being dropped on save.
|
|
* A body with **no slot** was accepted and stored as a literal `null` entry - the `[null]` an
|
|
earlier empty-body post left on account 2 is exactly that. A missing slot is now a 400, matching
|
|
the reference server: defaulting it would overwrite slot 0, the one outfit the player did not ask
|
|
to replace. Stored blobs are also filtered on read, so that legacy `[null]` is dropped rather than
|
|
handed to the client as an entry it cannot parse.
|
|
|
|
Verified live against the running server: no token is a `401` (the route exists), a body without a
|
|
slot is a `400`, a real save is `200 {"Success": true, "Slot": 0}`, and
|
|
`GET /econ/api/avatar/v3/saved` serves that outfit back with its selections verbatim. The writes
|
|
were made on a throwaway slot and account 2's stored blob was restored afterwards.
|
|
|
|
## Loading a room: what the second-per-second actually goes to
|
|
|
|
A room join is slow - minutes for a Rec Room Studio room, and uncomfortably long even for a Dorm
|
|
whose save is 1.8 KB - and the log's own numbers say why. Measured against live from the client's
|
|
machine:
|
|
|
|
| Measurement | Result |
|
|
| --- | --- |
|
|
| Fresh HTTPS request to the API | 0.57 - 0.86 s (`dns 0.28` + `tcp 0.19` + `tls 0.2` + server) |
|
|
| Second request on the same connection | **0.19 s** |
|
|
| Server-side work for a trivial route (`/api/version`) | the same 0.19 s as any other route |
|
|
| CDN asset bundle, one stream | 10 - 12 MB/s (85 MB ⇒ ~8 s) |
|
|
| TLS session resumption | already working (`Reused, TLSv1.3`) |
|
|
|
|
0.19 s for *every* route including a no-op one is ~2 RTT to the VPS, which is 100 ms away - the
|
|
server is not spending that time, the wire is. So a room load costs what it costs because the client
|
|
makes dozens of calls and **opens a fresh TLS connection for each one** (the `[TLS] Accepting server
|
|
certificate ...` line is printed again before every single request in the log). Nothing server-side
|
|
removes that; two things were making it worse:
|
|
|
|
* **`GET /econ/api/roomcurrencies/v1/getBalance` did not exist.** The client asks it immediately
|
|
after `getAllBalances` on every room join and retries an answer it cannot use; a 404 is an
|
|
exception plus another round trip per retry. Nothing here tracks room-currency balances, so it now
|
|
answers `200` with a zero balance that echoes the currency and account asked for
|
|
(`RoomCurrencyAPI.GetBalance`).
|
|
* **The CDN sent no `Cache-Control` at all.** `Accept-Ranges`, `Content-Length` and `Last-Modified`
|
|
were there, but nothing told the client it may reuse bytes it already has - and for a Studio room
|
|
the bytes in question are the entire asset bundle. Blob and asset routes now send
|
|
`public, max-age=31536000, immutable` for `.assetbundle` names (the id is minted per upload, so a
|
|
different bundle is a different URL) and `public, max-age=86400` for everything else, because an
|
|
admin repair can replace a room save under its existing name (`VPS/fix-dorm-blob.sh`).
|
|
|
|
### Two things in the log that are not what they look like
|
|
|
|
`Malformed Response: '[]'`, `'{}'` and `'[ {...rooms...} ]'` are thrown by the client's obfuscated
|
|
DTO reader, which **reads members positionally** - the same property `AlgorithmicListsAPI` documents
|
|
for `lists/algorithmiclists`. An empty body is therefore not a valid "nothing here" answer, and the
|
|
client retries instead of moving on. Several routes still answer that way by design (keepsakes off,
|
|
`progressionEvents/active`, `roomkeys/v1/room`); the retries are visible as 4x `photon_access_token`
|
|
and 5x `experience/player` per join.
|
|
|
|
`Exception: Can't parse '' as a hex number!` fires ~112 times per session and is **not**
|
|
`PhotonAccessToken` being empty, despite that field being `""` in
|
|
`GET /rooms/photon_access_token`: the client fetches that route 7 times per session, and both
|
|
reference servers return `""` there too (`config/v1`'s `UseNewPhotonAuthToken` is `false`, so the
|
|
token is not used for the join). Whatever parses hex 112 times is elsewhere, and changing the token
|
|
to guess would risk the joins that currently work.
|
|
|
|
### The failure at the end of a slow load
|
|
|
|
`Unexpected Photon Disconnect due to cause: ServerTimeout` is what the client reports as *"Failed to
|
|
load room due to disconnect during load (Code 8706-3)"*: the load outlives the room's Photon
|
|
connection. The room-load stage timeouts are ours to set and are generous
|
|
(`RoomLoad.DownloadAssetBundleTimeoutSeconds = 900`, `PreDownloadTimeoutSeconds = 120`,
|
|
`PostDownloadTimeoutSeconds = 240`); the Photon peer timeout is not in that table, so the lever there
|
|
is client-side, not a config key.
|
|
|
|
Verified locally against a dev server, then the server was stopped:
|
|
|
|
```
|
|
GET /econ/api/roomcurrencies/v1/getBalance?currencyId=...&accountId=2 -> 200 {"CurrencyId":...,"AccountId":2,"RoomId":0,"Balance":0}
|
|
GET /cdn/data/{blob}.room -> 200 Cache-Control: public, max-age=86400
|
|
GET /cdn/data/{id}.assetbundle -> 200 Cache-Control: public, max-age=31536000, immutable
|
|
GET /cdn/data/{id}.assetbundle (-r 0-1) -> 206, Content-Range: bytes 0-0/1, same directive
|
|
```
|
|
|
|
Tests: the two CDN routes and `getBalance` are pinned in `CdnRangeRequestTests` and
|
|
`RoomEconomyPersistenceTests` (8/8), and the full suite is 688 passed / 1 failed - the pre-existing
|
|
`AvatarCatalogSourceTests.ShippedLookupCoversTheCatalogServedToClients`.
|
|
|
|
## Run 30 fixes (2026-10-01): the ambiguous routes, the club category rows, the carousel envelope
|
|
|
|
One landed batch from a single player report. Each item is the client's own URL, taken from
|
|
`BepInEx/LogOutput.log` / `Player.log` in the deployed client rather than from the templates.
|
|
|
|
### `AmbiguousMatchException` (HTTP 500) on the club member actions
|
|
|
|
`ClubsAPI` carries `[Route("clubs/club")]` (plus the `api/clubs/v{1,2}/club` copies), so an action
|
|
with BOTH the class-relative template `{clubId}/minlevel` and an absolute
|
|
`~/clubs/club/{clubId}/minlevel` registers the same path twice. ASP.NET reports that as ambiguity,
|
|
so *every* request to it threw before any handler ran - `PUT minlevel`, `POST|DELETE members/remove`,
|
|
`PUT members/invite` and the accept/decline actions were all dead. The absolute `~/clubs/club/...`
|
|
copies are removed (the `~/club/...` aliases are a different path and stay); the same duplication in
|
|
`ClubAnnouncementsAPI` and `api/playerevents/v1/report` (EventsAPI owns v1, ContentReportAPI keeps
|
|
v2) went with them, and `PATCH admin/panel/{table}/{id}` vs `{id:long}` is now one action that
|
|
parses the id. `ServerTests/RouteAmbiguityTests.cs` reflects over every controller and asserts no
|
|
(method, path) pair has two owners, so this cannot come back silently.
|
|
|
|
### `POST clubs/club/{id}/members/acceptinvite` -> 405
|
|
|
|
The string literals (and the log) show the client accepts an invitation at `.../members/acceptinvite`;
|
|
the server only ever registered `.../members/accept`, so the invite notification led nowhere. Both
|
|
verbs are registered now, with `declineinvite` and `changetype` beside them, and `invitemembers`
|
|
joins `invite`. The invite reader also accepts the field spellings the reference DTO allows
|
|
(`accountId`/`accountIds`/`playerId(s)`/`targetPlayerIds`, single or repeated) instead of only
|
|
`accountId`, which is what silently invited nobody.
|
|
|
|
### `POST econ/api/influencerpartnerprogram/remove` -> 415
|
|
|
|
The economy client does not post JSON, and `[FromBody]` only accepts JSON content types. The handler
|
|
reads the fields from the query string, a urlencoded form or a JSON body (content type or not), the
|
|
same way `redeem` does.
|
|
|
|
### `DELETE api/customAvatarItems/v1/{guid}` -> 405 and `POST .../report` -> 404
|
|
|
|
The item's editor addresses it by id: `PUT` (metadata edit) and `DELETE` (remove) are registered
|
|
alongside the existing `GET`, both owner-gated, and the item report route resolves the item's creator
|
|
as the reported player before funnelling into the shared `SubmitReport`.
|
|
|
|
### `GET matchmaking/room/{roomId}/instances` -> 204
|
|
|
|
The instance browser is the watch menu every player opens for the room they are in. It required
|
|
`RoleType.Moderator` and answered `null` to everyone else - `null` serialises to 204 No Content,
|
|
which the client renders as "Failed to get room instance browser: Response was empty". It now
|
|
answers an array (empty when the room has no live instance) to any signed-in caller.
|
|
|
|
### "Clubs are appearing in every single category"
|
|
|
|
The Clubs screen asks `clubs/club/categoryTags` for its categories and then fetches each row on its
|
|
own: `GET clubs/club/search?sort=0&category=Social&count=32`, one call per tag. The server ignored
|
|
`category` and returned the whole catalogue, so the single club was drawn in every row.
|
|
`ClubStore.CategoryFilter`/`MatchesCategory` now filter on `primaryTag` or `customTags`
|
|
(case-insensitive, `#tag` tolerated) for `search`, `mostactivetoday`, `mostactivenow` and
|
|
`search/mostactivenow`; a request with no category still gets everything.
|
|
|
|
### `Error refreshing rooms from source CarouselEndpoint`
|
|
|
|
Still one per Play-menu open, and now explained: the client's template for the row is
|
|
`rooms/carousel/{0}&skip={1}&take={2}` (a paged read), and the client logged our answer as
|
|
`Malformed Response: '[ { "RoomId": 167, "IsDorm": false, ... } ]'` - a bare array where it reads
|
|
`{ Results, TotalResults }`, the envelope every sibling `*_rooms/{source}&skip=&take=` feed already
|
|
answers with. `rooms/carousel/{*source}` answers that envelope now. The earlier "a bare array works"
|
|
conclusion came from a run whose Play menu was fed by `lists/algorithmiclists` + `rooms/bulk`
|
|
instead, so the route had never actually been read by the client.
|
|
|
|
Tests: `RouteAmbiguityTests`, `ClubCategoryDiscoveryTests` (9), `CarouselFeedShapeTests` (3) and
|
|
three new instance-browser cases in `MatchmakeInstanceRouteTests`; full suite 798 passed / 9 failed,
|
|
all nine the pre-existing catalog set (`AvatarCatalogSourceTests`, `DorkNetCatalogTests`,
|
|
`EquipmentInventoryTests`, `StorefrontRewardConfigTests`).
|
|
|
|
## Run 34 (2026-10-15, live): every room's bundle answered `400`, so no room loaded its content
|
|
|
|
### What the player saw, and what it was not
|
|
|
|
"Error downloading room assets! Try again later or on a better connection." on every room, for every
|
|
player. In `Player.log` the exception surfaces inside `RoomLoad.RoomManager` and the client reports
|
|
`FailedToSpawnPlayer / (Code 8715)` to matchmaking; the Zenject
|
|
`InvalidOperationException: You should not try to retrieve bindings from a disposed container!` that
|
|
follows is that failed load task being torn down, not a second fault. Nothing in the client's own log
|
|
names the request, which is what made this look like a connection problem.
|
|
|
|
### The request the client was actually making
|
|
|
|
`BepInEx/LogOutput.log` logs every call with its status, and it has the answer:
|
|
|
|
```
|
|
[HttpStatus] #322 Get /rooms/unity_assets/Showdown_0_1.assetbundle/0/1 -> 400 bytes=39 reason=Bad Request
|
|
[HttpStatus] #543 Get /rooms/unity_assets/2n8bbqwnk6zs6k2blzgcdhcnc.assetbundle/0/1 -> 400 bytes=39 reason=Bad Request
|
|
```
|
|
|
|
Room 247 is the `MAKER_ROOM:247/313` in the error: subroom 313 advertises
|
|
`UnityAssetId: 2n8bbqwnk6zs6k2blzgcdhcnc.assetbundle`, and step two of the download is healthy -
|
|
|
|
```
|
|
GET /data/2n8bbqwnk6zs6k2blzgcdhcnc.assetbundle -> 200 68,673,320 b
|
|
GET /rooms/rooms/247?include=5421&unityAssetTarget=0&unityAssetVersion=1
|
|
-> 200 SubRooms[0].UnityAssetId = 2n8bbqwnk6zs6k2blzgcdhcnc.assetbundle
|
|
```
|
|
|
|
- so step one, the metadata call, was the only thing broken, and it was broken for every id of that
|
|
shape on the server rather than for one room.
|
|
|
|
### The regression, in one line
|
|
|
|
`b33d5b3` ("Checkpoint the in-flight work before merging origin/2023") reworked `UnityAssetsCDN` for
|
|
the Studio pipeline and put this in front of the resolution:
|
|
|
|
```csharp
|
|
if (!StudioUnityAssetRegistry.IsValidAssetId(assetId) || target < 0 || ...) return BadRequest();
|
|
```
|
|
|
|
`IsValidAssetId` is `value is { Length: 40 } && value.All(char.IsAsciiLetterOrDigit)` - the shape of a
|
|
Studio manifest id, and of nothing else that is stored as a bundle. Every legacy id fails it:
|
|
`Showdown_0_1.assetbundle` (23 characters, `_` and `.`), the 24-character RecNet ids
|
|
(`2n8bbqwnk6zs6k2blzgcdhcnc`, `8aas7b5ivtaggn9swhe3wkgdj`), the 36-character dashed id the importer
|
|
binds (`32cafb11-c51b-485c-8f1f-73b73159feff`), and the built-in rooms' `*_0_1.assetbundle` names.
|
|
`ResolveLegacyFilename` was still underneath, unreachable for exactly the ids it exists for, so every
|
|
room whose subroom points at a bundle - which is every room with custom content, for every player -
|
|
answered `400 {"success":false,"error":"bad request"}`. The pre-Studio file had no such gate:
|
|
`ResolveFilename(assetId)`, the id with no extension first, then the id plus `.assetbundle`.
|
|
|
|
### What changed
|
|
|
|
`Server/CDN/UnityAssetsCDN.cs` - 40 alphanumerics *with a manifest behind them* is still the Studio
|
|
path, and a target/version its metadata does not name is a `404` (the file stored under a manifest id
|
|
is the manifest JSON, so it must never be handed over as a bundle). Everything else resolves as a
|
|
stored file: the name as given first, then `<name>.assetbundle`.
|
|
|
|
`Server/CDN/CdnStorageNames.cs` (new) holds the two read-side rules the blob routes share - one bare
|
|
file name in that one directory (no separator, no `..`), never a name ending in the admin upload's
|
|
`.uploading` suffix, and `<id>` resolving to `<id>.assetbundle` - and `DataCDN`, `RoomsCDN` (both the
|
|
`/cdn/room` + `/unity` blob route and the raw `{assetId}/{target}/{version}` route) and
|
|
`InventionCDN` all go through it. Two things fall out of that: `/data/<name>.uploading` no longer
|
|
serves a half-imported bundle by name, and the bare `/unity/{id}` alias now answers for a bundle
|
|
stored only as `<id>.assetbundle` - the hard link per bundle that Run 31 needed is no longer
|
|
required.
|
|
|
|
### Verified
|
|
|
|
`ServerTests/UnityAssetMetadataTests.cs` (21 cases: both spellings of three id shapes, the Studio
|
|
manifest with and without a bake, the manifest never served as a bundle, an id that only looks like a
|
|
manifest, unknown names, separators and `.uploading`, out-of-contract target/version, and the blob
|
|
routes) - 21/21. `CdnRangeRequestTests`, `StudioUploadTests`, `AdminRoomImportTests`,
|
|
`AdminRoomPartUploadTests`, `AdminBundleBindingTests` together with it: 59/59.
|
|
|
|
Live on a local instance (Development, cwd `Server`, `http://127.0.0.1:3031`, storage
|
|
`Server/RadicadeServer-Data/CDN/Storage`), the URL from the player's log:
|
|
|
|
```
|
|
GET /rooms/unity_assets/Showdown_0_1.assetbundle/0/1 -> 200
|
|
{"UnityAssetId":"Showdown_0_1.assetbundle","Target":0,"Version":1,
|
|
"Filename":"Showdown_0_1.assetbundle","RejectedDependenciesFilename":null}
|
|
GET /rooms/unity_assets/Showdown_0_1/0/1 -> 200 Filename="Showdown_0_1.assetbundle"
|
|
GET /rooms/unity_assets/Showdown_0_1.assetbundle -> 200 (the short form)
|
|
GET /rooms/unity_assets/not-on-disk.assetbundle/0/1 -> 404 {"success":false,"error":"not found"}
|
|
GET /data/Showdown_0_1.assetbundle (Range 0-15) -> 206 16 b, Accept-Ranges: bytes
|
|
GET /unity/Showdown_0_1 -> 200 76,719,774 b (was 404 without the hard link)
|
|
GET /data/Showdown.room -> 200 1,222,161 b
|
|
```
|
|
|
|
and the refusals, with the file present on disk so the rule is what refuses:
|
|
|
|
```
|
|
GET /data/probe-upload.assetbundle.uploading -> 400 (was 200, a truncated bundle)
|
|
GET /rooms/unity_assets/probe-upload.assetbundle.uploading/0/1 -> 400
|
|
GET /rooms/unity_assets/..%2F..%2Fappsettings.Development.json/0/1 -> 400
|
|
GET /data/../appsettings.Development.json -> 404
|
|
```
|
|
|
|
The probe file was removed afterwards and the instance stopped; nothing left listening on 3030/3031.
|
|
|
|
Full suite: 1556 passed / 12 failed. Eight of the twelve fail identically with this change stashed
|
|
out (the catalog set the Run 30 note records: `AdminGiftSkinTests`, `ConnectionRecoveryTests`,
|
|
`DorkNetCatalogTests` x2, `EquipmentInventoryTests` x2, `StorefrontRewardConfigTests`,
|
|
`WeeklyChallengeTests`), and the other four (`GameRewardFlowTests` x2, `RecNetShapeConformanceTests`
|
|
x2) pass when their classes run alone and mutate the same two statics -
|
|
`DBConfig.DefaultAvatarCatalog` / `DefaultAvatarUnlocks` - that `AvatarCatalogSourceTests`,
|
|
`AvatarWireFormatTests` and `EquipmentInventoryTests` write from parallel collections. That race is
|
|
pre-existing and is not this change's.
|
|
|
|
Not verified: nothing was deployed, so production still answers the `400` until the server is
|
|
rebuilt and restarted, and the client has to rejoin room 247 to confirm the load.
|
|
|
|
## Run 35 (2026-10-15, live): the join box had no sender, so the client had no name to put on it
|
|
|
|
### The box already carried a sender - no room could set one
|
|
|
|
RecNet's `Gift.FromPlayerId` is the field the client reads to name a box's sender, and the panel's own
|
|
Gift Player page already lands there (`AdminGiftFromTests`). A room's join gift built its `Gift` in
|
|
`RoomJoinGiftUtils.TryDeliverAsync` and left `FromPlayerId` at its default of zero, so every join box
|
|
arrived from nobody, and no room setting could change that.
|
|
|
|
### What changed
|
|
|
|
- `RoomData.JoinGiftFromPlayerId` (bigint, `0` = no sender), added both by
|
|
`20261015120000_AddRoomJoinGiftFromPlayerId` and by `EnsureRoomJoinGiftColumns` for a database whose
|
|
migration history is already past that point.
|
|
- `RoomJoinGiftUtils.TryDeliverAsync` puts it on the box it hands out on join.
|
|
- The admin panel's Room Details modal carries a FromPlayerId inside the Gift Box On Join block
|
|
(`assets/js/rooms.js` in `Radicade-Admin`), and `AdminPanelAPI.UpdateRoom` reads
|
|
`join_gift_from_player_id`, refusing anything that is not digits rather than dropping it quietly.
|
|
|
|
The id travels as digits in a string, never as a JSON number: an account id is eighteen digits, a JSON
|
|
number is read back as a double, and its last digits are rounded away - so the panel would save a
|
|
different account than the one it was shown. The room row the panel reads and the value it posts are
|
|
both text, the same way the Gift Player page already posts ids.
|
|
|
|
Only a sender that actually changes bumps `JoinGiftVersion`, so a save that leaves the field alone does
|
|
not hand every player a fresh box.
|
|
|
|
### Verified
|
|
|
|
`ServerTests/RoomJoinGiftFromTests.cs`, 8/8, driving the real routes and then reading the box the way a
|
|
client does (`GET api/avatar/v2/gifts`, asserted on the wire JSON): the saved sender becomes the box's
|
|
sender; an eighteen-digit id survives the panel both ways; a changed sender re-issues the box while a
|
|
save that leaves it alone does not; a blank clears it back to no sender; a payload without the field
|
|
keeps the stored sender; a non-digit value is a `400`; and a room that names no sender still hands out
|
|
its box.
|
|
|
|
Live on a local instance (Development, cwd `Server`, `http://127.0.0.1:3031`, SQL Server
|
|
`.\SQLEXPRESS`) the migration applied on startup and the route behaved:
|
|
|
|
```
|
|
Applying migration '20261015120000_AddRoomJoinGiftFromPlayerId'.
|
|
GET /admin/panel/rooms -> 200 all 45 rooms carry
|
|
"join_gift_from_player_id": "0"
|
|
PATCH /admin/panel/rooms/58 {"join_gift_from_player_id":"114903603133502227"}
|
|
-> 200 {"success":true}
|
|
GET /admin/panel/rooms/58 -> 200 "join_gift_from_player_id": "114903603133502227"
|
|
"join_gift_version": 2 (was 1)
|
|
PATCH /admin/panel/rooms/58 {"join_gift_from_player_id":"not-a-player"}
|
|
-> 400 'join_gift_from_player_id' must be
|
|
an account id in digits, or blank
|
|
for no sender. (room untouched)
|
|
PATCH /admin/panel/rooms/58 {"join_gift_from_player_id":"","join_gift_version":1}
|
|
-> 200 "join_gift_from_player_id": "0"
|
|
"join_gift_version": 1
|
|
```
|
|
|
|
Room 58 was left exactly as it started (no sender, version 1) and the instance was stopped; nothing
|
|
left listening on 3031.
|
|
|
|
Not verified: the modal itself was not clicked in a browser - the panel sits behind SSO, so the served
|
|
page redirects before the room list loads. `rooms.js` was parsed as a classic script in the browser
|
|
(`new Function` over the served file, no `SyntaxError`) and its field markup and save handler read;
|
|
nothing was deployed, so production needs a rebuild and a restart, at which point the column arrives
|
|
with the rest of the startup migrations.
|
|
|
|
Full suite: 1566 passed / 10 failed / 1 skipped, and every failure is one the Run 34 note already
|
|
records as pre-existing: `AdminGiftSkinTests` (x1), `ConnectionRecoveryTests` (x1),
|
|
`DorkNetCatalogTests` (x2), `EquipmentInventoryTests` (x2), `StorefrontRewardConfigTests` (x1),
|
|
`WeeklyChallengeTests` (x1), and the two order-dependent `RecNetShapeConformanceTests` avatar-catalog
|
|
cases that mutate `DBConfig.DefaultAvatarCatalog` / `DefaultAvatarUnlocks` from parallel collections.
|
|
The two `GameRewardFlowTests` scheduled into that same race passed this run.
|