Forum :: EOSERV :: Structural definition of the EO protocol

Random post. This is a structural definition of the EO protocol (or at least the parts that are used in EOSERV, which isn't 100% of it, notably missing law/priest packets). There's probably a few errors here and there as well. The structure of the language it's written in shouldn't be too hard to figure out.

• https://tehsausage.com/upload/eo_protocol.txt
  

As a bonus, here's the same thing for pub/map files (though maps couldn't 100% be represented in the way I needed them to be because of the way tile data is stored).

• https://tehsausage.com/upload/pub_protocol.txt
  

They might be useful if you need a reference, or also want to auto-generate code from them. Note that a limitation in the code I'm generating means DialogEntry has an incorrect definition: link_id is not present at all when entry_type = Text.

Obviously this doesn't make any reference to what exactly is meant by char/short/three/int ( / how numbers are encoded), how strings are encoded, how packets themselves are frames and encoded, or the semantics/meaning of any of the packets.

This needs cutting up and used to replace the current mess in the Wiki. Any takers?

---
http://sordie.co.uk
http://twitter.com/@SordieEO

IMO , a better wiki for eo would be like this :

*Full documentation of the encryption method

*Full documentation of the packets composition in this orientation : 

A-Packets received by the server

*A page for each family

-A page for each action derived from this family and complete explanation

B-Packets sent by the server

*Full documentation of how maps/pubs are being dealt with.

freezingsoul posted: (9th Dec 2016, 05:26 pm)

IMO , a better wiki for eo would be like this :

*Full documentation of the encryption method

*Full documentation of the packets composition in this orientation : 

A-Packets received by the server

*A page for each family

-A page for each action derived from this family and complete explanation

B-Packets sent by the server

*Full documentation of how maps/pubs are being dealt with.

Apart from the encryption*^mangling method, that's pretty much what those two text files define. True they are in a (very nice and clean) pseudo-code layout but if can't understand it then you probably don't need to.

---
http://sordie.co.uk
http://twitter.com/@SordieEO

Sordie posted: (9th Dec 2016, 06:42 pm)

freezingsoul posted: (9th Dec 2016, 05:26 pm)

IMO , a better wiki for eo would be like this :

*Full documentation of the encryption method

*Full documentation of the packets composition in this orientation : 

A-Packets received by the server

*A page for each family

-A page for each action derived from this family and complete explanation

B-Packets sent by the server

*Full documentation of how maps/pubs are being dealt with.

Apart from the encryption*^mangling method, that's pretty much what those two text files define. True they are in a (very nice and clean) pseudo-code layout but if can't understand it then you probably don't need to.

I was speaking about soemthing user-friendly something like the one here https://eoserv.net/wiki/Technical but complete and better organized.
Anyway since it's wiki = freedom , i would be happy to do it myself when i have time.

Neato. Thanks for this documentation.

---
Want to learn to pixel?
Pixelsource.org

Trust me, I'd love to write out a full protocol documentation, but it's a lot more work then it seems. The amount of packets alone is surprisingly high, and making sure to get things 100% right: a decent amount of things would involve cross-checking with the official server to be sure of. A lot of things that ended up in EOSERV were guesses or left blank. Even the low level protocol itself isn't exactly the same. Official EO apparently has the concept of variable-sized integers which EOSERV just doesn't do. Testing all the cases where that can happen and work correctly with the official server sounds like a nightmare.

It's hard to formalize a flow of which packets are sent/received, because past the login screen a lot of stuff kind of "just happens". The effects of almost every server packet corresponds directly to a specific set of actions that happen in the client. Simple things like request/reply happening aren't guaranteed, and the game server uses packets in creative ways to get certain results. To model the protocol accurately is to model a game client state. Even saying something like "This packet opens the board dialog" for example is incomplete since you can't have more than one board dialog open and I believe the server actually takes advantage of this to refresh the listings. There's similar abuse of "chest open" packets.