Live compatibility

[masterfreek64]

Keeping it live compatible ...
The way I propose keeping EQ2Emu always compatible to the latest version of live EQ2 is the way DOL handles it.
You just remove all direct packet handling from the core and place net packet creation ( not TCP / IP stuff etc , just making the byte sequence ) in modules. Like this , the server can ALWAYS be upgraded to the newest version by just upgrading the packet libraries ... This can be done by fans.
However a problem would occur with Login servers -
either you release at least the packets somehow or you got to do that yourself...

[ZexisStryfe]

The major problem with this at this point is that the world isn't even working yet (no combat, quests, etc) and we effectively have 2 developers working on getting all the features working. Would you rather they keep up with live or get everything else working?
There is no need really to keep up with live. Expansions only come out once a year now, giving us plenty of time to get things up and running on the previous expansion before the next is released.

[LethalEncounter]

Keeping it live compatible ...
The way I propose keeping EQ2Emu always compatible to the latest version of live EQ2 is the way DOL handles it.
You just remove all direct packet handling from the core and place net packet creation ( not TCP / IP stuff etc , just making the byte sequence ) in modules. Like this , the server can ALWAYS be upgraded to the newest version by just upgrading the packet libraries ... This can be done by fans.

That is how it works right now. The packet structs are stored in WorldStructs.xml and can be edited in any text editor to get it working with Live. If someone wants to do this they are more than welcome, but I am going to be spending my time working on the core functionality. Playing catch up to live at this point isnt really beneficial in my opinion.

[masterfreek64]

ok thanks ... well I would still go for a code alternative , but like this it is ok as well ...

[LethalEncounter]

Yah, code would definitely be faster and eventually we might convert it back to code instead of using the xml structs, but the ease of use and simplicity is the driving factor for using xml structs. With most of the structs being dynamic sizes we could either make it use for people to use (xml structs) or we could have made a hard coded solution that would have been a pain for everyone involved. It was decided to go with the more flexible option at the time. Eventually if we ever get to a point where the structs start becoming the bottle neck of the whole system, we can change them if necessary but we are far from that point.