Spell window

[e@tme1]

Hey Folks,

back in the day, detrimental spells cast by player onto mobs used to appear in the spells window... I have noticed that this doesn't happen anymore. Am I missing something in the configuration or was this a functional change somewhere along the way or as intended now?

Cheers :)

[BlueAdept]

It is probably just an OP code that needs to be changed or it may need struct changes. A lot of "features" have been neglected and only core functions have been updated.


Hey Folks,

back in the day, detrimental spells cast by player onto mobs used to appear in the spells window... I have noticed that this doesn't happen anymore. Am I missing something in the configuration or was this a functional change somewhere along the way or as intended now?

Cheers :)

[cn187]

I think there's one for the spell window, and another for spell messages. I know they're not on the list of opcodes that I find regularly (though I have found them in the past), and I don't think they're in the list of opcodes that Newby finds, either. So to get that functionality we'll need to start including those in the regular updates. I don't think that should be a big deal.

Assuming the structs haven't changed, that should do it. If the structs have changed, then it'll take a little more work (but probably not too much - it's not a particularly complicated struct).

[fransick]

I can take a run at the spell window if it helps spread the work around. I've fixed it in the past when it was only opcode and struct edits. May call for reinforcements if it requires some c++ changes ;)

[cn187]

I've included the opcodes for spellcasting in today's release. A quick test shows it adds my own spells OK, but I haven't tested spells cast by others. I didn't see any struct length warnings or get any crashes, so the structs may be OK. Give it a whirl and let me know if it fixes it for you.

[fransick]

I am testing some changes to buffStruct in everquest.h:

struct buffStruct{
/*0000*/ uint32_t spawnid; //spawn id
/*0004*/ uint8_t unknown0004[64];
/*0068*/ uint32_t spellid; // spellid
/*0072*/ uint32_t duration; // Time remaining in ticks
/*0076*/ int32_t unknown0024; // Buff length in ticks
/*0080*/ uint8_t unknown0080[25];
/*0105*/ int8_t level; // Level of person who cast buff
/*0106*/ uint8_t unknown0106[6];
/*0112*/ uint32_t spellslot; // buff slot number in buff window
/*0116*/ uint32_t changetype; // 1=buff fading,2=buff duration
/*0120*/
};
The changes appear correct but still seeing some strangeness with the spell list. For one, it lists the base spell length which leads me to belief the spell list is not pulling the data from buffStruct as that is reporting duration in ticks including spell duration enhancements. This is where my rudimentary understanding of code fails me!

[cn187]

I'm not sure how much you've dug into the code, so forgive me if already you know this stuff. But here's the basic flow:



interface.cpp:2360

m_packet->connect2("OP_Buff", SP_Zone, DIR_Server|DIR_Client,
"buffStruct", SZC_Match,
m_spellShell, SLOT(buff(const uint8_t*, size_t, uint8_t)));


This says that when OP_Buff comes in, it gets passed to the SpellShell's buff function.



spellshell.cpp:325

if (b->changetype == 0x01) // removing buff
deleteSpell(item);
else if (b->changetype == 0x02)
{
// right now we only know how to find the updated duration
item->setDuration(b->duration * 6);
emit changeSpell(item);
}



And this, for a duration update, converts the OP_Buff's duration in ticks to the duration in seconds, sets the new duration on the spell item, and signals that the spell has changed.




spelllist.cpp:287

void SpellList::changeSpell(const SpellItem *item)
{
if (item) {
SpellListItem *i = Find(item);
if (!i)
return;
int sid = i->text(SPELLCOL_SPELLID).toInt();
int cid = i->text(SPELLCOL_CASTERID).toInt();
int tid = i->text(SPELLCOL_TARGETID).toInt();
if ((sid == item->spellId()) &&
(cid == item->casterId()) &&
(tid == item->targetId()))
i->update();
else {
DeleteItem(item);
addSpell(item);
}
}
}



The spell list receives the signal, and updates the window with the new info.


So just looking at it briefly, it looks like it *should* be working, assuming the both the struct and the opcode for OP_Buff are correct.

[fransick]

Thank you! I hadn't gotten that far into it as it was getting late last night.

Oddly enough, I had the opcode for OP_Buff set correctly and it the spell list refused to populate at all. When I set it back to "ffff" it would populate the spell list. That's what had me thinking maybe OP_Buff might have been deprecated in the code. I'll set it again and do some more testing as your thought that everything looks right is what I am seeing too. The only thing I am guessing on is the time remaining and duration structs. They are always identical when you trigger the packet by casting making it hard to tell which is which. Since they are identical, I don't think that accounts for the duration inaccuracy I am seeing. I confirmed the packet has the right duration but the spell list has the base length only.

I also noticed a new phenomena where they are spamming a rather long packet that has all of your current buffs in it at first glance. When I cast, it spams that packet incessantly which makes even a 2 second zone.log a PITA to go through. This is something new as I never had to deal with it when I was doing opcodes by hand a few years ago. Wonder if there is something useful in there we could use down the road?

[BlueAdept]

Off topic, but I use the spawn point list that keeps track of spawn points and how long between them. Ive gotten use to not having it, but I used to find it useful. That has been broken for a couple years, but never investigated it because I really dont get to play very much.

[cn187]

The last time I tried it, it "sort of" worked, but not fully. I'll add it to the list of stuff to work on.

[cn187]

Fransick, I don't usually use the spell window, but I'll pull it up tonight and see how things behave over the course of normal play. Is 0x11f1 the same as what you found for OP_Buff?

[fransick]

Yes. That's the opcode I added to zoneopcodes.xml

I don't use it either so sort of flying blind as to what it is supposed to do. At least it is showing proper spell length now. It's not always adding spells to the list and targeting myself before casting seems to help but I have had enough testing to determine if that's influencing things or was just dumb luck.

[cn187]

I didn't notice your post about committing to my dev branch until after I was done playing tonight, so I haven't actually tried your changes yet.

Without your changes (but with the OP_Buff opcode), I'm still getting spells (including buffs) added to the spell window. Since, based on your changes, the buff struct I was using was obviously wrong, I'm guessing those are coming from OP_CastSpell and/or OP_BeginCast, or maybe even OP_Action. I'm not sure yet.

There are definitely some issues with the spell handling, because there were cases where I got duplicates of the same spell, even after only 1 cast. There were also some cases where the target or caster were missing, and some cases where the caster was "Buff" (which might be normal - I don't know how it's supposed to work either)

I'm hoping to have time to play tomorrow, so I should be able to test with your changes then. But in the mean time, I did compare your struct changes to my logs, and they look good to me.

[showeq42]

It's OP_Action and/or OP_Action2
Been years since I played with it, but used to have showeq telling me the caster and the target of every spell cast in range.

[cn187]

OK, I had some time to play with the struct changes applied, and it looks good. The issues I was having with duplicates seems to be resolved by the struct change.

I looked through the code some, and it looks like the "Buff" caster name is applied when the spell is loaded from the buff list that's included in the player profile (on zone-in). So I guess that makes sense - the caster ID would be the spawn ID of the caster, which would change from zone to zone. So it would need to be rewritten to something when zoning. That would also explain the cases where I saw N/A for the target or the caster - I probably zoned at some point, so the IDs got invalidated.

So it seems to be all working, at least from the perspective of someone who never uses that functionality...

Thanks for working on that, Fransick.

[e@tme1]

Awesome! thanks for working on this. The changes made in the last patch release work well. impressed that you have taken it a step further. Really appreciate your efforts folks.