You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Create EOLib.Net.Protocol project
Add eo-protocol as a submodule of EndlessClient
Code generation using Roslyn generators, similar to how [Record] works
Take eo-protocol net directory as an input
Structures from eo-protocol get turned into class files
Packet specs from eo-protocol get turned into "parsers"
Each parser takes a Packet input and spits out a parsed object
Existing handlers take a parsed object as a parameter and no longer do parsing (data handling only)
Incoming packets are fed through a top-level parser object that finds the appropriate packet parser based on Family/Action
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.
The text was updated successfully, but these errors were encountered:
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
Cons
Some thoughts:
[Record]
worksnet
directory as an inputStill 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.
The text was updated successfully, but these errors were encountered: