Starting the discussion back up on this since it is basically required to implement RoF completely for EQEmu.
I think your system looks pretty good for the most part. Though, the "range" stuff could probably just be changed to match the RoF slot type system. That should leave no conversions needed for RoF slots. The only issue I see with following the RoF slot system exactly is the possibility that another slot could be added to the worn inventory, which would push the main inventory slots up by 1 (or whatever number) for future clients (which would be a simple conversion in the patch files). If the types get changed up, that would mean another conversion would be needed as well, but I don't think it would require any major work at all.
I think the benefits of using the RoF slot system probably outweigh the cons. It would mean less confusion about which slot is which when looking at the slot stuff between what is stored in the DB and what is used by the client. There would be no need to have to look up what slot type 20 (buy back for example) for RoF is in the DB, they would just match. Their system is already very flexible and is very similar to what you put together minus splitting up worn and main inventory.
We already know most of the slot types from RoF are as follows:
0 - Worn and Main Inventory Slots
1 - Bank Slots
2 - Shared Bank Slots
3 - Trade Slots
4 - Tradeskill Container Slots
5 - Cursor Buffer
6 - Tribute Slots
20 - Buy Back/Reclaim Slots
21 - Parcel Slots
We also have the conversion functions in RoF.cpp that would be needed for the older clients to use the Titanium system.
Since it is a pretty big project to move to a new slot system, I was thinking we might be able to break it up a bit and just use conversion functions that can be moved to different parts of code as we progress. For example, we could start off by providing SQL that will convert the slots in the inventory system to the new slot system, and then use conversion functions to convert to Titanium slots after it loads them from the DB (as well as when it saves to the DB) until further support is in place. Then work through all of the code that deals with slot stuff and finally put in conversions in the patch files for each of the older clients that will need it and change all of the related structs in eq_packet_structs.h.
One issue with converting the inventory table will be that I think augments will need to be stored in their own rows instead of in the same row as the item they are augmenting. This should allow for more flexibility anyway, but will require a bit more thought on making sure the SQL is correct to convert them all. Basically, augments will be loaded the same way as items inside a bag.
Also, I am sure we will need to review how these changes will affect corpse blobs with items in them, as that thing is always messy to deal with. Ideally that blob should go away at some point and be replaced with separate tables for player_corpses and player_corpse_inventory or something like that.
More thoughts to come as time permits...
|