Author | Message | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ![]() 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. 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). 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 packets composition in this orientation :
*Full documentation of how maps/pubs are being dealt with.
|
| ![]() freezingsoul posted: (9th Dec 2016, 05:26 pm) Apart from the --- http://sordie.co.uk http://twitter.com/@SordieEO
|
| ![]() Sordie posted: (9th Dec 2016, 06:42 pm)freezingsoul posted: (9th Dec 2016, 05:26 pm) 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. |