The Rust model of the ygopro data structures.

This crate mirrors the types used by the original C++ ygopro and its core, so it is the shared data layer for the Rust ports.

Modules

• [data] — outside game data: cards, decks, limit lists, replays; and the complicated structs inside messages: queries, responses.
• [message] — ygopro protocol messages (client-to-server, server-to-client) and ygocore protocol messages (game message).
• [constants] — the constants and enums shared across the protocol (players, locations, ...).
• utils — UTF-16 string helpers and the lazy Complex message type.

Notes

Some types and functions whose purpose is obvious from their name are left undocumented.

Most plain types are byte-for-byte identical to ygopro. However, the following types have a memory layout that differs from their serialized layout:

• UpdateData is a variable-length list read until EOF; ygopro's unique layout makes it impossible to map soundly in safe Rust.
• Any type that uses a Vec: in memory a Vec is a pointer plus a length and a capacity, while on the wire it is a contiguous byte stream. Examples: SelectBattleCommand.
• TypeChange: differs because of Netplayer change.
• Replay: boxed because it is too large to inline in the message enum.

The following types differ noticeably because of design issues in the ygopro crate:

• Netplayer, and consequently CorePlayer.

Why binrw instead of serde

serde's data model does not fit ygopro's data types well, while binrw offers more freedom — e.g. compressed formats like Replay and streamed structs like the query structs (CardPosition, InfoLocation).