Halflife: [CS 1.6] [Feature Request] sv_infinite_ammo

Created on 19 Jul 2019  Â·  25Comments  Â·  Source: ValveSoftware/halflife

A server-side cvar to allow the use of infinite ammo on every weapon,

sv_infinite_ammo "1" to shoot infinitly.
sv_infinite_ammo "2" to be able to reload but the reload ammo never runs out.

Yes, this is a CS:GO feature but that doesn't mean that wouldn't be a good feature for CS 1.6

Feature Request

Most helpful comment

@Splatt581 @RauliTop I’d actually already started on infinite grenades with that same cvar name a few days ago when I started looking into adding infinite ammo to all games as @SamVanheer suggested. It was actually when I got to TFC that I figured it would be good to be able to independently set infinite grenades since it could be a bit chaotic to always be able to throw grenades everywhere.

All 25 comments

There are a lot of QoL commands that should be added and are not that hard to implement (mostly for dev purpose).

There are a lot of QoL commands that should be added and are not that hard to implement (mostly for dev purpose).

What's QoL?

*QoL = Quality of Life.* Makes your gameplay experience more easy and simple.

This would require each weapon to be updated since there is no common base class that handles ammo subtraction, and the cvar value would need to be networked to clients so weapon prediction works properly.

Since the crowbar bug fix would also require a cvar value to be networked this could add up pretty quickly once other cvars start needing it so it may be a good idea to come up with a way to network cvars independently of the weapons code. That would probably require a change to the network protocol though.

+1 we should fix client ammo field's too, coz there some of stupid limit's if we gonna set for example clip of m4a1 to 31 then reload animation gonna break, coz max clip is 30 on client, and it's hardcoded.

That would require all of the weapon info to be networked as well, which can't be done effectively within the restrictions of the current networking system.

Here's an example of the info that weapons have:
https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/dlls/mp5.cpp#L93-L108

And here's the M4A1's version:

int CM4A1::GetItemInfo(ItemInfo *p)
{
  p->pszAmmo1 = "556Nato";
  p->iMaxAmmo1 = 90;
  p->pszName = STRING( pev->classname );
  p->pszAmmo2 = 0;
  p->iMaxAmmo2 = -1;
  p->iMaxClip = 30;
  p->iSlot = 0;
  p->iPosition = 6;
  p->iFlags = 0;
  m_iId = 22;
  p->iId = 22;
  p->iWeight = 25;
  return 1;
}

@SamVanheer I think infinite ammo could actually be done the slightly hacky way of just resetting the weapon ammo to max in CBasePlayerWeapon::UpdateClientData and the player's primary/secondary ammo to max in CBasePlayer::SendAmmoUpdate. Differences in ammo between the client and server are already synchronized so if this cvar gets set when the player has already fired the new amount would be synchronized on the next update and forcing the values to max before sending updates prevents the additional CurWeapon message that would be sent if the amount changed then changed back to max.

I concur 100% with you on actually changing the clip sizes or max ammo counts. Theoretically those should be adjustable through sending WeaponList messages that override the default values but unfortunately most of the weapons have hardcoded values for clip size or max ammo in them rather than using the values stored in the item/ammo info array, as you point out.

That should work as long as none of the weapons can use up all of their ammo in-between updates. Vanilla weapons don't do that but custom/modified weapons might do that.

Though perhaps there is an edge case where if a player sends an IN_ATTACK command and then no more commands, PreThink won't be called anymore and the weapon will run out of ammo eventually since it isn't calling UpdateClientData as a result.
But then the player probably won't be getting any updates to see this happen and will time out eventually anyway, so maybe that isn't an issue.

Those are good points, I ended up doing it in ItemPostFrame after any handling of PrimaryAttack and Reload has already occurred, so it should always keep ammo counts at max regardless of what the player/server relationship is like. I tested with an M4A1 I forced to 1 round in the clip and everything worked as expected, so I'll include this in the next update.

That sounds good, but ItemPostFrame is called by CBasePlayer::PostThink which is also subject to the same rules as PreThink, namely it only runs when processing a user command. If the client isn't responding that won't be called either. SV_RunCmd in the engine handles all of that stuff.

Yeah, I figured it would be best to see how it does with only the server handling infinite ammo before adding any support to the prediction for it. If there are reports that reasonable latencies are resulting in a long enough time between updates to cause the client to have issues I'll go into the prediction logic and add similar changes there.

This is added in build 8303 as mp_infinite_ammo.
The settings for it match what @Maxi605 has above:
1 makes the weapon clip infinite
2 makes the weapon have infinite ammo for reloading

This is added in build 8303 as mp_infinite_ammo.
The settings for it match what @Maxi605 has above:
1 makes the weapon clip infinite
2 makes the weapon have infinite ammo for reloading

Works fine, thanks!

@kisak-valve can be closed.

Just tested it, big thanks for adding this. Though I found that CS weapons aren't designed to have a spray pattern for more than their magazine capacity. For example, try shooting an M4 or AK for a few seconds and you'll notice that the weapon's spray will lock into 2 specific points and switch between them. I dunno if it's intentional but it doesn't make sense to do spray like that anyway..

It might be a good idea to implement this in all official games since the logic is pretty generic.

Also, the Deleted Scenes beta doesn't have this. Maybe the beta is out of date but it would be nice if it had this as well.

I think it would be nice to also add endless grenades for CS - if the player has grenades and the cvar mp_infinite_grenades 1, then they will be infinite. This would make it easier for players to train throwing grenades.

So, then we gonna get flashbang grenade bug's.

Sv_infinite_ammo should give infinite grenades too instead.

Sv_infinite_ammo should give infinite grenades too instead.

Not agree with that, another new command will be better.

@Splatt581 @RauliTop I’d actually already started on infinite grenades with that same cvar name a few days ago when I started looking into adding infinite ammo to all games as @SamVanheer suggested. It was actually when I got to TFC that I figured it would be good to be able to independently set infinite grenades since it could be a bit chaotic to always be able to throw grenades everywhere.

I'm going to move this to future releases for the completion of mp_infinite_grenades and mp_infinite_ammo in all games due to each game having slight quirks to how ammo and grenades are handled so I want to give them a bit more time for testing. Infinite ammo for CS will be included in the next release.

@kisak-valve Counter-Strike label should be removed.

I think it would be good to add a sprite (that is the infinity symbol, ∞) replacing the clip/ammo count when mp_infinite_ammo is 1 or 2 (the same goes for mp_infinite_grenades being set to 1).
With Half-Life's open source code, I made all weapons have their clip always set to 100 and then I replaced the clip count with an infinity symbol from Counter-Strike: Online.

Screenshots:

20190814193148_1
20190814193205_1
20190814193234_1
20190814193244_1
20190814193254_1
20190814193315_1
20190814193550_1
20190814193607_1
20190814193633_1
20190814193644_1
20190814193703_1
20190814193714_1

@mikela-valve it would be awesome if this feature (infinity symbol replacing clip/ammo count) becomes a real thing for all mods of Half-Life and Half-Life itself.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

BlackShadow picture BlackShadow  Â·  3Comments

CS-PRO1 picture CS-PRO1  Â·  3Comments

perforatorRU picture perforatorRU  Â·  3Comments

perforatorRU picture perforatorRU  Â·  3Comments

ptrBR picture ptrBR  Â·  3Comments