Question about Titanium and sending buffs to clients

[Cottus]

I've been working on making buffs not top slot when refreshed on the server I help GM. The code works server side, but the 'refreshed' buff is still getting top slotted client side (till zoning causes a refresh of all buffs, etc).

I was going just going to put in a call to SendBuffsToClient, but noticed that KimmySprite committed a change in Rev 1574 to that method with the message

Only send target buff packets for SoD and later to address an obscure crashing issue with Titanium. (Netcode artifact).

I know a large portion of our user base plays with Titanium (and I do as well), so I was wondering if there were any more details around the obscure crashing issue?

[trevius]

I believe that note is for target buffs, not normal client buffs. Target buffs are a feature only available in newer clients (to show the buffs of your current target in a new window), not in Titanium. It was occasionally causing Titanium clients to crash when sent to them IIRC.

[Cottus]

Yeah, thanks for pointing that out. I was hoping it would be a quick fix, but it looks like its more involved (if its even possible). It looks like the process for buffing is:

Mob::SpellOnTarget
	sends action_packet (OP_Action) to target / caster
	sends action_packet to clients in the area
	calls Mob::SpellEffect
		calls Mob::AddBuff
	sets a flag & resends the action packet to target / caster
	send new message packet (OP_Damage)

And the action packet is what tells the client to create the buff icon, but not what slot it goes into.

I also looked at setting UpdateClient = true on the buff, and relying on SendBuffDurationPacket to try to update the slot, but I am guessing the slot and slot id members on SpellBuffFade_Struct dont do what I hoped they might.

I dug around a bit and found OP_BuffCreate, but that only seems to be in the Live patch set.

Also, sending the whole player profile via OP_PlayerProfile seems to be how zoning gets the buffs to end up in the right slots, but that seems massively overkill for what I am doing, and I am not even sure if that would work.

I will keep digging. Any feedback or guidance would be appreciated.

[haynar]

In Mob::AddBuff

	if(will_overwrite)
	{
		vector<int>::iterator cur, end;
		cur = overwrite_slots.begin();
		end = overwrite_slots.end();
		for(; cur != end; cur++) {
			// same spell, so put in same slot
			if (buffs[*cur].spellid == spell_id)
				emptyslot = *cur;
			// strip spell
			BuffFadeBySlot(*cur, false);

			// if we hadn't found a free slot before, or if this is earlier
			// we use it
			if(emptyslot == -1 || *cur < emptyslot)
				emptyslot = *cur;
		}
	}

Crude, but works for a lot of what you want. Could expand the checks to work for overwriting of spells of a higher level version of spells.

Haynar

[haynar]

Very annoying not being able to edit. Now I remember another reason I don't post here.

Sorry, but I misread your post. Since I did a half assed post, here is a real solution.

To get it to not topslot, you can do it for same spell id. But put in a condition to not send a fade packet to the client. That way when new buff goes over to client, it will update same slot. I tested it, and the client will topslot lower level versions of spells, that would get overwritten.

You will have to add additional parameters to BuffFadeBySlot(), which perform the fade packet function. You have to call BuffFadeBySlot(), to get procs, etc., other things updated properly.

The BuffFadeBySlot I am using is:

void	BuffFadeBySlot(int slot, bool iRecalcBonuses = true, bool death = false, bool sendmessage = true, bool sendfadepacket = true);

You can figure out where to put the checks for sendmessage (for sending the message that the buff faded) and sendfadepacket in the function, so they send when you want them.

The section of AddBuff() now becomes:

	if(will_overwrite)
	{
		vector<int>::iterator cur, end;
		cur = overwrite_slots.begin();
		end = overwrite_slots.end();
		for(; cur != end; cur++) {
			if (buffs[*cur].spellid == spell_id) { // special handling for same spell (should overwrite only one buff)
				emptyslot = *cur;
				if(caster && buffs[*cur].casterid == caster->GetID()) {
					BuffFadeBySlot(*cur, false, false, false, false); // no fade message or packet (same caster)
				} else {
					BuffFadeBySlot(*cur, false, false, true, false); // no fade packet, but send fade message
				}
			} else {
				BuffFadeBySlot(*cur, false);
				if (*cur < emptyslot || emptyslot == -1)
					emptyslot = *cur;
			}
		}
	}

Haynar

[Caryatis]

Now I remember another reason I don't post here.

lol..........