FightPingsEvent

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.