`
How the hell do I hit directs consistently?
posted in
Q/A Help
usnpeepoothe monitor I bought doesn't let me use my mic on my headset
what
[quote=usnpeepoo]the monitor I bought doesn't let me use my mic on my headset [/quote]
what
what
Hitting directs consistently is hard for even dm lords. What I would recommend is to do what aiera said gunboat soldier vs scout mge, but what I would add is limit yourself to directs only splash if you have already directed him once. Hit up temple knockout its an amazing arena to practice directs gl.
Hitting directs consistently is hard for even dm lords. What I would recommend is to do what aiera said gunboat soldier vs scout mge, but what I would add is limit yourself to directs only splash if you have already directed him once. Hit up temple knockout its an amazing arena to practice directs gl.
tommyhttps://youtu.be/CKqMD3rwUMk
was literally about to link that same damn clip
[quote=tommy]https://youtu.be/CKqMD3rwUMk[/quote]
was literally about to link that same damn clip
was literally about to link that same damn clip
hitting directs consistently is impossible on really good players, most of the time you're going for splash rockets and only go for directs if you have a hard read. at least that applies when shooting at scouts.
hitting directs consistently is impossible on really good players, most of the time you're going for splash rockets and only go for directs if you have a hard read. at least that applies when shooting at scouts.
why direct them when you can shoot the floor near them
edit: also comparing yourself to people insanely better than you will only serve to discourage you and make yourself fail to see your own progress. the only person you need to compare yourself to is the past you. those soldiers you are comparing yourself to have spent thousands of hours in game, everything takes time. there is no shortcut.
why direct them when you can shoot the floor near them
edit: also comparing yourself to people insanely better than you will only serve to discourage you and make yourself fail to see your own progress. the only person you need to compare yourself to is the past you. those soldiers you are comparing yourself to have spent thousands of hours in game, everything takes time. there is no shortcut.
edit: also comparing yourself to people insanely better than you will only serve to discourage you and make yourself fail to see your own progress. the only person you need to compare yourself to is the past you. those soldiers you are comparing yourself to have spent thousands of hours in game, everything takes time. there is no shortcut.
DewItthe only person you need to compare yourself to is the past you.
nah bruh u dont compare urself to how bad u used to be, u compare urself to how good u can & will be, Sigma Grindset.
also there are shortcuts, for those that want them im offering at an 80% discount, only 2 keys: https://steamcommunity.com/tradeoffer/new/?partner=132262126&token=bbezxK-A
[quote=DewIt]the only person you need to compare yourself to is the past you.[/quote]
nah bruh u dont compare urself to how bad u used to be, u compare urself to how good u can & will be, Sigma Grindset.
also there are shortcuts, for those that want them im offering at an 80% discount, only 2 keys: https://steamcommunity.com/tradeoffer/new/?partner=132262126&token=bbezxK-A
nah bruh u dont compare urself to how bad u used to be, u compare urself to how good u can & will be, Sigma Grindset.
also there are shortcuts, for those that want them im offering at an 80% discount, only 2 keys: https://steamcommunity.com/tradeoffer/new/?partner=132262126&token=bbezxK-A
Thank you to C.C.C.O. for being the first of many trades! And thank you to "chalupa" for buying me a copy of Five Nights at Freddy's! They will both be reaping the rewards shortly...
Thank you to C.C.C.O. for being the first of many [url=https://prnt.sc/NSvTJB90yT40]trades![/url] And thank you to "chalupa" for buying me a copy of [url=https://prnt.sc/QAbWl0u3P33Q]Five Nights at Freddy's![/url] They will both be reaping the rewards shortly...
https://www.youtube.com/watch?v=71AVaQI-_d8
it's like anime training weights if you train with this on you can take it off during matches to increase your power level by 1000x
[youtube]https://www.youtube.com/watch?v=71AVaQI-_d8[/youtube]
it's like anime training weights if you train with this on you can take it off during matches to increase your power level by 1000x
it's like anime training weights if you train with this on you can take it off during matches to increase your power level by 1000x
play dm, practice directs only, try to predict/aim, one day you will be hitting it automatically
play dm, practice directs only, try to predict/aim, one day you will be hitting it automatically
Whenever I play against good scouts I like to enter a parasocial relationship with them in order to get better reads
Whenever I play against good scouts I like to enter a parasocial relationship with them in order to get better reads
usnpeepooZestyIDK man, i'm just assuming it because i've used the headphones before and the mic worked perfectly but connecting it to this new one doesn't let it work. Called their support page and they verified that it doesn't let you use voice/mics with it.usnpeepoothe monitor I bought doesn't let me use my mic on my headsetwhat
you are supposed to plug the headphones into your pc.....
[quote=usnpeepoo][quote=Zesty][quote=usnpeepoo]the monitor I bought doesn't let me use my mic on my headset [/quote]
what[/quote]
IDK man, i'm just assuming it because i've used the headphones before and the mic worked perfectly but connecting it to this new one doesn't let it work. Called their support page and they verified that it doesn't let you use voice/mics with it.[/quote]
you are supposed to plug the headphones into your pc.....
what[/quote]
IDK man, i'm just assuming it because i've used the headphones before and the mic worked perfectly but connecting it to this new one doesn't let it work. Called their support page and they verified that it doesn't let you use voice/mics with it.[/quote]
you are supposed to plug the headphones into your pc.....
practice tr_juggle_final honestly, shit's helpful. After you start doubling/trippling the bots, you should be able to hit more airshots/directs in-game.
practice tr_juggle_final honestly, shit's helpful. After you start doubling/trippling the bots, you should be able to hit more airshots/directs in-game.
seekeerpendplay dm, practice directs only, try to predict/aim, one day you will be hitting it automatically
Yeah, that's completely wrong.
Direct hit arithmetic is not some kind of lottery where you sometimes get more than you expected.
Ceil will not randomly round 40.00000... to 41 because of some mysterious "hand crafted assembly". Either you've got exactly 40 and ceil will give you 40 or you've got 40.000001 or something like that and ceil will give you 41, as it should. If you are running TF2 on x86 (and by god I hope you do) the mysterious hand crafted assembly is simply ROUNDSD if you're allowed to use SSE4.1 but because TF2 is ancient it's most likely FRNDINT and a lot of code to save/restore the state of the FPU and generate a control word because x87 is a piece of shit that just won't die. They are both guaranteed to give exact roundings. If someone bothered to optimize it then maybe you'll get FISTP/FILD because FRNDINT is slow, but that's just the same thing by actually converting to an integer with rounding, then loading it again, instead of rounding the float/double directly, which is somehow slower because x87 is an ancient piece of shit that just won't die.
Anyway, that's neither an error, nor implementation dependent.
Next up, the result of 200 * 0.2 being slightly more than 40 depending on your library implementation would be hugely concerning. Why have you rewritten floating point multiply by hand instead of using the floating point instructions the CPU provides and why is it giving wrong results? On the other hand if you are using FMUL/FMULP/FIMUL (or more modern instructions) why would you get the wrong result? The last time an Intel FPU gave results that were slightly off it was a huge deal and ended in a complete recall. I can guarantee you that that is not the case.
No, you forgot a step:
0. Convert PackRatio (0.2f) to float
And this is where the error is introduced. The floating point math from that point on is completely flawless, there will be no errors regardless of implementation. Because there is absolutely no leeway in the implementation of multiply and ceil in IEEE 754 and actual errors, where you get an actual wrong result, not just one that is "inaccurate in different ways depending on the implementation" aren't allowed.
But the starting point is "wrong", because it is inaccurate.
0.2 can not be represented as binary floating point number. 0.2 is 1/5 and 5 does not share all of its divisors with our base, which is 2, because it is actually coprime to 2 because both 2 and 5 are actual primes. Basically this means that 0.2 in binary floating point is repeating. It's 0.0011001100110011... and so on.
Because float/double are finite this has to be rounded. Either up or down. For float that means the choice is between 0.199999988079071044921875 and 0.20000000298023223876953125. The latter is simply closer to the "true value" 0.2 than the former. Also printf with 8 or more decimal places showing "0.2f" as "0.19999999" tends to really upset people.
So yeah, do a quick
printf("%.30f\n", 0.2f);
and watch your worldview crumble.
[quote=seekeerpend]play dm, practice directs only, try to predict/aim, one day you will be hitting it automatically[/quote]
Yeah, that's completely wrong.
Direct hit arithmetic is not some kind of lottery where you sometimes get more than you expected.
Ceil will not randomly round 40.00000... to 41 because of some mysterious "hand crafted assembly". Either you've got exactly 40 and ceil will give you 40 or you've got 40.000001 or something like that and ceil will give you 41, as it should. If you are running TF2 on x86 (and by god I hope you do) the mysterious hand crafted assembly is simply ROUNDSD if you're allowed to use SSE4.1 but because TF2 is ancient it's most likely FRNDINT and a lot of code to save/restore the state of the FPU and generate a control word because x87 is a piece of shit that just won't die. They are both guaranteed to give exact roundings. If someone bothered to optimize it then maybe you'll get FISTP/FILD because FRNDINT is slow, but that's just the same thing by actually converting to an integer with rounding, then loading it again, instead of rounding the float/double directly, which is somehow slower because x87 is an ancient piece of shit that just won't die.
Anyway, that's neither an error, nor implementation dependent.
Next up, the result of 200 * 0.2 being slightly more than 40 depending on your library implementation would be hugely concerning. Why have you rewritten floating point multiply by hand instead of using the floating point instructions the CPU provides and why is it giving wrong results? On the other hand if you are using FMUL/FMULP/FIMUL (or more modern instructions) why would you get the wrong result? The last time an Intel FPU gave results that were slightly off it was a huge deal and ended in a complete recall. I can guarantee you that that is not the case.
No, you forgot a step:
0. Convert PackRatio (0.2f) to float
And this is where the error is introduced. The floating point math from that point on is completely flawless, there will be no errors regardless of implementation. Because there is absolutely no leeway in the implementation of multiply and ceil in IEEE 754 and actual errors, where you get an actual wrong result, not just one that is "inaccurate in different ways depending on the implementation" aren't allowed.
But the starting point is "wrong", because it is inaccurate.
0.2 can not be represented as binary floating point number. 0.2 is 1/5 and 5 does not share all of its divisors with our base, which is 2, because it is actually coprime to 2 because both 2 and 5 are actual primes. Basically this means that 0.2 in binary floating point is repeating. It's 0.0011001100110011... and so on.
Because float/double are finite this has to be rounded. Either up or down. For float that means the choice is between 0.199999988079071044921875 and 0.20000000298023223876953125. The latter is simply closer to the "true value" 0.2 than the former. Also printf with 8 or more decimal places showing "0.2f" as "0.19999999" tends to really upset people.
So yeah, do a quick
printf("%.30f\n", 0.2f);
and watch your worldview crumble.
Yeah, that's completely wrong.
Direct hit arithmetic is not some kind of lottery where you sometimes get more than you expected.
Ceil will not randomly round 40.00000... to 41 because of some mysterious "hand crafted assembly". Either you've got exactly 40 and ceil will give you 40 or you've got 40.000001 or something like that and ceil will give you 41, as it should. If you are running TF2 on x86 (and by god I hope you do) the mysterious hand crafted assembly is simply ROUNDSD if you're allowed to use SSE4.1 but because TF2 is ancient it's most likely FRNDINT and a lot of code to save/restore the state of the FPU and generate a control word because x87 is a piece of shit that just won't die. They are both guaranteed to give exact roundings. If someone bothered to optimize it then maybe you'll get FISTP/FILD because FRNDINT is slow, but that's just the same thing by actually converting to an integer with rounding, then loading it again, instead of rounding the float/double directly, which is somehow slower because x87 is an ancient piece of shit that just won't die.
Anyway, that's neither an error, nor implementation dependent.
Next up, the result of 200 * 0.2 being slightly more than 40 depending on your library implementation would be hugely concerning. Why have you rewritten floating point multiply by hand instead of using the floating point instructions the CPU provides and why is it giving wrong results? On the other hand if you are using FMUL/FMULP/FIMUL (or more modern instructions) why would you get the wrong result? The last time an Intel FPU gave results that were slightly off it was a huge deal and ended in a complete recall. I can guarantee you that that is not the case.
No, you forgot a step:
0. Convert PackRatio (0.2f) to float
And this is where the error is introduced. The floating point math from that point on is completely flawless, there will be no errors regardless of implementation. Because there is absolutely no leeway in the implementation of multiply and ceil in IEEE 754 and actual errors, where you get an actual wrong result, not just one that is "inaccurate in different ways depending on the implementation" aren't allowed.
But the starting point is "wrong", because it is inaccurate.
0.2 can not be represented as binary floating point number. 0.2 is 1/5 and 5 does not share all of its divisors with our base, which is 2, because it is actually coprime to 2 because both 2 and 5 are actual primes. Basically this means that 0.2 in binary floating point is repeating. It's 0.0011001100110011... and so on.
Because float/double are finite this has to be rounded. Either up or down. For float that means the choice is between 0.199999988079071044921875 and 0.20000000298023223876953125. The latter is simply closer to the "true value" 0.2 than the former. Also printf with 8 or more decimal places showing "0.2f" as "0.19999999" tends to really upset people.
So yeah, do a quick
printf("%.30f\n", 0.2f);
and watch your worldview crumble.
Please
sign in through STEAM
to post a comment.