Steam RoF Development Tracking

[sorvani]

During development of the UF client the same issue was experienced.. Interesting that it resurfaced.

[trevius]

It looks like it is just a simple packet struct change. Since all of the gem fields in that packet are basically bools, they changed them from uint32 to uint8. Also, ShowEQ notes that MAX_PP_MEMSPELL was changed to 16, so that is what we have it set to for RoF to use in other structs, but in OP_LoadSpellSet I think it is actually only 12. The packet is 16 bytes, but the last field I think is a uint32, which means it only uses 12 spell slots. The value for the last field I saw was 12, so maybe it is a gem count field? Though, the char I tested it on only had the basic 8 gem slots available.

Here is an example of the packet:

[OPCode: 0x38b4] OP_LoadSpellSet [Client->Server] [Size: 16]
000 | 01 01 00 00 00 00 00 00 01 01 01 01 0c 00 00 00  | ................

And, I think the following changes will fix the issue, but I haven't tested yet:

RoF_structs.h

struct LoadSpellSet_Struct {
	uint8	spell[12];	// 0xFFFFFFFF if no action, slot number if to unmem starting at 0
	uint32	unknown;	//Seen 12 - Maybe a gem count?
};

Note that I had to hard set the spell count to 12, when it normally is set by MAX_PP_MEMSPELL, because MAX_PP_MEMSPELL is set to 16 now. Maybe MAX_PP_MEMSPELL should be changed to 12 in RoF, but that would require a few changes where it is used as well (which may be good or bad).

RoF.cpp

DECODE(OP_LoadSpellSet)
{
	DECODE_LENGTH_EXACT(structs::LoadSpellSet_Struct);
	SETUP_DIRECT_DECODE(LoadSpellSet_Struct, structs::LoadSpellSet_Struct);

	for(unsigned int i = 0; i < MAX_PP_MEMSPELL; ++i)
	{
		if (eq->spell[i] == 0)
			emu->spell[i] = 0xFFFFFFFF;
		else
			emu->spell[i] = eq->spell[i];
	}

	FINISH_DIRECT_DECODE();
}

Also, note that before the server sends the packets to unmem the spells, it replies to the client with the same packet it was sent, per this example:

[OPCode: 0x38b4] OP_LoadSpellSet [Server->Client] [Size: 16]
000 | 01 01 00 00 00 00 00 00 01 01 01 01 0c 00 00 00  | ................

I don't think that packet is required, but it is something to keep in mind.

Either way, this should be a really easy issue to resolve. I will test it today or this weekend and commit if no issues. Thanks for the report!

Edit: Actually, it looks like that would only affect the Player Proflle Struct/Encode, so it probably could be changed. If the location of the mem_spells field is correct in the RoF PP, something is a bit odd. For all fields with multiple iterations in the RoF PP, there is an iteration count field right before it. For the mem_spells field, the count was observed as 16. Though, only 12 fields are set in that iteration and the rest are all 0s. Maybe that just means they are planning to expand to 16 spell gems max at some point and have already added that part to the PP, but not other parts of the code dealing with memmed spells.

[trevius]

BTW, I have been working a bit on figuring out the bazaar stuff. I am still looking through packets and currently just trying to get starting trader mode to work. It looks like they changed the way items are tracked to a serialized id string to keep track of all items individually. I don't think we actually need to use this new system initially, but to match Live exactly, it may be required eventually.

I tested on Live and found that I am able to have whatever I want in my trader satches, and as long as I don't try to sell anything that is no drop, it will let me enter trader mode and just not list the items I didn't set a price for and ones that are no drop. On EQEmu, we just check for the item ID of the trader's satchel and cycle through the 8 inventory slots looking through the satchels. If there are any items that don't have a price set or of any no drop items are in the satchels, it just prevents trader mode from being started. This isn't a major issue at all, but figured it was worth noting here for reference.

Another thing to note is that previously only 80 slots were possible for trader mode due to having a max of 8 trader satchels with 10 slots each. On RoF, it has been changed to 200 slots due to having 10 main inventory slots and I am guessing there is now a 20 slot trader's satchel available so you can reach 200 slots for sale. Since we currently check for the trader's satchel by its item ID, we will need to also add the item ids for any new trader's satchels once the new slot system is in place that will allow larger than 10 slot bags. We will also need to increase the slots searched from 80 to 200. This is something that can be done later when the new slot system is completed and won't affect the initial implementation of the bazaar systems in RoF.

Once I can get trader mode starting properly, I will just keep working my way through the packets to get the rest of the trader system worked out. I think the hardest part may be the fact that you can use /bazaar search from any zone and purchase items directly through that system. It then sends the purchased item to the parcel system, which is another system that will need to be implemented.

This is the first time I have messed with bazaar stuff at all, so it is taking a while for me to get familiar with it and work my way through it. Hopefully I can get it all worked out.