Game Mechanics: Buff client/server desyncing, when debuffs overwriting buffs

[fash]

Occasionally, buffs/debuffs will reorder when logging out and back in. For example, Spirit of the Wolf, which was in buff slot 15, may appear in slot 1 upon logging back in.

[Nirgon]

this happens when zoning too

let a buff fade (from top usually)

recast the buff with other open buff slots

zone or relog


bug reproduced

[planarity]

I think this is the result of discrepancies in the buff order between the client and server.

When I started on P99, If you refreshed a buff that you already had, it wouldn't change the location in the buff stack even if slots above that location were free. At some point, this changed so that refreshing a buff would move it to the first free slot in the stack.

My guess is that the client was changed but the server retains the old behavior, which results in the discrepancy.

Many of the buff reordering issues I've seen seem to result from this, but not all of them. I've also seen strange behavior result from being given a buff that is somehow blocked, such as a str buff blocked by rez effects or a str debuff, or similar issues with regen etc. The buff isn't there as far as the client is concerned, but logging or zoning perhaps causes the server to assert that it's there.

[fash]

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

I think this is the result of discrepancies in the buff order between the client and server.

This seems to be the problem.

I often use two damage absorption buffs, Rune V and Berserker Spirit. The buff in the higher slot (cast earlier) has always absorbed damage first. Today, I noticed for the first time the lower slot buff absorbing damage first. After noticing this behavior, I zoned, and several buffs I had were reordered.

It seems that the client and server get into different states, which causes this visual buff order discrepancy. Zoning appears to sync the client to the server's state, causing the buffs to reorder.

[fash]

When a debuff overwrites a buff on a player, the buff state of that player can become out of sync between the server and client.

Client-side, the buff appears to correctly have been overwritten visually, except in an edge case when the player has max (15) buffs and the buff being overwritten is _not_ in slot #1.

Server-side, both the debuff and buff, which should have been overwritten, are active on the player. In the edge case described above, buff is correctly overwritten by the debuff, but whatever buff is in slot #1 is incorrectly removed.

Repro steps:
1. Cast Berserker Spirit (enchanter lvl 49) on player. Berserker Spirit should be in slot #1 and slot #2 should be empty. [You must be logged in to view images. Log in or Register.]
2. Cast Weakness (enchanter lvl 44) on player. Client-side, Weakness appears in slot #1 and slot #2 appears empty. Ostensibly, Weakness overwrote Berserker Spirit correctly.[You must be logged in to view images. Log in or Register.]
3. Zone the player to cause the client to sync with the server.

Result: Berserker Spirit is in slot #1, and Weakness is in slot #2.
[You must be logged in to view images. Log in or Register.]

This causes a few issues. If you dispell the player prior to zoning, the hidden buff (Berserker Spirit) is dispelled, not the debuff even though the debuff appears to be in slot #1. Any new buffs applied to the player (prior to zoning), will be out of sync e.g. it will appear in slot #2 client-side, but slot #3 server-side. This of course makes dispelling buffs appear to misbehave untill the player's client resyncs with the server e.g. by zoning/relogging.


I was similarly able to reproduce this behavior with Augmentation (enchanter lvl 29) and Cripple (enchanter lvl 53).

[Erati]

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

[fash]

Regarding the edge case described in OP (all 15 slots filled and buff to be overwritten is _not_in slot #1), client-side, the debuff overwrites the correct buff _visually_, but server-side the debuff overwrites whatever happens to be in slot #1 instead.

1. 15 slots filled. Berserker Spirit is in slot #3.
[You must be logged in to view images. Log in or Register.]

2. After casting Weakness. Client-side, Weakness visually overwrites Berserker Spirit in slot #3.
[You must be logged in to view images. Log in or Register.]

3. After zoning/syncing, we see that Weakness actually overwrote the buff in slot #1 instead, and Berserker Spirit remains in slot #3.
[You must be logged in to view images. Log in or Register.]

[eisley]

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.

anyway, good research - much clearer than i could ever explain.

[fash]

bump

[Daldaen]

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.