PC Ammo disappearing from weapons when swapping out

[Chucklehead]

Category: Code

Reproducibility: Sometimes

Summary: Switching weapons causes a bit of ammo to disappear

Description: On occasion, when swapping the primary weapon with my secondary weapon in the slot first weapon slot (such switching to the medic shotgun from my medic assault rifle,) the ammo count for my first weapon will decrease and the lost ammo just vanishes. I have mostly noticed this during the trader periods between waves although I have yet to pinpoint whether or not it could be related to recent trader menu usage.

1) Reload first weapon in the primary slot
2) Switch to second weapon in the primary slot
3) Ammo counter for the first weapon goes from max capacity to just a few bullets below max, deducted bullets do not go back into your total ammo pool.

 

[Rawley]

I've had this happen a lot, but only on Commando. It seem to be reproducible in this situation:
1 - Make sure you have 2 different assault rifles that are fully loaded
2 - Fire a few rounds from both rifles
3 - Reload one of the rifles
4 - Switch to other rifle fairly quickly after the reload finishes
5 - The reloaded gun loses 2-3 rounds after about 0.5-1 seconds

It doesn't seem to happen again until both weapons have been fired.

 

[Chucklehead]

I haven't played commando but it's happened to me a lot as a medic. I thought I was going crazy at first but I know when I've reloaded a weapon recently and switching back to a weapon I've already reloaded onto to have 28 out of my 30 bullets in a magazine had me second guessing myself. Happens to my medic assault rifle after swapping to my shotgun. I haven't noticed if this happens to weapons of other types/in other slots.

What convinced me that the bullets just vanish was when the bug occurs after I have just shopped and hit auto-fill ammo button, reloading my assault rifle put me at 298 remaining bullets when it should be 300. This has happened multiple times.

 

[Grigori]

Had the same exact issue with different classes.

 

[TTQ]

Can confirm this is an issue, swapping out weapons from the same slot type while reloading deducts total ammo without reloading the weapon, effectively just removing ammo from the pool.

 

[undeadkyle134]

Can confirm it happens to me as well.

 

[undeadkyle134]

Hope this gets fixed, very annoying bug for supports.

 

[g3412]

I don't know if this issue has been addressed recently, but i am having this issue with every class I play. does not happen all the time, but most repeatable times:

at the beginning of trader round, reload main weapon, switch to another weapon, watch as 1-5 round disappear from your main weapon. also after filling all weapons at the trader, if you switch to your main weapon, and then away you will find missing ammo and have to go back and buy more again.

happens only on main weapons, classes affected by my notice, commando, field medic, firebug. I have not played much of other classes.

 

[infntnub]

I noticed this often on my AA12 this past weekend - glad to hear it's not just me...

 

[BBgun]

Definitely an issue, I've had it as well, and its annoying.

 

[infntnub]

Just sharing - I can confirm this bug still exists.

 

[infntnub]

Ongoing.

 

[Kothre]

Someone from Tripwire explained this (annoying) phenomenon.

Hey all, thought I'd shed some light on what's happening here. I'll try not to be too techy.

Demo weapons function differently than normal weapons, because a reload is done after every shot is fired and reloads are often done automatically in quick succession. Shoot, reload, shoot, reload, etc. Your client goes into the reload state, and it tells the server to do the same. Normally this is fine! But when we introduce frame rate variance, things get a little trickier. Servers tick at 30 fps max. Ideally, they're always at 30 fps. Your client on the other hand is going through much more frame variance. You might be running at, say, 60 fps or 120 fps.

Let's go with 60 fps. For every tick on the server, you're doing 2. The server resolves frames every ~0.03 seconds. The client resolves every ~0.017. But, game timers don't fall within perfect multiples of either number, so if we have a 2 second reload timer, what ends up happening is the client finishes the reload first. There is a tiny, tiny difference, probably about 0.5 hundredths of a second. But now picture firing and reloading over and over again. The client is gradually getting further and further ahead of the server, until it reaches a point where the client finishes the reload, the player fires, and when the sever receives the fire notification it says "wait a minute, I'm still reloading, I can't fire" and nothing happens. It denies the fire call. The client is perfectly happy to play the fire animation and FX, but with nothing happening on the server, no projectile is spawned.

The good news is that we know what's happening and have several ideas on how to approach fixing it. I'd imagine something similar might be happening in the OP's case, where perhaps the client arrived at the end of a reload just a tiny bit too fast and the server never started its fire sequence. It's slightly different because bullets use client-side hit detection, which is one of the major reasons our weapons feel so responsive even in high latency, but that doesn't mean they're not subject to the server's authority. The server says "no, you can't do that" as a security measure.

Hold on to your butts, a fix is coming.

Someone asked if this is why the ammo disappearing bug occurs, and TWI responds with:

It's similar but not related to reloading. The fire rate of autos is so high that thousandths of a second can make a big difference. It's why guns like the SCAR see it the most often.

It's also why the AA-12, caulk n' burn, flamethrower, and microwave gun see this so often, but pistols and demo weapons don't suffer from this. At any rate, I hope it's fixed soon. Both issues are extremely irritating.

Source: https://www.reddit.com/r/killingfloor/comments/49uwiq/its_happening_with_commando_weapons_as_well/

 

[Shuu]

Aware of this issue, engineers are working on it, thanks.