Binaries for 0.8.x test thread

[sago007]

I took the source from https://github.com/undeadzy/openarena_engine discussed in another thread.

http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-bin-0.8.x-30.zip
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-source-0.8.x-30.tar.bz2

It also includes patch for CVE-2012-3345 (http://seclists.org/oss-sec/2012/q2/511). A local attack affecting Linux and Mac on systems with multiple users. 

It is compiled with out the dynamically loaded renderer. I do want to use the the dynamically loaded renderer but I want to know what files to include in my packing script.

[jackoverfull]

Do you need a Mac OS X build?

[ostar2]

Is possible open arena will ever use quake 4?

[Neon_Knight]

No.

[smcv]

It is compiled with out the dynamically loaded renderer. I do want to use the the dynamically loaded renderer but I want to know what files to include in my packing script.

Unpatched ioquake3 loads renderer_${cl_renderer}_${CPU}.so, where cl_renderer defaults to "opengl1". So as a minimum you need renderer_opengl1_${CPU}.so, or whatever corresponds to the new default for cl_renderer if it's been patched.

Unpatched ioquake3 also has an "opengl1_smp" renderer, which isn't used by default. It corresponds to the old ioquake3-smp executable, which isn't compiled any more if you use dynamically-loaded renderers.

[Gig]

I took the source from https://github.com/undeadzy/openarena_engine discussed in another thread.

http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-bin-0.8.x-30.zip
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-source-0.8.x-30.tar.bz2

It also includes patch for CVE-2012-3345 (http://seclists.org/oss-sec/2012/q2/511). A local attack affecting Linux and Mac on systems with multiple users.  

It is compiled with out the dynamically loaded renderer. I do want to use the the dynamically loaded renderer but I want to know what files to include in my packing script.

Maybe I forgot to test this in June (I had many things to do at that time! Not that now I have a lot of time, but...).
What changes should it contain against 0.8.8 binaries (version 28, right?)? What should I test?

[sago007]

What changes should it contain against 0.8.8 binaries (version 28, right?)? What should I test?

There isn't much new functionality. The new version was mainly released to include the security fix for the local exploit present in 0.8.8.

Because this goes back to use STANDALONE variable it is also a good idea to test that mods load correctly (this was earlier a problem with the STANDALONE variable and the reason OA did not use it until now). I have loaded ReactionQuake and WasternQuake in Linux so the problems appears to be fixed.  

Testing that network compatibility still works is the most important (this has failed before).

[Gig]

Tried Target Quake Arena and Alternate Fire mods, they work.
Also tried Target Quake from dedicated server mode, connected from a client (from the same computer), and works.
OS: Windows XP.

Someone should try with a "real" dedicated 2 server...

[Gig]

A thing I noticed with the new (v30) binaries.

Do you remember about cl_yawspeed and cl_pitchspeed (turning around using keyboard)?
http://openarena.ws/board/index.php?topic=4466.0
They were hard-coded to their default value (140) in official 0.8.5 and 0.8.8 binaries (as some sort of anti-abuse protection). You were able to change them to any value you liked, but the game continued to work as if they were set to 140. It has been pointed out that was a strange behavior, that may confuse users.

In the new test binaries, you are not allowed to change their values anymore. They do not appear as "cheat-protected" (even in devmap mode, you cannot change them), but as "read only". You cannot change them when playing, or when playing demo, or from main menu, or from devmap mode....
The problem is... if you change them form 0.8.8 binaries (e.g. set them to 500), then launch v30 binaries, it keeps the "500" value, uses it, and prevents you from changing it again.
Well, changing their values from old binaries is not the only way to "workaround" the lock... you can change them also simply text-editing your q3config.cfg file, or starting openarena with "openarena.exe +set cl_yawspeed 500".
In other words, the new lock is not good enough yet.
I can imagine that the old kind of lock (unelegant) was done to be not "workaroundable" in any way (unless using unofficial binaries). However, I suppose it should be possible to prevent abuse also using the "elegant" lock in some way (maybe resetting to the default value on program start/match start? Or making the variable as cheat-protected? I don't know...)...

I don't know if you thought about a way to let server admins to decide if their players would be allowed to customize such variables or not (it was one of Corvette's thoughts) or allowing some ranges of freedom... e.g. using "dmflags" or "videoflags" (ehm.. its not "video"... maybe the old name "fairflags" would have been better for that)...

Another thing: strangely enough, if you type /cl_pitchspeed ENTER, it says its current value only, and it doesn't say ", default value is 140"! I don't know the reason of this (maybe because, being a read-only variable, it thinks it may never be changed? Wrong!), but hope it may be fixed and the default value being mentioned.

[grey matter]

Code: (qcommon/cvar.c)

void Cvar_Register(vmCvar_t *vmCvar, const char *varName, const char *defaultValue, int flags)
{
cvar_t *cv;

// 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.
if ((flags & (CVAR_ARCHIVE | CVAR_ROM)) == (CVAR_ARCHIVE | CVAR_ROM)) {
Com_DPrintf( S_COLOR_YELLOW "WARNING: Unsetting CVAR_ROM cvar '%s', "
"since it is also CVAR_ARCHIVE\n", varName );
flags &= ~CVAR_ROM;
}

In other words, variables that are declared to be read-only AND should be saved/loaded to/from config files are silently made writeable (you'll see the WARNING in console with "set developer 1").
This is a sane approach, since the read-only value is a constant that must be present in the binary anyways, so there's no need to use a config for those at all.

[sago007]

I think the problem is that Cvar_Get does not use the new meaning of CVAR_ROM and therefore reads the value from config anyway like before.

To me it sounds like Cvar_Get should be updated to understand the new CVAR_ROM. I wonder how much that would break in the engine.

[hairball]

Should cl_yawspeed and cl_pitchspeed simply be set as CVAR_CHEAT rather than CVAR_ROM?

The #define for CVAR_ROM makes it sound like it is more protective than it really is:

Code:

#define CVAR_ROM                0x0040  // display only, cannot be set by user at all

In practice, a CVAR_ROM without any other flags appears to work as Gig mentioned.  It shouldn't be used for protecting against modifications.  I looked at some of the other uses of CVAR_ROM and it turns up in com_standalone etc.  That makes sense: you want the user to be able to set com_standalone at startup but it's a global setting that should never be able to alter without restarting.  The comment and name CVAR_ROM is a misnomer.

I think using CVAR_CHEAT would be sufficient.  What do you guys think?  This was one of the things I mentioned in the README.md.  It felt wrong with the 0.8.8 code removing the variable entirely and using a value.  I think CVAR_ROM was the wrong choice.  CVAR_CHEAT could be the correct setting.

[Gig]

Reading what grey matter wrote, it seems the program would completely disable the "read only" part in that case (making it a standard stored variable, one may guess), but it does not look like exactly like that, because it is still "read only" from inside the game.
Are we sure now it has got both archive and rom attributes? Hairball says, however, that a cvar with the rom attribute only works like that variable now... so also without the archive flag, would it be loaded from q3config.cfg anyway? Or only from OS command line?

As hairball suggests, maybe we may try to make it "cheat protected" instead. In that case, what would happen? Would it be changeable from devmap mode? Would it be automatically restored to its default, when later playing in standard mode?

By the way, I'd like to understand better what are the abuses that caused them to be considered cheating. Someone in the thread I linked in the post above mentioned something like a 180 degree turn or spin? What did he mean exactly? Are we sure it is necessary to completely lock these settings, or maybe we could accept a range of "sane" values (e.g. between 100 and 200  -just an example-... if you set it lower or higher than that, it will be automatically reverted to 140... maybe with an "out of range" or similar warning to the user)?

[hairball]

Reading what grey matter wrote, it seems the program would completely disable the "read only" part in that case (making it a standard stored variable, one may guess), but it does not look like exactly like that, because it is still "read only" from inside the game.

Based on what grey matter posted, the current value is a mistake and it should be changed.

As hairball suggests, maybe we may try to make it "cheat protected" instead. In that case, what would happen? Would it be changeable from devmap mode? Would it be automatically restored to its default, when later playing in standard mode?

 I have since changed it to CVAR_CHEAT in git and it works as intended in my testing.  It works like any other CVAR_CHEAT in that you can only change it if cheats are enabled.

Code:

code/qcommon/q_shared.h:897:#define CVAR_CHEAT          0x0200  // can not be changed if cheats are disabled

[GrosBedo]

Someone should try with a "real" dedicated 2 server...

I have run a few dedicated 2 servers running both vanilla OA, Excessive+ server-side, AfterShock and Defrag since the first release of undeadzy, and everything seems to run smoothly.

I have currently a few servers online that I relaunched since about a month, running the latest undeadzy's release, plus a few new commits from ioquake3 and server-side demos patch:
https://github.com/lrq3000/openarena_engine_serversidedemos/tree/latestwithtell

Everything is fine for now. I'll keep you updated if I notice a problem.

[GrosBedo]

About the vars problem, I had the same problem with the sv_demoClients variable I used for my server-sideo demos patch.

What I did to fix that was to forcefully set the value at engine start:

Code:

Cvar_SetValue("sv_democlients", 0);

Also it was set as CVAR_ROM.

Another thing to note: there are hacks for Quake 3 Arena which can set a variable even if it is cheat protected.