[r00t]

yes, the bug is present in TwentySeven's client. And yes, tested vanilla version and it's still there.
Tried turning different options on/off, but still get this problem.
This is only map I have this problem, so far I have played ~20 other maps without any problems.

Will report it in the other thread...

Edit: This is some driver or GFX card issue, I now have same problem in all 3D applications (be it DX or OGL)

This post has been edited by R00t: 23 July 2010 - 02:08 AM

[Banned onemoar]

R00t, on 23 July 2010 - 01:58 AM, said:

yes, the bug is present in TwentySeven's client. And yes, tested vanilla version and it's still there.
Tried turning different options on/off, but still get this problem.
This is only map I have this problem, so far I have played ~20 other maps without any problems.

Will report it in the other thread...

Edit: This is some driver or GFX card issue, I now have same problem in all 3D applications (be it DX or OGL)

overheating

[mitsubishi]

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).

This post has been edited by mitsubishi: 23 July 2010 - 06:22 PM

[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