Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EOLib.Net - generated packet code #268

Open
ethanmoffat opened this issue Dec 3, 2022 · 0 comments
Open

EOLib.Net - generated packet code #268

ethanmoffat opened this issue Dec 3, 2022 · 0 comments

Comments

@ethanmoffat
Copy link
Owner

Cirras wrote a complete documentation of the EO protocol in XML format: https://github.com/Cirras/eo-protocol. It would be great to use this for automatic code gen of packet handlers and structures.

Pros

  • Implements parsing of unimplemented packets for free
  • More accurate to original EO parsing

Cons

  • Requires work to get code generation going
  • Significant rewrite needed for existing handler system (it was already a mess anyway though)

Some thoughts:

  1. Create EOLib.Net.Protocol project
  2. Add eo-protocol as a submodule of EndlessClient
  3. Code generation using Roslyn generators, similar to how [Record] works
    • Take eo-protocol net directory as an input
  4. Structures from eo-protocol get turned into class files
  5. Packet specs from eo-protocol get turned into "parsers"
    • Each parser takes a Packet input and spits out a parsed object
  6. Existing handlers take a parsed object as a parameter and no longer do parsing (data handling only)
  7. Incoming packets are fed through a top-level parser object that finds the appropriate packet parser based on Family/Action
  8. Once parsed, just need to find a handler based on the object type instead of looking up based on family/action again

Still need to figure out what the interface for the parsers/handlers will look like. Ideally the parsed objects would be strongly-typed classes with each of the fields defined as properties. This makes it a bit difficult to define a single interface since each of the object types is different.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant