Quake3World

Alright this is an odd question I guess.

I'm tempted to try out the logitech drivers for my MX510 mouse again. However, whenever I do my aim goes to shit. I do much better with the default windows drivers.

Whether this is down to practice or not I don't know, but someone mentioned that you get higher resolution on the optical sensor only if you're using the logi drivers. This sounds great, but then I thought that perhaps this might be the problem too? Either I can't get used to the higher resolution, or because I use a low sensitivity, perhaps the resolution of the mouse results in some sampling problems? Either in the mouse, the USB connection, or the drivers.

I dunno, I'm trying to figure this out because I'm convinced I can get more from my mouse input than I am already. Having said that, buying a mouse pad might be a start :icon32:

Stick it on a USB 2.0 port and you wont have bandwidth problems.

Yeah I figured I could rule out the bandwidth issue on the USB side at least with USB2. Even then, it raises questions over whether the USB2 port can still do 125hz sampling with that much data. The bandwidth limits of USB2 are great for a less time-critical application like moving data from a pendrive, but when you're using the same technology for time-dependant high frequency data input, I wonder what different factors come into it.

Foo wrote:someone mentioned that you get higher resolution on the optical sensor only if you're using the logi drivers.

This is correct. Without the drivers, Logitech mice operate at only half the resolution (the MX 518 is the exception to the rule, it has a hardware-based sensitivy adjuster). Mice only use about 1 KB/s so I doubt you're having bandwidth issues.

I got used to it, i'm playing at 800dpi on my mx1000

Well if you use the logi drivers and have enabled the higher dpi then you will most likely need to re-adjust your game sensitivity again. I use 1600dpi on my mx518 all the time anyway, I dunno, I have a really high sens in quake and can rail/shaft fine with it, and would rather keep it at 1600 at all times. If anything, the high dpi/sensitivity combo still lets me track the mouse really slowly when I want to and it still keeps a solid response.

You might also try raising the sampling rate to 500hz and see if it does anything for you.

http://fileforum.betanews.com/detail/US ... 05183690/1

And if you're using setpoint, theres a few options you have to play around with as well. If you untick "keep mouse acceleration" in setpoint, it will get rid of the winxp acceleration when a game starts up (in detect mode). If you uncheck "keep mouse speed" it will bypass the windows sensitivity (the one in mouse control panel where you adjust the notch speed). Then when you use quake it will only use the pure "game speed" /sensitivity setting instead of using both windows and the game setting. This also gets rid of negative mouse acceleration in games I think.

You can also try "setpoint implimintation" which I find is a little bit smoother in games, but again, I had to re-adjust the game sensitivity because with this enabled it was low in-game.

There's also in_mouse -1 in q3 (disables directx directmouse input) while it might free up neglible cpu cycles it feels a bit more responsive to me. cg_oversamplemouse 1 might also help (arq. said it should work in vq3 mods, it's built into cpma already though).

Hmmm I've noticed mouseware is the app for the mx510 mouse... so, you could try "mouserate advanced" which also has the option to "disable mouse speed and acceleration" just like in setpoint where it bypasses these features when you start a game.

http://www.princeton.edu/~pnelson/cfg/

I'm not sure, but are these options already built into the mouseware app? If they are, then you don't really have to use this app.

Thanks.

I've also been using a build of ioquake lately instead of quake3.exe (wherever viable). The new input method is really nice, and I'm hitting a lot of midair rockets/flick shots that I didn't before.

Hmm, link meh? This only works on non-pb?

btw, here is a decent writeup of negative mouse acceleration: http://www.xfire.be/?x=article&mode=item&id=49&nav=1

Now according to this guy using in_mouse -1 is the cuplrit (and prolly in other games that don't use directmouse input as well). I don't fully understand that. I've been using in_mouse -1 for a few years now and I don't really notice the effect he describes, so I dunno, take that as you will.

And you prolly know this, but eh, going from in_mouse -1 and in_mouse 1 will require you to adjust /sensitivity again (with in_mouse -1 you will probably have to drop it a bit).

There's just a few variables in place here and most of them will require the /sensitivity re-adjustment, so unless you do that, you might not like the outcome...

If you decide to raise to polling-rate, don't bother with 1000hz, it's overkill and at that setting you might notice some funky usb issues with your mouse or other devices...

dzjepp wrote:Hmm, link meh? This only works on non-pb?

http://tremulous.net/junk/ioquake3-r354.exe (courtesy of Timbo)

Only works on non-PB servers, yes.

Hey thanks.

So um, does that do anything else besides mess up my sound really bad? That is interesting though. Is that made in part of timbo and various other coders as a means to squash some bugs in relation to the q3 source? Is there a page anywhere with news and info of such project(s)? EDIT: I had the link to the coding forum, but don't remember it, but besides that forum are there any other info pages and such? And while at it link meh to that coding forum.

And while this relates to topic, do you know what cg_logitechbug does? I think I've seen a glance of this command while looking over the new bits in q3config.cfg the ioquake exe generated.

http://www.quakesrc.org/forums/viewforum.php?f=20 is where most of the Q3A developers hang out, http://icculus.org/quake3/ is the ioquake home page.

ioquake is more or less PR 1.33. Bugfixes, performance improvements, some general tweaks (fixed mouse input on Linux, for example) and support for more platforms/architectures.

Logitech drivers for Windows reportedly have a bug where they send mousewheel scroll events twice. in_logitechbug 1 deals with that by not processing the second event.

EDIT: I must add that the build you're using is actually rather old (release 354, the icculus SVN tree is currently at release 453). I'd build a more up-to-date version for you but I don't use Windows. You could try downloading the source and compiling it with MinGW.

set your sens to 3 with default windows sens.. same issue at first with me as well..

Thanks mis. Do you think the team could have any chance of collaborating with id or pb so the exe wouldn't be treated as a cheat and such? It'd be great if in the near future people can have a choice of what client they want to use like in quake 2. But pb looks to prevent all that.