PaleTree is a packet logger that utilizes data coming from packet providers, like Zemyna.
Just like its cousin MabiPale, PaleTree allows you to log packets, and save, load, and modify the logs. However, unlike MabiPale, you won't see clear, separated variables here, as ToS's protocol doesn't communicate this information. Instead, PaleTree features a hex editor on the right side, and it has a plugin to show which values might hide behind a bunch of random bytes, starting at the selected index. For deeper analysis, a tool like 010 Binary Editor is recommended.
Another difference to MabiPale, is that due to the availability of op codes, there are no unknown ops, and in case of changes, the ops are saved inside the logs, so you never have to worry about incorrect op names. But you should update PaleTree regularly, since any change in an op could result in confusing data.
Remember to regularly update PaleTree and Zemyna whenever one is available, as they need to be up-to-date to work with the latest client.
Log management (deleting, filtering)
Variable Preview: Displays what values could be read from a packet, starting at the selected byte.
How to use
Put Zemyna.exe into your ToS folder
Create a link to Zemyna.exe, using parameters for the appropriate server. For example to connect to the international server Laima, you would use Laima's login server IP and port:
Zemyna.exe host:126.96.36.199 port:2000
And to connect to a local server, without Steam auto-login, but with a login form, you would use this:
Zemyna.exe host:127.0.0.1 port:2000 nosteam
Start the client with that link whenever you want to log packets.
Click connect in Pale to subscribe to Zemyna's packet broadcast and to start logging packets.
The packet data in the hex editor is always the raw data received/sent by the client, incl. packet header. This means the actual values don't start at the first byte.
Packets from the client to the server have a 10 byte header:
Packets from the server to the client are the same, just without the checksum, so it's 6 bytes in total. Additionally, packets that don't have a fixed size have another short (2 byte) before the actual data, the length of the entire packet. Packets that have a fixed length will say something like "Size: 50 (Table: 50, Garbage: 0)" in the packet information on the right side, after the op, while dynamic packets don't say this (dynamic packets are ones that include lists or variable sized strings, where you can't define a fixed size).
The last thing of note is the potential "garbage" at the end of packets from the client to the server. Because of how the packet encryption works, the length of packets from the client to the server is always a multiple of 8. Packets that have a fixed size will be able to determine that X byte are "garbage", because they don't belong to the actual data, but are a left-overs from the encryption process.
The garbage bytes can generally be ignored, the only reason we don't truncate them is that we could potentially lose data if the ops are outdated.