A kit wearer sees their own login skin, not the kit's, on their own avatar

[andrewgazelka]

Symptom

A player who puts on a kit sees the kit's mob skin on every other player, but on their own avatar they keep the skin they logged in with (a premium player's real account skin, or the default for an offline/empty profile). Reported from a real client as "I see my own skin, not the custom kit skin."

Not on the wire

Captured against a running smash server with the new smash-skin-e2e gate (PR #1055). For any other player the wire is correct: the tab-list profile carries the committed textures value with its Mojang signature, and the entity metadata carries a 0x7F skin-overlay mask (hat included). No Respawn is sent. The wearer's own tab-list entry even carries the custom skin.

So this is not a server encoding bug; it is the 26.2 client caching LocalPlayer's skin. AbstractClientPlayer builds its skin once from the profile it had at spawn and does not rebuild it from a tab-list remove+add for the local player. The kit is chosen in the hub after join, so LocalPlayer was already built with the login skin, and only a rebuild (Respawn) would refresh it.

Already understood in-tree

crates/hyperion/src/egress/player_join/roster.rs documents this exact tradeoff and deliberately leaves the wearer's own view unfixed, because the only rebuild path found is a Respawn, which discards the wearer's world ("Loading terrain..." forever).

Options (needs a decision)

1. A targeted Respawn for the wearer, restreaming chunks + re-offering entity subscriptions (expensive; the reason roster.rs avoided it).
2. Assign the kit skin before the wearer enters the world so LocalPlayer is built with it - only works for a fixed/default kit, not a mid-session change.
3. Confirm whether 26.2 has any LocalPlayer skin-refresh path lighter than a full Respawn (requires the client decompile).

Regression coverage

The wire half (other players get the signed skin + hat bits) is now guarded by tools/skin-check.py / smash-skin-e2e (PR #1055). This issue is only about the wearer's own-avatar view, which a scripted client cannot render or assert.

Filed by an automated agent from a first-hand packet capture; the fix is deliberately not attempted here pending a decision on the options above.

[andrewgazelka]

Definitive verdict, read from the decompiled 26.2 client (not inferred). Evidence is now a store-cached derivation: nix build .#minecraft-client-skin-sources. Full writeup in docs/wearer-own-skin.md (PR #1065).

It is impossible to refresh the wearer's own avatar skin mid-session without a Respawn.

• AbstractClientPlayer.getSkin() reads a cached PlayerInfo (getPlayerInfo() sets this.playerInfo once, lazily; no setter ever nulls it). PlayerInfo.getSkin() memoizes skinLookup from the profile it was built with.
• ClientPacketListener.handlePlayerInfoRemove/handlePlayerInfoUpdate only touch playerInfoMap; neither resets this.minecraft.player's cached playerInfo. So hyperion's remove+re-add updates the tab list but not the wearer's rendered skin.
• Only a new LocalPlayer (built by handleLogin or handleRespawn) gets a fresh skin, and handleRespawn always calls startWaitingForNewLevel -> LevelLoadingScreen, even same-dimension.

So roster.rs's decision to leave the wearer's own view alone is correct, not a shortcut. Options:

1. Assign the skin before world-entry so the first LocalPlayer has it (no respawn) - fixes the join-time skin only, not a mid-session kit change.
2. Respawn the wearer on skin change (same dimension, keep metadata) - refreshes the skin at the cost of the loading screen + dropped entity subscriptions.
3. Leave it (current behaviour): the wearer keeps their login skin on themselves; everyone else sees the kit skin.

Recommendation: keep 3 as default; take 1 for a fixed join-time kit if the wearer's own skin matters. A mid-session own-avatar change is not achievable without a visible respawn - a property of the client, not of hyperion. Confirming the pixels would use the hyperion-pilot-mod (semi-automated). Leaving this open for the product decision on options 1-3.