[CS 1.6] [Feature Request] Crouch Limitation/Cooldown

[Maxi605]

A crouch cooldown (Or limitation, my enligsh isn't that good :S) as CS:GO has would be interesting as a server-side (If it's possible, may not be), its one of many additions that CS:GO has that i think are very very good.

If it can't be server-side then client-side.

[SamVanheer]

Backporting stuff from sequels shouldn't be done IMO.

[metita]

There are always good things from actual games that may be good to port to old games, is not a "must" get feature but may be taken into consideration.

[Maxi605]

Backporting stuff from sequels shouldn't be done IMO.

don't see why, there's a reason why is on CS:GO, it's really good and it would be good to see it on 1.6

[perforatorRU]

This will solve the problem DoubleDuck and SilientRun

[Rawr1337]

please no. movement in cs 1.6 is complete. just leave it as it is.

DoubleDuck and SilientRun

this is gameplay feature. use your hands and don't cry. When you do this movements your spread increases and you will have less chance of win in an unexpected fight. this is fair and also a huge part of Hide'N'Seek mode

[Maxi605]

please no. movement in cs 1.6 is complete. just leave it as it is.

DoubleDuck and SilientRun

use your hands and don't cry.

lmao, getting unrealistic speeds abusing an error shouldn't be in the game, you should use your hands, learn how to play the game instead of abusing the crouch mechanic, and as i said, if it's possible, there should be a server side cvar to toggle on/off so you don't cry about it. Its supposed to be a realistic game, i don't see the realism on going 100mph around the map, there's a reason why is not possible on CS:GO, they learned the mistakes from this game and fixed them, i don't see why not fixing it here too, they found the way to do it, they can do it again, many people would be against this and other in favor, it's on the hands of the dev team to decide if this exploit should be fixed or not.

[sjain882]

This game exists on Steam as a legacy, not for you CSGO kids to backport everything into CS.

Get out of this GitHub and don't come back, along with all the AlliedModder CS 1.6 slowhacking junkies.

[SamVanheer]

@sjain882 Please respect the rules of conduct:

• Do not insult, harass, or demean anyone.

You can disagree with them without being insulting.

Edit: just a heads up: this issue is bugged and has posts with future post dates, you probably won't be able to reply until those dates are in the past.

[AleXr64]

Cover by server cvar.

[ghost]

It should in no way limit the execution of Duckjump \ DoubleDuck using CTRL only. This should prevent the use of the mouse wheel for this purpose.

These are very interesting and unique elements of the game and their absence in CSGO is only a drawback of this game. These elements are also not in Counter-Strike: Source (2004 game).

Are you talking about realism? But in real combat, would you really use only running and walk? You would not use rifts, somersaults, various unexpected movements? Watch the video on how experienced antiterrorist units move during assaults. Instead of all this, CS has BunnyHop \ Duckjump \ DoubleDuck and their presence at least compensates for the lack of diversity of the many complex movement techniques that occur in real combat. There is nothing wrong with their execution on CTRL - this is also a manifestation of skill, not everyone knows how to do it correctly. And you can not, using only CTRL, "going 100mph around the map". Moreover, if you do not know how to use it correctly and at the right time, it will not give you anything, only harm, as Rawr1337 correctly noted.

Here you need to be very careful not to harm, not to spoil the game.

[Maxi605]

It should in no way limit the execution of Duckjump \ DoubleDuck using CTRL only. This should prevent the use of the mouse wheel for this purpose.

These are very interesting and unique elements of the game and their absence in CSGO is only a drawback of this game. These elements are also not in Counter-Strike: Source (2004 game).

Are you talking about realism? But in real combat, would you really use only running and walk? You would not use rifts, somersaults, various unexpected movements? Watch the video on how experienced antiterrorist units move during assaults. Instead of all this, CS has BunnyHop \ Duckjump \ DoubleDuck and their presence at least compensates for the lack of diversity of the many complex movement techniques that occur in real combat. There is nothing wrong with their execution on CTRL - this is also a manifestation of skill, not everyone knows how to do it correctly. And you can not, using only CTRL, "going 100mph around the map". Moreover, if you do not know how to use it correctly and at the right time, it will not give you anything, only harm, as Rawr1337 correctly noted.

Here you need to be very careful not to harm, not to spoil the game.

Never seen a dude by crouching and jumping going 100mph so, yeah, unrealistic.

Cover by server cvar.

would be ideal but i don't know if it is possible.

And as i said, there will be people who agree with me and people who don't, i don't use this exploit and have not much against people who use it but i run 9 servers on this game and having people abusing this exploit is really annoying, that's why i asked if it is even possible, add a cvar so the server can allow the use of this, so on servers where people like to use this, can.

[SamVanheer]

Adding a cvar isn't really an option. We're talking about player physics so the cvar would need to be replicated to clients in order to properly simulate physics.

GoldSource doesn't allow specifying cvars to be replicated to clients. The engine has to explicitly send changes to cvars that need to be replicated, which are stored in this structure: https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/pm_shared/pm_movevars.h#L15-L43

While adding new variables to the structure shouldn't break old mods, changing the message that sends these to clients will break old clients. Anyone running an older Steam build, or even a No-Steam build will experience message buffer corruption, likely followed by disconnection.

It would be possible to add a new message id but unless the message were to be designed to allow changes to it later on it's a one time deal, and older clients won't recognize it and will again disconnect upon encountering the unknown message. Even if older clients didn't disconnect they'd still be unable to simulate player physics properly.

The same problem exists with weapon prediction since cvars can't be replicated anywhere else automatically either. It simply isn't practical to add cvars to control various features.

[ghost]

Unbind mwheel[up\down] +duck on client side (with sv_cheats "0")

[Maxi605]

Adding a cvar isn't really an option. We're talking about player physics so the cvar would need to be replicated to clients in order to properly simulate physics.

GoldSource doesn't allow specifying cvars to be replicated to clients. The engine has to explicitly send changes to cvars that need to be replicated, which are stored in this structure: https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/pm_shared/pm_movevars.h#L15-L43

While adding new variables to the structure shouldn't break old mods, changing the message that sends these to clients will break old clients. Anyone running an older Steam build, or even a No-Steam build will experience message buffer corruption, likely followed by disconnection.

It would be possible to add a new message id but unless the message were to be designed to allow changes to it later on it's a one time deal, and older clients won't recognize it and will again disconnect upon encountering the unknown message. Even if older clients didn't disconnect they'd still be unable to simulate player physics properly.

The same problem exists with weapon prediction since cvars can't be replicated anywhere else automatically either. It simply isn't practical to add cvars to control various features.

Well, i don't think they should support or even care about no-steam anyways. I though it wasn't possible to add a cvar, but, well, is up to the devs.

[Maxi605]

Unbind mwheel[up\down] +duck on client side (with sv_cheats "0")

Unbinding isn't really a solution, they need to add a cooldown to the duck as it is on CS:GO.

[SamVanheer]

Adding a cvar isn't really an option. We're talking about player physics so the cvar would need to be replicated to clients in order to properly simulate physics. GoldSource doesn't allow specifying cvars to be replicated to clients. The engine has to explicitly send changes to cvars that need to be replicated, which are stored in this structure: https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/pm_shared/pm_movevars.h#L15-L43

While adding new variables to the structure shouldn't break old mods, changing the message that sends these to clients will break old clients. Anyone running an older Steam build, or even a No-Steam build will experience message buffer corruption, likely followed by disconnection. It would be possible to add a new message id but unless the message were to be designed to allow changes to it later on it's a one time deal, and older clients won't recognize it and will again disconnect upon encountering the unknown message. Even if older clients didn't disconnect they'd still be unable to simulate player physics properly. The same problem exists with weapon prediction since cvars can't be replicated anywhere else automatically either. It simply isn't practical to add cvars to control various features.

Well, i don't think they should support or even care about no-steam anyways. I though it wasn't possible to add a cvar, but, well, is up to the devs.

This change will affect every game and mod, so i seriously doubt they'll do so.

[Maxi605]

Adding a cvar isn't really an option. We're talking about player physics so the cvar would need to be replicated to clients in order to properly simulate physics. GoldSource doesn't allow specifying cvars to be replicated to clients. The engine has to explicitly send changes to cvars that need to be replicated, which are stored in this structure: https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/pm_shared/pm_movevars.h#L15-L43

While adding new variables to the structure shouldn't break old mods, changing the message that sends these to clients will break old clients. Anyone running an older Steam build, or even a No-Steam build will experience message buffer corruption, likely followed by disconnection. It would be possible to add a new message id but unless the message were to be designed to allow changes to it later on it's a one time deal, and older clients won't recognize it and will again disconnect upon encountering the unknown message. Even if older clients didn't disconnect they'd still be unable to simulate player physics properly. The same problem exists with weapon prediction since cvars can't be replicated anywhere else automatically either. It simply isn't practical to add cvars to control various features.

Well, i don't think they should support or even care about no-steam anyways. I though it wasn't possible to add a cvar, but, well, is up to the devs.

This change will affect every game and mod, so i seriously doubt they'll do so.

Well, i'm just hoping that they at least consider fixing the exploit.

[bucketss]

Well, i'm just hoping that they at least consider fixing the exploit.

it's not an exploit

it's a key feature that should be preserved at all costs