im not gunna get too involved in this discussion, but I will throw in what I took away from me and Doodman talking about this a while back.
Basically the best way to achieve independance from struct changes in the client is to do what I did for opcodes: Make all the game code use an internal representation of the struct which will not change, and therefore not need recompile. Then have some agent to convert from this internal representation to the actual net-layer representation when you send or receive the packet.
Your meta layer would address some of this in that it could generate the internal structures, and assuming it supported different named maps for each 'patch' you supported then it could generate most or all of the translation routines as well.
The major problem with this scheme is that you have to keep in mind what a struct change normally means: they added something to the packet. The internal packet representation would work fine if they scrambled or shortened a packet, but that is rarely the case. In the case of addition, in order to do something useful with the additional field, you would have to also add something to the internal representation of the packet to get that additional information down to the packet translator, which means recompile. Granted, if you just wanted to leave the new space as 'unknown' then you could get away without recompiling. But this kinda limits the utility of it to pure testing and ignoring the new fields.
Also keep in mind that there are many dynamic length packets which do not contain their length at all, but instead rely on (possibly many different) null terminated strings to dictate their length. Also arrays of dynamic length structs. Both of these are getting more and more common in eq1, so I can only imagine they are coming from eq2-isms.
I am sure there are other ways to pull this off as well, such as using some dynamic structure in memory, and a dynamic converter, but your talking about significant overhead in those situations.
|
Threaded Mode
