EQEmulator Forums - Missing items since SoF

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Support::General Support (https://www.eqemulator.org/forums/forumdisplay.php?f=598)

- - Missing items since SoF (https://www.eqemulator.org/forums/showthread.php?t=28497)

Missing items since SoF

Other than the fast rate of food consumption, we noticed things missing. Could this be from the opcodes ? One of my players camped and I saw this in the log....how do gems have charges ?

Code:

[Debug] [NET__ERROR] Moved item from 31 to 323

[Debug] [INVENTORY__SLOTS] Ellisar: Src slot 30 has item Crushed Onyx Sapphire (25841) with 1 charges in it.

[Debug] [INVENTORY__SLOTS] Ellisar: Dest slot 312 has item Crushed Onyx Sapphire (25841) with 1 charges in it.

[Debug] [INVENTORY__SLOTS] Ellisar: Move from 30 to 312 with stack size 1. dest has 1/20 charges

[Debug] [INVENTORY__SLOTS] Ellisar: Dest (312) now has 2 charges, source (30) was entirely consumed. (1 moved)

[Debug] [NET__ERROR] Moved item from 2182 to 31

[Debug] [INVENTORY__SLOTS] Ellisar: Src slot 2181 has item Crushed Onyx Sapphire (25841) with 15 charges in it.

[Debug] [INVENTORY__SLOTS] Ellisar: Split stack of Crushed Onyx Sapphire (25841) from slot 2181 to 30 with stack size 1. Src keeps 14.

[Debug] [NET__ERROR] Moved item from 31 to 323

[Debug] [INVENTORY__SLOTS] Ellisar: Src slot 30 has item Crushed Onyx Sapphire (25841) with 1 charges in it.

[Debug] [INVENTORY__SLOTS] Ellisar: Dest slot 312 has item Crushed Onyx Sapphire (25841) with 2 charges in it.

[Debug] [INVENTORY__SLOTS] Ellisar: Move from 30 to 312 with stack size 1. dest has 2/20 charges

[Debug] [INVENTORY__SLOTS] Ellisar: Dest (312) now has 3 charges, source (30) was entirely consumed. (1 moved)

[Debug] [NET__ERROR] Moved item from 326 to 31

[Debug] [INVENTORY__SLOTS] Ellisar: Src slot 315 has item Ancient Tarnished Chain Tunic (24907) with 1 charges in it.

[Debug] [INVENTORY__SLOTS] Ellisar: Moving entire item from slot 315 to slot 30

[Debug] [NET__ERROR] Moved item from 31 to 324

[Debug] [INVENTORY__SLOTS] Ellisar: Src slot 30 has item Ancient Tarnished Chain Tunic (24907) with 1 charges in it.

[Debug] [INVENTORY__SLOTS] Ellisar: Moving entire item from slot 30 to slot 313

Now that you mention it, I've noticed items disappearing from my bags as well... I picked up one of each of the GM race illusion items a while back, and afterward it seemed like every time I logged in and checked the bags, some of them were missing.

- Shendare

Well this player would know, he can spot things wrong in a heartbeat.

When it mentions charges in those cases, it is referring to how many are in the stack. Sometimes the word charges gets used for both stacksize and actual charges on an item. In the case of stackable items, it sees them as charges.

As for the disappearing items issue, it sounds like there are still some problems with the slot conversions between Titanium and SoF. The change of slot numbers between the 2 clients has been one of the biggest pains to getting all of the item related packets working properly. This is not an opcode issue, as opcodes are simply a way of identifying the type of packet being sent and we have most of those identified properly. It also shouldn't be related to packet structures. The problem is that with any case that involves items slots, we have to do a conversion of the slot id so that Titanium and SoF slots are compatible. Really, this is a bit of a pain, because SoF has more slots than Titanium does, so converting them causes a few issues, especially due to the addition of the new Power Source slot which took the place of the Ammo slot id and bumped up all of the normal inventory slots as well.

I think what needs to be done is that we need to put in some type of conversion function that accounts for all slots between each expansion as noted in the slot list here:

http://www.eqemulator.net/wiki/wikka...InventorySlots

I believe we have all possible slots identified other than maybe merchant slots. Even corpse looting slots got adjusted, but I should already have the encode set to account for that change properly.

It would be easy for me to write up the actual conversion for each slot, but I am not sure of the best way to utilize it in each encode yet. Maybe a function named TitaniumToSoFSlot() and another named SoFtoTitaniumSlot() or something could be made and used to convert each slot. I am not sure of where the best place to put that is, other than maybe directly in SoF.cpp, since that is probably the only place that it would get used.

Then, an encode could be done like this:

Code:

ENCODE(OP_DeleteCharge) {  ENCODE_FORWARD(OP_MoveItem); }

ENCODE(OP_MoveItem) {

        ENCODE_LENGTH_EXACT(MoveItem_Struct);

        SETUP_DIRECT_ENCODE(MoveItem_Struct, structs::MoveItem_Struct);



        eq->from_slot = TitaniumToSoFSlot(emu->from_slot);

        eq->to_slot = TitaniumToSoFSlot(emu->to_slot);

        OUT(number_in_stack);



        FINISH_ENCODE();

}

Instead of doing this, which is what we current have to do and is sloppy:

Code:

ENCODE(OP_DeleteCharge) {  ENCODE_FORWARD(OP_MoveItem); }

ENCODE(OP_MoveItem) {

        ENCODE_LENGTH_EXACT(MoveItem_Struct);

        SETUP_DIRECT_ENCODE(MoveItem_Struct, structs::MoveItem_Struct);

        if(emu->from_slot >= 21 && emu->from_slot < 50)

        {

                eq->from_slot = emu->from_slot + 1;

        }

        else if(emu->from_slot >= 251 && emu->from_slot < 351)

        {

                eq->from_slot = emu->from_slot + 11;

        }

        else if(emu->from_slot >= 2031 && emu->from_slot < 2270)

        {

                eq->from_slot = emu->from_slot + 1;

        }

        else if(emu->from_slot >= 2531 && emu->from_slot < 2550)

        {

                eq->from_slot = emu->from_slot + 1;

        }

        else

        {

                OUT(from_slot);

        }



        if(emu->to_slot >= 21 && emu->to_slot < 50)

        {

                eq->to_slot = emu->to_slot + 1;

        }

        else if(emu->to_slot >= 251 && emu->to_slot < 351)

        {

                eq->to_slot = emu->to_slot + 11;

        }

        else if(emu->to_slot >= 2031 && emu->to_slot < 2270)

        {

                eq->to_slot = emu->to_slot + 1;

        }

        else if(emu->to_slot >= 2531 && emu->to_slot < 2550)

        {

                eq->to_slot = emu->to_slot + 1;

        }

        else

        {

                OUT(to_slot);

        }

        OUT(number_in_stack);

        FINISH_ENCODE();

}

We have far too many encodes using the long way of doing this and it is almost certain that there are mistakes in some of them. By having a function to handle the conversion, we would just need to make sure that the function worked perfectly, and once it did, everything else using it will as well.

I might look into adding this tonight, but any input from the other devs would be nice. I am not exactly sure of the best spot to implement this or what the best way to use it would be. Should be fairly straight-forward, but I won't know until I try it, I guess.

Also, using this option, it should make it easier for us to pick an unused Titanium slot that we can use to store the Power Source slot as so it can be used for SoF and automatically converted back and forth without having to alter every encode/decode for slots.

Quote:

Originally Posted by trevius (Post 171572)

When it mentions charges in those cases

I think you lost me on that line :-0

Ok, I think I got the conversion functions written properly, but it might not hurt to have them double-checked:

Code:

// Converts Titanium Slot IDs to SoF Slot IDs for use in Encodes

static inline int32 TitaniumToSoFSlot(int32 TitaniumSlot) {

        int32 SoFSlot = 0;



        if(TitaniumSlot >= 21 && TitaniumSlot <= 50)        // Cursor/Ammo/Power Source and Normal Inventory Slots

        {

                SoFSlot = TitaniumSlot + 1;

        }

        else if(TitaniumSlot >= 251 && TitaniumSlot <= 340)                // Bag Slots for Normal Inventory and Cursor 

        {

                SoFSlot = TitaniumSlot + 11;

        }

        else if(TitaniumSlot >= 2031 && TitaniumSlot <= 2270)        // Bank Bag Slots

        {

                SoFSlot = TitaniumSlot + 1;

        }

        else if(TitaniumSlot >= 2531 && TitaniumSlot <= 2550)        // Shared Bank Bag Slots

        {

                SoFSlot = TitaniumSlot + 1;

        }

        else if(TitaniumSlot == 9999)        //Unused slot ID to give a place to save Power Slot

        {

                SoFSlot = 21;

        }

        else

        {

                SoFSlot = TitaniumSlot;

        }        

        

        return SoFSlot;

}



// Converts Sof Slot IDs to Titanium Slot IDs for use in Decodes

static inline int32 SoFToTitaniumSlot(int32 SoFSlot) {

        int32 TitaniumSlot = 0;

        

        if(SoFSlot >= 22 && SoFSlot <= 51)        // Cursor/Ammo/Power Source and Normal Inventory Slots

        {

                TitaniumSlot = SoFSlot - 1;

        }

        else if(SoFSlot >= 262 && SoFSlot <= 351)        // Bag Slots for Normal Inventory and Cursor 

        {

                TitaniumSlot = SoFSlot - 11;

        }

        else if(SoFSlot >= 2032 && SoFSlot <= 2271)        // Bank Bag Slots

        {

                TitaniumSlot = SoFSlot - 1;

        }

        else if(SoFSlot >= 2532 && SoFSlot <= 2551)        // Shared Bank Bag Slots

        {

                TitaniumSlot = SoFSlot - 1;

        }

        else if(SoFSlot == 21)

        {

                TitaniumSlot = 9999;        //Unused slot ID to give a place to save Power Slot

        }

        else

        {

                TitaniumSlot = SoFSlot;

        }



        return TitaniumSlot;

}

When working on that, I noticed that there were a couple of issues with the current slot move related stuff in the encodes and decodes that could cause items to be lost if stored in certain slots. Right now, I think those would include:

1. The last slot in a 10 slot bag that is on your cursor.
2. The last slot in the last bag of your bank in SoF.
3. The last slot in the last bag in you shared bank.

This conversion should fix all of that once it is working. Hopefully it will also make it easy to for us to add in any more conversions for slots without having to go through each encode/decode and adjusting them 1 by 1. I will try this out later and see how well it works. Seems like it should be ok.

I am not completely sure what uses slot 31 to 50 in Titanium, but maybe that is how stacked items are stored on the cursor when being moved. If so, we might need to increase that from 50 to at least 130, so it could account for stacks up to 100.

Well thanks for looking at it, that was quick ?

Note: I have found that after zoning, the erroneously eaten/drunk food/drink return. Even if the slots are displaying as empty, the items are back upon zoning.

Weird, eh?

- Shendare

That is probably because the SoF client is removing the items thinking you are eating them but the server knows better. When you zone, you get a fresh copy of the data from the server so you have the proper amount again.

This makes it merely a cosmetic bug in communicating to the client under most circumstances. However, I wonder what happens if you try to pick up the items and move them to another slot. I wonder if the server amount or the client amount will be what is used.

I tried that.

If I have 18 left in a stack, and the server eats that down to 10, and I move 5 out into another slot, upon zoning I now have 13 in the first stack and 5 in the second.

If I let a stack completely disappear and move something else into it, upon zoning the "vanished" items appear on my cursor.

The server does appear to be keeping track of everything properly. It is indeed purely cosmetic, down to the "You are thirsty, you are out of drink" messages.

- Shendare

I got the new conversion functions into SoF.cpp and they seem to work just fine. It should correct at least a few possible issues with slots in some of the encodes. If there are still issues, it may be due to some other structure that needs to have slot encoded for it that I am not thinking of.

This fix won't fix the consuming food/drink too fast issue, BTW. It will just correct possible issues with normal items inside of bags.

BTW, those errors in the log of the Original Post here aren't actually errors at all. They are just poorly named. Those are the slot IDs of the move before the slots get converted.

This:

Code:

[Debug] [NET__ERROR] Moved item from 31 to 324

Really means this instead:

Code:

[Debug] [INVENTORY__SLOTS] SoF Client moved item from slot 31 to slot 324