Memming Spell Sets: bug and fix
 

At the moment, if you have no memmed spells at all, then loading a spell set from the client UI works. But, it doesn't un-mem spells first. I've added code for OP_LoadSpellSet to simply unmem all spells first, and it works. It seems the client deals with handling the sequential memming of the spells, presumably so the user can interrupt it, so that turned out to be an easy one. It works fine for me with the titanium client, can't test with any other.

** edit: It's been pointed out by one of my players that this still doesn't quite mimic "live" behaviour, which apparently only un-mems spells that are about to change, thus speeding things up. Sorry - but I think this is a reasonable halfway house, I don't know how to parse the contents of the EQApplicationPacket.

Cheers, Paul.

*** ../../EQEmu-0.7.0-903/zone/client_packet.h 2006-08-15 02:18:33.000000000 +0100
--- client_packet.h 2006-11-13 11:17:23.000000000 +0000
***************
*** 207,210 ****
--- 207,211 ----
void Handle_OP_RequestTitles(const EQApplicationPacket *app);
void Handle_OP_PurchaseLeadershipAA(const EQApplicationPacket *app);
void Handle_OP_Ignore(const EQApplicationPacket *app);
+ void Handle_OP_LoadSpellSet(const EQApplicationPacket *app);

*** ../../EQEmu-0.7.0-903/zone/client_packet.cpp 2006-10-31 03:04:23.000000000 +0000
--- client_packet.cpp 2006-11-13 11:24:08.000000000 +0000
***************
*** 307,312 ****
--- 307,313 ----
ConnectedOpcodes[OP_SenseHeading] = &Client::Handle_OP_Ignore;
ConnectedOpcodes[OP_FloatListThing] = &Client::Handle_OP_Ignore;
ConnectedOpcodes[OP_WorldUnknown001] = &Client::Handle_OP_Ignore;
+ ConnectedOpcodes[OP_LoadSpellSet] = &Client::Handle_OP_LoadSpellSet;

}

***************
*** 4393,4398 ****
--- 4394,4406 ----
return;
}

+ void Client::Handle_OP_LoadSpellSet(const EQApplicationPacket *app)
+ {
+ Client::UnmemSpellAll(true);
+ return;
+ }
+
+
void Client::Handle_OP_PetitionBug(const EQApplicationPacket *app)
{
if(app->size!=sizeof(PetitionBug_Struct))

Did more testing and there's an issue. If you have a spell in, say slot 1 in spellset 1 and spellset 2 has the same spell in the same slot, the client does not attempt to re-mem it when switching. What this means is that I think the client is sending over info about what it meant to be un-memmed in the EQApplicationPacket.

I will work on this and try to decode the packet and make this work properly. Apologies :) Does anyone have any magic ways to decode EQAppicationPacket? If not I'll just dump them out to hex and scratch my head a bit!

Paul.

I worked it out. Here's the "real" patch; it deals with only unmemming the spells you need to remove, and everything appears to work perfectly. I will go and have a lie-down now :)

Paul.

lol, knocks the wind out of ya, eh?

Thanks for your diligence!

good work. I'll get this put in.

There's a mistake in the current CVS code related to my spell set patch which I guess has crept in when you tidied things up. I originally had, in common/eq_packet_structs.h, this:

but you have it as
The client actually sends back 10 spell entries to the server, even though the client actually crashes if it is asked by the server to manipulate the 10th slot. In the current source you've changed MAX_PP_MEMSPELL to 10. I've fixed it on my server by having the for loop run through to MAX_PP_MEMSPELL-1. I originally tried setting MAX_PP_MEMSPELL back to 9 but this had strange effects (the client was not seeing my characters at login).

Paul.

Is he using MAX_PP_MEMSPELL because you normally only get 8 slots unless you spend the AA to get 9?

Therefore, it cannot be hardcoded to 0-9 (or 10)? Or does the client get them all regardless of what you can use?

MAX_PP_MEMSPELL is a constant in the server code and reflects the number of spell slots the server is prepared to support. It's separate to the question of whether the character currently in use has 8 or 9 active slots.

The issue is that when the client does a LoadSpellSet, it sends across a data packet containing information for 10 spells. But, if the server sends back a SpellUnmem request for the 10th slot, the client crashes out. It seems to me that whoever programmed the client decided to put a hard max of 10 on the packet structure for LoadSpellSet but didn't manage to code it to ignore any requests for spell un-memming in slots that the client doesn't actually handle. If the client receives requests for the 9th slot and that isn't enabled, then it just ignores the request - this is sensible, but sadly not done for the 10th slot :)

So, in a nutshell, we have to forcibly prevent LoadSpellSet from sending back data out of range of slots 0-8 otherwise the titanium client crashes. Do other versions of the client act differently? I don't know. Perhaps the "correct" solution is to allow configuring of the maximum number of spell slots in the patch file for each client version.

Paul.

Ahh, I was wondering why I was crashing to desktop everytime I tried to load a spell set that worked yesterday. I really need to read all the forums more often...

MAX_PP_MEMSPELLS was changed to 10. Further, its unlikely that a packet which is only sent TO the server with no reply would cause the client to crash.

I assure you that if you do an "UnmemSpell(9, true);" the client crashes.