Pages: 1 ... 13 14 [15]
  Print  
Author Topic: Binaries for 0.8.x test thread  (Read 193260 times)
sago007
Posts a lot
*

Cakes 61
Posts: 1639


Open Arena Developer


WWW
« Reply #350 on: June 16, 2012, 04:30:57 am »

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.
Logged

There are nothing offending in my posts.
jackoverfull
Member


Cakes 14
Posts: 385


Member


WWW
« Reply #351 on: June 16, 2012, 04:33:18 am »

Do you need a Mac OS X build?
Logged
ostar2
Nub


Cakes 0
Posts: 5


« Reply #352 on: June 23, 2012, 06:36:14 pm »

Is possible open arena will ever use quake 4? Huh
« Last Edit: June 23, 2012, 06:49:43 pm by ostar2 » Logged
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3653


Trickster God.


« Reply #353 on: June 23, 2012, 09:36:14 pm »

No.
Logged


"Level Designers are 1 part architect, 1 part artist, 1 part game designer, and 1 part beta tester!" Cliff Bleszinski
Want to contribute? Read this.
smcv
Nub


Cakes 5
Posts: 23


ioquake3/OA/Q3 Debian maintainer


« Reply #354 on: August 15, 2012, 08:27:47 am »

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.
Logged
Gig
In the year 3000
***

Cakes 48
Posts: 4198


WWW
« Reply #355 on: September 25, 2012, 06:45:05 am »

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?
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
sago007
Posts a lot
*

Cakes 61
Posts: 1639


Open Arena Developer


WWW
« Reply #356 on: September 25, 2012, 10:43:00 am »

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).
Logged

There are nothing offending in my posts.
Gig
In the year 3000
***

Cakes 48
Posts: 4198


WWW
« Reply #357 on: September 26, 2012, 01:51:22 am »

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...
« Last Edit: October 01, 2012, 10:55:38 pm by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Gig
In the year 3000
***

Cakes 48
Posts: 4198


WWW
« Reply #358 on: October 01, 2012, 04:14:25 am »

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.
« Last Edit: October 01, 2012, 05:16:32 am by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
grey matter
Member


Cakes 8
Posts: 381

>9k


« Reply #359 on: October 03, 2012, 03:05:08 am »

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.
Logged

This space is for rent.
sago007
Posts a lot
*

Cakes 61
Posts: 1639


Open Arena Developer


WWW
« Reply #360 on: October 03, 2012, 01:22:42 pm »

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.
Logged

There are nothing offending in my posts.
hairball
Half-Nub


Cakes 2
Posts: 52


« Reply #361 on: October 03, 2012, 07:45:06 pm »

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.
Logged
Gig
In the year 3000
***

Cakes 48
Posts: 4198


WWW
« Reply #362 on: October 03, 2012, 11:44:24 pm »

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)?
« Last Edit: October 03, 2012, 11:58:52 pm by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
hairball
Half-Nub


Cakes 2
Posts: 52


« Reply #363 on: October 21, 2012, 10:34:04 am »

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
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #364 on: March 12, 2013, 04:03:38 pm »

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.
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #365 on: March 13, 2013, 02:40:22 pm »

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.
Logged
Hitchhiker
Member


Cakes 11
Posts: 180


« Reply #366 on: February 01, 2014, 10:29:50 am »

which is the latest version of the source? If I start adding my changes to the oa renderer, can I use the file 'openarena-engine-source-0.8.x-30.tar.bz2' (link here above by sago007) or I need to go through the SVN?
Cheers
Logged
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3653


Trickster God.


« Reply #367 on: February 01, 2014, 10:38:01 am »

Well, the latest version of the source, regarding binaries, seems to be 0.8.x-30.
Logged


"Level Designers are 1 part architect, 1 part artist, 1 part game designer, and 1 part beta tester!" Cliff Bleszinski
Want to contribute? Read this.
Hitchhiker
Member


Cakes 11
Posts: 180


« Reply #368 on: February 05, 2014, 03:45:25 pm »

Thanks Neon_Knight!
Logged
Pages: 1 ... 13 14 [15]
  Print  
 
Jump to: