- summary: The full member list of one fight team: the branch of a team record that names every fighter.
- area: Game.Fight
The full member list of one fight team: the branch of a team record that names every fighter.
Kind struct · Area Game.Fight
The detailed form of a team: one entry per member. It is the
FightTeamInformation.team_members branch; the other branch,
FightTeamInformation.light_information, only summarises a team without listing it.
HOW TO READ IT
1. Walk FightTeamMembersInformation.team_members. Each entry is one
FightTeamMemberInformation; the client converts every entry into its own
team-member object and keeps them in the order received.
2. Merge, do not replace, when the record comes from FightTeamUpdateEvent: that
event adds members to a team the client already knows.
3. Ignore FightTeamMembersInformation.alliance_relation. The client never reads it.
THE MONSTER TEAM OF A FIGHT YOU JUST STARTED MAY BE EMPTY. In one capture (3.7.8.7) the
monster team of a fresh PvM fight arrived with no entries while the player team listed
the attacker. The fighters themselves arrive later, one
FightFighterShowEvent each.
PADDING. Builds may declare a second list of the same element type beside the real one. The client walks one list only; the other stays unnamed. Read the recovered list.
Not sent on its own — it travels only as the FightTeamInformation.team_members branch. proven
Used by
Fields
| # | Field | Type | Meaning | You set it |
|---|---|---|---|---|
| 1 | alliance_relation | AllianceRelation | How the viewer's alliance relates to this team; the client never reads it. Explicit presence: absent is not the same as zero. Named from its stable explicit-presence declaration across every dumped build, not from client behaviour. Ignore it: no client code consults it. | never |
| 2 | team_members | repeated FightTeamMemberInformation | The team's members, one entry each, in the order the server lists them. Proven as the list the client walks; a second list of the same element type is padding. | never |