Admin tool progress
I was up late last night hacking at the admin tool code, and I'm pretty confident now that I'll be able to have the next version use text files that describe the profile structures instead of having them hard-coded. I've constructed text files for player profile, item profile, and item info (for inventory slots), and I have the read portion working. That is to say, the admin tool is using the original record structure internally, but my code allows it to read from the database using the definitions in the text files and translate the information on a field-by-field basis to its internal structure. I still have to finish the capability of going from the internal structure back to the database (making sure to preserve any "unknown" fields), but it's mostly coded. It's a little bit slower than before, but not all that much (the field list is sorted which allows Delphi to use log(n) binary searches). I can also speed it up in several places, since most of the time the tool only needs the item name, not the entire record.
What all this means is that, if fields move around due to a patch, all that has to change are the text files. The application won't have to be recompiled, unless the change is really major. The application finds fields and structures by name, so it's important not to change the field and structure names in the text files. The text files are very closely based on eq_packet_structs.h, so it would be a real snap for the emu team to update them once they update their .h file. Each text file has lots of info at the top describing the format that's expected. My code even does type-size checking to make sure that fields aren't overwritten, so even if, for example, VI went to a larger or smaller type size for a given field, the app wouldn't break as long as the text file reflected the change. It even supports nested structures (needed to handle inventory slots in the player profile), but I still have to test this. It also supports n-dimensional arrays (Delphi open arrays are *wonderful*). Unions aren't supported in the syntax that C handles them, but they *are* supported (every field definition *must* be preceded by an integer describing the byte offset from the start of the structure).
I don't know if this technology is useful to any other programs, but conceivably it allows general-purpose record translation that makes maintaining software a bit easier since the configuration can be changed without recompiling. There *is* a performance hit, but in areas where performance isn't critical it might be useful.
Windcatcher
|