Upvote Upvoted 17 Downvote Downvoted
Flamethrower Rehabilitation
posted in Projects
1
#1
0 Frags +

Years ago I made "Meet the Broken Flamethrower" video that demonstrates how flamethrower is clearly malfunctioning which is manifested through constant and unpredictable damage drops that players have no way to control and which provide no visual cues for why they happen (even in a slowed-down replay). YT: https://www.youtube.com/watch?v=JqaI5LhNalk Thread: https://www.teamfortress.tv/52226/meet-the-broken-flamethrower

Unfortunately, it has never got any better. However, recently I invested some time into investigation of technical side of flamethrower (TF2 code being open source really helps!) and I've managed to come up with a solution that drastically improves consistency while also fixing that infamous "flail-around and hold M1" post-JI tactics FOR REAL (that "Blue Moon" rampup system never ever fixed it despite what update notes claimed!). Oh, and no more -50% damage near walls.

I implemented the solution in a form of a SourceMod plugin and I called it "Flamethrower Rehabilitation". I wonder if competitive community will find it useful? Anyways, I'll leave the links below.

Video demonstration: https://www.youtube.com/watch?v=xsNfgdueT9U
Plugin & code: https://github.com/bigmazi/flamethrower-rehabilitation
AlliedModders thread: https://forums.alliedmods.net/showthread.php?p=2841241

In-depth information about what it actually does, how it works and what it supercedes may be found at GitHub & AlliedModders pages that are linked above.

Years ago I made "Meet the Broken Flamethrower" video that demonstrates how flamethrower is clearly malfunctioning which is manifested through constant and unpredictable damage drops that players have no way to control and which provide no visual cues for why they happen (even in a slowed-down replay). YT: [url=https://www.youtube.com/watch?v=JqaI5LhNalk]https://www.youtube.com/watch?v=JqaI5LhNalk[/url] Thread: [url=https://www.teamfortress.tv/52226/meet-the-broken-flamethrower]https://www.teamfortress.tv/52226/meet-the-broken-flamethrower[/url]

Unfortunately, it has never got any better. However, recently I invested some time into investigation of technical side of flamethrower (TF2 code being open source really helps!) and I've managed to come up with a solution that drastically improves consistency while also fixing that infamous "flail-around and hold M1" post-JI tactics FOR REAL (that "Blue Moon" rampup system never ever fixed it despite what update notes claimed!). Oh, and no more -50% damage near walls.

I implemented the solution in a form of a SourceMod plugin and I called it "Flamethrower Rehabilitation". I wonder if competitive community will find it useful? Anyways, I'll leave the links below.

Video demonstration: https://www.youtube.com/watch?v=xsNfgdueT9U
Plugin & code: https://github.com/bigmazi/flamethrower-rehabilitation
AlliedModders thread: https://forums.alliedmods.net/showthread.php?p=2841241

In-depth information about what it actually does, how it works and what it supercedes may be found at GitHub & AlliedModders pages that are linked above.
2
#2
0 Frags +

This is a really nice plugin, flamethrower particles have always been very inconsistent in my experience, especially during the heat of a team fight. I'm not sure if competitive leagues would introduce this plugin as in the grand scheme of things it isn't something that desperately needs to be fixed, it just makes pyro more effective at close range, and depending on who you ask, some people might not want pyro to be more effective while that close.

Regardless, great plugin and perhaps valve themselves may introduce this fix in the future.

This is a really nice plugin, flamethrower particles have always been very inconsistent in my experience, especially during the heat of a team fight. I'm not sure if competitive leagues would introduce this plugin as in the grand scheme of things it isn't something that desperately needs to be fixed, it just makes pyro more effective at close range, and depending on who you ask, some people might not want pyro to be more effective while that close.

Regardless, great plugin and perhaps valve themselves may introduce this fix in the future.
3
#3
20 Frags +

Awesome work! You seem very passionate and knowledgeable about the flames. I loved the video you did back in the day which raised a lot of awareness regarding this issue, and this plugin is awesome too! Do you think you could maybe review if the flamethrower fix I did here to the SDK makes sense: https://github.com/mastercomfig/tc2/commit/0435ae3ebd8bb0a3781482501c3d236ce3747a32

Subsequent adjustment commits:

https://github.com/mastercomfig/tc2/commit/0951bc517106822f10dc5b11383df78c4a429dd6
https://github.com/mastercomfig/tc2/commit/783a94cf20875ae0a2ec3ea8f5198090e7304c94
https://github.com/mastercomfig/tc2/commit/fbe48cd6c86fc8e118ea2f44ffd8080f9887bb70

Awesome work! You seem very passionate and knowledgeable about the flames. I loved the video you did back in the day which raised a lot of awareness regarding this issue, and this plugin is awesome too! Do you think you could maybe review if the flamethrower fix I did here to the SDK makes sense: https://github.com/mastercomfig/tc2/commit/0435ae3ebd8bb0a3781482501c3d236ce3747a32

Subsequent adjustment commits:

https://github.com/mastercomfig/tc2/commit/0951bc517106822f10dc5b11383df78c4a429dd6
https://github.com/mastercomfig/tc2/commit/783a94cf20875ae0a2ec3ea8f5198090e7304c94
https://github.com/mastercomfig/tc2/commit/fbe48cd6c86fc8e118ea2f44ffd8080f9887bb70
4
#4
5 Frags +
mastercomsAwesome work!

Thanks!

mastercomsDo you think you could maybe review if the flamethrower fix I did here to the SDK makes sense

Regarding reversing flames priority: yes, absolutely, this must be done. I have no idea how it was never changed. That comment in the code - "take the first flame", "THE FIRST" - hints strongly that this is an obvious oversight that they simply forgot that they store the flames in chronological order.

As for tweaking Blue Moon rampup. The thing is that this rampup accomplish nothing. Nothing. As the update notes claim its purpose was to combat flail-around post-ji tactics. Does this mechanics accomplish this goal? No, it does not! This "heat index", or whatever they call it, this metric has no correlation to flame density. It completely fails to detect flail-around WHILE constantly penalizing focused fire (especially at point blank). And with post-JI flames the game absolutely MUST have SOMETHING to combat that flail-around. If Blue Moon fails to do it wile having horrific side effects, why even bother tweaking it? If devs want to estimate density and penalize sparse flames, well, let them craft something that actually does it. If devs want damage ramp up as a separate mechanic that is unrelated to density estimation, let them implement something simple and comprehensible that doesn't involve a hidden metric that updates itself every frame based on complex computations. If devs want damage to be accounted by player's precision at a fine-grained level, then, well, probably just scrap JI system and go back to per-particle damage? Blue moon rampup fails at all three possible goals. As already said, density estimation is poor; the fact that damage rampup spans across several frames is incindental and its rate is heavily inconsistent and unpredictable; as for precision estimation, well, it penalizes focused fire against static target, I don't even know what to add here. I see no point in bothering with tweaking numbers of this system, this rampup system must simply be deleted and replaced with something else.

[quote=mastercoms]Awesome work![/quote]

Thanks!

[quote=mastercoms]Do you think you could maybe review if the flamethrower fix I did here to the SDK makes sense[/quote]

Regarding reversing flames priority: yes, absolutely, this must be done. I have no idea how it was never changed. That comment in the code - "take the first flame", "THE FIRST" - hints strongly that this is an obvious oversight that they simply forgot that they store the flames in chronological order.

As for tweaking Blue Moon rampup. The thing is that this rampup accomplish nothing. Nothing. As the update notes claim its purpose was to combat flail-around post-ji tactics. Does this mechanics accomplish this goal? No, it does not! This "heat index", or whatever they call it, this metric has no correlation to flame density. It completely fails to detect flail-around WHILE constantly penalizing focused fire (especially at point blank). And with post-JI flames the game absolutely MUST have SOMETHING to combat that flail-around. If Blue Moon fails to do it wile having horrific side effects, why even bother tweaking it? If devs want to estimate density and penalize sparse flames, well, let them craft something that actually does it. If devs want damage ramp up as a separate mechanic that is unrelated to density estimation, let them implement something simple and comprehensible that doesn't involve a hidden metric that updates itself every frame based on complex computations. If devs want damage to be accounted by player's precision at a fine-grained level, then, well, probably just scrap JI system and go back to per-particle damage? Blue moon rampup fails at all three possible goals. As already said, density estimation is poor; the fact that damage rampup spans across several frames is incindental and its rate is heavily inconsistent and unpredictable; as for precision estimation, well, it penalizes focused fire against static target, I don't even know what to add here. I see no point in bothering with tweaking numbers of this system, this rampup system must simply be deleted and replaced with something else.
5
#5
4 Frags +

Thank you for reviewing the code and letting me know. I wanted to make a clarification for the ramp up / density system changes, keep in mind that I did change the math in addition to tweaking parameter values. And I did test it and basically measured using +left and cl_yawspeed. I used various different rotations per second that correlate to the tick rate of the flames, to measure if DPS proportionally decreased for reduction in persistent contact in between flame damage ticks. And I tuned it such that you get a nearly proportional increase to your accuracy on the target. So, if you have 50% accuracy, you get 50% DPS. If you have 70% accuracy, you have 70% DPS, etc.

I think the issues were that the parameters were not tuned to be proportional to flame accuracy, so it wasn't very responsive to focus fire, and it was based on lifetime rather than just tracking collision rate. This meant that if you were slightly too far away, each flame collision would not be enough to "fight" against the heat drain rate, and your DPS would decrease, despite being 100% accurate. And small variations in lifetime could cause this problem too even at closer ranges. The lack of parameter adjustment and the way heat decays each tick regardless of a hit or not, and regardless of if you had a chance to fire a flame that tick, meant that it was very slow to get up to 100% DPS, and when it got there, there were times where you simply had no chance to stop the DPS lowering. So, I very intentionally tuned the parameters and the math to counteract this based upon tickrate patterns, contact accuracy proportionality, etc.

Thank you for reviewing the code and letting me know. I wanted to make a clarification for the ramp up / density system changes, keep in mind that I did change the math in addition to tweaking parameter values. And I did test it and basically measured using +left and cl_yawspeed. I used various different rotations per second that correlate to the tick rate of the flames, to measure if DPS proportionally decreased for reduction in persistent contact in between flame damage ticks. And I tuned it such that you get a nearly proportional increase to your accuracy on the target. So, if you have 50% accuracy, you get 50% DPS. If you have 70% accuracy, you have 70% DPS, etc.

I think the issues were that the parameters were not tuned to be proportional to flame accuracy, so it wasn't very responsive to focus fire, and it was based on lifetime rather than just tracking collision rate. This meant that if you were slightly too far away, each flame collision would not be enough to "fight" against the heat drain rate, and your DPS would decrease, despite being 100% accurate. And small variations in lifetime could cause this problem too even at closer ranges. The lack of parameter adjustment and the way heat decays each tick regardless of a hit or not, and regardless of if you had a chance to fire a flame that tick, meant that it was very slow to get up to 100% DPS, and when it got there, there were times where you simply had no chance to stop the DPS lowering. So, I very intentionally tuned the parameters and the math to counteract this based upon tickrate patterns, contact accuracy proportionality, etc.
6
#6
4 Frags +

This is in-depth work, thank you for this. I remember the original vid, kind of crazy (well, maybe not that crazy) that nothing has changed.

Regarding this point:

bigmaziI implemented the solution in a form of a SourceMod plugin and I called it "Flamethrower Rehabilitation". I wonder if competitive community will find it useful?

A plugin that just reversed priority of flames from oldest -> youngest (fixing the wall bug) would I imagine be pretty uncontroversial. Hard to argue this isn't a bug and is pretty low impact compared to other plugins already allowed such as self-reflect fix or ghost crossbow fix.

If there was just a simple change that would fix the point blank bug(s), analogous to reversing priority fixing the wall bug, I think that would be similarly uncontroversial. To my understanding though, and correct me if I'm wrong, but the point blank bug is not so easy to fix and manifests because of the messed up ramp up system, and fixing it would probably require a total overhaul of the system or disabling it outright. To me this is more contentious because while I do think the ramp up as currently implemented is bugged (the point-blank behavior being the most obvious example), overhauling the system feels less like a bug fix and more of a "trying to read what Valve was intending to do" which seems, to me anyway, more like a (pro)mod in spirit.

Of course I don't really think that the current iteration of Blue Moon ramp up is what Valve probably intended; that being said, this is also the same company that just prints extremely incorrect things on patch notes especially related to pyro. Obvious example here are the "cone-shaped airblast" or "reduced air control for a short period" or "total push force slightly increased", none of which were touched in Blue Moon. The push force one is particularly egregious because a stated intent for the JI overhaul was for the airblast recipient to have more control (i.e. this was "Valve's intent"), but the actual system arguably has even less but was never changed after the fact, perhaps signaling that this is what the devs intended all along. Similarly while I think the wall bug and point-blank bug are almost surely not intended, reading the machinations of Valve devs is basically impossible and as far as I'm concerned the rest of the ramp up system could be totally what they had in mind for whatever godforsaken reason, making any changes to it """feel""" like less of a bug fix.

Just my two cents. Not an RGL admin though, and maybe other people will disagree.

This is in-depth work, thank you for this. I remember the original vid, kind of crazy (well, maybe not that crazy) that nothing has changed.

Regarding this point:

[quote=bigmazi]I implemented the solution in a form of a SourceMod plugin and I called it "Flamethrower Rehabilitation". I wonder if competitive community will find it useful?[/quote]

A plugin that just reversed priority of flames from oldest -> youngest (fixing the wall bug) would I imagine be pretty uncontroversial. Hard to argue this isn't a bug and is pretty low impact compared to other plugins already allowed such as self-reflect fix or ghost crossbow fix.

If there was just a simple change that would fix the point blank bug(s), analogous to reversing priority fixing the wall bug, I think that would be similarly uncontroversial. To my understanding though, and correct me if I'm wrong, but the point blank bug is not so easy to fix and manifests because of the messed up ramp up system, and fixing it would probably require a total overhaul of the system or disabling it outright. To me this is more contentious because while I do think the ramp up as currently implemented is bugged (the point-blank behavior being the most obvious example), overhauling the system feels less like a bug fix and more of a "trying to read what Valve was intending to do" which seems, to me anyway, more like a (pro)mod in spirit.

Of course I don't really think that the current iteration of Blue Moon ramp up is what Valve [i]probably[/i] intended; that being said, this is also the same company that just prints extremely incorrect things on patch notes especially related to pyro. Obvious example here are the "cone-shaped airblast" or "reduced air control for a short period" or "total push force slightly increased", none of which were touched in Blue Moon. The push force one is particularly egregious because a stated intent for the JI overhaul was for the airblast recipient to have more control (i.e. this was "Valve's intent"), but the actual system arguably has even less but was never changed after the fact, perhaps signaling that this is what the devs intended all along. Similarly while I think the wall bug and point-blank bug are almost surely not intended, reading the machinations of Valve devs is basically impossible and as far as I'm concerned the rest of the ramp up system could be totally what they had in mind for whatever godforsaken reason, making any changes to it """feel""" like less of a bug fix.

Just my two cents. Not an RGL admin though, and maybe other people will disagree.
7
#7
4 Frags +
springrollsThis is in-depth work, thank you for this.

Thanks!

springrollsA plugin that just reversed priority of flames from oldest -> youngest (fixing the wall bug) would I imagine be pretty uncontroversial.

You can do it with this plugin. Features are controlled with cvars and may be toggled separately.

[quote=springrolls]This is in-depth work, thank you for this.[/quote]

Thanks!

[quote=springrolls]A plugin that just reversed priority of flames from oldest -> youngest (fixing the wall bug) would I imagine be pretty uncontroversial.[/quote]

You can do it with this plugin. Features are controlled with cvars and may be toggled separately.
Please sign in through STEAM to post a comment.