[p5yc0runn3r]

versus666, on 26 July 2010 - 04:38 PM, said:

I understand very well the problem with 'negative acceleration'.

What's the point of trying to use RAW with a low quality mouse like a DELL, 125Mhz USB polling rate, 800 DPI at best ?
Whatever the possible improvement in the processing of mouse input, *IF* the mouse allow the RAW method, it would be negligible given the specs of the mouse, don't you think ? And it doesn't produce 'negative acceleration' whatever the method used.

High DPI mouse have problem with some weird sensitivity settings on classic method ? Use RAW !
Use RAW and want accel ? Fine tune with cl_mouseAccelOffset and cl_mouseAccelStyle !
Have a low DPI mouse and can't use RAW ? Use classic method and don't bother !

I really don't see the problem.
Ok, having a method that sometimes don't works on competition mouse is a but frustrating but sometimes perfection is not possible, maybe it's just the method which is flawed and does not fit to extreme hardware input.

I really think the actual SDL implementation is flawed (not Mitsu's fault BTW). If the input is more coupled in the main module, it should be a different story. I have implemented this in the vanilla non SDL version (with VBO) of Twentyseven and I really do not have any problems and also I can aim more precisely.

[mitsubishi]

versus666, come again when you have read this isn't only about negative acceleration.

This post has been edited by mitsubishi: 26 July 2010 - 07:52 PM

[versus666]

mitsubishi, on 26 July 2010 - 05:29 PM, said:

versus666, come again when you have read this isn't only about negative acceleration.

Don't get it wrong, I try to help, sorry if I upset you.

[mitsubishi]

Did you read this isn't only about negative acceleration?

:P

[p5yc0runn3r]

mitsubishi, on 27 July 2010 - 09:04 AM, said:

Did you read this isn't only about negative acceleration?

:P

I think the RAW mouse feature needs its own thread...

[mitsubishi]

it has.

[mitsubishi]

Now included: In-Game Voice (VoIP) support for servers that support it (/cl_voip 1; ioq3 server: /sv_voip 1). Full instructions are here. Bind a key to +voiprecord to talk, '/voip muteall' to mute all. It requires OpenAL and a high /rate.

cl_voip is 0 by default and if it's enabled the console will be slightly spammy about its requirements, i.e. "I need OpenAL" and "I need high /rate" (in bright yellow) if they're not available. If it's initialized reasonably, i.e. it got a recording device on OpenAL, it will print '* VoIP is initialized'.

Packages now include OpenAL-soft libraries for all windows builds because a) they sound good and they offer basic binaural audio b) An OpenAL library is required for VoIP. [They are also compiled for sse2 and mmx separately; overkill ftw.]


The reason it's not enabled by default is that it would be spammy in console by default about OpenAL and /rate requirements. This may change if they become the default..

--

ut4_iran3 crash on 'bumpy' is workarounded (similarly to one related to harbortown).

This post has been edited by mitsubishi: 29 July 2010 - 02:41 PM

[SubJunk]

Awesome, Mitsu.
Do you have any information on how it compares with Ventrilo, TeamSpeak, Mumble, ImpTalk, etc.? Have tests been done?

[mitsubishi]

VoIP; I tested it in default settings and it was reasonable. It's not destined by ioq3 to be about high quality and clanning but for fun pubbing. For quality they have Mumble positional audio. It'd be cool if others like TeamSpeak offered simple code 'hooks' for games. The code ioq3 has (given by Mumble) to support 3D in mumble is surprisingly tiny.

[mitsubishi]

Teleportation: bind a key with /bindteleport <key> and transfer back there when key is hit (locally or with rcon; server cmd: /teleport <cl num> x y z).

--

/bindteleport is a bit gimmicky, mainly for /map and /devmap since it doesn't add 'rcon' in front. If someone was running a server with it I guess they could add manually clients to binds with /rcon teleport <client number> <x> <y> <z>.

--

PS. I thought of server admin exploitation but it's burying our heads in the sand: admin exploitation is so easy that it's silly trying to avoid it by removing such features (which are a couple of lines and released in a client). If an admin wanted to exploit, they can do a lot more things than just using this. And nastier, hard to detect things. This is pretty obvious with spec (or recorded demo) (and this time really obvious, not "i can see wallhack"-obvious).

This post has been edited by mitsubishi: 30 July 2010 - 03:28 PM