Question about Client::SendBuffDurationPacket

[noudess]

I started a different thread about buffs being displayed incorrectly. Consider that one irrelevant.

FIRST: This only applies to clients PRE SoF.

I see that Client::SendBuffDurationPacket is used by Mob::BuffProcess. My understanding after reading the code, and stepping through it with kdbg, is that Client::SendBuffDurationPacket is only being called when BuffProcess is NOT ticking down buffs. BuffProcess does not tick down buffs when a zone has tickdown suspended , ala the guild lobby.

So, we're only calling Client::SendBuffDurationPacket in the guild lobby/hall. I see the effect of this is that we counter the fact that the GUI is ticking down in the guild lobby and the server thinks this is incorrect.

Looking at Client::SendBuffDurationPacket, it uses a packet with the duration we want restored. It chooses to use slot 2 in the packet. A side effect of this, is whatever is in slot 2 for the buff being updated with an new duration, also processes again. So for example, if you're in the GL and you have bravery up, slot 2 for bravery is max_HP. That bump from bravery keeps getting reapplied, so that in the GL your max HP is unusually out of whack. If you have say, augmentation up, then AGI goes sky high, as agi si slot 2.

My question is this: Is there a way to update spell duration only? I've tried various things like : slot 0 or one of the blocking slots. That just breaks the call entirely (ie nothing updates).

I am not really concerned with the GL/Hall, but I have a couple of spots where I want to update the duration from the server, where the GUI is incorrect and I can't find a way to do that without reapplying some part of a buff and screwing that up.

The code that's there today that whacks out slot 2 is below. The comments seem to imply it is used more often, but it is not.

//This member function sets the buff duration on the client
//however it does not work if sent quickly after an action packets, which is what one might perfer to do
//Thus I use this in the buff process to update the correct duration once after casting
//this allows AAs and focus effects that increase buff duration to work correctly, but could probably
//be used for other things as well
void Client::SendBuffDurationPacket(uint16 spell_id, int duration, int inlevel)
{
	EQApplicationPacket* outapp;
	outapp = new EQApplicationPacket(OP_Buff, sizeof(SpellBuffFade_Struct));
	SpellBuffFade_Struct* sbf = (SpellBuffFade_Struct*) outapp->pBuffer;

	sbf->entityid = GetID();
	sbf->slot=2;
	sbf->spellid=spell_id;
	sbf->slotid=0;
	sbf->effect = inlevel > 0 ? inlevel : GetLevel();
	sbf->level = inlevel > 0 ? inlevel : GetLevel();
	sbf->bufffade = 0;
	sbf->duration = duration;
	FastQueuePacket(&outapp);
}

[noudess]

Anyone? I could try and get the old packet sniffer out on live, but I'd much rather work on content. I guess its possible there is no packet to update only the duration?

[KLS]

You're calling it in more than guild lobby, it's also being called when you have duration inc focus. I'm not sure about the restacking effects.

[KLS]

I've tried to reproduce the stacking issue on titanium and have basically not gotten it to stack like described in GH. Using bravery I'm still at the exact same hp as when i cast it.

[noudess]

Interesting.

Strip off all your buffs. Check HP. Cast bravery. Bravery should add hp as per spell description. Here, I see it added correctly, and then the next time the function gets called, it goes up again until it hits some cap.

Perhaps you need to try with a char who's HP are not near or already capped? Try with a low level. Any buff with a slot 2 effect has this bug. If I let this code work outside the GL, spells like SoW leapfrog up and people move faster.

On my side, maybe I need to get your lastest versions of the files?

[KLS]

I sorta reproduced it but it only stacked once.

I changed the duration packet function to:

	EQApplicationPacket* outapp;
	outapp = new EQApplicationPacket(OP_Buff, sizeof(SpellBuffFade_Struct));
	SpellBuffFade_Struct* sbf = (SpellBuffFade_Struct*) outapp->pBuffer;

	sbf->entityid = GetID();
	sbf->slot = -1;
	sbf->spellid = spell_id;
	sbf->slotid = 0;
	sbf->effect = inlevel > 0 ? inlevel : GetLevel();
	sbf->level = 0;
	sbf->bufffade = 0;
	sbf->duration = duration;
	FastQueuePacket(&outapp);

Though I'm fairly certain level / effect are swapped on some clients so gotta look into that but that seemed to work for titanium.

[noudess]

I think I tried -1, and oither non-stat slots. Those basically broke it for me.

On titanium, the GUI handles buff duration tickdown. The Guild Lobby (not hall, the gui knows about hall) started to tick down buffs, since this call no longer had an effect. At least that's what happened when I tried -1 and other non-stat slot options.

I am glad you reproduced it.

[KLS]

I've gotta play around with it some more but it did appear to work at least initially. I don't think we have a really good idea on how this packet actually works which is the issue.

[noudess]

The best place to test it is the GL on Titanium. There, the code is being used to keep the timer from ticking down. If it ticks down, the change broke the call.

Everywhere else, its hard to see if its working, as the GUI does the duration maintenance.

Briefly, I allowed the code to always update duration, but outside the GL I got buffs mega stacked.