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..........

[Cottus]

Excellent! I'm gonna put this onto our test server and give it another whirl.

Thanks for the help with this. It's been an annoyance for people when it comes to keeping certain slots open for dispelling detrimentals in pvp.

[haynar]

Did some more playing with it.

Remember how on live, if you had like focus, cast on you by a level 65. Then a level 64 tries to cast focus on you. They would get a reply that the spell would not take hold?

The client handling of updating using this method appears the same. So you will need to probably add some checks for stacking, so that same spells being cast by a lower level, will not take hold.

Its getting closer to working though.

I added a stacking rejection for same spell id's, if new caster level is less than the one whose buff it is. I remember live was like that.

There were also issues with durations too. Probably don't want to overwrite if new one has a shorter duration, like from less focus effects or duration enhancing AAs.

Update: Duration of new buff, has no effect, on whether the client will allow overwriting. Only the level of the caster of the new buff, if it is lower than the level of the caster of the existing buff.

In CheckStackConflict, I added:

	if(spellid1 == spellid2 && caster_level2 < caster_level1) {
		mlog(SPELLS__STACKING, "Blocking same spell because new caster level is less than level of existing buff");
		return -1;
	}

Works great now, and has that annoying effect of not taking hold, if you are lower level than one who orginally cast.

I remember with debuffs the effect especially, after a new expansion came out, and a debuff was landed by someone at a higher level. Then noone could refresh that buff, like malo, unless they were same level or higher.

Haynar

[haynar]

The client should allow multiple dots of same spell. So might need to do additional restriction to the way to update buffs to only beneficial spells.

I am not sure if the client handles dot stacking the same way for both pvp and pve.

Haynar