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

[trevius]

Well, I got the actual slot stuff set in the SoF code last night to allow items set as slot 22 to show up as Power Source in SoF and items with Slot 21 to show up as Ammo like they currently do.

I did a DB check last night on my items table and it looks like they didn't add any new ammo slot items since SoF, because I didn't see anything set to use slot 22 at all. Maybe a fresh PEQ DB would show differently, but I think the last update I did on mine should have included them if there were any.

Basically, this means that only the Power Source items would have to be changed over to use slot 22 to work with the new slot arrangements. I tested it last night and setting them to slot 22 does make them equipable in the latest SVN, so it should be ready for a database change now. I don't think the change is as simple as a single query though, because both Ammo and Power Source items currently in the Database use slot 21. So, I think they have to be changed by hand. I used Navicat last night and sorted my items table by slot and was able to manually change all of the Power Sources from slot 21 to slot 22 very quickly with just copy and paste. There were only 50 or so of them and they were all right next to each other.

I would not advise for anyone to actually put an item into the Power Source slot right now unless they are testing it, because it will definitely delete the item after you do so. This is because I don't have the extra code in place to support the new inventory slot yet, but I will try to work on that further tonight. It will have to be added to be able to save to the database, and to be usable as a clicky if it has a click effect. Also, I noticed that if you set stats on a Power Source item, the client will definitely gain those stats, which means that I will need to add that slot in to calculate the bonuses from it so that the server factors them in properly. That's pretty cool, because I was not aware that Power Sources could actually give stats to the client directly. So, not only could the item be used for an extra clicky slot, but it could also be used for any other stat and probably even worn and focus effects, which is nice.

[cavedude]

Originally Posted by 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

I only replied because Trevius mentioned me by name asking my opinion.

In PEQ's case, the change actually should only take one query with the way you set it up. If I remember from the last time I played around with ammo vs power source items there was a column or two that identified the two right off the bat for me other than slots. I probably should have bumped power slot items when I changed ammo slots to work on Titanium but I didn't think ahead.

[trevius]

Ahh, I see! So, that makes sense why I didn't see anything set to use Slot 22 when I checked my items table after recently updating it to PEQ. I didn't know that you had already done that conversion to make them compatible with Titanium. Good to know

If there is another field to help you identify Power Source items, then that should make it fairly simple. And yes, I was referring directly to Cavedude, because IMO, his database is the most important for current items that would include new stuff like Power Sources. For custom servers, it doesn't really matter much, because if they haven't updated to add in new items from the PEQ DB, then they probably don't have Power Source items in the first place. For custom servers, they would most likely just be creating new items and would then just set them to slot 22 if they wanted them to be usable in the Power Source slot.

It sounds like the DB change should be really quick and simple. I will probably mention the new slot 22 to GeorgeS so he can update his tools to add in the new slot if possible.

Hopefully I can get all or at least most of the new slot stuff worked out tonight so it can be saved in the database and can be handled just like any other worn slot. While I am doing that, I am also going to see if I can get Cursor added to the nukeitem() function so we will finally be able to delete items from player's cursors. I don't know why cursor wasn't added to that long ago, but since I am adding another slot in that for Power Source, I might as well get cursor added in there too.

[gaeorn]

Sorry I wasn't clear in my earlier post. I was merely trying to re-express Trevius' concern over the difficulty some people might have had updating their DBs if slot numbers had changed more radically. I was just stating this because Cavedude's post indicated it would be easy for him to convert either way.

Anyway, if what I was trying to say still isn't clear, just ignore it, lol. It somehow got all convoluted up to the point it almost doesn't make sense to me anymore.

In any case, based on Trevius' expertise with the code, I expect his judgment of which course to take was the best one. I merely was submitting a different point of view in case it had not been considered.

[trevius]

LOL, I don't know if "expertise" is the right word for my skill level with the source code :P

I know a ton more about it than I did 10 months ago, but I am still quite a newb at coding. I have simply read over the code repeatedly in almost every spot, so I am fairly familiar with it. The only thing I am getting decent at is understanding packet structures and how all of that stuff works. As for the actual code, I have a very long way to go before I would consider myself an "expert", LOL.

The suggestion you made really is the ideal way to go, but that doesn't mean that it is the best way to go. In the end, I don't think it would really make much of a difference in the long run, so it probably just isn't worth the extra work now.

[cavedude]

Originally Posted by gaeorn

Sorry I wasn't clear in my earlier post. I was merely trying to re-express Trevius' concern over the difficulty some people might have had updating their DBs if slot numbers had changed more radically. I was just stating this because Cavedude's post indicated it would be easy for him to convert either way.

They couldn't have, remember slots are handled by the client. If somebody started changing slot values around the items wouldn't function properly. It will always come down to a single subtraction or addition query of the slot's base binary value. The trick is, as Trevius and I were discussing is figuring out which are ammo and which are power slots (because my dumb ass changed ammo a while back and left power slots alone) but I have that worked out.

At any rate, I'll write a post-it reminding me to fix power slot items in the DB today.

[gaeorn]

Originally Posted by cavedude

They couldn't have, remember slots are handled by the client. If somebody started changing slot values around the items wouldn't function properly. It will always come down to a single subtraction or addition query of the slot's base binary value. The trick is, as Trevius and I were discussing is figuring out which are ammo and which are power slots (because my dumb ass changed ammo a while back and left power slots alone) but I have that worked out.

At any rate, I'll write a post-it reminding me to fix power slot items in the DB today.

I know the slot numbers are hard coded on the client. I meant the numbers used on the server end since the two clients disagree on a few slot numbers.

[cavedude]

Originally Posted by gaeorn

I know the slot numbers are hard coded on the client. I meant the numbers used on the server end since the two clients disagree on a few slot numbers.

I'm not sure what you mean? It is true that the two disagree on ammo slot (no others though) though, KLS changed that a while ago. If you are using stock EQEmu code then the DB change will be the same regardless of what DB you're using.

If any custom servers changed the slot numbers in their code then that it isn't our concern to support them because we're not mind readers and don't know what they changed :P If they changed their code and deviated from the core code, then it's their responsibility to make the required DB changes, not ours.

[gaeorn]

Cavedude, it appears what I have been writing in here is not coming across as intended to you. I've been kinda thrown off by your last couple of replies since they didn't seem to have much to do with what I was trying to say. I guess my replies appeared the same way to you. As best I can tell, it appears you were taking each of my replies on their own, rather than being an attempt to clarify one of my earlier replies, which is how the last few were intended. Maybe I should have been more specific in my replies.

In any case, I believe I understand and agree with everything you have said. I just didn't seem to be able to get that across.

This is starting to feel like the Abbott and Costello "Who's on first?" routine, lol.