tiny change to header

[noudess]

mob.h - The default for item slot was 0xFFFFFFF (which I assume was an attempt at -1). The argument is unsigned, so every spell was thinking it was an item slot as the value was some huge #. I think that's not intended? This large # never matched a slot, but I don't think you wanted that? I changed rge default param to be 0 in two spots:

virtual bool CastSpell(uint16 spell_id, uint16 target_id, uint16 slot = 10, int32 casttime = -1, int32 mana_cost = -1, uint32* oSpellWillFinish = 0, uint32 item_slot = 0x0, uint32 timer = 0xFFFFFFFF, uint32 timer_duration = 0, uint32 type = 0, int16 *resist_adjust = NULL);^M
virtual bool DoCastSpell(uint16 spell_id, uint16 target_id, uint16 slot = 10, int32 casttime = -1, int32 mana_cost = -1, uint32* oSpellWillFinish = 0, uint32 item_slot = 0x0, uint32 timer = 0xFFFFFFFF, uint32 timer_duration = 0, uint32 type = 0, int16 resist_adjust = 0);^M

[Uleat]

0xFFFFFFFF is cast to 0xFFFFFFFF regardless of signed or unsigned.

You may have issues with the intended value if you improperly widen or narrow.


I haven't followed the code all the way through, but by setting the default item_slot to 0x0, you may have issues with charm slot item
deletions under certain conditions..or you may not...

--GetItem((int16)0xFFFFFFFF)) = Invalid Slot
--GetItem((int16)0x0) = Charm Slot

If you run a public server, I'd recommend heavy testing to determine any negative effects, aside from the error in the log entries, before
pushing this live.

Casting isn't my specialty... (do I have one?)

[noudess]

It will indeed retain the value, but that value will never be negative unless it's assigned into a signed variable somewhere down the line.

Anything stored in a uint32 var will never pass (if var > 0) unless manually casted up or assigned into a signed variable.

The spots where it is being passed in as the 0xFFFFFFF value assign it to casting_spell_inventory_slot.

If you check the code, and step through spell casting, it checks every single spell as if it was cast from an inventory slot because the value is > 0.

That's how I found the problem. The spell code was running through "cast from spell slot" every time.
It never found a match, since no slot was numbered 0xFFFFFFF but it seems like a waste of time.

I don't think that's the intent, unless the 0xFFFFFFF value is just meant to be non-zero.

This is the code I found in spell_effects.cpp that always executes.

GetCastedSpellInvSlot() always returns a large number when the default arguments from all the way back at CastSpell() is 0xFFFFFFF instead of 0.

SpellEffect() code below. GetCastedSpellInvSlot() returns unsigned as well. As a whole, if negative numbers are desired, Id change all the types to signed for that value, but that's a great many changes in this case. As far as I can tell, 0 as well as -1 are both invalid slots. Certainly the code below thinks so, it does not execute if its 0, but does run though the code checking for matches when its 0xFFFFFFF (or a very large value in this case).

The charm slot thing is disturbing, as then this code doesn't work for that, unaltered... Unless that is not used when casting... but it seems like it would be.

if(caster && caster->IsClient() && GetCastedSpellInvSlot() > 0)^M
{^M
const ItemInst* inst = caster->CastToClient()->GetInv().GetItem(GetCastedSpellInvSlot());^M
if(inst)^M
{^M
if(inst->GetItem()->Click.Level > 0)^M
{^M
caster_level = inst->GetItem()->Click.Level;^M
c_override = true;^M
}^M
else^M
{^M
caster_level = caster ? caster->GetCasterLevel(spell_id) : GetCasterLevel(spell_id);^M
}^M
}^M
else^M
caster_level = caster ? caster->GetCasterLevel(spell_id) : GetCasterLevel(spell_id);^M
}^M

[Uleat]

I'm house-sitting this week and need to go grab my home computer in a bit.

I'll play around this with and see what comes up.

It will be interesting to see if there are any click-to-cast charm items.