Saw your cleanup, and your note at the top. Pretty sure it's 450 dpi. 800 dpi would be too high for what we saw from behind the man at quakecon (mouse movement to screen movement).
As a note, kinzu v1 at 450 dpi = 560 dpi measured.
All you have to do is find the vods that have his viewpoint from behind his chair, where you can see his mouse and screen.
You can then set different sensitivities in your own quake game and see how different "swipe lengths vs screen movement" match up to his "swipe lengths vs screen movement", until you find a sensitivity that matches his.
I haven't done such a thing, but you can, and it would be interesting to see what you find :)
I do that sometimes, usually I dont need to and can tell if a player hs high low sens etc. Ýn evil's case I think the kinzu's accel itself gives him the fast flicky aiming style than.
Well if you know someone with a kinzu, you can just have them set it to 400 dpi and figure out what the cm/360 is for a sensitivity of 2.4. We can work backwards from there to guess the dpi +/- acceleration factor.
I haven't been able to find the damned thing in a long time, the original test.
What I recall was that the measured dpi for 800 dpi was accurate, but the measured dpi for 400 dpi was not accurate and was about 560, so looking at those two measurements gives you an idea that they took into acceleration at some level.
I feel like I'm going crazy here trying to find this information.
For a mouse to have built-in accel though, it _must_ either miss counts, or add counts that it shouldn't. Therefore the counts per inch would have to vary depending on the speed. Hence my concern over the speed being considered in the measurements.
maybe a dumb question but how did you manage to clean up the cfg to even the commands being smallest to largest? hopefully you didn't type that all out?
I also have the vast majority of the cvars memorized and what they do, so I know what to take out, what's ineffectual or irrelevant. I also know the default values of the majority of the cvars.
I left a lot of default cvars in that config in case people don't know they're defaults.
Like if I see a config and it has no r_mapOverBrightBits cvar listed, to me that means that it is set to 2 since 2 is the default value. As long as someone resets defaults via the website unlisted cvars will be default. That's how I got my own config to be so short.
"I'll think I'll go with bst's mouse. Still at beta stage, but I really like the shape. Only been using it for a couple of days in an intensive way, and I'm really happy with it."
I changed my sens and accel some because I used to use in_mouse 2 but I changed this year to in_mouse -1. So I altered the sens and accel to fit something that I like.
what made you change it? I've seen people switching away from it in Source based games because it got delayed/worse with some updates there, but raw input is totally fine in QL, at least I haven't really seen anyone having problems whereas -1 is kinda OS/registry specific
I figured hey I'd give it a shot to try what I used to use back around 2009 before there even was an in_mouse 2 to see if I didn't have as many issues with sens changing. I still have the problem but it happens less frequently now that I use in_mouse -1.
Are you sure it may not be related to the way you aim with your mouse (arm on table)? I tried your style of aiming a long time ago and the cursor would always point up if i tried to swipe it very far and fast whereas this issue is almost non-existent with the normal way of aiming (wrist/mid-arm on table). I found your style of aiming was subjected to a lot of unintentional mouse tilting.
It's not just high picmip. Set r_texturemode to a specific value (dont remember) and it really looks like it's made of lego bricks. http://www.foopics.com/showfull/0d417bc84294136454fdb483825a8cc4
Screenshot is from warsow I think, but it's similar for QL.
Wow, VJ's config is nuts. So many nonsensical/surprising things. Some examples:
r_texturebits "64"
..then:
r_texturebits "32"
..then:
r_texturebits "32"
Pitch is half of yaw, sometimes less than half because yaw changes depending on the weapon. I figure this is a kinzu v1 acceleration thing, because I think this is likely to make rocket jumping overly difficult otherwise.
Some weapons feature a change in r_texturemode, not just from linear_mipmap to nearest, but from linear_mipmap to linear as well. Also this is with simpleMipMaps 0 which I suspect will amplify the differences a bit.
Weapons also feature changes to autoTimeNudge, as well as a bunch of other things, most of them typical.
F12 is bound to "vstr nomouse". There is no entry for 'nomouse'.
Of course it also features the typical level of junk found in a lot of configs but that's nothing special.
Its funny that we wrote almost the same thing about the config. I changed one thing tho. I use gl_nearest on shaft. I still want the soild square xhair but keep the sharp lightninggun if you know what i mean :)
I also have the crosshair still displayed, it's just that the hud covers it so that when spectating or following another player when the hud crosshair disappears, I still have a crosshair, it's just the older one with the roundish edges. No biggie.
Just exec,vid_restart,look at it and reproduce in a clean fashion. Just stupid to use a cfg and only change sens etc cause there is so much more to it. You wont get their feeling if you dont have the exact same setup anyway. Use your lovely linkin-cfg and just change xhairs,fovs,gfx etc etc untill it looks like for example,evils.
Nothing should be to easy :P
Edit: mine looks like viju's now. I feel his config was the most inspiring to me with the texturemode changes and all the weird stuff. Not to mention the insanly low m_pitch (imo thats what people like me need) i have a terrible rocket and this helped :D
O
O
T
.
C
F
G