ExchangeStartedWithStorageEvent

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.