[n4n3rz]

i've seen it happen with LR and M4 mostly but i think it's happened with others too. those just happen to be my most common choice. anyway, what happens is the crosshair stays but the reload animation carries on, and the clip isn't actually reloaded. i can cancel the reload by switching weapons and reloading again, and very very occasionally it'll happen twice in a row.

[SubJunk]

mitsubishi, on 21 July 2010 - 02:20 PM, said:

Special SubJunk update with UI/CG cursor not getting raw. *let me know if it works! (It wouldn't be nice having a pointless tweak)

I feel so special ;) Thanks for the effort.
However, the mouse is still high-sensitivity in menu screens with ioq3-1788-urt-nobumpy-210710, so the patch makes no difference for me either.

mitsubishi, on 21 July 2010 - 02:20 PM, said:

Also the fact you negative accelerate either means you don't have it enabled (I doubt it, its status is printed on the console on startup and var change) or, and that's my assumption, Razer has internal hardware negative acceleration:P

I do use positive mouse acceleration from the Razer Configurator settings. It all still works perfectly with in_rawmouse 0, the sensitivity and acceleration are normal with that setting. The weirdness only starts with in_rawmouse 1.

mitsubishi, on 21 July 2010 - 02:20 PM, said:

I'll go ahead and assume it's Razer's fault as I usually do by default (:P) unless we find otherwise, that company gives me the willies with its fluorescent lights and cheap plastics:P Nice mousepads though. This cheap Sphex is awesome for my needs.

Well at the time I got this Mamba it was the only wireless gaming mouse and had the highest polling rate and DPI and I needed something more ergonomic than my Sidewinder, which was making my hand very sore with daily use. I tried Logitech mice for a long time because I like their designs ergonomically but I had 3 faulty Logitech mice in a row (I bought one, sent it back, they gave me a new one instead of fixing it, then repeat that another time) so I gave up on that company for mice. I think both Razer and Logitech have high fault rates with their mice, while Microsoft seems reliable, it's a shame they don't design their mice for human hands ;)
So, the Razer was really my only choice at the time. I disable all the lights anyway so none of that affects me.

mitsubishi, on 21 July 2010 - 02:20 PM, said:

BTW now that I use dmaEX, Win64 client is an awesome alternative. It still loads slightly slower but it's a great feeling knowing you run a native binary (I'm such a dork).

Being a dork is the best :) Does dmaEX offer superior audio to iKALiZER, or do you use it for another reason?

P.S. Later today I will test my Sidewinder to see if the issues happen with that mouse too.

This post has been edited by SubJunk: 21 July 2010 - 11:38 PM

[mitsubishi]

Alright, I suspected it won't do much, I'll remove the tweak as junk and to get back the awesome feature of having an HD cursor (j/k :P).

I suspected razer is doing some voodoo internally when it detects Windows are reading the raw device but now that the tweak does nothing I guess it might be something else; maybe it sends the x/y positions in a different 'format' or something; anyway. I won't know easily without directly testing it I guess.

SubJunk, on 21 July 2010 - 11:33 PM, said:

Does dmaEX offer superior audio to iKALiZER, or do you use it for another reason?

well, I'm not an "audiophile" but it sounds good to me (after I realize its audio improves tremendously with s_sdlspeed 44100, 22050 was horrible). Only improvement that might important at this point is to have lower latency. It's slightly limited by the vanilla q3 system in having 0.1s s_mixahead. Author might improve it in the future.

n4n3rz, on 21 July 2010 - 07:56 PM, said:

LR and M4 mostly

Well I see M4 a lot and I don't see that so I won't be able to do much about it unless I find a way to reproduce it.

[Mod ObScUrE]

SubJunk, on 21 July 2010 - 11:33 PM, said:

I feel so special ;) Thanks for the effort.
However, the mouse is still high-sensitivity in menu screens with ioq3-1788-urt-nobumpy-210710, so the patch makes no difference for me either.

For me it works on 800x600 with Razer D3g 1800dpi on UrT 0.8 sens with windows default driver.
there is no sensitivity difference in the main menu.

Quote

I do use positive mouse acceleration from the Razer Configurator settings. It all still works perfectly with in_rawmouse 0, the sensitivity and acceleration are normal with that setting. The weirdness only starts with in_rawmouse 1.

I think you are used to the positive acceleration better you test it with a ruler (raw input is not affected from windows pointer ballistics or software simulated acceleration).

Quote

Being a dork is the best :) Does dmaEX offer superior audio to iKALiZER, or do you use it for another reason?

iKALiZER is better for positional sound when your system can run it be happy. :-)
dmaEX is a improved version of the default sound engine with good performance.

This post has been edited by ObScUrE: 22 July 2010 - 02:28 AM

[SubJunk]

ObScUrE, on 22 July 2010 - 12:57 AM, said:

I think you are used to the positive acceleration better you test it with a ruler (raw input is not affected from windows pointer ballistics or software simulated acceleration).

Yeah, you're right. That was it. So I have gone back to using the normal mouse system since I like acceleration.

This post has been edited by SubJunk: 22 July 2010 - 02:45 AM

[~SG~Juno]

So far so good.
On my rig latest 190710 (both) are working much better then previous version.
But.
Game looses smoothness directly proportional to intense of gameplace.
At the first go it was terrible. Now is muuuch better.
So the first approach i can treat as accident and computer depended issues.
During fast gameplay its like loosing fps (fps-meter doesnt confirm my feeling).

And there is something wrong with changing weapon animation.
Sometimes it looks like it doesnt work at all and I dont see weapon after changing.
Im not sure if changing was performed.
But its very early observation and im not sure. It can be razer issue maybe.

This post has been edited by Juno: 22 July 2010 - 09:52 AM

[mitsubishi]

update with r_windowPosition. It mostly aids in case one uses r_noborder.

r_windowPosition    "0,0"   // comma separated window position when r_centerWindow 0. It's mostly usefull when
                            // r_noborder is 1 since in that case taskbars can be accommodated. It's ignored when
                            // r_noborder is 0 + it's on "0,0" to not be messing with 'draggability'.

[it uses an SDL env var as r_centerWindow did]

--

also that previous 'tweak' is removed since it did nothing.
--

new var takes some tweaking, e.g. working even with r_noborder 1 (weird crash occurs currently if I attempt it (via a method that still ignores it if it's on the default value, a 0,0 border window can't be dragged necessarily) that doesn't happen on a debug binary (weirder)) and perhaps being able to be overwritten by ENV but that's probably not the "convention" since r_centerWindow (which also uses ENV) doesn't do it.
--
Oh silly me, the fix was easy. hm.
[done]
--

OK fix,

now r_windowPosition does get to work on r_noborder 0 too; it only gets ignored on 0,0 when r_noborder is 0 since in that case it'd be losing the ability to be dragged in many window managers (mainly because the value is the default) (plus it's an easy way to retain the 'random window positioning' behavior).

--
oops, misuploaded; fixed.

This post has been edited by mitsubishi: 23 July 2010 - 01:52 AM

[r00t]

After some time I decided to update to latest version, everything was OK until server loaded ut4_paris.
Serious rendering problems on this map, completely unplayable with jagged triangles everywhere...


... back to ioq3-1778-urt-020310.exe for me

[Mod ObScUrE]

root could you test if it happens with the vanilla renderer build or test r_simpleshaders 1 & 0 setting on the regular optimized build?

[mitsubishi]

Yes, I have in gold letters 'bumpy is relatively unstable check vanilla renderer too'.

Thanks for this report though, very useful at this stage. See if it is the same on TwentySeven's client and report it there. It might be important for 4.2.
--
(it appears ok here)
--
yes, r_simpleshaders might be important to be checked on 0 and 1 (/vid_restart or restart needed) since it's different from the upstream default.

This post has been edited by mitsubishi: 23 July 2010 - 01:26 AM