- summary: Asks for the character's friend list. Empty payload - the server knows who is asking.
- area: Game.Social
- confidence: 0.90
Asks for the character's friend list. Empty payload - the server knows who is asking.
- Kind request
- Area Game.Social
- Named by beta, gamemapping
It is one of a FIXED FOUR-REQUEST BURST the client fires once per entry into the
world, straight after asking for the game context. The client's own name for the
routine survives obfuscation: SendRequestAfterCharacterLoaded. The order is
constant:
ContextCreationRequest(the context first) 1.FriendListRequest2.AcquaintanceListRequest3.SpouseInformationRequest4.GuildInformationRequest
That order is not guessed from traffic: it is the order the routine allocates the four objects in, and a live capture reproduces it exactly - the first three land inside the same millisecond, the guild request three milliseconds later.
SEND IT ONCE, AT THAT POINT. NEVER POLL IT. The trigger is "the character finished loading", not a timer.
THERE IS A SECOND TRIGGER, AND IT IS A UI ONE. The client also sends this every
time the friends panel is shown - the panel's OnEnable refreshes its data,
which the contact service turns into this request. A script with no friends
panel has no reason to reproduce that one.
Carries nothing.
There is a name collision worth knowing about: a DIFFERENT FriendListRequest
exists in the Connection protocol. This is the Game one.
When you may send it
- Requires
character_loadedobserved
Related messages
- Reply not yet recovered: the friend list arrives as an event that has no signature here yet.
Sequence
Step post_character_load.1 observed — of 4 requests, in the order the client's own routine allocates them
Recovered with score 270, confidence 0.90, margin 270 over the runner-up. A margin close to the score means nothing else came near; a thin margin means a decoy nearly won. Members recovered: 0 of 0.
Aucun avis à afficher.