[Grimjaw]

Originally Posted by Erati [You must be logged in to view images. Log in or Register.]

is Res effects acting like a "debuff" in terms of buff stacking after being resd?

ya res effects acts as a debuff, however technically its always applied before any buff. OPs applying buffs first then debuff second. therefore rez has nothing to do with this scenario.

Originally Posted by eisley [You must be logged in to view images. Log in or Register.]

theres been a few posts about the relation between buff order and the client - there are other oddities, such as how if you have a buff in slot #3, but then click off your #1 buff, and refresh the #3 buff, itll then appear to jump to slot 1 on your client, but is truly still in 3.

got link?

Originally Posted by Daldaen [You must be logged in to view images. Log in or Register.]

I think the most pressing issue with buff stacking is a misleading post lead to it being in the current state.

The current state suggests that when a buff is overwritten by either a superior buff, or by a Debuff occupying the same slot, that new buff/Debuff will go into the highest slot that is open.

This is false, and shouldn't work like this. Nilbog even tested it:

http://www.project1999.com/forums/sh...0&postcount=25

Also if you want more evidence it wasn't this way on classic / Mac server with old code:

https://m.youtube.com/watch?v=6NyERUQeub0

From 4:30 - 7:45 in that video you will see Boost has bard Chorus + Rizlona's on in slots 13 and 14, with an empty slot 12 and 15.

Shortly after that 4:30 beginning mark, Chorus ends very briefly and restarts, this causes it to disappear for about a second in slot 13 and reappear in slot 12 (as one would expect when the buff fades and is recast).

Also from 4:30-7:45 you will see there is an empty slot 13 and Rizlona's stays active in slot 14 the entire duration. It is clearly being refreshed every 18 seconds (because bard songs), but is not jumping up slots after the first refresh where there is a void available in his buff list that would allow the jump.

-----

If they fix this buff replacing coding, you won't run into this issue where the server desynchs when it replaces a lower slot buff with either a better buff or a Debuff, trying to place that new effect in an empty top slot instead of the slot where you actually had the original buff like it should.

everyone agreed that change was classic, even you were fine with it 3 posts later (in that thread you linked). whether or not it made it onto eqmac is technically a different topic (same applies to ur vid). my guess is that this is just residual effect from the root issues, or else just a minor bug on haynar's implementation. Either way, something that needs to be looked into.

Originally Posted by Nirgon [You must be logged in to view images. Log in or Register.]

best way I recreated the buff stacking issue is by letting a buff fade on its own (short duration stuff like DS is good) then rebuffing afterwards and zoning.

A fresh coat of buffs then zoning doesn't have any problems in every test I did.

another great detailed scenario.

keep em coming. detailed reproductions is exactly what they need to pinpoint the few underlying root issues which are causing these oddities to be seen across the board.