Source-1-Games
Source-1-Games copied to clipboard
ValveSoftware
[TF2] Demoman shield charge does not grant extra melee range as intended
I'm unsure if fixing this would be a wise balance decision, but I am putting this here just in case.
While under condition 17 (TF_COND_SHIELD_CHARGE), all melee attacks will have their range set to 128 hammer units long. However, since starting a melee attack removes the condition, and melee attacks happen after a delay (rather than happening instantly), the increased melee range is never applied. I believe this is unintentional.
Players have been working around this by initiating a normal melee swing before starting the charge. Due to the inherent delay with melee attacks, the attack becomes active while the condition is also active, granting the player extended melee reach. This has some situational usage for quickly finishing off a hurt enemy. However, this still means that mini-crit and critical attacks can never benefit from the range boost.
If this is something deemed worth fixing, a proper fix would likely involve checking for when the player starts an attack while the condition is active, and then granting the bonus melee range for a temporary duration (enough time for one melee swing to land). Perhaps add this on top of the current implementation, to avoid removing the strategy mentioned above.
Since this is something that has been broken since the release of those weapons, every player is used to playing without this perk in the game. That makes this request a grey area, as it would be beneficial to fix this due to it being a bug, but yet people might see this as a large buff to the kit if fixed. Due to that, however, I believe it'd be beneficial to fix this for the moment just to see what it would be like, and if it's deemed by the community to be too powerful then it can be reverted. I personally think it would make demoman charges more interesting and forgiving for the player doing them (especially newer players), and I believe that this was the original intention by the developers.
It's sort of like the opposite of the Iron Bomber hitbox bug. It was there from the start, and fixing the bug technically affected the weapon's balance (even if by a very small amount). This time, the change would end up making something more effective, rather than less.
It's sort of like the opposite of the Iron Bomber hitbox bug. It was there from the start, and fixing the bug technically affected the weapon's balance (even if by a very small amount). This time, the change would end up making something more effective, rather than less.
Perfect example of a bug affecting balance, even if it's miniscule. I didn't think of that. This definitely should be fixed, then.
Is the extra melee charge something seen as needed before discovery that there is non-functional code for it? The request, in my opinion, should come from that standpoint rather than the mere presence of non-functional code. Because as it stands, the state of the game does not necessarily rely on various bits of code which were never required to be functional to be fixed.
The code technically isn't non-functional though. A better word would be malfunctioning. There already exist strategies to make use of the extra melee range, and thus the code behind it. They just aren't the intended strategies.
If the devs ever decide to go about fixing the bug, there is a decision to be made.
- Axe the range buff mechanic entirely, which would technically be removing an intended feature
- Fix the bug such that the mechanic only works as intended (i.e. only for swings started while charging)
- Make the mechanic work during charge swings, but also keep the unintended strategy as players have been using this for years
Something else to note this that this functionality would seemingly allow players to successfully land a crit melee attack after shield bashing enemy players with the Splendid Screen. Currently, the extra damage of the Splendid Screen does so much knockback to the point where it's next to impossible to land the crit attack unless you shield bash the enemy into a wall, or try and avoid shield bashing altogether. I would imagine that fixing that issue was the intended use of this code.