- Framerate counter reports 2x the framerate it actually is- SDL input is still quite slow in low framerates (try com_maxfps 30, and maneuver around oa_dm3, it is obivous)- Crash when quitting through the console

Logged

asking when OA3 will be done won't get OA3 done.Progress of OA3 currently occurs behind closed doors alone

- Framerate counter reports 2x the framerate it actually is- SDL input is still quite slow in low framerates (try com_maxfps 30, and maneuver around oa_dm3, it is obivous)- Crash when quitting through the console

You MUST specify the platform when u've encountered these problems

Gee everyone knows I use Windows. I have to do my development on that.

Logged

asking when OA3 will be done won't get OA3 done.Progress of OA3 currently occurs behind closed doors alone

Build on SVN 1432Icons have been fixed (I hope)IPv6 removed (based on info from the ioquake3 mailing list it looks like it is going to be changed soon and this might end up being incompatible) (This might also fix Windows 2000 and older support)Sago's Custom Windows Mouse Acceleration Hack

About Sago's Custom Windows Mouse Acceleration Hack:This is a workaround the mouse acceleration bug found in the Windows version of the gameMac OS X is already using a hack like itIf the game or computer crashes the mouse acceleration will not return.It might break earlier versions of Windows that did not have mouse acceleration. Possible killing the speed instead (please test on a non productive system... and please do not use Windows 98 as a production system)The Windows API is not documented very well, my hack might create a huge disaster with possible lethal damage as a result. Please wear protective gear while testing!

How many Windows versions works with the hack. I have only tested on Windows 2003. The Windows API documentation tells that the mouse speed is stored in mosueInfo[2] but it is really the acceleration that is stored there and I fear that on pre-Windows XP machines there are only two values in that array. I don't think it is a particular safe way to access such values but I think it is the Windows way.

Instead of removing IPv6 support , a better solution could be to temporary declare net_enabled cvar as CVAR_CHEAT or CVAR_ROM and lock the value to 1 , so forcing OA to use IPv4 only and not use IPv6 even if present . That's logically WRONG , but the final result could be acceptable.

A problem (besides pre-winxp) is that our version will never be able to access a IPV6 master server. The ioquake3 IPv6 implementation is currently being changed meaning that our 0.8.0 version will be incompatible with the future versions.

However if it wasn't for the pre-winxp problem I would properly not have touched it.