"In case anyone might find it useful..."
a_civilian
Likes seeing numbers Join Date: 2003-01-08 Member: 12041Members, NS1 Playtester, Playtest Lead
Likes seeing numbers Join Date: 2003-01-08 Member: 12041Members, NS1 Playtester, Playtest Lead
<div class="IPBDescription">Miscellaneous NS research, copied from my CAL forum thread</div><strike>From <a href="http://forums.caleague.com/showthread.php?t=37395" target="_blank">this CAL forum thread</a>, copied here because the CAL forums are viewable by members only.</strike> <i>Edit: The CAL-NS forum no longer exists. I've also since added a number of entries.</i>
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Delays between attacks (inverse of rate of fire) at 100 fps, in seconds:<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->Light Machinegun: .060
Shotgun: .66
Heavy Machinegun: .060
Grenade Launcher: .61
Pistol (cap): .10
Mines: .50
Knife: .33
Skulk Bite: .40
Parasite: .25
Leap: .50
Spit: .40
Heal Spray: .80
Bile Bomb: .75
Web: .25
Lerk Bite: .32
Spores: 1.00
Umbra: .50
Swipe: .48
Metabolize: 1.45
Acid Rocket: .50
Gore: .45
Devour: 1.00
Stomp: .75<!--c2--></div><!--ec2-->
Should be accurate to within �1 to the last significant digit (�0.001 seconds for LMG and HMG, �0.01 seconds for all else). Also, note that there is no delay before the first attack.
Reload times, in seconds:<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->LMG: 3.00
Pistol: 3.00, 3.10 (magazine not empty, magazine empty)
Shotgun: 1.10+.47n
HMG: 6.30
GL: 2.20+1.10n<!--c2--></div><!--ec2-->
Should be accurate to within �0.01 seconds.
Both were measured using the wait command and the fact that at 100 fps (constant), each such command waits 0.01 seconds.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Weapon draw times, in seconds:<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->LMG: .40
Shotgun: .90
HMG: .60
GL: .30
Pistol: .35
Knife: .25
Welder: .55
Mines: .30
Grenade: .30
Skulk Bite: .10
Parasite: .10
Leap: ~0 (<.02)
Xenocide: .10
Spit: .10
Healspray: .10
Bilebomb: .10
Web: 1.00
Lerk Bite: .20
Spores: .60
Umbra: .10
Primal Scream: .60
Swipe: .10
Blink: .10
Metabolize: .10
Acid Rocket: .10
Gore: .50
Devour: .60
Stomp: .60
Charge: .60<!--c2--></div><!--ec2-->
Accurate to within �0.01 seconds.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Fall damage:
Fall damage is taken past 580 units/second, and is modeled by:
damage = 0.225v - 130
(vertical component of the velocity; downward is taken to be positive)<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Leap speed:
Leap adds 500 units of speed in the direction you're aiming.
If you're on the ground, it also jumps, adding vertical speed.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Marine bunnyhopping:
A marine can bunnyhop on landing if the vertical component of his velocity is less than his base speed.
Hence the height difference <i>h</i> needed to bunnyhop at base speed <i>v</i>, jump speed* <i>s</i>, and sv_gravity <i>g</i> is given by:
<i>h</i> = (<i>s</i>^2 - <i>v</i>^2)/(2<i>g</i>)
And conversely, the base speed <i>v</i> needed to bunnyhop on a height difference <i>h</i> with jump speed* <i>s</i> and sv_gravity <i>g</i> is given by:
<i>v</i> = sqrt(<i>s</i>^2 - 2<i>gh</i>)
*see entry on jump speed below<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Dependence of movement speed on framerate:
For the purposes of movement, the unit <i>time</i> varies with framerate. This causes variation in movement speed that does not show up on cl_showspeed, and is the reason for drastically lengthened jump durations at certain very high framerates.
Here is a <a href="http://img382.imageshack.us/my.php?image=timemultipliervsfps21io.jpg" target="_blank">plot of the factor by which the unit time is lengthened, against framerate</a>. Notable troughs are labeled (major troughs in red, minor troughs in orange); these are desirable framerates as they maximize speed (lower time multiplier is better).
(Major troughs, in text form, occur at framerates 20, 25, 27, 37, 40, 50, 62, 71, 83, 100, 111, 125, 142, 166; minor troughs at 30-33, 43, 45, 47, 52, 55, 58, 66, 76, 90)<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Dependence of attack rate on framerate:
The dependence of attack rate on framerate appears defined by the statement that there must be a constant integer number of frames between attacks at any framerate. The measured numbers of frames between attacks for each framerate value are shown below for selected weapons:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->LMG and HMG:
framerate frames/attack
20 1
21-38 2
39-58 3
59-76 4
77-90 5
91-111 6
112-125 7
126-142 8
143-166 9
167-? 10
pistol (cap):
framerate frames/attack
20-29 2
30-40 3
41-47 4
48-58 5
59-66 6
67-76 7
77-83 8
84-100 9
101 10
102-111 11
112-125 12
126-142 14
143-166 16
167-? 19
shotgun:
framerate frames/attack
20-21 14
22 15
23-24 16
25 17
26-27 18
... (I interpolate insignificant attack rate variation)
91-95 65
96-100 66
101 69
102-111 73
112-125 82
126-142 93
143-150 108
151-166 109
167-? 127
bitegun:
framerate frames/attack
20 8
21-22 9
23-25 10
26-27 11
28-29 12
30-32 13
... (as previously)
63-66 27
67-71 29
72-76 31
77-83 34
84-90 37
91-99 40
100 41
101-102 44
103-111 45
112-125 50
126-142 57
143-166 67<!--c2--></div><!--ec2-->
Obviously, the attack rate is maximized by setting the framerate to the highest value that preserves any given number of frames per attack (that is, the highest value in one of the given ranges).
The attack rate (in attacks/second) can be determined by dividing the framerate by the number of frames per attack.<!--QuoteEnd--></div><!--QuoteEEnd-->(the CAL forums formatted this last one nicely :( )
Addition, 3/1/07: Blink
----------------
Each attack of blink adds 225 units of speed. At 100 fps, blink fires every 0.06 seconds (6 frames). (This is in 3.2.)
Thus it takes 0.19 seconds* to reach maximum non-celerity horizontal speed (aiming between 0 and 36 degrees from the horizon) and 0.25 seconds to reach maximum celerity horizontal speed (aiming between 0 and 32 degrees from the horizon).
<!--sizeo:1--><span style="font-size:8pt;line-height:100%"><!--/sizeo-->* remember that the first attack fires instantly - that is, in one frame.<!--sizec--></span><!--/sizec-->
Blinking while standing on the ground also automatically jumps for an additional 268 units of speed upward.
----------------
Addition 2, 3/1/07: Jetpack
----------------
Jetpack vertical acceleration is modeled at 100 fps by a = 7.16s - 324 (in units/second^2), where s is the base run speed. (Note: This does not include the effect of gravity; to account for that, subtract 800.)
The dependence of this on framerate, as with gravity, is as the inverse of the <a href="http://img382.imageshack.us/my.php?image=timemultipliervsfps21io.jpg" target="_blank">time multiplier</a> with respect to speed or the inverse square of the time multiplier with respect to distance.
If a directional command is held while using the jetpack, 12 units of speed are added to the horizontal velocity <i>per frame, regardless of the framerate</i>.
The jetpack's vertical and horizontal thrusts are independent.
----------------
Addition, 3/9/07: Friction
----------------
At speeds above 100 units/second, the acceleration due to friction is -sv_friction*v (in units/second^2), where v is the horizontal velocity.
At nonzero speeds below 100 units/second, the acceleration due to friction is a constant 100*sv_friction units/second^2 opposite the direction of motion.
----------------
Addition 2, 3/9/07: Surface acceleration
----------------
The ground acceleration of every class is (base run speed)/(0.1 seconds). (Note this does not include the effects of friction.)
----------------
Addition, 5/21/07: Jump speed
----------------
Jump speed for every class is 268 units/second. However, HL seems to apply changes in velocity before changes in position, so one frame's worth of gravity is subtracted from the speed before you even leave the ground.
Therefore the correct formula for jump speed <i>v</i> is
<i>v</i> = 268 - sv_gravity/framerate
----------------
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Delays between attacks (inverse of rate of fire) at 100 fps, in seconds:<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->Light Machinegun: .060
Shotgun: .66
Heavy Machinegun: .060
Grenade Launcher: .61
Pistol (cap): .10
Mines: .50
Knife: .33
Skulk Bite: .40
Parasite: .25
Leap: .50
Spit: .40
Heal Spray: .80
Bile Bomb: .75
Web: .25
Lerk Bite: .32
Spores: 1.00
Umbra: .50
Swipe: .48
Metabolize: 1.45
Acid Rocket: .50
Gore: .45
Devour: 1.00
Stomp: .75<!--c2--></div><!--ec2-->
Should be accurate to within �1 to the last significant digit (�0.001 seconds for LMG and HMG, �0.01 seconds for all else). Also, note that there is no delay before the first attack.
Reload times, in seconds:<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->LMG: 3.00
Pistol: 3.00, 3.10 (magazine not empty, magazine empty)
Shotgun: 1.10+.47n
HMG: 6.30
GL: 2.20+1.10n<!--c2--></div><!--ec2-->
Should be accurate to within �0.01 seconds.
Both were measured using the wait command and the fact that at 100 fps (constant), each such command waits 0.01 seconds.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Weapon draw times, in seconds:<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->LMG: .40
Shotgun: .90
HMG: .60
GL: .30
Pistol: .35
Knife: .25
Welder: .55
Mines: .30
Grenade: .30
Skulk Bite: .10
Parasite: .10
Leap: ~0 (<.02)
Xenocide: .10
Spit: .10
Healspray: .10
Bilebomb: .10
Web: 1.00
Lerk Bite: .20
Spores: .60
Umbra: .10
Primal Scream: .60
Swipe: .10
Blink: .10
Metabolize: .10
Acid Rocket: .10
Gore: .50
Devour: .60
Stomp: .60
Charge: .60<!--c2--></div><!--ec2-->
Accurate to within �0.01 seconds.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Fall damage:
Fall damage is taken past 580 units/second, and is modeled by:
damage = 0.225v - 130
(vertical component of the velocity; downward is taken to be positive)<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Leap speed:
Leap adds 500 units of speed in the direction you're aiming.
If you're on the ground, it also jumps, adding vertical speed.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Marine bunnyhopping:
A marine can bunnyhop on landing if the vertical component of his velocity is less than his base speed.
Hence the height difference <i>h</i> needed to bunnyhop at base speed <i>v</i>, jump speed* <i>s</i>, and sv_gravity <i>g</i> is given by:
<i>h</i> = (<i>s</i>^2 - <i>v</i>^2)/(2<i>g</i>)
And conversely, the base speed <i>v</i> needed to bunnyhop on a height difference <i>h</i> with jump speed* <i>s</i> and sv_gravity <i>g</i> is given by:
<i>v</i> = sqrt(<i>s</i>^2 - 2<i>gh</i>)
*see entry on jump speed below<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Dependence of movement speed on framerate:
For the purposes of movement, the unit <i>time</i> varies with framerate. This causes variation in movement speed that does not show up on cl_showspeed, and is the reason for drastically lengthened jump durations at certain very high framerates.
Here is a <a href="http://img382.imageshack.us/my.php?image=timemultipliervsfps21io.jpg" target="_blank">plot of the factor by which the unit time is lengthened, against framerate</a>. Notable troughs are labeled (major troughs in red, minor troughs in orange); these are desirable framerates as they maximize speed (lower time multiplier is better).
(Major troughs, in text form, occur at framerates 20, 25, 27, 37, 40, 50, 62, 71, 83, 100, 111, 125, 142, 166; minor troughs at 30-33, 43, 45, 47, 52, 55, 58, 66, 76, 90)<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Dependence of attack rate on framerate:
The dependence of attack rate on framerate appears defined by the statement that there must be a constant integer number of frames between attacks at any framerate. The measured numbers of frames between attacks for each framerate value are shown below for selected weapons:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->LMG and HMG:
framerate frames/attack
20 1
21-38 2
39-58 3
59-76 4
77-90 5
91-111 6
112-125 7
126-142 8
143-166 9
167-? 10
pistol (cap):
framerate frames/attack
20-29 2
30-40 3
41-47 4
48-58 5
59-66 6
67-76 7
77-83 8
84-100 9
101 10
102-111 11
112-125 12
126-142 14
143-166 16
167-? 19
shotgun:
framerate frames/attack
20-21 14
22 15
23-24 16
25 17
26-27 18
... (I interpolate insignificant attack rate variation)
91-95 65
96-100 66
101 69
102-111 73
112-125 82
126-142 93
143-150 108
151-166 109
167-? 127
bitegun:
framerate frames/attack
20 8
21-22 9
23-25 10
26-27 11
28-29 12
30-32 13
... (as previously)
63-66 27
67-71 29
72-76 31
77-83 34
84-90 37
91-99 40
100 41
101-102 44
103-111 45
112-125 50
126-142 57
143-166 67<!--c2--></div><!--ec2-->
Obviously, the attack rate is maximized by setting the framerate to the highest value that preserves any given number of frames per attack (that is, the highest value in one of the given ranges).
The attack rate (in attacks/second) can be determined by dividing the framerate by the number of frames per attack.<!--QuoteEnd--></div><!--QuoteEEnd-->(the CAL forums formatted this last one nicely :( )
Addition, 3/1/07: Blink
----------------
Each attack of blink adds 225 units of speed. At 100 fps, blink fires every 0.06 seconds (6 frames). (This is in 3.2.)
Thus it takes 0.19 seconds* to reach maximum non-celerity horizontal speed (aiming between 0 and 36 degrees from the horizon) and 0.25 seconds to reach maximum celerity horizontal speed (aiming between 0 and 32 degrees from the horizon).
<!--sizeo:1--><span style="font-size:8pt;line-height:100%"><!--/sizeo-->* remember that the first attack fires instantly - that is, in one frame.<!--sizec--></span><!--/sizec-->
Blinking while standing on the ground also automatically jumps for an additional 268 units of speed upward.
----------------
Addition 2, 3/1/07: Jetpack
----------------
Jetpack vertical acceleration is modeled at 100 fps by a = 7.16s - 324 (in units/second^2), where s is the base run speed. (Note: This does not include the effect of gravity; to account for that, subtract 800.)
The dependence of this on framerate, as with gravity, is as the inverse of the <a href="http://img382.imageshack.us/my.php?image=timemultipliervsfps21io.jpg" target="_blank">time multiplier</a> with respect to speed or the inverse square of the time multiplier with respect to distance.
If a directional command is held while using the jetpack, 12 units of speed are added to the horizontal velocity <i>per frame, regardless of the framerate</i>.
The jetpack's vertical and horizontal thrusts are independent.
----------------
Addition, 3/9/07: Friction
----------------
At speeds above 100 units/second, the acceleration due to friction is -sv_friction*v (in units/second^2), where v is the horizontal velocity.
At nonzero speeds below 100 units/second, the acceleration due to friction is a constant 100*sv_friction units/second^2 opposite the direction of motion.
----------------
Addition 2, 3/9/07: Surface acceleration
----------------
The ground acceleration of every class is (base run speed)/(0.1 seconds). (Note this does not include the effects of friction.)
----------------
Addition, 5/21/07: Jump speed
----------------
Jump speed for every class is 268 units/second. However, HL seems to apply changes in velocity before changes in position, so one frame's worth of gravity is subtracted from the speed before you even leave the ground.
Therefore the correct formula for jump speed <i>v</i> is
<i>v</i> = 268 - sv_gravity/framerate
----------------
Comments
also, what about framerates in the high 500's? i dont mean to brag, but i regularly get 400+ fps on combat maps and 300+ on classic. how would this impact my play?
So, way i read this, higher framerates would cause you to fire slower?<!--QuoteEnd--></div><!--QuoteEEnd-->
It actually looks something like <a href="http://img237.imageshack.us/img237/7928/lmgrofal1.gif" target="_blank">this</a>.
<!--quoteo(post=1565781:date=Aug 23 2006, 09:39 AM:name=todd1Ok)--><div class='quotetop'>QUOTE(todd1Ok @ Aug 23 2006, 09:39 AM) [snapback]1565781[/snapback]</div><div class='quotemain'><!--quotec-->also, what about framerates in the high 500's? i dont mean to brag, but i regularly get 400+ fps on combat maps and 300+ on classic. how would this impact my play?<!--QuoteEnd--></div><!--QuoteEEnd-->
I can't answer that, unfortunately, as my computer can't go anywhere near that high and I can't discern any clear pattern from which to extrapolate.
sooo, basically fps_max 60 would be the most benefical setting for maximizing your shots per second?
<!--QuoteEnd--></div><!--QuoteEEnd-->
That's 58. And 20 gives a higher attack rate - see the single point above 20 fps.
<!--quoteo(post=1565787:date=Aug 23 2006, 12:04 PM:name=Golden)--><div class='quotetop'>QUOTE(Golden @ Aug 23 2006, 12:04 PM) [snapback]1565787[/snapback]</div><div class='quotemain'><!--quotec-->
Actually, its either 75 or 77, think its 77. One of my clan memebers uses fps_max of 77 while playing. At the start of his jump script he has his fps_max go to I think 200 and back to 77 at the end. This allows him to fire at max speed and his jumps fire faster allowing for less of a speed loss when bunnyhopping.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Are you sure it's not 76? 77, in my measurements, gave a significantly lower attack rate (it is one of the troughs).
---
Edit: similar plot of the pistol's attack rate is <a href="http://img98.imageshack.us/img98/6317/pistolrofkj2.gif" target="_blank">here</a>.
So basically, a good compromise for having decent fps, decent bhopping (time multiplier) and lmg rof would be 111 fps?
Hmmm, apparently i have to play in "developer 1" or i seem to be capped at 100 fps even with v-sync off. And HL seems to reset to dev 0 randomly when i play?! May need to bind a key to re-reset it to 1 easily while playing.
Another question; when i set fps_max to 111, i'm capped at 110 fps (or so cl_showfps tells me). Setting fps_max to 112 seems to do the trick (capped at 111 then), is that the exact setting i have to use? Or do i have to set it at 111 regardless of what cl_showfps and r_speeds 1 tells me?
H4x! <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
Interesting research though, and certainly worth (if a bit dry) reading.
- Shockwave
Try it yourself, try jetpacking with 100 fps then with 200fps+, and you'll notice a different behavior with the jatpack
With the knife, or skulk bite, i clearly felt a <i>negative</i> effect (it's a bit slower, it seems). About the lmg rof, honestly, i felt no change. It probably does, but compared to 100 fps it's so minimal it feels the same to me. Ideally, we would need a graph for each weapon so we could load a .cfg for each class (marine, skulk, lerk, fade, etc...) with optimal settings, for testing purpose.
About bhopping, the only thing i noticed is that i may need to add one more "wait" in my script, nothing else <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
Then again, i'm judging from what i see client-side. How the server interpret this i've no idea.
also, what about framerates in the high 500's? i dont mean to brag, but i regularly get 400+ fps on combat maps and 300+ on classic. how would this impact my play?
<!--QuoteEnd--></div><!--QuoteEEnd-->
That is not at all unusual considering the age of the half life engine, one thing you should note is that you can not see more frames than your monitors refresh rate, some people believe having a higher frame rate still makes gameplay seem "smoother" even when your monitor isn't displaying the frames and I would suggest its the above type of effects which lead to this.
Or is it just another HL1 engine quirk?
I thought this stuff was fixed in the 3.0final/3.1 patch? (I remember the dev team talking about fixing it)
Or is it just another HL1 engine quirk?
<!--QuoteEnd--></div><!--QuoteEEnd-->
It is the HL engine. It occurs in other HL mods too.
It is the HL engine. It occurs in other HL mods too.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Good ole HL engine.
i may not be the best player in the game, and maybe its because this stuff eludes me, but i enjoy simply playing the game using most of the regular settings. going throught the console and cfg files simply doesnt entice me.
personally, i think this stuff should all be server-side... this is probably half the reason servers are so laggy all the time, people's rates are constantly so out of whack with each other, but, again, what do i know?
@ Krimson: You're not missing much by not understanding this stuff... As was said, it's just another quirk of the aging HL engine... which IIRC is basically an updated quake based engine...
There's no real way to regulate a players video frame rate via server side. It would add just another thing that would have to be communicated between the 16+ players and the server at all times... The ROF and Movement items would be possible to add into the packets... but it would add a number of calculations to the server that it really shouldn't have to deal with, especially since they're not going to get rid of the bunny-hopping "glitch" in NS. (It's a glitch for everyone else... but eh.)
why is it that this information completely goes over my head?
i may not be the best player in the game, and maybe its because this stuff eludes me, but i enjoy simply playing the game using most of the regular settings. going throught the console and cfg files simply doesnt entice me.
personally, i think this stuff should all be server-side... this is probably half the reason servers are so laggy all the time, people's rates are constantly so out of whack with each other, but, again, what do i know?
<!--QuoteEnd--></div><!--QuoteEEnd-->
So do I; ive never touched my rate's or anything like that; but "Pro" player's like to perfect there game to the Tee i guess...
So do I; ive never touched my rate's or anything like that; but "Pro" player's like to perfect there game to the Tee i guess...
<!--QuoteEnd--></div><!--QuoteEEnd-->
Well at least rate, cl_rate, cl_updaterate and cl_cmdrate should be tweaked by everybody...
why is it that this information completely goes over my head?
i may not be the best player in the game, and maybe its because this stuff eludes me, but i enjoy simply playing the game using most of the regular settings. going throught the console and cfg files simply doesnt entice me.
personally, i think this stuff should all be server-side... this is probably half the reason servers are so laggy all the time, people's rates are constantly so out of whack with each other, but, again, what do i know?
<!--QuoteEnd--></div><!--QuoteEEnd-->
Nothing, apparently.
why is it that this information completely goes over my head?
i may not be the best player in the game, and maybe its because this stuff eludes me, but i enjoy simply playing the game using most of the regular settings. going throught the console and cfg files simply doesnt entice me.
personally, i think this stuff should all be server-side... this is probably half the reason servers are so laggy all the time, people's rates are constantly so out of whack with each other, but, again, what do i know?
<!--QuoteEnd--></div><!--QuoteEEnd-->
Well it actually should be limited by the server.
If I recall correctly your high fps only matters if the server does process them.
So if the server does process a maximum of 60 fps (there are console commands to set this limit) then you can get 600fps client side, but yet the whole engine treats you as if you were getting 60 fps. This is also the reason why you can experience server lags. Even if you are getting 600 fps your game will look sloppy when the server only calculates 20 fps due to too much entinitys.
I am not sure, how listen servers are handling this issue, but I am assuming that the max server fps is dynamically changing with the actuall fps it displays on the listen server. This would explain why you can meassure the difference when making a listen server, but when joining a dedicated one you wont get any advantage/disadvantage out of your 600 fps, unless the server processes that much.
That is not at all unusual considering the age of the half life engine, one thing you should note is that you can not see more frames than your monitors refresh rate, some people believe having a higher frame rate still makes gameplay seem "smoother" even when your monitor isn't displaying the frames and I would suggest its the above type of effects which lead to this.
<!--QuoteEnd--></div><!--QuoteEEnd-->
i dunno but playing with 85 fps which is my monitor refresh rate makes my eyes bleed and gives me a headache
I've got a few questions on this, this is a hl engine gimmick and useable by anyone, but I can't get my fps higher the 75 atm (probably vsync to turn off)
With a geforce 6700 I should be able to reach at least 300 fps, right? and since my monitor sucks at 75 Hz a sec I get a 4x multiplier which is good also.
I wonder.