Weapons shoot wrong ammo upon switching in certain cases
Sometimes when the player runs out of ammo and autoswitches weapons, the weapon he switches to will fire the rounds of the previous ammo (ex. player runs out of rocket launcher ammo, autoswitches to super shotgun, supershotgun shoots rockets). Its quite difficult to reproduce.
It's actually easier to reproduce it with higher ping. I did it three times in the same match just before.
*** Bug 304 has been marked as a duplicate of this bug. ***
Commited on 993, test it out
Ghostly's old fix did not fix this bug. As a matter of fact, his bug fix actually causes more problems sometimes when the client thinks you picked up a weapon and the server disagrees. This is how that works now:
Example: Sometimes if you barely touch a weapon, say a chaingun, the client will switch your weapon to the chaingun. However, on the server you're still holding whatever weapon you were originally holding. After about two seconds, the client will correct itself and pull the correct weapon you're holding server side back out. Not good.
So, this bug still exists as of r1431 and Ghostly's fix ended up furthering the bug as a result.
*** Bug 561 has been marked as a duplicate of this bug. ***
Remove from CC
*** Bug 605 has been marked as a duplicate of this bug. ***
Join up to a high ping server (120 and up seems to work) running SVN and
32in24-5 MAP02 (just one of those reproducable maps, its not exclusive to it).
Join and run past the BFG and in most cases, the server will never tell the
client that it got picked up, thus giving the player an SSG or Pistol that
fires BFG shots and uses both cells that the player isn't aware of, as well as
using up Pistol or SSG ammo.
< HeX9109> The server does have to tell the client "YOU GRABBED THE BFG" so the client now goes "Oh, OK Ill use these frames and ammo"
< tm512> it already does
< tm512> but the client doesnt switch
< tm512> because it checks range
Having the client check to see if it is range of the item is problematic under high-ping situations. The player will have the item server-side, but the client will disregard ever having the item because it was out of range by the time it receives the message, causing a desync. Submitting a patch that will remove this check client-side during a netgame, thus fixing this bug.
Remove client range check during a netgame
Spleen was talking about making many checks that currently happen on the client not happen when connected to a server. Would that be a more comprehensive approach to solving this problem? Does your patch account for other use cases where weapon autoswitching issues occur?
if (!toucher || !special) // [Toke - fix99]
// GhostlyDeath -- Spectators can't pick up things
if (toucher->player && toucher->player->spectator)
// Dead thing touching.
// Can happen with a sliding player corpse.
if (toucher->health <= 0)
fixed_t delta = special->z - toucher->z;
if (delta > toucher->height || delta < -8*FRACUNIT)
// out of reach
sound = 0;
if (!P_GiveArmor (player, deh.GreenAC))
There are a bunch of checks, but it really looks like only the out of reach check could cause problems, to be honest.
r1706 applies this patch.
Please remember to include comments in future patches where code is being changed.
Also this may need to be tested to ensure it doesn't add any new bugs in.
Looks like yet another bug is out of the way. Thanks again for applying the patch.
I'm not fully convinced that all weapon autoswitch desyncs issues are gone, but everyone seems to think so at this point. We'll see if it gets reopened.
This isn't fixed entirely...
*** Bug 632 has been marked as a duplicate of this bug. ***
From bug 632:
Weapon animations sometimes desync with their hitscans/projectiles. As in, fire
and the hitscans will be (sometimes dramatically) delayed. Please note that
ping isn't the cause of this.
This seems to happen sometimes when you run over a weapon while in the process
of firing another (happens often while spawning?). You pick it up server-side
but the client has to wait until the previous firing animation is over until it
can switch, causing a desync. Normal weapon behavior can be restored by waiting
for both the client and server to return to a "weapon ready" state.
Bug 632 isn't the same bug as this, it may very well have some relation with this though: A player will get animation desync and will fire one or two rounds when the client runs out of ammo, but the server still has ammo.
Regardless, bug is back and happens in a way like I described in comment 8. I'm removing more of the checks from my client and I will post my findings.
*** Bug 682 has been marked as a duplicate of this bug. ***
A full-on weapon desync can be caused by doing the "quick pickup" trick, where you run over a new weapon just as you switch to a new one. For example:
1. start a switch from the super shotgun to the shotgun
2. Weapon lowers
3. Pickup rocket launcher.
4. Rocket launcher raises on the *client's* side.
5. Rocket launcher fires shotgun fire.
I did a quick video of this:
I was able to get a netdemo of a weapon desync occurring, this one happens when switching between weapons your player already has.
The required WADs are included in the zip file.
Weapon desync correction
This patch reintroduces weapon pickup prediction (removed in r2943) and adds a new cvar, cl_predictpickup, that turns the prediction on and off. A menu item controlling this cvar is also added.
More importantly, this patch adds a way of correcting any weapon desyncs that do happen, without causing the "repeat pickup" glitch that previously happened. When a player fires a weapon on the server, the server makes use of the message "svc_fireweapon", telling the client what weapon they fired. When the client receives this message, they check to make sure that the weapon they fired on the server is the same as they have on their client. If it isn't, the client immediately sets their weapon to the correct one and sends the new "clc_getplayerinfo" message to the server, asking for the server to send the correct playerinfo to them.
I committed a reworked version of tm512's patch in r3014 using the idea he outlined. Please test.
Desync fix desyncs
The patch I submitted corrected desyncs clientside. The fix applied in r3014 is serverside and causes minor to severe issues with weapon animations when it attempts to correct desyncs. The attached demo demonstrates the most common one, it is obvious and easily reproducable.
Weapon desync correction (take 2)
This patch reverts r3014 and corrects an issue in the first patch that I submitted where desyncs would be corrected but the client's weapon frame would not be advanced to account for latency.
This also adds a Printf in CL_FireWeapon to alert the user that a desync happened and was corrected (this may be useful for testing).
Is this still a problem?