http://www.splashdamage.com/index.php?n ... ic&t=11397
Can anyone tell me if it's just a client side glitch? Does the client send over the
aimSpread value? Does PM_AdjustAimSpreadScale() get called more frequently on
the server for clients with higher fps?
The only ways I can test it are by running a local server (dedicated 1) with
some debugging code in bg_pmove and bulletfire() and by recording a demo on some
internet server.
A local server is a problem since it will see that the client is connecting from localhost,
and even though the problem shows up in a recorded demo I can't be sure if that's
what the server is seeing.
I had assumed that a demo is more or less just a dump of the network packets coming
into the client, or do demos also contain the information the client is sending?
aim spread and fps
Moderators: Forum moderators, developers
...atleast for others LOL ).I can confirm the behaviour you described in the other thread, very interesting finding. 
Inside a room where I reached about 200 fps, it became very significant. However, only after I had turned down the USB poll rate from 250 to 125 Hz. In that case, spread really seems to be almost absent (if one can trust the pulsing crosshair animation, which I suppose we can, at least for comparing similar situations).
With a poll rate of 250 Hz though, there seems to be no clearly visible difference in terms of crosshair pulsing between 43, 125, or uncapped (i.e. ~200) fps.
This fits in with the explanation you gave on the other thread, only when you have your com_maxfps much higher than the mouse report rate, you will notice this drastic decrease of spread, right?
Since only people with higher fps than mouse rate strongly profit from this, I guess the impact it has (on competition) is not huge. USB is 125 Hz normally and many players have tweaked it to 250(+); PS/2 is 60(?) usually, but that just feels too rough and so I guess most people prefer to have it at the maximum possible, 200 Hz.
But of course it should be fixed for a level playing field. After all, it's probably hard to quantify how much % spread reduction a certain ratio gives you, and that might still be significant.
I'm not entirely sure, but I think it doesn't work the other way around...? At least I didn't feel like spread was much higher when I tested 43 or even 20 fps / 250 Hz compared to when I tested 43 fps / 125 Hz. Could there be an upper limit? (Yes, I know, I should check the source code...
)
Inside a room where I reached about 200 fps, it became very significant. However, only after I had turned down the USB poll rate from 250 to 125 Hz. In that case, spread really seems to be almost absent (if one can trust the pulsing crosshair animation, which I suppose we can, at least for comparing similar situations).With a poll rate of 250 Hz though, there seems to be no clearly visible difference in terms of crosshair pulsing between 43, 125, or uncapped (i.e. ~200) fps.
This fits in with the explanation you gave on the other thread, only when you have your com_maxfps much higher than the mouse report rate, you will notice this drastic decrease of spread, right?
Since only people with higher fps than mouse rate strongly profit from this, I guess the impact it has (on competition) is not huge. USB is 125 Hz normally and many players have tweaked it to 250(+); PS/2 is 60(?) usually, but that just feels too rough and so I guess most people prefer to have it at the maximum possible, 200 Hz.
But of course it should be fixed for a level playing field. After all, it's probably hard to quantify how much % spread reduction a certain ratio gives you, and that might still be significant.
I'm not entirely sure, but I think it doesn't work the other way around...? At least I didn't feel like spread was much higher when I tested 43 or even 20 fps / 250 Hz compared to when I tested 43 fps / 125 Hz. Could there be an upper limit? (Yes, I know, I should check the source code...
)
Having your mouse right higher than your FPS be the same as having it equal, since the game will only sample your mouse every frame.
If your mouse rate is less than your FPS, it will still sample every frame, but a certain number of samples will be the same. Thus, if you are doing a steady turn, instead of getting
<turn><turn><turn> you will get <turn><no turn><big turn>
It isn't completely clear to me (without putting in a bunch of debugging printfs) how this will work to final spread. The total amount of mouse movement will be the same, but the amout your spread can grow to is capped, so if the small turns are reaching that cap, then the big turns wouldn't give you additional spread, and you would have spread recovery in the frames when there wasn't new mouse input available.
aLinuxUser:
You can run a local dedicated server, and not connect via localhost. This should be the same as an internet server, except that because of LAN detection, your maxpackets will be ignored (one packet per frame, no matter what your FPS), and some other stuff if the server doesn't have sv_lanforcerate 0.
pmove on the server should be run once per client command, which isn't exactly the same as once per client frame.
If your mouse rate is less than your FPS, it will still sample every frame, but a certain number of samples will be the same. Thus, if you are doing a steady turn, instead of getting
<turn><turn><turn> you will get <turn><no turn><big turn>
It isn't completely clear to me (without putting in a bunch of debugging printfs) how this will work to final spread. The total amount of mouse movement will be the same, but the amout your spread can grow to is capped, so if the small turns are reaching that cap, then the big turns wouldn't give you additional spread, and you would have spread recovery in the frames when there wasn't new mouse input available.
aLinuxUser:
You can run a local dedicated server, and not connect via localhost. This should be the same as an internet server, except that because of LAN detection, your maxpackets will be ignored (one packet per frame, no matter what your FPS), and some other stuff if the server doesn't have sv_lanforcerate 0.
pmove on the server should be run once per client command, which isn't exactly the same as once per client frame.
send lawyers, guns and money
This change to PM_AdjustAimSpreadScale() :
Local server:
./etded.x86 +dedicated 1 +set sv_lanforcerate 0 +set sv_pure 0 +set g_gametype 2
+set sv_fps 20 +set sv_punkbuster 0 +set fs_game fps +map oasis
Tried sv_lanforcerate 1 and dedicated 2
Local client:
et +set fs_game fps +set r_mode 3 +set r_fullscreen 0 +connect 127.0.0.1:27960
For +connect tried my local lan address, 192.168.1.50:27960, and also the IP number
assigned by the cable company.
125 fps on the client makes the server console spam 8,9,8,9,8,8,8, etc..
43 fps ... 23,24,23,24, etc ...
Code: Select all
--- bg_pmove.c 2003-08-28 15:43:22.000000000 -0500
+++ bg_pmove.c 2005-04-04 16:47:00.000000000 -0500
@@ -2976,6 +2976,10 @@
float increase, decrease; // (SA) was losing lots of precision on slower weapons (scoped)
float viewchange, cmdTime, wpnScale;
+#ifdef GAMEDLL
+ G_Printf ("%d\n", pm->cmd.serverTime - pm->oldcmd.serverTime);
+#endif
+
// all weapons are very inaccurate in zoomed mode
if(pm->ps->eFlags & EF_ZOOMING) {
./etded.x86 +dedicated 1 +set sv_lanforcerate 0 +set sv_pure 0 +set g_gametype 2
+set sv_fps 20 +set sv_punkbuster 0 +set fs_game fps +map oasis
Tried sv_lanforcerate 1 and dedicated 2
Local client:
et +set fs_game fps +set r_mode 3 +set r_fullscreen 0 +connect 127.0.0.1:27960
For +connect tried my local lan address, 192.168.1.50:27960, and also the IP number
assigned by the cable company.
125 fps on the client makes the server console spam 8,9,8,9,8,8,8, etc..
43 fps ... 23,24,23,24, etc ...
Thats the result I would expect.
you most likely want sv_lanforcerate 0 (i.e. do NOT force rate if LAN is detected). However, your client will still 'detect' a LAN connection, and simply send one packet per frame, regardless of your cl_maxpackets setting. It even seems to ignore the normal hard coded 100 cl_maxpacket limit.
2.6 may fix some of this.
All of this of course is only vaguely related to the question about spread, but you do need to keep it in mind while testing.
you most likely want sv_lanforcerate 0 (i.e. do NOT force rate if LAN is detected). However, your client will still 'detect' a LAN connection, and simply send one packet per frame, regardless of your cl_maxpackets setting. It even seems to ignore the normal hard coded 100 cl_maxpacket limit.
2.6 may fix some of this.
All of this of course is only vaguely related to the question about spread, but you do need to keep it in mind while testing.
send lawyers, guns and money
I guess a better way of putting it might have been "frequency of calls to PM_AdjustAimSpreadScale() with respect to mouse rate" as opposed to fps and mouse
rate.
It doesn't necessarily have to be high fps triggering the problem, just anything that affects the number of times PM_AdjustAimSpreadScale() is called, maybe even network settings.
rate.
It doesn't necessarily have to be high fps triggering the problem, just anything that affects the number of times PM_AdjustAimSpreadScale() is called, maybe even network settings.
good stuff. i recently went back to the 125hz mouse rate and setup an "fps-is-god" config, uncapped fps, and tried to see if there was anything noticeable. went in some small rooms and managed to pass 400 fps - but i couldn't tell, tbh. all i know is that having the mouserate hacked up to 500 or 1000 DOES feel a hell of a lot smoother - in both windows and games. you can even see how it moves more smoothly.
dunno if i could stand going back to 125 even to benefit from this "exploit".
i'm still very interested in this though. please keep posting whatever you guys discover
dunno if i could stand going back to 125 even to benefit from this "exploit".
i'm still very interested in this though. please keep posting whatever you guys discover
Please direct all gameplay-changing feature requests here.
That fps-relation is surely true. But there is more than usb-rate and fps-rate that will pack the whole system together. One thing is that not all USB2.0-protocol "cards" or integrated USB-ports are like they should be according to standards..
And it's good to remeber that 250Hz means that the "state" of the sampled signal is infact 500 different "states" per sec...based on that theres no reason to increase the usb-sample rate to 500Hz (infact). The 250Hz "tweak" is more than enough for games...even if it "feels good" to have 500Hz or even 1000Hz (that is way too much if thinking PC-machine..).
P.S. If measurements are taken they can NOT be taken with some software ...only external devices give the nearest result. Datastream saved from prog is rather close but not "right"...
Hard to explain...the whole thing would demand kinda LOT of writing...infact too much...
And it's good to remeber that 250Hz means that the "state" of the sampled signal is infact 500 different "states" per sec...based on that theres no reason to increase the usb-sample rate to 500Hz (infact). The 250Hz "tweak" is more than enough for games...even if it "feels good" to have 500Hz or even 1000Hz (that is way too much if thinking PC-machine..).
P.S. If measurements are taken they can NOT be taken with some software ...only external devices give the nearest result. Datastream saved from prog is rather close but not "right"...
Hard to explain...the whole thing would demand kinda LOT of writing...infact too much...
*bump*
i just tested this again and was able to reproduce it this time. i'm now convinced it is real.
with my usb port at 1000hz, i got the same (normal) crosshair spread at 43, 76, 125, 333 fps. with my usb port at 125hz, i got almost no spreading at 333 fps.
so basically, people with superior hardware are able to have less bullet spread. this needs to be treated as a critical flaw and fixed asap imo.
i just tested this again and was able to reproduce it this time. i'm now convinced it is real.
with my usb port at 1000hz, i got the same (normal) crosshair spread at 43, 76, 125, 333 fps. with my usb port at 125hz, i got almost no spreading at 333 fps.
so basically, people with superior hardware are able to have less bullet spread. this needs to be treated as a critical flaw and fixed asap imo.
here is the usb port patcher: http://www.shitstormfiles.com/utilities/usbmrs11.exe
here is a mouserate tester: http://billegal.org/files/mouserate.exe
what prompted me to retest this was a demo i found on your webspace, i believe. pardon my snooping, lol. it's a demo of someone demonstrating crosshair spread at 125 and 200 fps.
on a small enclosed map like fapractice, i am able to hit the fps "limit" (666). anything above 400-500 though and i can barely move. also, my mouse (mx500) is able to reach and even slightly pass 1000hz. and like i said, the mouserate was the thing that allowed me to nearly eliminate spread (at the default 125hz & 333fps).
in reality i doubt many people could maintain 333 in a match of 6v6 or more. and patching the usb port is pretty popular, i doubt many would intentionally go back to 125, or even ps/2 @ 100, just to benefit from this. but it's still a flaw.
PS crosshair spread when shooting remained in effect regardless.
here is a mouserate tester: http://billegal.org/files/mouserate.exe
what prompted me to retest this was a demo i found on your webspace, i believe. pardon my snooping, lol. it's a demo of someone demonstrating crosshair spread at 125 and 200 fps.
on a small enclosed map like fapractice, i am able to hit the fps "limit" (666). anything above 400-500 though and i can barely move. also, my mouse (mx500) is able to reach and even slightly pass 1000hz. and like i said, the mouserate was the thing that allowed me to nearly eliminate spread (at the default 125hz & 333fps).
in reality i doubt many people could maintain 333 in a match of 6v6 or more. and patching the usb port is pretty popular, i doubt many would intentionally go back to 125, or even ps/2 @ 100, just to benefit from this. but it's still a flaw.
PS crosshair spread when shooting remained in effect regardless.