[GlaD-Solitary]

Something I've noticed is that mouse1 doesn't register at times in game. Doesn't seem like this raw input for mouse buttons is working all that well.

[mitsubishi]

press it harder:P

j/k. Dunno, if anyone sees that happening let us now. I've spammed a lot lately with it and it never failed.

--

Don't do the crime to use the 1st version of it. It was fixed the same day.

This post has been edited by mitsubishi: 24 July 2010 - 03:01 AM

[p5yc0runn3r]

mitsubishi, on 23 July 2010 - 06:09 PM, said:

ok this update took way more time to do than it deserves due to its relative uselessness unless you're testing something one-off but here it is anyway (I was almost ready to delete it:P)



as usually,
/cl_drawmouse 1 //see it (it requires a map loaded)
/cl_drawmouseinterval 0.08 //interval it waits to calculate
/cl_drawmouseposx //pos x on screem
/cl_drawmouseposy //
/cl_drawmousesize 7 //font size

(updates/sec, dots/sec, total dots for an interval and max dots)

--

It's basically a 'mouse stats meter'. It works on raw as source or if on non-raw whatever sdl sends (something particular on unix, either mousemove or directx on windows depended on in_mouse).

--

also, cleaner console, safer and more informative rawmouse, fixed stats meters to work properly on timescale (unlike cg_drawfps:P).

Mitsu!, 80ms is too much for mouse update :(

[mitsubishi]

That's just the number for the meter to not be very erratic like the source number on top. e.g. the q3 fps meter had a 3 frame delay to be smoother, the top left number on my meter was without any delay to be more accurate:P though if it didn't have the interval versions it wouldn't look good on its own.
--
PS. the nabs at id software had timescale borking their fps meter:)
--
i.e. internally the mouse updates are actually done collected each frame, obviously, for intends of the gameplay.
--
you can change the meter interval [with a var listed above]. It can even be 0. It's also for collecting data for intervals.
--
This meter is near pointless. Well, you could at least say it proves collection is done properly, since its collecting variables are at the same place with the vars used by gameplay.
--
Still near pointless.

This post has been edited by mitsubishi: 24 July 2010 - 02:40 PM

[n4n3rz]

is there any kind of software to measure/determine the frequency at which mouse1 is pressed?
e.g. 180 clicks/minute or something

[mitsubishi]

that's a good idea for a meter that could be done in the game but it's probably an overkill.

it's also doable externally with an OS utility.

[blizakster]

mitsubishi, on 20 July 2010 - 05:01 PM, said:

ioq3-urt updated with a more "live" version of in_rawmouse. One can now do /in_rawmouse 0 and 1 during a run with no in_restart etc. needed. It's also a bit smarter internally, disabling windows' raw device when not needed which might have minimal advantages.

Notice the functionality is generally "live", i.e. in the middle of the game it does take effect (to go from raw to non-raw and back) immediately.




ok, this might be important. Can you give more details? Windows version, mouse, when did it stop, did it stop for Windows in general or just game, did it fix after you restarted game etc. Did it happen fast or after hours? etc.

Also, check the version now available. It slightly changes the way /in_rawmouse works (it is able to 'live' do /in_rawmouse 0 and 1 without needing restart or /in_restart), though I don't expect it to be much different in that case.

Alright I am running Windows XP 32 bit it was working from the time I started it for the very first time after setting up the modified exe and all of that then after I closed the game and started again rawmouse 1 would make the mouse stop moving instantly, also that other command in_mouse ? or something like that any change would also make the mouse stop responding. I am using a stock dell wired mouse not sure on model or anything nothing special. It only stopped working in game when I alt tabbed it would work again. and mouse would only work again after I set rawmouse to 0

This post has been edited by blizakster: 25 July 2010 - 07:59 PM

[n4n3rz]

right, i'm looking for said external OS utility

[MerkyMerc]

Input stopped responding for me on in_rawmouse 1 as well. I noticed upon start up I had a little bit of time where I could move the cursor and when xfire popped up the input stopped. Disabling xfire in-game stopped this issue.

[mitsubishi]

I saw xfire coming up and it didn't alter anything here.

The implementation of raw input is rather cookie cutter; you can do some minor adjustments and can deregister it (and re-register it during the course of the game) but to initially start it and have it give signals is generally a very predefined standard process can't easily be 'wrong' as soon as it works. Hence I'd imagine it's probable we're talking about xfire or driver or windows bugs.

Notice id software on quake3 live has raw input and have not set it to default to avoid quirks. I'm pretty certain they're confident the quirks don't come from their own implementation.

Also this technology is available only after XP and server 2003; It might behave better lately.

--

It might be interesting to see on what Windows version and what Mouse those issues occur.

This post has been edited by mitsubishi: 26 July 2010 - 12:48 AM