Radicade/docs/2023-ONBOARDING-FORCE-NOTES.md

# Forced new-account onboarding: what the 2026-10-12 runs proved

The client-side force (`2023Patch/RadicadeSeptemberClient/ForcedNewAccountOnboarding.cs`) has been
removed. This file records what it measured, because the measurements are the useful part and
several of them contradict the guesses that built it.

The conclusion they point at: **this is a server-side problem.** The 2023 client decides everything
about the title screen from data the server sends it, and every attempt to override that decision
inside the client either did nothing or produced a state the client was never designed to be in.

## 1. Where the title screen decision is actually made

From the Beta install's `BepInEx/LogOutput.log`, in this order, before the token request:

```
[Onboarding] enter KFGCEPNLFBA        (BaseRouteFlowModel route-flow update)
[Onboarding] enter NHAJFLJDHBA        (route-flow getter)
[Onboarding] exit  NHAJFLJDHBA => HHGLIBCDIDA
[Onboarding] enter get_IsInAccountCreationState
[Onboarding] exit  get_IsInAccountCreationState => false      <- and then "Welcome back!"
[Net] Post /auth/connect/token   [AuthGrant] grant_type=cached_login
```

So the question the client asks itself is "am I mid-account-creation?", answered **before** it
decides how to sign in, from the player-settings markers it holds:

- `Recroom.AccountCreation.HasStarted`
- `Recroom.AccountCreation.HasFinished`

and it reads those back out of `GET /playersettings/playersettings`. Answer `false`, and the client
takes the cached-account route and resumes with `grant_type=cached_login`.

`get_IsInAccountCreationState` and `get_IsInCachedAccountState` are both `public bool` getters on
`RRUI.Data.TitleScreenFlowModel` — cheap to patch, and the first one is definitely called. Overriding
it was tried: it answers the question the *client* asks, but the client is not the only thing that
decides, so the result was a different sign-in, not a different flow (see 3).

## 2. The flow update crashes when the cached-account list is not empty

`RRUI.Data.TitleScreenFlowModel.OFOIOHEFGAB()` is the client's own title-screen update. In the runs
where the server returned a real cached account, it threw, immediately after that response arrived:

```
[Net] Get /auth/cachedlogin/forplatformid/{redacted} -> 200 bytes=179
[Onboarding] enter OFOIOHEFGAB
Exception: Il2CppInterop.Runtime.Il2CppException: System.NullReferenceException
  at RRUI.Data.TitleScreenFlowModel.OFOIOHEFGAB ()
```

In the run where the same endpoint answered `[]` (2 bytes, no account), the same method did **not**
throw, and no `[ForceOnboard] ... OFOIOHEFGAB threw` line was recorded all run. Same client build,
same plugins; the only difference was that one response.

That member is what moves the title screen to its next page. While it throws, no page — the
client's or a patch's — is applied, which is why "the hook installed but the screen did not move"
looked like a patching problem for so long. It is worth finding out whether the client is being
handed a cached account that is missing something the real service always sends.

What the server sends for that endpoint today (live, `forplatformid/0/76561198624498265`):

```json
[{ "accountId": 18, "platform": 0, "platformId": "76561198624498265",
   "lastLoginTime": "2026-10-12T14:41:14.8984545", "requirePassword": false }]
```

## 3. Overriding the state changes the sign-in, not the flow

With `get_IsInAccountCreationState` forced to `true`:

```
[ForceOnboard] forced get_IsInAccountCreationState false -> true
[HttpStatus] #6  Get  /auth/cachedlogin/forplatformid/{redacted} -> 200 bytes=2      (empty)
[AuthGrant]  connect/token grant_type=create_account                                 (was: cached_login)
[HttpStatus] #8  Post /auth/connect/token -> 200 bytes=703
... token claims carry "userId":"19" ...
[HttpStatus] #26 Post /matchmaking/player/login -> 200
```

The client left the cached-account path, which is what was wanted, and then **provisioned a brand-new
account** rather than being put through the flow for the account that already existed. The creation
pages' own hooks (`SubmitAvatarCustomizationAndGoToNext`, `SubmitAccountCreationBirthdayAndGoToNext`,
`AcceptCodeOfConductAndGoToNext`, `LaunchGameAccountCreation`) never fired: the client did not walk
the pages, it just made an account and launched.

So forcing the state gets a new account, not onboarding. The account that *needs* onboarding is
chosen by the server, from `CachedLogins` and the creation markers.

## 4. Two server-side things found on the way

**The standalone guard cannot fire for this client.** `Server/Auth/Cached/CachedLoginAPI.cs`:

```csharp
if (platform == Platforms.Standalone) return Ok(new List<CachedLogin>());
```

`Platforms.Standalone` is `7`, but this client identifies as platform `0` (**Steam**, with a SteamID64
as its platform id — `"rn.plat":"0"`, `"rn.platid":"76561198624498265"` in its own token). That guard
therefore never applies to the build being tested, and the row is returned.

**Two SteamIDs appear for the same machine.** `...24498265` (account 18, the one with the cached
row) and `...23533377` (the identity that created account 19). A platform change explains it, but it
means `CachedLogins` is keyed on the *platform identity*, not on the machine, and a device that
changes platform looks like a brand-new device to every "has this device been here before?" rule in
`AuthAPI` and `PlayerUtils`.

## 5. Client interop facts worth keeping

`RRUI.Data.TitleScreenFlowModel`, from `BepInEx/interop/Assembly-CSharp.dll` (metadata, not inferred):

| Member | Signature |
|---|---|
| `HBKLANJACMF` | `void (JPDJBDGFIGP)` — the page navigator; its parameter is *named* `ENNJBOCEGDH`, which is why a named-value-type prefix was rejected by HarmonyX |
| `DBHMKMHNJOO` | `JPDJBDGFIGP ()` — the reported page |
| `get_IsInAccountCreationState` | `bool ()` |
| `get_IsInCachedAccountState` | `bool ()` |
| `OFOIOHEFGAB` | `void ()` — the title-screen update |
| `KFGCEPNLFBA` | `void ()` — the route-flow update |
| `get_LocalAccount` | `INMPLDLFHAF ()` |
| `LaunchGameCachedAccount` / `LaunchGameAccountCreation` | `void ()` |
| `SubmitAccountCreationBirthdayAndGoToNext`, `SubmitAccountCreationUsernameAndGoToNext`, `SubmitAccountCreationPasswordAndGoToNext`, `AcceptCodeOfConductAndGoToNext`, `SubmitAvatarCustomizationAndGoToNext` | `void ()` |

Page enum `JPDJBDGFIGP`: `TITLE_SCREEN_NEW_ACCOUNT = 8`, `TITLE_SCREEN_CACHED_ACCOUNT = 9`,
`TITLE_SCREEN_INTERRUPTED_ACCOUNT_CREATION = 10`, `AVATAR_CUSTOMIZATION = 18`, `BIRTHDAY = 19`,
`USERNAME_NON_JUNIOR = 20`, `USERNAME_JUNIOR = 21`, `PASSWORD = 22`.

`TitleScreenFlowModel` also exposes `initialBootPage`, `titleScreenNewAccountPage`,
`titleScreenCachedAccountPage`, `titleScreenInterruptedAccountCreationPage`, `avatarCustomizationPage`,
`birthdayPage`, `usernamePage`, `passwordPage`, `accountCreationCodeOfConductPage`,
`accountCreationLaunchGamePage` as `TitleScreenPage` properties, and the flow navigates by
`RRUI.Navigation.Route` through `RRUI.Data.BaseRouteFlowModel`.

## 6. The one thing not to repeat

The force was gated on a marker file, and an early build wrote that marker when the flow reached its
own end **regardless of whether anything had been forced**. A plain walk of the vanilla flow
therefore consumed the arming, and every later boot printed
`the marker file is present, so nothing will be forced` — which is exactly what the 01:26, 10:41 and
10:43 logs all say. Two test runs in a row were spent on a force that was switched off by its own
bookkeeping, and the gate now says so in the log rather than in a comment.