Drakkin Features

**trevius** · #1 05-12-2009, 07:33 PM

I am trying to figure out the best way to handle new SoF specific stuff like Drakkin Features. For NPCs, we could just add drakkin_heritage, drakkin_tatoo, and drakkin_face_spikes to the npctypes table with default of 0. But, for characters, I am wondering what the best way is to save that info. I think there are 3 possibilities to consider:

1. Use one of the following unknown fields in the player profile blob to assign them as drakkin related fields. I think this would work just fine, but wanted some input on it just in case. Probably any of these unknowns would work:

common\eq_packet_structs.h

Code:

/*0112*/    uint32                unknown0112;        //
/*0245*/    uint8                unknown0245[7];    //
/*0348*/    uint8                unknown0256[44];
/*2456*/    uint32                unknown1496;
/*2505*/    uint8                unknown1545[47];    // ?
/*2580*/    uint8                unknown1620[4];
/*4716*/    uint8                unknown3756[4];        //

2. Add the drakkin_heritage, drakkin_tatoo, and drakkin_face_spikes fields to the character_ table and pull them from there.

3. Create a new table named "Profile" that could be used for player profile related fields. It might not hurt to have some of the profile in table format anyway, since it is much easier to adjust if needed. I recently did a currency change on all characters and something that would have been extremely simple to do if the profile was in a table instead of a blob became quite a hassle. Does having the profile in a blob really help overhead that much?

I figured I would start a discussion on this to consider the options before trying to implement any of the new stuff. I am sure there are other minor DB changes like this that will be required as well. Even though 13th floor doesn't have record of it, and I don't think any items on Live utilize it, SoF most certainly has Heroic Resists, and we need fields added to the Items table for those stats. Of course, even once the fields are added, there will need to be code to get that data for use in game.

**KLS** · #2 05-13-2009, 12:22 AM

I would suggest against that, what if we later find out what the field we stored it in means? You then have to write a utility to convert every character over. I would suggest the extended player profile.

**trevius** · #3 05-13-2009, 02:40 AM

(KLS, I know you fully understand what I am explaining below, but I am just trying to explain my understanding of it so others can follow and so I can be corrected if I am wrong about something. And I am trying to figure out if we should really care about the blob struct anymore.)

I figured that the profile blob didn't really matter at all. It is essentially used as a table inside a table. In that we pull out the blob, pull the data from whatever piece of it we are needing and then save changes if needed and put it back in. Seems like we could arrange it in any order we wanted. It doesn't send the actual blob itself, unmodified. It creates the profile 1 field at a time by us telling it where to look in that blob based on the structure we have set for it.
There is so much wasted space in our current profile blobs, that I am sure it eats up a fair amount of space in the DB. Any unknowns in there are just a waste as far as I can tell.

One problem I have is that all of our clients have encodes set on the player profile. This means that the structures for our clients do not match our blob structure. So, even if we did ever identify new fields on either Titanium or SoF, the player profile blob is completely useless to us for that since it most likely isn't going to line up perfectly anyway (they are very different). So, we have a ton of fat on the current PP blob that is just there for no reason as far as I can tell. We should probably either try to use it, or get rid of it.

Just a little math (and yeah, sorry I am getting off subject lol):
The player profile structure for the blob is currently about 20,000 bytes (20k)
If PEQ has 100,000 characters (just making up a number), then their total space used just for player profile blobs is about 2GB (100k X 20K)
That makes for a fairly large database backup file I am sure. So, over half of that blob is unknown, and I believe completely unused. So, they could be saving 1GB of space if the unknowns were removed. The Storm Haven full database backup is about 2GBs and 500MBs of that is just the character_ table alone, and I am sure almost all of that table is player profile blob. Not that size is really an issue, but just giving an example of how much space we are wasting with the unknowns.

Since we do encodes of the whole thing anyway for all of the expansions we use on EQEmu, couldn't we just make up our own PP structure to however we wanted it? I am sure it would be a hassle to convert it over, but other than that, I don't see why not. I personally would love to see it moved into it's own table, but that would probably be a nightmare to write that all up.

Sorry again about getting off of the subject, but I just think the old player profile is not as useful as it probably once was. Before needing to do the encodes, we could probably just send that whole thing in 1 big chunk! But now, we break it down and put it back together again however we want it, so it probably isn't that great of a way to handle it anymore.

**KLS** · #4 05-13-2009, 03:01 AM

Alright but you gotta make sure you write the encodes so they work. And remember once you put something into the pp it's kinda hard to take it out~

**trevius** · #5 05-14-2009, 07:49 PM

Still trying to figure out exactly how I want to start implementing these. Maybe I will try to use the extended profile after-all, just to get away from using the player profile blob. Maybe some day we can do an overhaul on the PP storage or replace it with something better and easier to manage.

Seems like it is going to be quite a pain to get these new fields added. Going to need to update the npc_types table with the new fields, and update the extended profile with the new fields. Then, going to have to update all of the related structures and encodes/decodes where appropriate. I think that will include the char select, char create, spawn, player profile and facechange structures at the very least. The hardest part is probably going to be making sure that the way these structures get that data are all setup properly. I haven't added new fields like this before, so this should definitely be a learning experience. Hoping not to mess anything up in the process, but I will try to test as much as I can to be sure before updating the SVN with anything.

Before doing anything with the new features, I need to make sure that Titanium facial features are all working properly without the previous hacks. I already removed the hacks and SoF is working perfectly as far as I can tell, but now I need to get Titanium working 100%. Once that is all done, I will try to get started with adding the new drakkin features. It's gonna be cool to have this stuff finalized

**realityincarnate** · #6 05-14-2009, 08:13 PM

Sorry to be the bearer of bad news, but it looks like at least some of the Titanium features are wrong now. I haven't looked into it in depth, but one of my test characters is now bald (no idea what he used to look like, I hadn't looked at him for a while, but I know he had hair), and Arias in gloomingdeep has a beard and combination ponytail/baldness. I know he's never looked right, but he never looked like this either. Those are the only two issues I've seen so far, but I haven't looked much either.