Open SkillartzHD opened 5 years ago
Gameplay element, also hard to do, Just leave this as it is. Not a bug but feature.
Gameplay element, also hard to do, Just leave this as it is. Not a bug but feature.
how can this be a feature...
Gameplay element, also hard to do, Just leave this as it is. Not a bug but feature.
how can this be a feature...
As strafes, eb, gs, wb are. This is a part of cs physics already. Does not need to be changed.
Rawr1337 not everyone knows what eb, gs, cj, wb are. Can you use full names or references to the techniques on xtreme-jumps or something.
But why is this an issue exactly? You say "undesirable under certain circumstances" but what are those circumstances? People are using them, yes, but it only hurts certain communities by removing it. And if it's used to bypass the bunnyhop cap, why not remove the cap as well?
Gameplay element, also hard to do, Just leave this as it is. Not a bug but feature.
also, you forgot to mention that the speedhack/aimbot/all ddos & exploit vulnerabilities are a characterestric in the gameplay , Seriously?
you mean for you it's OK to jump off the building and you don't get damage? , then stay until the year 3003 to play with this exploit in the gameplay
Let's fix double-duck bug too. There no double-ducks in source engine. And stand up groundstrafe https://www.youtube.com/watch?v=4_sgN7gnAys Also fix this bug with decal showing without real shoot. https://www.youtube.com/watch?v=QU4kKVmIzkc
@mikela-valve
A casual player can accidentally hit a 0.01 second timing window with precise inputs? Speedrunners and KZ climbers have fun playing the game? Oh no! We must stop this immediately!
In fact, I, (the person who hates fun the most), have done all the work already in this branch. Absolutely no fun is guaranteed while playing. You're welcome.
It has to be controlled by cvar Example: sv_bugs 1\0 sv_bugs_jumpbug 1\0 sv_bugs_groundstrafe 1\0 sv_bugs_etc...
Changing this would only hurt the communities that rely on the game's movement mechanics, primarily CS 1.6 KZ. Not to mention that a casual player is EXTREMELY unlikely to ever encounter this, you have to know what you're doing.
Yeah, but this can be abused too. There are scenarios where you need to jump somwhere and lose some damage, whereas this will completely bypass it. Otherwise, this is required by some mods/servers.. A server-sided cvar would be a nice touch, if possible. This will reconcile the both sides. Also, this does not compare to the normal bhop where nothing bad can happen, this can be exploited in a malicious way.
Just wait and see what Valve rep. got to say.. don't be so rough. These are just opinions.
Also, you forgot to mention that the speedhack/aimbot/all DDoS & exploit vulnerabilities are a characteristic in the gameplay, Seriously?
It's less they're a characteristic for the gameplay but an unintended feature that healthy communities have built around. How many players are returning to or buying (on Steam) 1.6 and Half-Life just to engage in communities like surf, kreedz, or other movement skill-based gamemodes? This is really just change for change's sake, impacting only a tiny percentage of casual players while completely destroying whole communities that rely on features like jumpbugging, bunnyhopping and other movement features. Implying casual people can regularly perform precise frame-perfect inputs on servers regularly for meagre benefits is absurd. While I and many others against a change like this could name many instances where this could be a huge negative change, I have only seen hypothetical situations presented like There are scenarios where you need to jump somewhere and lose some damage
I can only think of a few maps where this has any benefit, and those are VERY small gains, nothing to destabilise the entire meta. If you can name me an instance where someone has performed a jumpbug in a casual match setting and it has hugely changed the round/game with proof I would support a change like this.
Hello there SkillartzHD,
seems like you're busy checking HL for "bugs". This has happened to Sven Coop too, as you might know, fixing the game for beginners to be able to keep up with experienced hl bhoppers. Nothing wrong with that, maybe in this special case.
Fixing Jumpbugs and the like which actually make for a deeper, more complex, more challenging game experience and therefore a longer game life in total is imo not the right approach. As you might not realize from a dev perspective, these glitches are so hard to master, they are not at all viable for casual players, only by those that invest massive amounts of time and skill to make for perfect gameplay executions. These people are being watched by hundreds of thousands of other players being inspired to try out the game themselves and experience the same rush (and buy it on Steam). Especially Half-Life is very popular exactly because it is so hard, because it allows for crazy difficult movement that you can have fun practicing and getting good at for a long time.
Imo "fixing" these glitches is like cutting into your own arm. Maybe have a look at the actual communities and find out about what makes them play your game for so long. Casuals are not affected by this. And if you're searching for a more "realistic" experience, create a new game. Those old games are perfect in some ways exactly because they are gameplay based, and not stuck at imitating reality.
Greetings
Another quick point: most speedrunners still use the WON version of the game because the Steam version has the awkward bunnyhop cap. People also have older Steam versions that have quickguass and so on for runs where the cap isn't a problem. So fixing a bunch of speedrunning tricks would be a complete waste of time. People just wouldn't use that version. What I'm more interested in seeing is fixes for the horrible run-killing bugs like item pickup crashes and hornet level transition crashes. I actually don't know if these bugs are present in the current Steam build or not, but due to the bunnyhop cap we wouldn't be able to use this version anyway.
Something that also hasn't been mentioned with jumpbugs is that not all jumpbug heights are possible at all framerates. Unless you can hit a 1 millisecond button timing in casual play, you'll have to look up a precise FPS value based on in-game coordinates that you can only conveniently see with an injected plugin specifically meant for speedrunners. As a fan of jumpbugs myself I currently have about 12 jumpbug-related binds for use throughout a full game run. A casual player probably doesn't even have a way to bind stuff in console. Calling for this to be fixed is just an odd thing to focus on, in my opinion.
Logically, all the movement mechanics should be modified somehow server-sided only.. Client-side is not worth...
There's a lot of good conversation here back and forth but I don't think fixing issues that are bugs but have become accepted game mechanics are necessarily good things to do. If there was time to do everything I'd say that fixing issues like this and adding ways for SP and MP to enable/disable the fixes would be the way to go, but if the bug or exploit is not game breaking or obviously needs fixing I'll err on the side of leaving it the way it is for now.
Jumpbug is one of a few exploits that can bypass fall damage when landing on any ground. The downside of jumpbug is that a jump must be made, which may be undesirable under certain circumstances. For example, when the player jumps the bunnyhop cap will be triggered. To begin a jumpbug sequence, suppose that the player is initially not onground (as determined by the first onground check) and that the duckstate is 2, as illustrated by the +duck bounding box in the figure above. Some time later the player unducks, hence
PM_UnDuck
will be called to change the duckstate back to 0 and the second onground check will be triggered. If there exists a ground 2 units below the player, then the player will now be onground (as shown by the -duck box above), and if +jump happens to be active the player will jump when PM_Jump is called within the same frame (shown by the +jump box). But recall thatPM_Jump
will always make the player to be not onground. Also, as the upward velocity is now greater than 180 ups, when the third onground check is made the player will again be determined to be not onground. As a result, when the control passes toCBasePlayer::PostThink
, the game will not inflict fall damage to the player. Jumpbug can fail if the player was not able to unduck to make himself onground after the second groundcheck. The chances of this happening is greater at lower frame rates and higher vertical speeds.https://www.youtube.com/watch?v=IJK83dDfc0E