Power Source Slot

[trevius]

As part of finishing off the SoF client, we need to get something figured out for the new Power Source slot in SoF, which the client currently sees as slot 21 (which is the slot for ammo in Titanium). Since worn slots in Titanium go from slot 0 to slot 21, we cannot use any of those slots for Power Source. The next available slot would be slot 22, and I think we can use that one just fine if we do it correctly. Here is what I propose:

Any items in the database that should for the Power Source slot should currently be set to use Slot 21, and so those will need to all be changed to slot 22. We can probably also do a query before that change to see if anything is currently set to use slot 22, since that is the new ammo slot now, and we could convert all of those to slot 21.

Since slot 22 in the inventory is actually the first main inventory bag slot in Titanium, we will have to do a conversion to have it save the slot the items are equiped in. To do this without worrying about overlapping other slots, I have conversions already in place to convert anything in the Power Source slot in SoF to be saved as slot 9999 to the inventory table. This way, the database can use the Power Source slot without overlapping any current slot, but SoF can still use the slot properly. Basically, the conversion to 9999 would happen when you move items to or from the Power Source slot, or when saving your inventory or selling items, etc.

The actual slot that Power Sources can be equiped in is slot 21 in SoF. So, once we have the database set to change all Power Sources to slot 22, we can do a simple conversion to convert any items that are usable in slot 22 to be set to use slot 21 in SoF. This slot 22 setting is only for the items table itself, and has nothing to do with how the server sees the slot id. This is because the client has to see it as slot 21 for it to be able to equip it. Since equipable slot settings in items are set in bits, here are the 2 bit settings for the current AMMO slot as well as the new slot 22 for Power Source:

SLOT_AMMO = 2^21 = 2097152
SLOT_POWERSOURCE = 2^22 = 4194304

I don't think these need to be set anywhere in the source code other than just doing the conversions where needed. I recently added conversion functions into the SoF.cpp that converts Titanium slots into SoF slots. All of the existing conversion stuff should be ready for the new Power Source stuff to be coded in.

I think once the database is changed, the only other change that will need to be done is in SoF.cpp to have it convert slot 22 to slot 21 if the item is set to slot 22. If the item is not slot 22 to begin with, it will just move to the next step and run the function to do the conversion.

I think this should be good enough to get around the slot issues with the new Power Source. The main reason for posting this before doing it is for any feedback in case there might be better suggestions on how to handle it. Given that we have 2 different clients with 2 different slot sets, I think we are limited in what we can do without some type of conversion like this. I also mostly wanted to post this here to see what Cavedude thought about it from a database standpoint. If I make these changes, he would need to edit the PEQ DB items table to do the slot conversions. I think that converting the existing slot 22 stuff (which should all be for Ammo slot) should be really quick and easy to do. Then, converting Power Source slots would probably need to be done manually. There aren't too many of them, so it shouldn't be overly hard to do. And, any future ones that get added would also need to be converted.


According to this page on Allas:

http://everquest.allakhazam.com/dyn/...er_Source.html

It looks like all Power Source slots in Live have the word "Energeian" in the name, so it might not be too hard to find them all and get the slot id changed from 2097152 to 4194304.

This isn't a very big issue, since the Power Source slot currently has no code to actually support what it is supposed to do, but I figured custom servers might like to have that slot available for clicky items or something. It would at least be nice to be able to put something in that slot instead of having a perma-empty slot in SoF.

[gaeorn]

Although what you suggest would work, I had a thought of a different approach.

What if we have everything stored on the server side using the slot numbers that SoF uses. Then all we would have to do for Titanium is convert the slot numbers that are different. This moves the database engine forward to match SoF and new item data as it comes in.

Also, since Titanium has a subset of the SoF slots, it should simplify the code overall. Since some of the slot numbers are different for Titanium, we can convert the SoF slot numbers to Titanium slot numbers in the code for the Titanium client. But the main code and the SoF code would not require any conversion at all. And the item DB would have the proper slot numbers for the future.

Additionally, when we no longer wish to use Titanium, we simply drop that code. We wouldn't be carrying over historical slot number changes that no longer made any sense.

What do you think?

[trevius]

Ideally, that would be a good approach, but it is also quite a bit more of a pain in the a$$! For one thing, everyone's inventory tables are already built around the Titanium slot layout. Which would mean everyone would have to run queries against their entire inventory table to convert the slots over. This would be no simple query either, so the risk of something going wrong is high and if something did go wrong, it would probably be pretty bad. Of course, as long as you had a backup ready to go, it could be corrected, but not everyone is smart enough to do a backup before making big changes like that.

Then, another issue is that we finally now have all of the encodes in SoF.cpp set to handle the slot conversions between the 2 clients. If we change everything to use the SoF slot order, we will have to take every one out of SoF.cpp and put the reverse into Titanium.cpp as well as adding a ton of encodes in there that don't currently exist. It wouldn't be insanely hard to do, but why waste the time?

Also, a large portion of the items table is already built around Titanium slots, so it would probably mean converting all slot 21s into slot 22s and then manually setting the Power Source items back to slot 21. This part wouldn't really be more work either way, because almost the same thing is going to have to happen no matter how it is done.

We are going to have to do conversions one way or another. As long as everything works perfectly in the end, I think it is all fine no matter how it is done. Since almost all of the conversion work is done from Titanium to SoF for slots and other stuff like Structures, I would really hate to have to undo all of that and start doing it over for Titanium.

The point of having multiple patch compatibility options like we do is that we can have a centralized system that the different client versions can use and make conversions to or from to make sure that they are all compatible with the server. I doubt that Titanium will ever be phased out. I also think it is unlikely that there will ever be another expansion past SoF that will be used by the emulator. Since SoF is almost done, there isn't much reason to go back now and redo everything like that as long as stuff can be easily fixed with little work-arounds.

I think by even starting this thread, I probably made the whole thing sound more complicated than it is lol. I will test it out and see how well the changes work.

[gaeorn]

Fair enough. You are much more familiar with the code base than I am. As long as it isn't going to cause regular problems in the future, I see no reason not to do it as you suggest.

[cavedude]

From a database perspective converting either way will only be two easy queries since they are bitmasks. Just let me know what the final decision is, so I can get into PEQ

[gaeorn]

I suspect Trevius is more concerned about others with custom DBs that are not as good at SQL queries. In any case, it's up to him since he's writing the code and I'm still a noob around here