Smooth

A placement swap was made: the new cell and direction of the fighters that moved. Kind event · Area Game.Fight.Preparation The result of an accepted placement swap. Each entry is an EntityDisposition: a fighter, the cell it now stands on and the direction it faces. WHAT TO DO WHEN YOU RECEIVE IT 1. For every entry, put the fighter EntityDisposition.entity_id on EntityDisposition.cell_id, facing EntityDisposition.direction. 2. Leave the other fighters alone: it lists only those that moved. 3. Forget the pending swap offer. SEND NOTHING BACK. NOT THE SAME AS EntitiesDispositionEvent, which carries the same kind of list for any (re)placement and belongs to the context protocol file. This one is the swap's own result, from the fight-preparation file. PADDING. Some builds add an unread optional bool; leave it alone. When you may send it Requires context_ready inferred Related messages Arrives after FightPlacementSwapPositionsAcceptRequest Fields #FieldTypeMeaningYou set it 2dispositionsrepeated EntityDispositionThe fighters that moved, with their new cell and direction. Element type EntityDisposition.never

A placement swap could not be made. The message is empty. Kind event · Area Game.Fight.Preparation The server could not set up or carry out a placement swap. Nothing changed: both fighters keep their cells. WHAT TO DO WHEN YOU RECEIVE IT 1. Treat the swap you asked for or accepted as failed. Forget the pending offer. 2. SEND NOTHING BACK. The client only shows an error message. 3. If you still want the cell, pick another one with FightPlacementPositionRequest. There is nothing to read: the message is empty, and the client reacts to its arrival only, with the localized error ui.fight.swapPositionRequestError in the chat. When you may send it Requires context_ready inferred Related messages Arrives after FightPlacementPositionRequest Arrives after FightPlacementSwapPositionsAcceptRequest

A pending placement swap was refused or withdrawn; says which offer and who cancelled it. Kind event · Area Game.Fight.Preparation Closes a pending placement swap without moving anybody: the fighter who was asked refused it, or the fighter who asked withdrew it. WHAT TO DO WHEN YOU RECEIVE IT 1. Find the pending offer by FightPlacementSwapPositionsCancelledEvent.request_id and drop it. Both fighters keep their cells. 2. FightPlacementSwapPositionsCancelledEvent.canceller_id says who closed it; when it is not you, the other fighter refused or withdrew. 3. SEND NOTHING BACK. WHAT THE CLIENT DOES. It removes the offer from its pending list (looked up by the request id), hides the swap icon, and when somebody else cancelled, prints ui.fight.swapPositionRequestRefused in the chat with a clickable link to that player. PADDING. Builds add an unread int64 beside the two members; leave it alone. When you may send it Requires context_ready inferred Related messages Arrives after FightPlacementSwapPositionsCancelRequest Fields #FieldTypeMeaningYou set it 2canceller_idint64The fighter who refused or withdrew the swap. (entity id)never 3request_idint32The swap offer that was closed, by the request id its offer carried. (swap request id)never

During fight placement, refuses a swap offered to you, or withdraws a swap offer you made. Kind request · Area Game.Fight.Preparation Says no to a placement swap, from either side. The fighter who was asked refuses with it; the fighter who asked withdraws the offer with it. It is the same message. HOW TO SEND IT 1. Only while placing, for a pending offer (FightPlacementSwapPositionsOfferEvent, no signature here yet) - one made to you, or one you made with FightPlacementPositionRequest on an ally's cell. 2. Put the offer's request id in FightPlacementSwapPositionsCancelRequest.request_id. 3. Nothing moves. FightPlacementSwapPositionsCancelledEvent closes the offer on both sides. TO SAY YES instead, send FightPlacementSwapPositionsAcceptRequest with the same request id. Only the fighter who was asked may accept. WHERE THE CLIENT SENDS IT. Refuse in the swap notification popup, Refuse in the swap context menu (the fighter asked) and Cancel in the same menu (the fighter who asked) all raise one client action carrying the request id; the fight-preparation request service turns it into this message. When you may send it Requires context_ready inferred Raised by: the player clicks Refuse on a swap offer made to them (notification popup or swap context menu), or Cancel in the swap context menu of an offer they made themselves proven Related messages You will then receive FightPlacementSwapPositionsCancelledEvent inferred — the client clears the offer when this event names it; no capture of a refusal yet Fields #FieldTypeMeaningYou set it 1request_idint32The swap offer being refused or withdrawn, by the request id the offer event carried. (swap request id)required

During fight placement, accepts the offer another fighter made to swap starting cells with you. Kind request · Area Game.Fight.Preparation Says yes to a placement swap. During placement a team mate can ask to take your starting cell and give you theirs; this message accepts that offer. HOW TO SEND IT 1. Only while placing, and only for an offer made TO YOU. The offer arrives as FightPlacementSwapPositionsOfferEvent (no signature here yet); the fighter who made it cannot accept their own offer - the client shows them Cancel only. 2. Put the offer's request id in FightPlacementSwapPositionsAcceptRequest.request_id. Nothing else: the server knows both fighters and both cells from the offer. 3. Expect the swap to happen: FightPlacementSwapPositionsEvent gives both fighters' new cells, or FightPlacementSwapPositionsErrorEvent says it failed. The client does not wait for a specific reply. TO SAY NO, send FightPlacementSwapPositionsCancelRequest with the same request id. The two requests have the same shape and are sent by the same client service; only the button differs. WHERE THE CLIENT SENDS IT. Two buttons raise the same client action: Accept in the swap notification popup, and Accept in the swap context menu. Both copy the offer's request id; the fight-preparation request service turns the action into this message. When you may send it Requires context_ready inferred Raised by: the player clicks Accept on a swap offer: in the swap notification popup, or in the swap context menu, which offers Accept only to the fighter who was asked proven Related messages You will then receive FightPlacementSwapPositionsEvent inferred — the swap's result, the two fighters' new dispositions; no capture of a swap yet You will then receive FightPlacementSwapPositionsErrorEvent inferred — when the swap can no longer be made Fields #FieldTypeMeaningYou set it 1request_idint32The swap offer being accepted, by the request id the offer event carried. (swap request id)required

The placement cells of both teams for the fight being prepared, and the team your character was put in. Kind event · Area Game.Fight.Preparation Tells you where you may stand before the fight starts. It arrives once the fight has been set up around your character, during the placement phase. WHAT TO DO WHEN YOU RECEIVE IT 1. REPLACE your placement cells. The client empties both of its cell lists and refills them from FightPlacementPossiblePositionsEvent.starting_positions: the two lists of the record are copied unchanged, nothing is merged. 2. Record FightPlacementPossiblePositionsEvent.team: it is the team your character fights in, and it tells you which of the two lists is yours. 3. To move before the fight starts, send FightPlacementPositionRequest with a cell taken from YOUR team's list. A cell outside it is not a placement cell. 4. When you are placed, send FightReadyRequest with is_ready = true. SEND NOTHING BACK. The handler builds no request; it only stores the cells and redraws the placement display. THE CLIENT WAITS BEFORE APPLYING IT. Its handler starts an asynchronous routine that first waits until the fight display is ready, then applies the message. A script has no display to wait for and can apply it at once. The cell ids are map cell ids, the same numbering as EntityDisposition cell ids. When you may send it Requires context_ready inferred Related messages Unsolicited - nothing you send causes this the server sends it when the character's fight enters its placement phase; no request asks for it Fields #FieldTypeMeaningYou set it 1starting_positionstype not documented yetThe placement cells of the two teams, as two lists of map cell ids. (map cell ids) The client copies both lists unchanged into its own placement lists, replacing what it held.never 2teamTeamThe team your character is placed in for this fight. Stored as the character's team in the fight-preparation state; it selects which of the two cell lists is yours.never

During fight placement, asks the server to move one of your fighters to another placement cell. Kind request · Area Game.Fight.Preparation Moves a fighter during the placement phase, before the fight starts. HOW TO USE IT 1. Take the cell from YOUR team's list in FightPlacementPossiblePositionsEvent. Any other cell is not a placement cell. 2. Put that cell in FightPlacementPositionRequest.cell_id and the fighter to move in FightPlacementPositionRequest.entity_id: your character's id, or the id of a companion you control. 3. Wait for the new positions to arrive before sending another one. The client sends nothing else with it and expects no direct reply. AIMING AT AN ALLY'S CELL IS A SWAP REQUEST. The client's "switch places" menu entry sends this very message with the ally's cell and your own id. The server then asks the ally to accept the swap; nothing moves until they do. Both values are copied unchanged from the client's placement action; the client adds nothing and checks nothing in the writer itself. When you may send it Requires context_ready inferred Raised by: during the placement phase, the player clicks a free placement cell for one of their fighters, or picks "switch places" in the context menu of an ally (player, companion or fighter ally), which targets that ally's cell proven Related messages You will then receive EntitiesDispositionEvent inferred — the fight placement handlers move the fighters to the cells this event carries; no capture of a placement move yet You will then receive FightPlacementSwapPositionsErrorEvent inferred — when the cell holds an ally and the swap cannot be offered Reply not yet recovered: W Reply not yet recovered: h Reply not yet recovered: e Reply not yet recovered: n Reply not yet recovered: Reply not yet recovered: t Reply not yet recovered: h Reply not yet recovered: e Reply not yet recovered: Reply not yet recovered: c Reply not yet recovered: e Reply not yet recovered: l Reply not yet recovered: l Reply not yet recovered: Reply not yet recovered: h Reply not yet recovered: o Reply not yet recovered: l Reply not yet recovered: d Reply not yet recovered: s Reply not yet recovered: Reply not yet recovered: a Reply not yet recovered: n Reply not yet recovered: Reply not yet recovered: a Reply not yet recovered: l Reply not yet recovered: l Reply not yet recovered: y Reply not yet recovered: , Reply not yet recovered: Reply not yet recovered: t Reply not yet recovered: h Reply not yet recovered: e Reply not yet recovered: Reply not yet recovered: s Reply not yet recovered: e Reply not yet recovered: r Reply not yet recovered: v Reply not yet recovered: e Reply not yet recovered: r Reply not yet recovered: Reply not yet recovered: m Reply not yet recovered: a Reply not yet recovered: y Reply not yet recovered: Reply not yet recovered: i Reply not yet recovered: n Reply not yet recovered: s Reply not yet recovered: t Reply not yet recovered: e Reply not yet recovered: a Reply not yet recovered: d Reply not yet recovered: Reply not yet recovered: o Reply not yet recovered: f Reply not yet recovered: f Reply not yet recovered: e Reply not yet recovered: r Reply not yet recovered: Reply not yet recovered: t Reply not yet recovered: h Reply not yet recovered: a Reply not yet recovered: t Reply not yet recovered: Reply not yet recovered: a Reply not yet recovered: l Reply not yet recovered: l Reply not yet recovered: y Reply not yet recovered: Reply not yet recovered: a Reply not yet recovered: Reply not yet recovered: s Reply not yet recovered: w Reply not yet recovered: a Reply not yet recovered: p Reply not yet recovered: Reply not yet recovered: ( Reply not yet recovered: F Reply not yet recovered: i Reply not yet recovered: g Reply not yet recovered: h Reply not yet recovered: t Reply not yet recovered: P Reply not yet recovered: l Reply not yet recovered: a Reply not yet recovered: c Reply not yet recovered: e Reply not yet recovered: m Reply not yet recovered: e Reply not yet recovered: n Reply not yet recovered: t Reply not yet recovered: S Reply not yet recovered: w Reply not yet recovered: a Reply not yet recovered: p Reply not yet recovered: P Reply not yet recovered: o Reply not yet recovered: s Reply not yet recovered: i Reply not yet recovered: t Reply not yet recovered: i Reply not yet recovered: o Reply not yet recovered: n Reply not yet recovered: s Reply not yet recovered: O Reply not yet recovered: f Reply not yet recovered: f Reply not yet recovered: e Reply not yet recovered: r Reply not yet recovered: E Reply not yet recovered: v Reply not yet recovered: e Reply not yet recovered: n Reply not yet recovered: t Reply not yet recovered: , Reply not yet recovered: Reply not yet recovered: n Reply not yet recovered: o Reply not yet recovered: Reply not yet recovered: s Reply not yet recovered: i Reply not yet recovered: g Reply not yet recovered: n Reply not yet recovered: a Reply not yet recovered: t Reply not yet recovered: u Reply not yet recovered: r Reply not yet recovered: e Reply not yet recovered: Reply not yet recovered: y Reply not yet recovered: e Reply not yet recovered: t Reply not yet recovered: ) Reply not yet recovered: . Fields #FieldTypeMeaningYou set it 1cell_idint32The placement cell to move the fighter to. (map cell id) Must be one of your team's cells from FightPlacementPossiblePositionsEvent; an ally's cell turns the request into a swap offer.required 2entity_idint64The fighter to move: your character's id, or a companion you control. (entity id)required

Asks for the pings currently placed in your fight. Sent empty when the fight map loads and when the 'see pings' option changes. Kind request · Area Game.Ping Asks the server for the pings currently placed in your fight. The answer is FightPingsEvent, a full snapshot. HOW TO SEND IT 1. SEND IT EMPTY. The client never writes a member; the bool some builds declare is padding and stays unset (the capture shows an empty payload). 2. Send it when the fight map has loaded. The client sends it from the same map-loaded notification that sends ContextReadyRequest and MapInformationRequest - in the observed fight start it left in the same millisecond as ContextReadyRequest, just before it. 3. The client also sends it again when the player changes the "see pings" option, and when a ping-file event tells it to refresh. 4. Replace your ping state with the FightPingsEvent that answers it. OBSERVED (3.7.8.7, fight start against monsters): sent at the fight map load, answered 27 ms later by an empty FightPingsEvent. When you may send it Requires context_ready inferred Raised by: a client-side state change: the map-loaded notification that also sends ContextReadyRequest (observed at fight start); also the player changing the 'see pings' option, and an inbound ping-file refresh proven Related messages You will then receive FightPingsEvent observed — the snapshot answering it, 27 ms later, 1 of 1 observation (fight start, 3.7.8.7) No fields you may set.

Snapshot of the tactical pings placed in your fight: the ping kind on each pinged cell and on each pinged fighter. Kind event · Area Game.Ping The full set of tactical pings placed in the fight you are in, as two maps: FightPingsEvent.cell_pings (cell id -> ping kind) and FightPingsEvent.entity_pings (fighter's entity id -> ping kind). Pings are the markers fighters drop on a cell or on a fighter to coordinate. WHAT TO DO WHEN YOU RECEIVE IT 1. REPLACE, DO NOT MERGE. It is a snapshot. The client removes every ping it shows on a cell or a fighter that is absent from the maps, then shows the ones listed. An empty event therefore clears every ping. 2. Key cell pings by cell id and fighter pings by entity id: the same cell or fighter carries at most one ping. 3. SEND NOTHING BACK. The handler builds no request. WHEN IT ARRIVES. It answers FightPingsRequest, which the client sends when the fight map has loaded (with ContextReadyRequest) and when the player changes the "see pings" option. In the observed fight start it arrived 27 ms after the request, with both maps empty. Single pings placed or removed during the fight are announced by the other messages of the ping file, not by this one. THE VALUE IS A PING KIND. The client converts it to its own ping-icon enum, which has eight kinds (0 to 7) plus -1 for none. The client's ping shortcuts list eight icons - heart, skull, sword, shield, target, 3, 2 and 1 - but which number is which icon is not proven. PADDING - DO NOT PICK A MAP BY TYPE OR NUMBER. Builds pad this message and move the maps around: 3.4.18.19 declares a SECOND int64-keyed map of the same type that the client never reads, 3.5.9.11 an optional int32, 3.6.10.10 a nested submessage, 3.7.x an int64. The cell map is field 2 on 3.3.20.19, 3 on 3.5.9.11 and 1 elsewhere. Only 3.3.20.19 and 3.6.12.16 declare exactly the two maps. Use the recovered names. When you may send it Requires context_ready inferred Related messages Arrives after FightPingsRequest Fields #FieldTypeMeaningYou set it 1cell_pingsrepeated type not documented yetThe pinged cells: map cell id -> ping kind shown on that cell. (key: cell id; value: ping kind) Named after the client's own labels: its cell routine's parameter is pingsByCells and the display container is named "cell_pings". No oracle names the wire field. A cell absent from the map has no ping: the client removes it.never 2entity_pingsrepeated type not documented yetThe pinged fighters: entity id -> ping kind shown above that fighter. (key: entity id; value: ping kind) Named after the client's display container "entity_pings". No oracle names the wire field. A fighter absent from the map has no ping: the client removes it.never

One team option of a fight changed: which fight, which team, which option and its new state. Kind event · Area Game.Fight.Preparation Reports the new state of one team option of one fight - after your own FightOptionToggleRequest, or when another team's leader changes theirs. WHAT TO DO WHEN YOU RECEIVE IT 1. Find the fight by FightOptionUpdateEvent.fight_id and its team by FightOptionUpdateEvent.team (Team). 2. Set the option FightOptionUpdateEvent.option (FightOption) to FightOptionUpdateEvent.state: true = on. 3. SEND NOTHING BACK. WHAT THE CLIENT DOES. The fight HUD service updates its option buttons from the option and the state; the map-fights service updates the fight's team options in the map's fight list (so it also arrives for fights you are not in, shown on your map). When you may send it Requires context_ready inferred Related messages Arrives after FightOptionToggleRequest Fields #FieldTypeMeaningYou set it 1teamTeamThe team whose option changed. Type Team.never 2stateboolThe option's new state: true = on.never 3optionFightOptionThe option that changed. Type FightOption.never 4fight_idint32The fight whose option changed. (fight id)never

Switches one option of your team in the fight: closed to spectators, party only, closed, or asking for help. Kind request · Area Game.Fight.Preparation Flips one option of your team in the current fight. It is a TOGGLE: the message names the option, not the new state. Sending it twice switches the option back. HOW TO SEND IT 1. Put the option in FightOptionToggleRequest.option (FightOption): - FightOption.FIGHT_OPTION_SET_SECRET: forbid spectators; - FightOption.FIGHT_OPTION_SET_TO_PARTY_ONLY: only your party may join; - FightOption.FIGHT_OPTION_SET_CLOSED: nobody may join; - FightOption.FIGHT_OPTION_ASK_FOR_HELP: ask other players for help. 2. Read the result from FightOptionUpdateEvent.state; do not assume it. WHERE THE CLIENT SENDS IT. Each option button of the fight HUD raises its own client action, and the writer for that action stores one constant option. The party window raises the party-only lock too. When you may send it Requires context_ready inferred Raised by: the player clicks one of the four option buttons of the fight HUD (forbid spectators, lock to party, lock the fight, ask for help), or locks the fight from the party window proven Related messages You will then receive FightOptionUpdateEvent inferred — the option's new state for the team; the service that sends this request handles it; no capture yet Fields #FieldTypeMeaningYou set it 1optionFightOptionThe option to switch. Type FightOption.required

A team option of a fight: closed to spectators, party only, closed, or asking for help. Kind enum · Area Game.Fight.Preparation The four options a team can switch in a fight. FightOptionToggleRequest.option names the one to flip; FightOptionUpdateEvent.option reports which one changed. EACH VALUE IS NAMED BY THE BUTTON THAT SENDS IT. The client builds the toggle request from one writer per HUD button, each storing a fixed value; the value is read from those writers in each build, never from its number. Not sent on its own — an enum is never sent on its own. inferred Used by FightOptionToggleRequest FightOptionUpdateEvent Values ValueNumberMeaning FIGHT_OPTION_SET_SECRET0Forbid spectators: nobody may watch the fight. Raised by the fight HUD's forbid-spectators toggle. FIGHT_OPTION_SET_TO_PARTY_ONLY1Only members of your party may join your team. Raised by the fight HUD's party lock and by the party window's fight lock. FIGHT_OPTION_SET_CLOSED2Nobody may join your team. Raised by the fight HUD's fight lock. FIGHT_OPTION_ASK_FOR_HELP3Ask other players to come and help. Raised by the fight HUD's help request.

A new fight round begins; carries the round number the client shows as the turn count. Kind event · Area Game.Fight Starts a new round: every fighter has played once and the timeline starts over. WHAT TO DO WHEN YOU RECEIVE IT 1. Store FightNewRoundEvent.round_number as the current round. It REPLACES the previous value; it is not an increment to apply. 2. Count round-based durations from it (buff and effect durations, cooldowns expressed in rounds, challenge conditions). 3. SEND NOTHING BACK. WHAT THE CLIENT DOES. It keeps the round as the fight's current turn count, publishes it to the end-turn widget (which shows it) and, from 3.7 on, prints the localized "turn N" line in the chat. The turn of the first fighter of the round arrives separately, with FightTurnEvent. FROM 3.7 THE MESSAGE CARRIES A SECOND int32, FightNewRoundEvent.order, which the client files as the position inside the round of its new FightTurn(round, order) value. When you may send it Requires character_loaded inferred Related messages Unsolicited - nothing you send causes this the server announces each round on its own when every fighter has played; no request asks for it Fields #FieldTypeMeaningYou set it 1round_numberint32The round that starts now; the client shows it as the fight's turn count. (round number)never 2orderint32Position inside the round, as the client files it in its turn value (3.7 and later). Named after the order parameter of the client's FightTurn(round, order, additionalId) constructor, which receives it. Not declared before 3.7.never

A fighter has left the fight you are in, during placement or during the fight itself. Kind event · Area Game.Fight.Preparation One fighter is gone from your fight. The only value is who: FightLeaveEvent.character_id. WHAT TO DO WHEN YOU RECEIVE IT 1. Remove the fighter FightLeaveEvent.character_id from your fight: from the fighters you show, from the team it was in and from the turn order. 2. IF THE ID IS YOUR OWN CHARACTER, you are out of the fight. The client treats that case apart; expect the context to change back to roleplay. 3. SEND NOTHING BACK. No handler of this message builds a request. WHAT THE CLIENT DOES. Both fight services handle it: - in the placement phase, the fight-preparation service removes the fighter from its placement state and refreshes the placement display; - during the fight, the battle service queues the departure as a fight sequence step, so it is played in order with the actions around it, and, when the id is not the player's own, announces the departure to the rest of the client (the map information panel, the chat and the fighter tooltips all listen for it). DO NOT CONFUSE IT WITH FightTeamRemoveMemberEvent. That one edits a team of a fight shown on the map (any fight, by fight id); this one is about the fight you are in. When you may send it Requires context_ready inferred Related messages Unsolicited - nothing you send causes this the server announces a departure when it happens (a player abandons, is kicked or disconnects); no request asks for it Fields #FieldTypeMeaningYou set it 1character_idint64The fighter that left the fight; your own character id when it is you. (entity id)never

Joins a fight that is running on your map, on the side of one of its team leaders, or as a spectator with fighter id 0. Kind request · Area Game.Fight.Preparation Enters a fight that already exists on your map: as a fighter on one team, or as a spectator. HOW TO SEND IT 1. BE ON THE MAP OF THE FIGHT, in roleplay. Fights on the map are announced by ShowChallengeEvent and in the map's contents (MapComplementaryInformationEvent), each as a FightCommonInformation. 2. PUT THE FIGHT'S ID in FightJoinRequest.fight_id (FightCommonInformation's fight id). 3. CHOOSE THE SIDE WITH FightJoinRequest.fighter_id: - to fight, the id of the LEADER of the team you join (each team of the fight names its leader); - to watch, 0. The client's "spectate" button sends exactly that. 4. If accepted you enter the fight like after an attack: FightStartingEvent, FightJoinEvent, one FightFighterShowEvent per fighter, then placement. WHERE THE CLIENT SENDS IT - clicking a fight's swords on the roleplay map (the roleplay world handler builds it directly); - the map's fight list: choosing a team (that team's leader id) or Spectate (0); - the party window, to join the fight a party member is in. A FIGHT YOU MAY NOT JOIN (locked, full, closed to spectators - see the fight options) is refused by the server. The client does not check it first. When you may send it Requires roleplay_context inferred Raised by: the player clicks a fight's swords on the map, picks a team or Spectate in the map's fight list, or joins a party member's fight from the party window proven Related messages You will then receive FightStartingEvent inferred — joining as a fighter enters the fight like an attack does; no capture of a join yet Reply not yet recovered: S Reply not yet recovered: p Reply not yet recovered: e Reply not yet recovered: c Reply not yet recovered: t Reply not yet recovered: a Reply not yet recovered: t Reply not yet recovered: i Reply not yet recovered: n Reply not yet recovered: g Reply not yet recovered: Reply not yet recovered: h Reply not yet recovered: a Reply not yet recovered: s Reply not yet recovered: Reply not yet recovered: i Reply not yet recovered: t Reply not yet recovered: s Reply not yet recovered: Reply not yet recovered: o Reply not yet recovered: w Reply not yet recovered: n Reply not yet recovered: Reply not yet recovered: j Reply not yet recovered: o Reply not yet recovered: i Reply not yet recovered: n Reply not yet recovered: Reply not yet recovered: a Reply not yet recovered: n Reply not yet recovered: n Reply not yet recovered: o Reply not yet recovered: u Reply not yet recovered: n Reply not yet recovered: c Reply not yet recovered: e Reply not yet recovered: m Reply not yet recovered: e Reply not yet recovered: n Reply not yet recovered: t Reply not yet recovered: Reply not yet recovered: ( Reply not yet recovered: F Reply not yet recovered: i Reply not yet recovered: g Reply not yet recovered: h Reply not yet recovered: t Reply not yet recovered: S Reply not yet recovered: p Reply not yet recovered: e Reply not yet recovered: c Reply not yet recovered: t Reply not yet recovered: a Reply not yet recovered: t Reply not yet recovered: o Reply not yet recovered: r Reply not yet recovered: J Reply not yet recovered: o Reply not yet recovered: i Reply not yet recovered: n Reply not yet recovered: E Reply not yet recovered: v Reply not yet recovered: e Reply not yet recovered: n Reply not yet recovered: t Reply not yet recovered: , Reply not yet recovered: Reply not yet recovered: n Reply not yet recovered: o Reply not yet recovered: Reply not yet recovered: s Reply not yet recovered: i Reply not yet recovered: g Reply not yet recovered: n Reply not yet recovered: a Reply not yet recovered: t Reply not yet recovered: u Reply not yet recovered: r Reply not yet recovered: e Reply not yet recovered: Reply not yet recovered: y Reply not yet recovered: e Reply not yet recovered: t Reply not yet recovered: ) Reply not yet recovered: . Fields #FieldTypeMeaningYou set it 2fight_idint32The fight to enter, by the fight id the map's fight announcements carry. (fight id)required 3fighter_idint64The leader of the team to join, or 0 to watch the fight as a spectator. (entity id (team leader), 0 = spectate)required

Puts the character into a fight: whether it is still in placement, the placement countdown and the fight type. Kind event · Area Game.Fight.Preparation Tells you how you are in the fight you just entered: placing your character before the fight, or dropped into a fight that is already running. WHAT TO DO WHEN YOU RECEIVE IT 1. Read FightJoinEvent.is_fight_started. - false: you are in the PLACEMENT PHASE. Start a countdown of FightJoinEvent.time_max_before_fight_start TENTHS OF A SECOND (the client multiplies it by 100 to get milliseconds; 443 means 44.3 s). Place your character and say you are ready before it runs out. - true: the fight is already under way (spectating, reconnecting into a fight). There is no placement; wait for the turn messages. 2. Store FightJoinEvent.fight_type (FightType). It is the same fight type as FightStartingEvent.fight_type; the client stores it again from here. 3. SEND NOTHING BACK because of this message alone. The client's own replies during placement come from the player's actions (choosing a cell, the ready button), not from this event. 4. Expect one fighter-show event per fighter right behind it: they place every fighter, you included, on its starting cell. WHAT THE CLIENT DOES. The fight-start handler stores the negation of FightJoinEvent.is_fight_started as the fight's "in preparation" flag and uses it to choose between the placement path and the running-fight path; on current builds the fight-state object and the fight UI service read it too (the UI flips to fight mode only when it is true). That handler then converts the countdown to milliseconds and passes it, together with FightJoinEvent.is_team_phase, to the notification that opens the placement interface, and starts the countdown display from the same value. TWO MEMBERS STAY UNNAMED. The canonical message also carries can_be_cancelled and can_say_ready. No client code reads either (the unobfuscated beta client does not read them either), so nothing tells the two same-typed booleans apart. Leave them unset; they are server information only. OBSERVED (one capture, PvM attack on a monster group): is_fight_started = false, time = 443, fight_type = PvM, is_team_phase = true; one of the two unnamed booleans was true, the other false. It arrived in the same burst as FightStartingEvent, right after it, and one FightFighterShowEvent per monster followed in the same millisecond. When you may send it Requires context_ready inferred Related messages You will then receive FightFighterShowEvent observed — in the same millisecond, one per fighter already in the fight (two monsters); 1 capture Arrives after FightStartingEvent Fields #FieldTypeMeaningYou set it 1is_fight_startedboolFalse while fighters are still being placed; true when you join a fight already under way. Observed: false The live boolean that does not travel with the countdown; the fight-start handler keeps its negation as the fight's in-preparation flag, and on dofus3 builds two or three client services read it.never 3time_max_before_fight_startint64Placement countdown: time left before the fight starts on its own. (tenths of a second) Observed: 443 The client multiplies it by 100 to get milliseconds.never 4is_team_phaseboolTeam-phase flag the client passes, with the countdown, to the placement interface. Observed: true Proven as the boolean that travels with the converted countdown into one constructor; the beta client names that argument isTeamPhase.never 5fight_typeFightTypeThe kind of fight joined. A FightType; the same value as FightStartingEvent.fight_type.never

The server asks whether the client has finished playing the turn that just ended; answer with FightTurnReadyRequest. Kind event · Area Game.Fight The server's "are you ready for the next turn?" question, asked at the end of a fighter's turn. The answer is FightTurnReadyRequest. WHAT TO DO WHEN YOU RECEIVE IT 1. Ignore the payload. The client reads nothing from this message: it is a question, and its arrival is the whole content. 2. If you are still playing back what the turn did (an action sequence opened by the server and not yet closed), WAIT until that sequence is finished. 3. Then send FightTurnReadyRequest with is_ready = true. Send it once per question. WHAT THE CLIENT DOES. Its battle message handler checks whether an action sequence is still being played. If not, it calls the battle service routine that builds the ready request and sends it at once. If one is, it logs that it is delaying the turn end acknowledgement, raises a "turn end pending" flag, and sends the request later, when the sequence finishes (the battle service then logs that a delayed turn end is being dispatched). NOT ANSWERING STALLS THE FIGHT until the server's own timeout: the next turn does not start before the server has the ready request. When you may send it Requires character_loaded inferred Related messages You must then send FightTurnReadyRequest proven — the handler calls the battle service routine that builds and sends the ready request; the fight does not move on to the next turn until the server has it Unsolicited - nothing you send causes this the server sends it on its own at the end of each fighter's turn; no request asks for it No fields you may set.

A player fighting with you, or you, became ready or not ready during the placement phase. Kind event · Area Game.Fight.Preparation The server's echo of the ready button, for every human fighter of your fight. It says who (FightHumanReadyStateEvent.character_id) and whether that fighter is now ready (FightHumanReadyStateEvent.is_ready). WHAT TO DO WHEN YOU RECEIVE IT 1. Store the ready flag for the fighter under FightHumanReadyStateEvent.character_id, replacing the previous value. 2. IF THE ID IS YOUR OWN CHARACTER, this is the server's word on YOUR ready state. Trust it over what you sent: the client switches its ready button from it, not from its own FightReadyRequest. 3. SEND NOTHING BACK. The handler builds no request. WHAT THE CLIENT DOES. The fight placement service looks the fighter up by id, plays or stops the fighter's ready animation from the flag, and, only when the id is the player's own, tells the end-turn widget "ready" or "not ready" - the widget whose button sends FightReadyRequest. WHEN IT ARRIVES. After a FightReadyRequest (yours or another human fighter's) during the placement phase. When every human fighter is ready, or when the placement countdown elapses, FightStartEvent follows. Monsters never send it: it is about human fighters only. PADDING. Builds add unread members (an optional int32 and a second bool on 3.7). Read the two recovered members only. When you may send it Requires context_ready inferred Related messages Arrives after FightReadyRequest Fields #FieldTypeMeaningYou set it 2character_idint64The human fighter whose ready state changed; your own character id when it is you. (entity id)never 3is_readyboolTrue when the fighter is now ready to start the fight, false when it is no longer ready.never

A fighter appeared in the current fight: its id, cell and direction, look and fighter details. Kind event · Area Game.Fight Adds one fighter to the fight you are in, or redraws one you already show. The record is an ActorPositionInformation: the fighter's id, its cell and direction (EntityDisposition), its EntityLook and the fighter branch of its actor information. WHAT TO DO WHEN YOU RECEIVE IT 1. Upsert the fighter under ActorPositionInformation.actor_id. The client keeps the look under that id and (re)builds the fighter's entity from the record; a fighter it already shows is updated, not duplicated. 2. Put it on the cell of ActorPositionInformation.disposition, facing its direction. 3. Remember static_pose for that fighter. The client stores it per fighter id and uses it to choose how the fighter's entity is displayed. 4. Send nothing back. No handler of this message builds a request. WHEN IT ARRIVES. While a fight is being set up, one message per fighter. It also arrives on its own when a fighter joins a fight that is already announced. In one capture of a monster fight started by attacking a group, two arrived in the same millisecond as FightJoinEvent, one per monster, each on its own placement cell, with static_pose unset. MONSTER FIGHTERS HAVE SMALL NEGATIVE IDS. The two monsters of that capture were fighters -1 and -2: per-fight ids, unrelated to the id of the monster group that was attacked (-20002 in the same capture). Key fighters by the id in this message, not by the group id. NOT A ROLEPLAY SPAWN. GameRolePlayShowActorsEvent carries the same record for a roleplay map. This message belongs to the fight. Another fight message, FightFighterRefreshEvent (no signature here yet), carries the same record without the flag and refreshes a fighter that is already shown. When you may send it Requires context_ready inferred Related messages Arrives after FightJoinEvent Fields #FieldTypeMeaningYou set it 1informationActorPositionInformationThe fighter: its id, cell and direction, look, and fighter details. An ActorPositionInformation; its actor information carries the fighter branch.never 2static_poseboolWhether the fighter is shown in a static pose. Observed: false (unset) for both monsters of one captured monster fight The client stores it per fighter id and uses it to choose between two display modes for the fighter's entity.never

The fight is over: the results of every fighter and the outcome of each team. Kind event · Area Game.Fight The fight is over. It carries the result of every fighter and the outcome of each team, and it is the last fight message: the context switches back to roleplay afterwards. WHAT TO DO WHEN YOU RECEIVE IT 1. Stop playing: no more turns, no more casts. 2. If a fight action sequence is still open, close it. The official client does it itself ('Fight end but no SequenceEnd was received') and delays the end of the fight until the sequence it is playing has finished. 3. Read FightEndEvent.results for your own entry (outcome, experience, loot) and FightEndEvent.named_party_teams_outcomes for which team won. 4. SEND NOTHING BACK. Wait for the context change that brings you back to the map (ContextCreationEvent naming the roleplay context). THE SCALARS ARE NOT NAMED HERE. The reference schema also declares the fight duration, a reward rate, a loot-share-limit malus and an optional budget; current builds declare several int32, two optional int32 and an int64 beside the two lists. The client copies them all into its fight report, but nothing it does with them tells which int32 is which, so they keep their wire names. When you may send it Requires context_ready inferred Related messages Unsolicited - nothing you send causes this the server ends the fight when one team is defeated or the fight is abandoned Fields #FieldTypeMeaningYou set it 2named_party_teams_outcomesrepeated type not documented yetThe named teams of the fight with their outcome (winners and losers). Proven as the list the client converts into its winners/losers team names.never 4resultsrepeated type not documented yetOne result entry per fighter: who it was, the outcome and the rewards. Proven as the list the client converts into its list of fighter result entries.never

One fight as seen from the map: its id, its type, its teams, where their swords stand and each team's options. Kind struct · Area Game.Common The description of one fight on a map, as a player outside it sees it. It travels in two places: MapComplementaryInformationEvent.fights lists the fights already running when the map loads, and ShowChallengeEvent announces each fight that starts later. WHAT IT CARRIES FightCommonInformation.fight_id which fight; use it to follow the fight FightCommonInformation.type what kind of fight, a FightType FightCommonInformation.teams_information one entry per team: its members, its leader, its side and its type FightCommonInformation.teams_position the map cell where each team's swords stand FightCommonInformation.teams_options each team's options: secret, restricted to the party, closed, asking for help The three lists run in parallel, one entry per team - a captured two-team fight carries two teams, two cells and two option sets. That pairing is read from the shapes and one capture, not from client code. HOW THE CLIENT USES IT. One routine turns the record into the client's fight object wherever it arrives: it keeps the id and the type, converts each team and each option set, and keeps the cells. The team and option records have no signature here, so their members keep obfuscated names in the recovered schema. Some builds pad the record with a bool or a string; the client reads neither. Not sent on its own — it is only ever carried by ShowChallengeEvent.fight_information and MapComplementaryInformationEvent.fights. inferred Used by MapComplementaryInformationEvent ShowChallengeEvent Fields #FieldTypeMeaningYou set it 1typeFightTypeWhat kind of fight it is. A FightType.never 2fight_idint32Which fight. (fight id) Observed: 2066never 3teams_positionrepeated int32The map cell where each team's swords stand, one per team. (map cell id) Observed: [309, 310]never 4teams_informationrepeated FightTeamInformationThe teams, one entry each: members, leader, alignment side and team type. A list of FightTeamInformation. In a monster fight the monster team's leader is the monster group's id on the map, which is negative.never 5teams_optionsrepeated type not documented yetEach team's options: secret, restricted to the party, closed, asking for help. A list of FightOptionsInformation (four flags), which has no signature here; one entry per team.never

The server opened a storage exchange, such as the bank: which storage it is and how many slots it has. Its content follows in StorageInventoryContentEvent. Kind event · Area Game.Exchange The server has opened a STORAGE for your character: the bank, or another storage the server hands you the same way. From now on you are in an exchange with that storage until the server closes it. WHAT TO DO WHEN YOU RECEIVE IT 1. RECORD WHICH STORAGE IS OPEN. ExchangeStartedWithStorageEvent.exchange_type is an ExchangeType value; the bank is one of them. ExchangeType is renumbered between client builds, so compare it with the bank's value in the build you run against, never with a number taken from another build. 2. RECORD ITS CAPACITY. ExchangeStartedWithStorageEvent.storage_max_slot is the storage's number of item slots. The bank sends the largest int32 (2147483647): no practical limit. 3. WAIT FOR THE CONTENT. StorageInventoryContentEvent carries every item and the kamas of this storage. This message carries no item of its own. 4. SEND NOTHING BACK. The client builds no request from it. 5. CONSIDER THE CHARACTER BUSY in this exchange until it closes. Moving items into or out of the storage happens inside it. WHAT THE OFFICIAL CLIENT DOES WITH IT - Converts exchange_type to its own exchange-type code and builds a storage-start object from (type, capacity). - Hands both to its exchange service, which sets a flag on the played character (by every sign the "in an exchange" state) and announces the started exchange with its type. - Its storage-window manager opens the storage window with that type and capacity. The window shows the bank's kamas line only when the type is the bank. NOT THE MULTI-TAB STORAGE. A sibling start message carries one more int32, the tab to open (the guild chest's tabs); the client reads all three of its members. This one has exactly two live members. PADDING. Builds add an unread member: a second ExchangeType field, a second int32, or both. The client reads exactly one of each; use the recovered names, never the field order. When you may send it Requires character_loaded inferred State it changes Establishes exchange_open inferred — the client records the started exchange and opens the storage window; items and kamas then move with ExchangeObjectMoveRequest and ExchangeMoveKamaRequest Related messages You will then receive StorageInventoryContentEvent observed — the opened storage's items and kamas; both arrived together when the bank was opened, 1 observation Reply not yet recovered: the exchange ends with an exchange-leave event, and the request that opens a storage (talking to a banker, using a chest) is not recovered here either; neither has a signature yet. Fields #FieldTypeMeaningYou set it 1exchange_typetype not documented yetWhich storage was opened: an ExchangeType value, the bank being one of them. (ExchangeType value) ExchangeType is renumbered between client builds; compare with the value of the build you run against.never 2storage_max_slotint32How many item slots the opened storage has. (slots) Observed: 2147483647 for the bank (no practical limit), observed in a capture The client hands it to the storage window as the storage's capacity.never

Move some units of one item between your inventory and the open exchange (bank, chest, trade, craft). Positive quantity puts in, negative takes out. Kind request · Area Game.Exchange The one request that moves items in every exchange window: the bank and other storages, a trade with a player, the crafting, recycling and smithing windows. The sign of the quantity gives the direction. HOW TO SEND IT 1. AN EXCHANGE MUST BE OPEN, for a storage the one ExchangeStartedWithStorageEvent announced. 2. PUTTING IN (from your inventory): ExchangeObjectMoveRequest.object_uid is the item's uid IN YOUR INVENTORY, ExchangeObjectMoveRequest.quantity the number of units, POSITIVE. 3. TAKING OUT (from the storage or exchange): object_uid is the item's uid IN THE STORAGE (from StorageInventoryContentEvent / StorageObjectUpdateEvent), quantity the number of units, NEGATIVE. The bank window sends -1 for a plain drag of one item. 4. NEVER MORE THAN THE STACK. The client checks |quantity| against the stack size of the item it finds under that uid (it looks in your inventory first, then in the bank). 5. WAIT FOR THE RESULT; the client sends nothing else for this move. For a storage: StorageObjectUpdateEvent (stack added or changed) or StorageObjectRemovedEvent (stack gone) on the storage side, and on your side ObjectAddedEvent or ObjectQuantityEvent (or an item removal), followed by InventoryWeightEvent. OBSERVED (one session): putting 2 of a 14-stack into a trash bin sent (inventory uid, 2) and was answered by StorageObjectUpdateEvent (new storage uid, quantity 2) and ObjectQuantityEvent (stack 12); taking 1 back sent (storage uid, -1). PADDING. Builds add an unread member (a repeated bool on 3.7). Fill only the two recovered members. When you may send it Requires exchange_open inferred Raised by: the player drags an item between the inventory and an open exchange window (bank, storage, trade, craft or recycling window), or confirms a quantity in it proven Related messages You will then receive StorageObjectUpdateEvent observed — the storage stack as it now stands, after putting in or taking out part of a stack; 3 observations in one session (trash bin) You will then receive StorageObjectRemovedEvent observed — when the last unit of a stored item is taken out; 3 observations (bank and trash bin) Fields #FieldTypeMeaningYou set it 1object_uidint32The uid of the item to move, in the inventory it leaves: yours when putting in, the storage's when taking out. (item uid)required 3quantityint32How many units to move: positive puts them into the exchange, negative takes them out. (item units, signed) Range: 1 .. stack size, or -stack size .. -1 The bank window sends -1 for a plain drag of one item out of the bank.required

Move kamas between your wallet and the open exchange (bank, trade). Positive deposits, negative withdraws. Kind request · Area Game.Exchange Moves kamas in the exchange you have open, the bank included. The sign is the direction. HOW TO SEND IT 1. AN EXCHANGE MUST BE OPEN (for the bank, after ExchangeStartedWithStorageEvent). 2. DEPOSIT: ExchangeMoveKamaRequest.quantity POSITIVE, at most the kamas you carry. 3. WITHDRAW: quantity NEGATIVE, at most the kamas in the storage (the bank window caps its amount box at the bank's kamas and negates the value). 4. WAIT FOR THE TOTALS. StorageKamasUpdateEvent gives the bank's new total; after a withdrawal KamasUpdateEvent gives your new carried total first. Both are amounts to overwrite, not changes. OBSERVED (one session, bank): +4 was answered by StorageKamasUpdateEvent 4; -4 by KamasUpdateEvent (carried total) and StorageKamasUpdateEvent with no value, i.e. 0. PADDING. Builds add unread members, including a second int64 on 3.7. Fill only the recovered amount. When you may send it Requires exchange_open inferred Raised by: the player confirms a kamas amount in an open exchange window: the bank (either side) or a trade proven Related messages You will then receive StorageKamasUpdateEvent observed — the bank's new kamas total; 2 of 2 observations (one deposit, one withdrawal) Fields #FieldTypeMeaningYou set it 1quantityint64The kamas to move: positive deposits into the exchange, negative withdraws from it. (kamas, signed)required

New cells and facing directions for one or more entities of the current context, typically the fighters during placement. Kind event · Area Game.Context Moves entities without a walk: each entry is an EntityDisposition - which entity, the cell it now stands on and the direction it now faces. Nothing animates a path; the entity is simply put there. WHAT TO DO WHEN YOU RECEIVE IT 1. For every entry, look the entity up by EntityDisposition.entity_id and OVERWRITE its cell (EntityDisposition.cell_id) and its direction (EntityDisposition.direction). 2. LEAVE EVERY OTHER ENTITY ALONE. It is not a snapshot: entities missing from the list keep their position. 3. SEND NOTHING BACK. No handler of this message builds a request. WHEN IT ARRIVES. In the client it is handled by the fight services (the placement cells and the fighters' on-map positions). In a capture it arrived right after AttackMonsterRequest: first with the attacker alone, then four more times with the attacker and one monster each, while the fight was being set up. Expect it whenever a fighter is (re)placed during the placement phase, yours or someone else's - including after your own FightPlacementPositionRequest. NOT THE PLACEMENT SWAP. The fight placement swap announcement carries the same kind of list but belongs to the fight-preparation protocol file; this one is the context-level message. PADDING. Builds pad this message with an unread int32, or with a SECOND list of the same record type (3.6.10.10) that the client never reads. Read the recovered list only. When you may send it Requires context_ready inferred Related messages Arrives after AttackMonsterRequest Arrives after FightPlacementPositionRequest Fields #FieldTypeMeaningYou set it 2dispositionsrepeated EntityDispositionThe entities that moved, each with its new cell and direction. Element type EntityDisposition. Only the listed entities change.never