Are you having issues with HH nade jumps shooting you straight up in the air? Are you having issues with rjumps while moving forward?
Add the following to your config.cfg file in C:\Program Files (x86)\Steam\steamapps\common\Half-Life\tfc
With these settings I can hit HH jumps on battlezone and most other servers about 95% of the time. All credit goes to xheon. Feel free to send him some pesos as a gratuity.
rate 20000
fps_max "125"
fps_override "1"
setinfo "ec" "1"
cl_backspeed "400"
cl_cmdbackup "3"
cl_cmdrate "3000"
cl_dlmax "128"
cl_timeout "35"
cl_updaterate "70"
Some of the rates usually depend on your FPS. Just sayin
Quote from: Guts on March 29, 2016, 06:03:41 PM
Some of the rates usually depend on your FPS. Just sayin
You are correct and this is why the fps_max "125" command is included.
Quote from: Rand on March 29, 2016, 06:35:17 PM
I always thought cmdrate and updaterate should be the same? I am no HL console expert. I think that both of mine are at 100. rate at 20000. Just recently changed my fps from a long time 100 to 200.
Rand, I was under the same impression about cmd and updaterate until I tried these settings. Do you ever has issues with HHs on battlezone? If so, back up your config and give these a whirl.
Hey, thanks xheon and Nuggs.
This has helped to perform HH's in the server better, some nades seem to mysteriously be disappearing still, but I guess that just happens every once in a while.
Thanks!
Quote from: Nuggs on March 29, 2016, 07:29:45 PM
Quote from: Guts on March 29, 2016, 06:03:41 PM
Some of the rates usually depend on your FPS. Just sayin
You are correct and this is why the fps_max "125" command is included.
Right, if you want to play at 125 fps. Some people play at higher fps, are comfortable at a certain rate or maybe can't go as high....depends... I use 100 FPS and read that the cl_cmdrate should be +5 of your fps, so cl_cmdrate 105. Xheon linked me to this page a while ago and I haven't had a problem since:
http://www.tfcommunity.com/forums/topic/208-fixing-lag/
I know it's helped quiet a few people...w/e works tho. ;)
So I went through that last link and I saw another link that reads really well. I am going to post it http://myweb.tiscali.co.uk/millard1/Netcode%20Explained%20Again/members.westnet.com.au/wlloyd/netcode_explained_again.htm
If you want to be able to hand held conc at specific heights more consistently I recommend you download client side nade timer. As far as what the OP is suggesting, the only rates that really make a difference for concing are cl_cmdrate and cl_updaterate (higher is better), but even those settings don't compensate for lag/ping fluctuations. Client side nade timer = truth.
Quote from: ma on August 16, 2016, 02:06:57 PM
If you want to be able to hand held conc at specific heights more consistently I recommend you download client side nade timer. As far as what the OP is suggesting, the only rates that really make a difference for concing are cl_cmdrate and cl_updaterate (higher is better), but even those settings don't compensate for lag/ping fluctuations. Client side nade timer = truth.
I tried this one.
/ Lag Free - Primer - Press To Prime, Press Again To Throw
alias kgren1_throw "+gren1;spk mytimer;alias kgren1 kgren1_drop"
alias kgren1_drop "throwgren;alias kgren1 kgren1_throw"
alias kgren2_throw "+gren2;spk mytimer;alias kgren2 kgren2_drop"
alias kgren2_drop "throwgren;alias kgren2 kgren2_throw"
alias kgren1 kgren1_throw
alias kgren2 kgren2_throw
bind "key" "kgren1"
bind "key" "kgren2"
But I hate that I have to tap the key again twice after I conc jump even if the nade goes off, it´s annoying.
Do you know a diferent timer/config that solves this problem?
This is the "press to prime, press again to jump" timer btw, I have never used the "hold" timer.
fps_max 500 ez.
Hand Helds (hh) just takes practice and reasonably stable connection. A client side timer is a good idea if your ping is much over 100 ms or you have an unstable connection, but isn't necessary if you have a good connection. I don't use a client based timer and basically never fail hh's with a ping ~70. Your rate settings shouldn't matter that much as long as you haven't set something foolish, which requires a basic understanding of what these settings mean. I don't recommend blindly using someone else's settings, so I'll provide a few comments on what was suggested here to help explain what is going on so people can make an informed decision on their setup.
Quote from: Nuggs on March 29, 2016, 05:05:01 PM
rate 20000
rate sets the bytes/sec limit coming to your client from server (although the max setting is limited by server's sv_maxrate). This is needed with slower connections, but with modern broadband connections this can usually be set to the max allowed. The server will not send (choke) the packets needed to support your cl_updaterate if the rate setting is too low (or cl_updaterate is too high). A rate of 10000 should usually work fine but if you have a good connection you should use the maximum the server allows (25000 at BZ).
Quote from: Nuggs on March 29, 2016, 05:05:01 PM
fps_max "125"
The fps is one of the most important rate settings but is limited by computer hardware. Ironically this has very little to do with your actual frames per second, since most monitors only refresh at 60Hz. However, the Gold Source Half Life engine uses your fps in a way that effects (in a small but noticeable way) many other game features, such as, how many bullets you can fire/second, how much air acceleration you get from strafing, how much damage you take, how high you jump, ect. Some values are better than others depending on what you are looking to do; 125 is good but there are some better ones.
Quote from: Nuggs on March 29, 2016, 05:05:01 PM
fps_override "1"
This is needed to have an fps over 100...and it is hard to bhop effectively with fps less than 100. For fps >100 you must also need set gl_vsync 0 so that your fps isn't limited to your monitor's refresh rate.
Quote from: Nuggs on March 29, 2016, 05:05:01 PM
setinfo "ec" "1"
This just sets your class specific cfg files to run when you choose a class (e.g. medic.cfg, engineer.cfg, etc.) I like to have class specific cfgs but this has nothing to do with rates or hh.
Quote from: Nuggs on March 29, 2016, 05:05:01 PM
cl_backspeed "400"
This sets your max backwards speed which is usually limited to less than 400 by your class. cl_forwardspeed; cl_backspeed; cl_sidespeed should all be set to 400 (scout speed) unless you want to run slower than what is allowed by the class (some spy scripts do this to emulate slower classes). Again this setting has nothing to do with rates or hh.
Quote from: Nuggs on March 29, 2016, 05:05:01 PM
cl_cmdbackup "3"
This is the number of backup packets that are sent. 2 is the default and should be fine. 3 shouldn't hurt if you have the bandwidth to support it, but is probably unnecessary.
Quote from: Nuggs on March 29, 2016, 05:05:01 PM
cl_cmdrate "3000"
This is the packets/sec sent to server. You want this to be high enough so that packets are always sent to the server right away and not deferred. Setting cl_cmdrate to ~5-50 more than fps_max is optimum and you can verify or fine tune with net_graph 1 (red dots at the bottom of the net_graph represents deferred packets to server and is bad). A cmd rate of 3000 is unnecessarily high, but I don't think it should hurt for good internet connections.
Quote from: Nuggs on March 29, 2016, 05:05:01 PM
cl_dlmax "128"
I believe this relates to the fragment size of player decals that you download while playing the game. Keeping this small isn't necessary with modern broadband connections and the default setting of 512 should be fine.
Quote from: Nuggs on March 29, 2016, 05:05:01 PM
cl_timeout "35"
Sets how many seconds of inactivity will disconnect you. Not a relevant setting.
Quote from: Nuggs on March 29, 2016, 05:05:01 PM
cl_updaterate "70"
Packets/sec requested from server (unless limited by client's rate or server's sv_maxupdaterate or sys_ticrate). The server will not send (choke) the packets needed to support your cl_updaterate if the rate setting is too low (or cl_updaterate is too high). The max setting allowed by the BZ servers for cl_updaterate is 100, which I recommend.
Bishop, thanks for the technical breakdown! Very enlightening.
Would you mind posting your config? Curious to see what you have setup for optimal performance.
Yes, please give us the fps settings "Whoz Dat" uses as hwguy to shoot 1,000,000 bullets per second. :yes:
20fps toggled with +attack
http://www.fortress-forever.com/fpsreport/
Quote from: xheon on August 17, 2016, 05:57:36 PM
Yes, please give us the fps settings "Whoz Dat" uses as hwguy to shoot 1,000,000 bullets per second. :yes:
fps_max 99.5, fps_override 0
Quote from: Cirno on August 18, 2016, 01:22:30 AM
Quote from: xheon on August 17, 2016, 05:57:36 PM
Yes, please give us the fps settings "Whoz Dat" uses as hwguy to shoot 1,000,000 bullets per second. :yes:
fps_max 99.5, fps_override 0
Real or troll?
Quote from: xheon on August 18, 2016, 10:19:56 AM
Quote from: Cirno on August 18, 2016, 01:22:30 AM
Quote from: xheon on August 17, 2016, 05:57:36 PM
Yes, please give us the fps settings "Whoz Dat" uses as hwguy to shoot 1,000,000 bullets per second. :yes:
fps_max 99.5, fps_override 0
Real or troll?
why wouldnt it be real???
Quote from: Cirno on August 18, 2016, 07:48:36 PM
Quote from: xheon on August 18, 2016, 10:19:56 AM
Quote from: Cirno on August 18, 2016, 01:22:30 AM
Quote from: xheon on August 17, 2016, 05:57:36 PM
Yes, please give us the fps settings "Whoz Dat" uses as hwguy to shoot 1,000,000 bullets per second. :yes:
fps_max 99.5, fps_override 0
Real or troll?
why wouldnt it be real???
because everyone knows your eyes cant see over 60fps so its pointless to play at anything higher than that. Kappa
Quote from: xheon on August 16, 2016, 08:06:11 PM
Quote from: ma on August 16, 2016, 02:06:57 PM
If you want to be able to hand held conc at specific heights more consistently I recommend you download client side nade timer. As far as what the OP is suggesting, the only rates that really make a difference for concing are cl_cmdrate and cl_updaterate (higher is better), but even those settings don't compensate for lag/ping fluctuations. Client side nade timer = truth.
I tried this one.
/ Lag Free - Primer - Press To Prime, Press Again To Throw
alias kgren1_throw "+gren1;spk mytimer;alias kgren1 kgren1_drop"
alias kgren1_drop "throwgren;alias kgren1 kgren1_throw"
alias kgren2_throw "+gren2;spk mytimer;alias kgren2 kgren2_drop"
alias kgren2_drop "throwgren;alias kgren2 kgren2_throw"
alias kgren1 kgren1_throw
alias kgren2 kgren2_throw
bind "key" "kgren1"
bind "key" "kgren2"
But I hate that I have to tap the key again twice after I conc jump even if the nade goes off, it´s annoying.
Do you know a diferent timer/config that solves this problem?
This is the "press to prime, press again to jump" timer btw, I have never used the "hold" timer.
There's no way around that problem. If you stick with it long enough, you'll get better at remembering whether or not your released the previous conc or used it to hand held (so you know if the conc will prime on your next key press after you res pawn, etc.). It's a trade off.
Quote from: Nuggs on August 17, 2016, 04:35:39 PM
Bishop, thanks for the technical breakdown! Very enlightening.
Would you mind posting your config? Curious to see what you have setup for optimal performance.
Post up dem rates bruh
Quote from: Master on August 18, 2016, 10:28:06 PM
because everyone knows your eyes cant see over 60fps so its pointless to play at anything higher than that. Kappa
They do? Are you sure about that?
The reason the US uses 30 or 60fps and (most of) the rest of the world uses 25 or 50fps for their video update rates is their mains power frequencies (60Hz and 50Hz respectively, divided by 2 due to interlacing), which provided a simple and stable timebase for CRT displays (you know, those old ones, before LCD's ::) ). At around 25-30fps video starts to look "smooth" to your eyes; try watching video at 15fps and it looks quite jerky. I wonder how much of that 25-60Hz requirement is physiology and how much is psychology. :thinking:
The benefits of increasing the frame rate start to taper off for most purposes by 50-60fps, hence why most screens max out at one of those frequencies. You can buy modern TV's and monitors that are happy at up to at least 120fps, nominally for watching fast action sports, because your eyes can in fact see the higher rates, just normally when you're watching a newsreader or a cooking show they don't matter.
In any case, the game itself runs at higher rate than 60fps, and (afaik, although Bishop may have a definitive answer) the frames aren't synchronized per player, so 2 players may see very different sets of frames.
What I mean by this is, assume you have 2 players running at 60fps but the server running at 120fps (no I'm not sure that's the architecture, but this is an EXAMPLE). If the players aren't synchronized then they will each see a different set of frames (in this example, player 1 sees all the odd frames and player 2 sees all the even frames), but the frames that each individual doesn't see still have an impact on their gameplay experience.