# Social-panel completion batch — exact wire mechanics (2026-08-13)

Read-only research for the user-ordered social-panel completion features:
friends add/remove, appear-offline, squelch add, fellowship option
operations, the three fellowship/allegiance character-option bits, and
world self-selection. Every claim below is cited to primary source; the
usual three-way agreement rule (retail decomp + ACE + a third reference)
is applied per message. `str16L` = `[u16 byteLen][Windows-1252 bytes][pad
to 4-byte multiple counting the 2 length bytes]` throughout (see
`2026-08-11-fa-fellowship-wire.md` §3 for the envelope conventions —
C→S GameAction body = `[u32 0xF7B1][u32 seq][u32 subOpcode][payload]`,
S→C GameEvent body = `[u32 0xF7B0][u32 targetGuid][u32 eventSeq][u32
eventType][payload]`; both already shipped in acdream).

**Headline finding:** the entire C→S sender layer, the inbound S→C
parser/state layer, AND the generation-gated Runtime command surface for
features 1–3 **already exist in acdream** (built for the CH command
registry and Campaign FA). The implementation gap is almost purely
*panel wiring*: the Friends/Squelch pages are deliberately read-only
(FA slice FA3 scope) and no UI affordance drives the existing commands.
Feature 4 (self-selection) is the one place acdream *diverges* from
retail behavior today.

---

## 1. Add friend / remove friend / appear offline / squelch add

### 1.1 AddFriend — C→S `0x0018`

| | |
|---|---|
| Body | `[u32 0x0018][str16L characterName]` |
| Retail sender | `CM_Social::Event_AddFriend @0x006A5C10` (buffer `strPackSize + 0xC`; opcode u32, then `PStringBase<char>::Pack`) |
| Retail UI caller | `gmFriendsUI::Request_AddFriend @0x0048D240` — Add button (`idElement 0x10000514`) reads the name edit box in `gmFriendsUI::ListenToElementMessage @0x0048D520`, clears it, dims the Add button (`SetState(0xD)`). Chat-command route: `gmFriendsUI::RecvNotice_ChatCommand_AddFriend @0x0048D470` |
| ACE handler | `references/ACE/Source/ACE.Server/Network/GameAction/Actions/GameActionAddFriend.cs:7-12` (`GameActionType.AddFriend = 0x0018`, `GameActionType.cs:12`) → `Player.HandleActionAddFriend`, `ACE.Server/WorldObjects/Player_Character.cs:141-172` |
| ACE validation | rejects self-add ("can't be friends with yourself"), unknown name ("That character does not exist"), duplicate ("already in your friends list") — each as a `ChatPacket.SendServerMessage` broadcast text, NOT a WeenieError |
| ACE success flow | DB add → **incremental** `GameEventFriendsListUpdate` with `FriendsUpdateTypeFlag.FriendAdded (0x0001)` (`Player_Character.cs:169`) + a "`{name} has been added to your friends list.`" text |
| Cross-check | Chorizite `Messages/C2S/Actions/Social_AddFriend.generated.cs:24-26` (str16L only). holtburger: opcode known but **commented out / no sender** (`crates/holtburger-protocol/src/opcodes.rs:427`) |
| acdream builder | `src/AcDream.Core.Net/Messages/ClientCommandRequests.cs:132-133` (`BuildAddFriend`, retail address cited in-file) |

### 1.2 RemoveFriend — C→S `0x0017`, RemoveAllFriends — C→S `0x0025`

| | |
|---|---|
| RemoveFriend body | `[u32 0x0017][u32 friendGuid]` — **guid, not name.** The retail Remove button resolves the selected list row's InstanceID attribute (`GetAttribute_InstanceID(…, 0x10000085, …)` at `@0x0048D67D`) and sends `CM_Social::Event_RemoveFriend @0x006A5650` (buffer 0x10). The `/friends remove <name>` chat route (`RecvNotice_ChatCommand_RemoveFriend @0x0048DAC0`) resolves name→guid client-side first (`@0x0048dbde`). |
| RemoveAllFriends body | `[u32 0x0025]` — parameterless. `CM_Social::Event_ClearFriends @0x006A55C0` (buffer 0xC), chat route `RecvNotice_ChatCommand_RemoveAllFriends @0x0048E020`. |
| ACE handlers | `GameActionRemoveFriend.cs:6-11` (`ReadUInt32` guid) → `HandleActionRemoveFriend` (`Player_Character.cs:178-198`): not-found → text error; success → incremental `0x0021` with `FriendRemoved (0x0002)` + text. `GameActionRemoveAllFriends.cs` → `HandleActionRemoveAllFriends` (`Player_Character.cs:203-211`): DB clear, **NO S→C list update at all** (the client is expected to clear its own list — retail does, in the `/friends removeall` handler). |
| Cross-check | Chorizite `Social_RemoveFriend.generated.cs:18-25` (`ObjectId` u32). |
| acdream builders | `ClientCommandRequests.cs:135-139` (`BuildRemoveFriend`, `BuildClearFriends`). |

### 1.3 S→C FriendsListUpdate — `0x0021` (verified; it IS the 0x0021 family)

`GameEventType.FriendsListUpdate = 0x0021`
(`ACE.Server/Network/GameEvent/GameEventType.cs:9`; Chorizite
`Social_FriendsUpdate.generated.cs`). Writer:
`GameEventFriendsListUpdate.cs:56-99`:

```
u32 count
count × FriendData:
    u32 friendId
    u32 online          (0/1; forced 0 when the friend has AppearOffline set — :74-79)
    u32 appearOffline   (ACE always writes 0 — :84)
    str16L friendName
    u32 numFriendsOfFriend   (ACE: always 0 / TODO)  [u32 ids…]
    u32 numFriendOf          (ACE: always 0 / TODO)  [u32 ids…]
u32 updateType      — LAST field, after the list:
                      0=FullList  1=FriendAdded  2=FriendRemoved  4=FriendStatusChanged
```

Retail parser: `CM_Social::DispatchUI_FriendsUpdate @0x006A5DD0` →
`FriendData::UnPack @0x005B9D20`; UI application:
`gmFriendsUI::ServerSays_AddFriend @0x0048DEF0` /
`ServerSays_RemoveFriend @0x0048DFB0` / `ServerSays_UpdateFriend
@0x0048DCD0`. The full list arrives unprompted at login
(`Player_Networking.cs:117` sends it with the login bundle).

**acdream already parses and owns this**:
`src/AcDream.Core.Net/Messages/SocialStateMessages.cs:13-43`
(`ParseFriendsUpdate`, retail addresses cited in-file) → registered at
`GameEventWiring.cs:341-346` → `AcDream.Core/Social/FriendsState.cs`
(`Apply` handles Full/Add/Remove/OnlineStatus), owned by J4.1's
`RuntimeCommunicationState`. Nothing to build inbound.

### 1.4 Appear offline — a character option, NOT a dedicated GameAction

There is **no** standalone appear-offline opcode. `AppearOffline` is
`PlayerOption 0x27`, stored in `options2_` bit 12 (mask `0x00001000` —
retail `PlayerModule::GetOption` switch `@0x005D3D56-67`; ACE
`CharacterOptions2.cs:25`). It is in retail's 21-entry auto-save table
(`CPlayerModule::IsAutoSaveOption @0x0059A600`, byte-verified list in
`2026-08-10-character-options-map.md` §1.3 — id 0x27 IS auto-save), so
setting it sends **`SetSingleCharacterOption (0x0005)`
`[u32 0x27][u32 value]` immediately** via
`CM_Character::Event_PlayerOptionChangedEvent @0x006A1510`, dispatched
from `CPlayerModule::OnChanged @0x0059A8E0` (`@0x0059a99d-9b6`).

ACE side (`GameActionSetSingleCharacterOption.cs:16-18`): the 0x0005
handler special-cases `AppearOffline` → `Player.SetAppearOffline`
(`Player_Character.cs:221-226`), which flips the option and calls
`SendFriendStatusUpdates` (`Player_Networking.cs:274-294`): every online
player who has YOU friended receives an incremental **`0x0021` with
`FriendStatusChanged (0x0004)` and the forced online flag** plus a
"`{Name} has gone offline.`" text — i.e., other players genuinely see
you go offline. Login/logout honor it too (`PlayerManager.cs:430,464`),
and the full-list writer masks you out of other players' lists
(`GameEventFriendsListUpdate.cs:76-79`). ACE deliberately does **not**
persist it (`Player_Character.cs:219` comment).

**Open retail question (carried, not new):** the 2013 client has NO UI
row and no `SetAppearOffline` caller outside the generic `SetOption`
switch — how retail's own client ever set 0x27 is **UNKNOWN** (options
map §3 row `0x27` + §8 item U4). Any acdream checkbox for it is an
acdream-authored affordance driving a fully retail wire path.
`HeadlessConfigurationLoader.cs:45` already declares it by name for bots.

### 1.5 Squelch add/remove (by name) — C→S `0x0058` / `0x0059` / `0x005B`

| Opcode | Body | Retail sender |
|---|---|---|
| `0x0058 ModifyCharacterSquelch` | `[u32 add(0/1)][u32 characterGuid][str16L characterName][u32 chatMessageType]` | `CM_Communication::Event_ModifyCharacterSquelch @0x006A42D0` (buffer `strPackSize + 0x18`; field order byte-read from the body: opcode, arg1=add, arg2=guid, Pack(name), arg4=type) |
| `0x0059 ModifyAccountSquelch` | `[u32 add][str16L characterName]` | `Event_ModifyAccountSquelch @0x006A41E0` |
| `0x005B ModifyGlobalSquelch` | `[u32 add][u32 chatMessageType]` | `Event_ModifyGlobalSquelch @0x006A3D00` |

**Add-by-name is native**: retail's squelch panel sends `guid = 0` with
the typed name (`gmSquelchUI::ListenToElementMessage @0x0048C860`, add
call `@0x0048CA0D`: `Event_ModifyCharacterSquelch(1, 0, &name, 1)` —
`chatMessageType 1 = AllChannels`, ACE `ChatMessageType.cs:47`). The
account-checkbox variant sends `0x0059` instead (`@0x0048C99C`). The
chat-window speaker toggle goes through
`gmMainChatUI::ToggleSquelchOnCurrentSpeakableTarget @0x004CD230`
(`@0x004CD2F6`).

ACE (`GameActionModifyCharacterSquelch.cs:12-17` →
`SquelchManager.HandleActionModifyCharacterSquelch`,
`ACE.Server/WorldObjects/Managers/SquelchManager.cs:74-124`):
- channel legality check (`IsLegalChannel`, :78) → text error if bad;
- **guid≠0 looks up by guid; guid==0 falls back to name lookup**
  (:86-107) — so name-only add works;
- self-squelch rejected (:109-113);
- on success `UpdateSquelchDB()` + `SendSquelchDB()` (:121-123) — the
  S→C answer is always a **full `0x01F4 SetSquelchDB` replacement**,
  never an incremental. Account (`:195-250`) and global (`:255-279`)
  do the same.

S→C `0x01F4 SetSquelchDB` (`GameEventType.cs:51`; writer
`GameEventCommunicationSetSquelch.cs` + `Network/Structure/SquelchDB.cs:158-165`
+ `SquelchInfo.cs:50-65`):

```
PackableHashTable<string,u32> accounts   — ALWAYS EMPTY in retail pcaps (ACE writes header 0/0)
PackableHashTable<u32, SquelchInfo> characters  — account squelches folded in with Account=true
SquelchInfo globals
SquelchInfo = [u32 filterWordCount][u32 mask × count][str16L playerName][u32 isAccount]
```

ACE writes each character's filter list as the same mask **4×**
(`SquelchInfo.cs:21-27` — "if not sent 4x, the checkbox in the chat menu
doesn't toggle"; why retail wants 4 words is an ACE-acknowledged
UNKNOWN). Chorizite `Communication_SetSquelchDB.generated.cs` agrees on
the envelope. acdream already parses it —
`SocialStateMessages.ParseSquelchDatabase` (`:45-61`, retail
`SquelchDB::UnPack @0x006B1900` cited) → `GameEventWiring.cs:350-355` →
`AcDream.Core/Social/SquelchState.cs` (full `Replace` semantics, matching
the wire).

### 1.6 acdream seam — feature 1 is wiring-only

Already shipped (verify, don't rebuild):
- Builders: `ClientCommandRequests.cs:132-188` (all six, retail
  addresses cited).
- Session sends: `WorldSession.cs:2235-2274` (`SendAddFriend`,
  `SendRemoveFriend`, `SendClearFriends`, `SendModifyCharacterSquelch`,
  `SendModifyAccountSquelch`, `SendModifyGlobalSquelch`) and `:2202`
  (`SendSetSingleCharacterOption` for appear-offline).
- Runtime commands (generation-gated, host-shared):
  `src/AcDream.Runtime/GameRuntimeCommands.cs:264-300`
  (`RuntimeFriendCommand` Add/Remove/Clear/RequestLegacyList,
  `RuntimeSquelchCommand` Character/Account/Global scopes,
  `IRuntimeSocialCommands`), executed at
  `DirectGameRuntimeCommandAdapter.cs:722-800`; graphical route bound at
  `LiveSessionRuntimeFactory.cs:520-525/595-599`.
- Option path: `RuntimeCharacterOptionsState.TrySetOption`
  (`RuntimeCharacterState.cs:806-838`) auto-save dispatch →
  `SendSetSingleCharacterOption` (adapter `:677`).

To build: Friends-page Add (edit box + button → `RuntimeFriendCommand
Add` with the typed name), Remove (selected row's guid → `Remove`),
appear-offline checkbox (option id `0x27` through the existing option
seam — note U4: no retail UI row to copy), Squelch-page add-by-name
(`RuntimeSquelchCommand` Character scope, guid 0, type `1 = AllChannels`,
account checkbox → Account scope). The pages
(`SocialFriendsPageController.cs`, `SocialSquelchPageController.cs`) are
currently read-only by FA-D1 design.

---

## 2. Fellowship option operations

Full derivation in `2026-08-11-fa-fellowship-wire.md` (lane B); this
section resolves the specific "change after creation" questions.

### 2.1 What CAN change after creation — openness only: `0x0291`

`FellowshipChangeOpenness` `[u32 isOpen]` —
`CM_Fellowship::Event_ChangeFellowOpeness @0x006A6040`, Open button
case 9 in `gmFellowshipUI` (client pre-toggles its local `_open_fellow`
optimistically `@0x0049038A`). ACE:
`GameActionFellowshipChangeOpenness.cs:7-12` →
`Player_Fellowship.cs:33-48` — **leader-only**
(`WeenieError.YouMustBeLeaderOfFellowship 0x050F`-family refusal) and
refused when locked (`WeenieError.FellowshipIsLocked`). Success →
`Fellowship.UpdateOpenness` (`Fellowship.cs:410-415`) →
`SendWeenieErrorWithStringAndUpdate(_IsNowOpenFellowship /
_IsNowClosedFellowship, name)` — i.e. every member gets the
WeenieErrorWithString **plus a full `0x02BE
FellowshipFullUpdate`**. acdream: builder
`SocialActions.BuildFellowshipChangeOpenness` (`SocialActions.cs:223-231`),
Runtime command `IRuntimeFellowshipCommands.SetOpen`
(`GameRuntimeCommands.cs:339-341`) — **both already shipped (FA1/FA2)**.

### 2.2 What CANNOT change after creation — ShareXP and ShareLoot

- **ShareXP** (retail option `FellowshipShareXP 0x0F`, named
  `ShareFellowshipExpAndLuminance` in ACE — luminance rides the same
  flag) is a **create-time-only wire field**: `0x00A2 FellowshipCreate`
  = `[str16L name][u32 shareXP]` (retail `Event_Create @0x006A67A0`
  reads the option at create; ACE `Fellowship.cs:51-54` latches
  `DesiredShareXP`/`ShareXP` in the constructor). There is **no
  GameAction to change it later** — the seven C→S fellowship opcodes are
  `0x00A2–0x00A6`, `0x0290`, `0x0291`, period (lane B §3; ACE's
  `GameActionType.cs` has nothing else fellowship-shaped). Toggling the
  0x0F option after creation changes only what your NEXT create sends.
  Level-spread proportional-vs-even demotion is server-side
  (`Fellowship.CalculateXPSharing`), reflected to clients as
  `_share_xp = 0` inside `0x02BE`.
- **ShareLoot** is not on the create message at all: ACE reads the
  LEADER's `ShareFellowshipLoot (0x11)` character option **once, in the
  Fellowship constructor** (`Fellowship.cs:56-57`), enforces it at
  `Corpse.cs:192-198`, and echoes it per-fellow as the `shareLoot` u32
  in the `Fellow` record. No post-create wire op exists in either ACE
  or the retail client (lane B master-table row 31). The only lever is
  flipping option 0x11 (auto-save → immediate `0x0005`) **before**
  creating.

### 2.3 Panel visibility — `0x00A6 FellowshipUpdateRequest` (not an option, but required)

`[u32 panelOpen]` from `gmFellowshipUI::OnVisibilityChanged @0x0048E460`.
ACE `GameActionFellowshipUpdateRequest.cs:8-14` →
`HandleFellowshipUpdateRequest` (`Player_Fellowship.cs:142-148`): sets
`FellowshipPanelOpen`, replies with a full `0x02BE` when open, and the
flag **gates the whole `0x02C0` member-vitals stream**
(`Fellowship.cs:723`). Already shipped:
`BuildFellowshipUpdateRequest` (`SocialActions.cs:190-198`) and
`IRuntimeFellowshipCommands.SetPanelOpen` — the fellowship page's
show/hide seam must keep calling it.

### 2.4 Auto-accept — server-side, driven by the option bits (see §3)

`Fellowship.AddFellowshipMember` (`Fellowship.cs:76-132`): inviter-side
recruit → busy check → **`AutomaticallyAcceptFellowshipRequests` on the
TARGET short-circuits the confirmation dialog**
(`Fellowship.cs:120-123` → `AddConfirmedMember` directly); otherwise a
`Confirmation_Fellowship` popup is enqueued. The
`IgnoreFellowshipRequests` filter fires earlier, on the inviter's
`FellowshipRecruit` (`Player_Fellowship.cs:98-102` —
`WeenieError.FellowshipIgnoringRequests` + "not accepting fellowship
requests" text). Neither bit generates any wire traffic of its own at
recruit time — they are read from the server's stored option words.

---

## 3. The three character-option bits — values, wire class, ACE reads

| Option | `PlayerOption` id (0x0005 payload) | Word | Mask | Retail accessor | Auto-save? | Client default |
|---|---|---|---|---|---|---|
| `IgnoreAllegianceRequests` | `0x01` | options1 | `0x00000004` | (options map §3) | **yes** | false |
| `IgnoreFellowshipRequests` | `0x02` | options1 | `0x00000008` | `@0x005D2B30` / `@0x005D2B40` | **yes** | **true** |
| `FellowshipAutoAcceptRequests` (ACE: `AutomaticallyAcceptFellowshipRequests`) | `0x12` | options1 | `0x20000000` | `@0x005D3020` / `@0x005D3030` | **yes** | false |
| (context) `AppearOffline` | `0x27` | options2 | `0x00001000` | `@0x005D3740` | **yes** | false |

Sources: retail bit map `PlayerModule::GetOption @0x005D3AA0` switch;
ACE `CharacterOptions1.cs:16-17`, `CharacterOption.cs:18-22,70`,
`CharacterOptions2.cs:25`; auto-save membership from the byte-verified
`IsAutoSaveOption @0x0059A600` table
(`2026-08-10-character-options-map.md` §1.3 — all four ids are in the
21-entry auto-save set).

**Wire class:** all three (plus AppearOffline) ride
**`0x0005 SetSingleCharacterOption` immediately** —
`[u32 optionId][u32 value]` — and never *trigger* the batched `0x01A1`
PlayerModule blob. (Their bits still appear inside the blob's
options1/options2 words whenever some *other* dirty option flushes it —
that is correct and harmless; ACE stores the whole word.)

**Mutual exclusion** (`CPlayerModule::OnChanged @0x0059A8E0`, case 2 /
case 0x12, decomp lines `@0x0059a971-98d`): setting
`IgnoreFellowshipRequests` clears `FellowshipAutoAcceptRequests` and
vice versa, each clear going through the real accessor so the CLEARED
option's own `0x0005` is emitted first. acdream models this exactly —
`RuntimeCharacterState.cs:821-834` (MF-2), and
`HeadlessConfigurationLoader.cs:254-266` rejects both-true bot configs.

**acdream option table** (`src/AcDream.Runtime/Gameplay/CharacterOptionTable.cs`):
- `:112` `IgnoreAllegianceRequests` — options1, `0x00000004`, autoSave, default false
- `:113` `IgnoreFellowshipRequests` — options1, `0x00000008`, autoSave, **default true**
- `:129` `FellowshipAutoAcceptRequests` — options1, `0x20000000`, autoSave, default false
- `:150` `AppearOffline` — options2, `0x00001000`, autoSave, default false

Id enum: `CharacterOptionId` (`SocialActions.cs:425-480`). Send seam:
`RuntimeCharacterOptionsState.TrySetOption` (`RuntimeCharacterState.cs:806-838`,
`entry.IsAutoSave → sendAutoSave(id, value)`) wired to
`WorldSession.SendSetSingleCharacterOption` (`WorldSession.cs:2202`) at
`DirectGameRuntimeCommandAdapter.cs:677`. Headless bots declare all of
them by name (`HeadlessConfigurationLoader.cs:30-45`).

**ACE READS each bit server-side (the D6 finding, confirmed with code):**
- `IgnoreFellowshipRequests` —
  `ACE.Server/WorldObjects/Player_Fellowship.cs:98`
  (`FellowshipRecruit`: `newPlayer.GetCharacterOption(...)` → inviter
  gets `WeenieError.FellowshipIgnoringRequests`). Pure server-side
  filter; the target's client never sees the attempt.
- `AutomaticallyAcceptFellowshipRequests` —
  `ACE.Server/Entity/Fellowship.cs:120`
  (`AddFellowshipMember`: bypasses the `Confirmation_Fellowship` popup,
  joins immediately). Also settable via ACE's own `/option` player
  command alias `AutoAcceptFellowRequest` (`PlayerCommands.cs:221`).
- `IgnoreAllegianceRequests` —
  `ACE.Server/WorldObjects/Player_Allegiance.cs:317`
  (`IsPledgable`, checked during SwearAllegiance: swearer gets
  `WeenieError.YourOfferOfAllegianceWasIgnored` + "Your offer of
  allegiance was ignored." text).
- `AppearOffline` — `Player_Character.cs:213-226`,
  `GameEventFriendsListUpdate.cs:76-79`, `PlayerManager.cs:430,464`
  (see §1.4).

The client-side consumer status in the FA fix round stands: these three
are **store-only** on the acdream client
(`CharacterOptionsPageController.cs:244-249` — D6 correction comments);
the server does all the filtering.

---

## 4. World self-selection — retail allows it; acdream blocks it

### 4.1 Retail: no self-exclusion anywhere in the selection pipeline

The retail pick is render-driven: `SmartBox::find_object @0x00451C60`
arms `Render::set_selection_cursor` + `lookingForObject = 1`; during the
next frame every drawn part runs the ray test; `SmartBox::DrawNoBlit
@0x00454C20` (`@0x00454C4E-70`) reads the raw winner
(`Render::GetMouseSelectionObjectID`) and publishes it via
`ECM_UI::SendNotice_SmartBoxObjectFound`. The eligibility chain:

1. `CPhysicsPart::Draw @0x0050D7A0` (`@0x0050D823-35`): sets
   `Render::check_curr_object = 1` for **any part whose `physobj->id`
   is nonzero** (or `creature_mode`). No player-id comparison exists.
2. `Render::GfxObjUnderSelectionRay @0x0054C740`: sphere test
   (`CSphere::sphere_intersects_ray`) then per-polygon
   (`CPolygon::polygon_hits_ray`), keeping the closest winner in
   `Render::m_MouseSelectData`. No identity filtering.
3. `UIElement_SmartBoxWrapper::RecvNotice_SmartBoxObjectFound
   @0x004E5AD0`: for the ordinary reasons —
   `sr_Select` (left click, set `@0x004E5805`) and `sr_Examine`
   (right click, `@0x004E58B8`) — it pulses lighting and calls
   `ACCWeenieObject::SetSelectedObject(foundId, 0)` **unconditionally**
   (`@0x004E5BAE`); `sr_Examine` additionally calls
   `ClientUISystem::ExamineObject` with the raw found id (`@0x004E5C0A`).
4. `ACCWeenieObject::SetSelectedObject @0x0058C2E0`: no filter of any
   kind — it swaps `selectedID`, fires `SendNotice_SelectionChanged`,
   and notifies plugins.

**The only self-related gate in the whole flow** is the double-click-use
branch (search reason 4): `if (found->pwd._wielderID !=
SmartBox::player_id)` before `ItemHolder::UseObject` (`@0x004E5BE9`) —
clicking your own **wielded item** selects/flashes but does not Use.
acdream already ports that exact gate
(`SelectionInteractionController.cs:169-180` comment + `IsWieldedByPlayer`).

Conclusion: **retail lets you left-click-select and right-click-examine
your OWN character** whenever your model is drawn (third person). In
first person the model simply isn't rendered, so it can't win the ray —
an emergent property, not a filter.

### 4.2 acdream: the exclusion is ours, and it is deliberate but retail-divergent

- Skip mechanism: `src/AcDream.Core/Selection/RetailWorldPicker.cs:29`
  — `if (part.ServerGuid == 0u || part.ServerGuid == skipServerGuid)
  continue;`
- Fed from `src/AcDream.App/Rendering/Selection/RetailSelectionScene.cs:220-233`
  (`Pick(..., uint skipServerGuid)`) ←
  `src/AcDream.App/Interaction/WorldSelectionQuery.cs:145-154`
  (`PickAt(..., bool includeSelf)` passes
  `includeSelf ? 0u : _playerGuid()`).
- Callers (`src/AcDream.App/Interaction/SelectionInteractionController.cs`):
  - `:151` `PickAndStoreSelection` — ordinary left click passes
    `_items.IsAnyTargetModeActive`, i.e. **self is excluded except in
    spell/item target mode**;
  - `:199` `PickSelectAndExamine` — right-click examine passes
    `includeSelf: false` — **self-examine impossible**;
  - `:101` `PlaceDraggedItem` and
    `InteractionRetainedUiComposition.cs:497` pass `true`.

To match retail, the select (`:151`) and examine (`:199`) paths should
pass `includeSelf: true` (target-mode already does). If the exclusion is
retained instead, it needs a
`retail-divergence-register.md` row — none exists today (the register
has no row for self-picking; this is an unregistered deviation).
Downstream note for the implementer: `WorldSelectionQuery.PickAt`
verifies the winner through
`LiveEntityRuntime.TryGetPickEligibleRecord`; confirm the local player's
record passes that eligibility check before assuming the one-line flag
flip is sufficient.

---

## 5. UNKNOWNs (explicit)

1. **U4 (carried):** how retail's 2013 client sets `AppearOffline 0x27`
   — no UI row, no non-generic setter call site
   (`2026-08-10-character-options-map.md` §3 row 0x27, §8 U4). Any
   acdream checkbox is a new affordance on a retail wire path.
2. **SquelchInfo 4× filter list:** why retail wants the mask repeated
   four times (`SquelchInfo.cs:21-27` — ACE's own "not sure"). Parse
   side already tolerant (acdream reads ≤4 words).
3. **Account-squelch key semantics:** ACE is unsure whether the (always
   empty) top-level accounts table keyed on account name or character
   name (`SquelchDB.cs:20-28`). Moot for a client — never populated.
4. **Per-channel character squelch:** no retail pcaps exist
   (`SquelchInfo.cs:24-25`); ACE accepts a `chatMessageType` mask but
   the panel only ever sends `AllChannels (1)`.
5. **`RemoveAllFriends` S→C silence:** ACE sends no `0x0021` after
   `0x0025`; retail clears its own list. acdream's `FriendsState` has no
   "clear on 0x0025 ack" hook — the panel action should clear the local
   state the way retail's chat handler does, or simply re-request.
   (Behavior choice for the implementer, flagged, not researched deeper.)
6. **Self-pick eligibility depth (§4.2):** whether
   `TryGetPickEligibleRecord` admits the local player's record today was
   not verified — check before shipping the includeSelf flip.

## 6. Ten-line summary

1. AddFriend `0x0018 [str16L name]`, RemoveFriend `0x0017 [u32 guid]`, RemoveAllFriends `0x0025` []; ACE answers with incremental `0x0021 FriendsListUpdate` (updateType LAST: 0/1/2/4) — acdream builders, WorldSession sends, `RuntimeFriendCommand`, and the `0x0021` parser ALL exist; only panel wiring is missing.
2. Appear-offline is CharacterOption `0x27` (options2 `0x1000`), auto-save → immediate `0x0005`; ACE's handler routes it to `SetAppearOffline`, which pushes `0x0021 FriendStatusChanged` to everyone who friended you. No retail UI row exists (U4) — our checkbox is a new affordance on a retail wire path.
3. Squelch add-by-name is native: `0x0058 [u32 add][u32 guid=0][str16L name][u32 type=1 AllChannels]`; ACE falls back to name lookup and always answers with a FULL `0x01F4 SetSquelchDB` replace — sender, Runtime command, and parser all shipped.
4. Fellowship post-create ops: openness is the ONLY one — `0x0291 [u32 isOpen]`, leader-only, refused when locked, answered by WeenieErrorWithString + full `0x02BE`. Builder + `IRuntimeFellowshipCommands.SetOpen` already exist (FA1/FA2).
5. ShareXP is a create-time field of `0x00A2` and ShareLoot is the leader's option `0x11` read once in ACE's Fellowship constructor — NO post-create wire op exists for either; the panel must dim them for an existing fellowship.
6. `0x00A6` is panel VISIBILITY (gates ACE's `0x02C0` vitals stream), not openness — keep `SetPanelOpen` wired to page show/hide.
7. The three bits: IgnoreAllegianceRequests `0x01`/options1 `0x04`, IgnoreFellowshipRequests `0x02`/options1 `0x08` (default TRUE), FellowshipAutoAcceptRequests `0x12`/options1 `0x20000000`; all auto-save → `0x0005` immediate, never triggering `0x01A1`; the 0x02↔0x12 mutual exclusion emits the cleared option's `0x0005` first (already modeled, MF-2).
8. ACE reads all three server-side: recruit filter `Player_Fellowship.cs:98`, auto-accept `Fellowship.cs:120`, swear filter `Player_Allegiance.cs:317` — client stays store-only (D6 stands).
9. Retail has NO self-selection exclusion: any drawn physobj is ray-eligible (`CPhysicsPart::Draw @0x0050D823`), and found ids are selected/examined unconditionally (`@0x004E5BAE/0x004E5C0A`); the only self gate is the wielded-item double-click Use check (`@0x004E5BE9`, already ported).
10. acdream's self-exclusion is an unregistered divergence: `RetailWorldPicker.cs:29` skip fed by `SelectionInteractionController.cs:151/:199` passing includeSelf=false — flip to true (after checking pick-eligibility admits the local player) or add a register row.