Bug Tracker – Bug 269

Weapons shoot wrong ammo upon switching in certain cases

Last modified: 2014-03-30 16:20:15 UTC
Bug 269 - Weapons shoot wrong ammo upon switching in certain cases
Summary: Weapons shoot wrong ammo upon switching in certain cases
Alias: None
Product: Odamex
Classification: Unclassified
Component: Client (show other bugs)
Version: (old) 0.x Alpha
Hardware: All All
: P2 normal
Assignee: Odamex Bug Reporter
: 304 561 605 632 682 (view as bug list)
Depends on:
Blocks: 424 567
  Show dependency tree
Reported: 2007-01-18 21:51 UTC by Ryan Nematollahi
Modified: 2014-03-30 16:20 UTC (History)
8 users (show)

See Also:


Remove client range check during a netgame (447 bytes, patch)
2010-08-06 06:17 UTC, Kyle
Details | Diff
Desyncs netdemo (485.57 KB, application/zip)
2011-08-11 20:16 UTC, Kyle
Weapon desync correction (7.01 KB, patch)
2012-04-15 07:16 UTC, Kyle
Details | Diff
Desync fix desyncs (1017.18 KB, application/octet-stream)
2012-04-20 23:49 UTC, Kyle
Weapon desync correction (take 2) (11.84 KB, patch)
2012-04-26 23:38 UTC, Kyle
Details | Diff
Show Obsolete (1) Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Nematollahi 2007-01-18 21:51:51 UTC
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.
Comment 1 Dean Joseph 2007-01-19 07:22:39 UTC
It's actually easier to reproduce it with higher ping. I did it three times in the same match just before.
Comment 2 Denis Lukianov 2008-05-04 13:02:24 UTC
*** Bug 304 has been marked as a duplicate of this bug. ***
Comment 3 GhostlyDeath 2008-07-16 19:02:03 UTC
Commited on 993, test it out
Comment 4 Ralph Vickers 2010-01-15 06:27:27 UTC
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.
Comment 5 Ralph Vickers 2010-01-15 07:54:50 UTC
*** Bug 561 has been marked as a duplicate of this bug. ***
Comment 6 GhostlyDeath 2010-01-16 04:07:58 UTC
Remove from CC
Comment 7 Ralph Vickers 2010-08-06 05:16:05 UTC
*** Bug 605 has been marked as a duplicate of this bug. ***
Comment 8 Kyle 2010-08-06 05:23:36 UTC
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.
Comment 9 Kyle 2010-08-06 06:16:49 UTC
< 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.
Comment 10 Kyle 2010-08-06 06:17:37 UTC
Created attachment 204 [details]
Remove client range check during a netgame
Comment 11 Mike Lightner 2010-08-06 14:29:09 UTC
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?
Comment 12 Spleen 2010-08-06 16:29:06 UTC
	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.
Comment 13 Mike Lightner 2010-08-06 22:38:25 UTC
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.
Comment 14 Kyle 2010-08-07 17:45:58 UTC
Looks like yet another bug is out of the way. Thanks again for applying the patch.
Comment 15 Mike Lightner 2010-08-07 21:17:09 UTC
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.
Comment 16 Mike Lightner 2010-09-08 13:13:11 UTC
This isn't fixed entirely...
Comment 17 Mike Lightner 2010-09-08 13:13:38 UTC
*** Bug 632 has been marked as a duplicate of this bug. ***
Comment 18 Mike Lightner 2010-09-08 15:02:25 UTC
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.

To Reproduce:

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.
Comment 19 Kyle 2010-09-28 04:20:00 UTC
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.
Comment 20 Ralph Vickers 2010-12-29 14:16:56 UTC
*** Bug 682 has been marked as a duplicate of this bug. ***
Comment 21 Kyle 2010-12-29 19:24:34 UTC
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:
Comment 22 Kyle 2011-08-11 20:16:26 UTC
Created attachment 308 [details]
Desyncs netdemo

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.
Comment 23 Kyle 2012-04-15 07:16:34 UTC
Created attachment 355 [details]
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.
Comment 24 Dr. Sean 2012-04-18 22:31:13 UTC
I committed a reworked version of tm512's patch in r3014 using the idea he outlined.  Please test.
Comment 25 Kyle 2012-04-20 23:49:04 UTC
Created attachment 359 [details]
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.
Comment 26 Kyle 2012-04-26 23:38:33 UTC
Created attachment 362 [details]
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).
Comment 27 Mike Lightner 2014-03-30 16:20:15 UTC
Is this still a problem?