Binaries for 0.8.x test thread

[sago007]

Updated again... new icons... and a few small backports (including a different win32 ipv6 mcast address).

[Falkland]

BTW , I've tested this patch proposed on ioq3 bugzilla http://bugzilla.icculus.org/show_bug.cgi?id=4322 ; apparently ( but maybe no ) it saves many CPU cycles and gives much more stable fps for me.

The status of this BUG has changed to RESOLVED WONTFIX : I've played Q3 , OA and UrT with a patched engine for each game ... the patch causes an enough serious rendering problem _only_ on q3dm14 (at least on my system, but anyway the all thing just adjusts itself in a few seconds of playing ) and not always ... but as a I stated , it significantly saves CPU cycles with the main obvious benefit of less CPU overheating (at least on my system) and as a consequence with less fps dropping ... I hope that ioq3 devs will improve this patch and/or will produce other patches to use much more GPU than CPU.

[sago007]

I hope that ioq3 devs will improve this patch and/or will produce other patches to use much more GPU than CPU.

I hope so too. The idea looks good.

[sago007]

It is almost two weeks since the last functionality enhancement and that is the longest break in new functionality for some time.

Unfortunately I quickly discovered that the new CVAR system deleted the single player progress for no reason at all. After some error investigation I found that g_spScoresX was not read from q3config.cfg because it has both the flag CVAR_ARCHIVE and CVAR_ROM set and the new CVAR system will reset all CVAR_ROM values even if they are supposed to be archived. This bug affects baseq3 too and I have reported it upstream. My workaround is simply to not ignore the value from q3config if it is an archive cvar.

EDIT:
There might be more problems with the new CVAR system, some old fixes has been mover or removed and they might have had a purpose. I have tested for the most obvious problems and have not discovered another bug in baseoa but other mods might have problems.

[Falkland]

I think this was caused by the fix they've applied to solve also the config pollution between the baseq3->mods/mods-baseq3 switch :
-  http://bugzilla.icculus.org/show_bug.cgi?id=2819
-  http://icculus.org/pipermail/quake3-bugzilla/2009-November/001350.html

[andrewj]

I am testing the latest source (openarena-engine-source-0.8.x-10.tar.bz2) but I get the problem where the main menu doesn't show up, just a blank screen.  Thankfully I can exit via the console (which is not drawn either).

It seems the UI VM is calling trap_GetCDKey(), but the code for that in client/cl_ui.c is disabled and hence it causes a 'bad UI system trap' error, which in turn causes the UI VM to be unloaded and I guess it gets reloaded and the cycle repeats.

The following patch works for me, but I think the proper fix would be to prevent the UI VM code from using the CDKEY functions (remove all the CD key stuff).

Code:

Index: client/cl_ui.c
===================================================================
--- client/cl_ui.c      (revision 1753)
+++ client/cl_ui.c      (working copy)
@@ -963,15 +964,17 @@
        case UI_MEMORY_REMAINING:
                return Hunk_MemoryRemaining();
 
+       case UI_GET_CDKEY:
 #ifndef STANDALONE
-       case UI_GET_CDKEY:
                CLUI_GetCDKey( VMA(1), args[2] );
+#endif
                return 0;
 
        case UI_SET_CDKEY:
+#ifndef STANDALONE
                CLUI_SetCDKey( VMA(1) );
+#endif
                return 0;
-#endif
        
        case UI_SET_PBCLSTATUS:
                return 0;       

[sago007]

I don't know how that patch works. The engine is not build with the standalone flag for the same reason.

Preventing the UI from touching the trap function will not work. Because players might use mods where it is not an option.

[andrewj]

Oh, sorry I thought BUILD_STANDALONE=1 was required in the makefile to build the OA binaries.

[sago007]

Updated binaries. Just compile parameter from ioquake3 and console patch from Falkland's other thread.

The console height cvar has been moved around in the code to fit better and has been renamed to cl_consoleHeight to match the naming convention for all other console cvars.

[Neon_Knight]

What about creating a GoogleCode page for these binaries, just like with OAX?

[iSubaru]

Oh finally some steps to new version to make brutal testing
I'm on it gimme just a few seconds to check boards and I will do some scouting in it
I can't wait to see what's new by my own eyes

EDIT #1
Oh my O_O
This is so great! looked through menu for now and everything looks good, too bad it's not official release yet but with this things done I feel it's matter of "few" days
I think I saw new possition in weapons ;] I can't wait to test it out muhahaha <cough> I mean <giggle>

EDIT #2
There is a bug
When I have started LAN game I couldn't move (Connection interrupted) until someone from enemies made hit on me, even 2 restarts of arena didn't helped
also dunno what about target cursor, I have set it colours but it changes only depending on HP
bots AI is rewritten or something because on Bring it on they are better
new maps yay!
that's all for now

[Falkland]

2 bugs in the latest engine binaries/sources :

- a minor bug about the window icon which is the old one ( oa081 )

- an enough serious bug but strictly connected to an eventual final user action , anyway : the new mouseaccel function imported in ioquake3 and previously coded and introduced in QL is in general better than old one because it's more tunable .

It introduces 2 new cvars ( quote from the updated ioquake3 README )

 cl_mouseAccelStyle                - Set to 1 for QuakeLive mouse acceleration behaviour, 0 for standard q3
  cl_mouseAccelOffset               - Tuning the acceleration curve, see below
...

QuakeLive mouse acceleration (patch and this text written by TTimo from id)
  I've been using an experimental mouse acceleration code for a while, and
  decided to make it available to everyone. Don't be too worried if you don't
  understand the explanations below, this is mostly intended for advanced
  players:
  To enable it, set cl_mouseAccelStyle 1 (0 is the default/legacy behavior)

  New style is controlled with 3 cvars:

  sensitivity
  cl_mouseAccel
  cl_mouseAccelOffset

  The old code (cl_mouseAccelStyle 0) can be difficult to calibrate because if
  you have a base sensitivity setup, as soon as you set a non zero acceleration
  your base sensitivity at low speeds will change as well. The other problem
  with style 0 is that you are stuck on a square (power of two) acceleration
  curve.

  The new code tries to solve both problems:

  Once you setup your sensitivity to feel comfortable and accurate enough for
  low mouse deltas with no acceleration (cl_mouseAccel 0), you can start
  increasing cl_mouseAccel and tweaking cl_mouseAccelOffset to get the
  amplification you want for high deltas with little effect on low mouse deltas.

  cl_mouseAccel is a power value. Should be >= 1, 2 will be the same power curve
  as style 0. The higher the value, the faster the amplification grows with the
  mouse delta.

  cl_mouseAccelOffset sets how much base mouse delta will be doubled by
  acceleration. The closer to zero you bring it, the more acceleration will
  happen at low speeds. This is also very useful if you are changing to a new
  mouse with higher dpi, if you go from 500 to 1000 dpi, you can divide your
  cl_mouseAccelOffset by two to keep the same overall 'feel' (you will likely
  gain in precision when you do that, but that is not related to mouse
  acceleration).

  Mouse acceleration is tricky to configure, and when you do you'll have to
  re-learn your aiming. But you will find that it's very much forth it in the
  long run.

  If you try the new acceleration code and start using it, I'd be very
  interested by your feedback.

There was a fix for this function in QL : if the final user should set cl_mouseAccelOffset to zero , there would be a division per zero in the code causing the loss of mouselook.

I guess some user has found it after creating an easy script/macro to decrease/increase the cvar in-game and noticed the loss of the mouselook after the cvar reached the zero value.

Here's the code :

Code:

...
/*
=================
CL_MouseMove
=================
*/

void CL_MouseMove(usercmd_t *cmd)
{
...

			// sensitivity remains pretty much unchanged at low speeds
			// cl_mouseAccel is a power value to how the acceleration is shaped
			// cl_mouseAccelOffset is the rate for which the acceleration will have doubled the non accelerated amplification
			// NOTE: decouple the config cvars for independent acceleration setup along X and Y?

			rate[0] = fabs(mx) / (float) frame_msec;
			rate[1] = fabs(my) / (float) frame_msec;
			power[0] = powf(rate[0] / cl_mouseAccelOffset->value, cl_mouseAccel->value);                   <---------------
			power[1] = powf(rate[1] / cl_mouseAccelOffset->value, cl_mouseAccel->value);                   <---------------

...

Anyway this is an ioquake3 bug so it should be reported there , but if they will not provide a fix we could code a workaround to not allow setting cl_mouseAccelOffset to zero.

[sago007]

Just two updates with in a couple of hours.

Updated to newer ioquake3 revision.
Ingame icon updated
The mouse acceleration thing Falkland mentioned
Some serverstatus changes

[Falkland]

Fix for the CVAR_ARCHIVE / CVAR_ROM issue : http://icculus.org/pipermail/quake3-commits/2010-January/001677.html

The comment in the code is enough explicative itself :

...
   // There is code in Cvar_Get to prevent CVAR_ROM cvars being changed by the
   // user. In other words CVAR_ARCHIVE and CVAR_ROM are mutually exclusive
   // flags. Unfortunately some historical game code (including single player
   // baseq3) sets both flags. We unset CVAR_ROM for such cvars.
...

EDIT : anyway this is more a VM fix rather than an engine fix ... sry for mistake.

[sago007]

EDIT : anyway this is more a VM fix rather than an engine fix ... sry for mistake.

Actually I believe it is an engine fix and therefore I have already fixed in the engine...

It is an obvious hack by id. There was never any correct solution. ioquake3 has a point that CVAR_ROM and CVAR_ARCHIVE is exclusive but the previous ioquake3 where CVAR_ROM was prioritized over CVAR_ARCHIVE was obviously wrong.

[Falkland]

... and therefore I have already fixed in the engine...

Yes , I know ... I just reported about the ioquake3 fix.
 

[sago007]

Applied http://files.poulsander.com/~poul19/public_files/oa/dev081/OORefFlare.patch

Compared to the original OORefFlare I have reduced brightness to half because there are no menu entry to reduce it to a playable value otherwise.
The new flares are automatically used if r_flares is set to 1 (still off by default)

Some might want to test motionJPEG because the memory functions are changed slightly and I have no idea what they do.

[sago007]

Updated 2010-04-24

Note:
The removal of qagame.qvm from pure check has not been verified to work.
say and say_team allows ';', but the VM still demands that "" are used.

[sago007]

After uploading the server binary to my own server I discovered the first problem with "-15". The 64 bit version is build on a newer version of glibc that is hardly supported anywhere yet. The windows and 32 bit versions should not have these problems as they are compiled in a dedicated environment.

[Falkland]

The removal of qagame.qvm from pure check has not been verified to work.

This change requires another mechanism to check at least that players don't use their own qagame.qvm.
Maybe a MD5 or SHA hash.

[sago007]

This change requires another mechanism to check at least that players don't use their own qagame.qvm.
Maybe a MD5 or SHA hash.

It SHOULD not matter because qagame is not used by the client. And even if it was the server would force the client to use the original qagame because it still cannot use a file the server does not have. Only the server skips the pk3-file.

I am not entirely sure why it is part of the check (the reason I write "SHOULD"). There are some suggestions in the code that it should never have been part of the check, because it is excluded from the qvm ccheck. But it is indirectly included in the part of the code that checks sums of the other files because it is not a txt, dat or such file.

[sago007]

Updated yesterday (-16). I have stopped working on the qagame.qvm exception for the time being. It still believe it is a good idea but not worth the trouble right now.

[sago007]

Updated to -17.

I have added a CVAR sv_dorestart that allows mods to tell the engine that a full restart is required. For example then g_instagib is changed in the middle of the game. This is based on the information from andrewj's message: http://openarena.ws/board/index.php?topic=3875.msg34394#msg34394

[sago007]

Update to -18

g_humanplayers are now set by the engine. This means that Q3-mods now show human players in the list.

I have not tested it. I applied this patch http://bugzilla.icculus.org/show_bug.cgi?id=4702#c2 by Zack "ZTurtleMan" Middleton.

Please spread the rumor to the people hosting mods that does not support g_humanplayers so we can test.

[Gig]

Update to -18

g_humanplayers are now set by the engine. This means that Q3-mods now show human players in the list.

I have not tested it. I applied this patch http://bugzilla.icculus.org/show_bug.cgi?id=4702#c2 by Zack "ZTurtleMan" Middleton.

Please spread the rumor to the people hosting mods that does not support g_humanplayers so we can test.

Sorry for my ignorance... what is g_humanplayers exactly? :-/