Binaries for 0.8.x test thread

[sago007]

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

Its the CVAR the ingame server list uses to see how many human players there is on a server.

[Gig]

So, when you set "only humans" option in the server browser on or off, the program reads g_humanplayers or another cvar (that olds the number of total players), right?

Is the new feature that, if the old mod does not contain the "only humans" option, it will read g_humanplayers instead of the cvar with the total number?

But this would seem a client-side feature, and you talked about server admins...

And if the "only humans" feature is supported (a mod for oa instead of for q3a), will it still be possible to select it on or off?

[sago007]

Remember there are two sides to show how many humans that are playing:
1. The server must tell the client how many humans that are (previously done by baseoa by setting g_humanplayers, from -18 by the engine)
2. The client must read the value (done by baseoa)

It is (1.) that has been improved, so old mods now advertise the number of humans too. However only the baseoa server browser (or compatible) can show the value.

Currently servers running old mods will always say that there are 0 humans even if there are more.

[Gig]

Maybe now I understand:
1) An OA server rurring baseoa (or a modern mod designed for OA) sends two variables, one with the total players number, and one with the number of humans.
2) An OA server running a mod for Q3A (that did not have the "only humans" option) sends only a variable, the one with the total players number.
- Thus:
3) An OA client that is already using a Q3A mod, when browsing servers, always sees the total number (independently if the server runs the same mod or something else), because the client doesn't look for g_humanplayers, but only the other CVAR.
4) An OA client server browser, from baseoa (or a modern OA mod), selects wich of the two variables show, changing the "only humans" option. But if the server runs an old mod, it does not send g_humanplayers cvar, so, if "only humans" is enabled in the client, it will always see 0 players for that server (thus, hiding the server!).

Right?
I wonder if also the deathmask server browser is affected.

And the new improvement makes all the servers (even if using an old mod) send also the g_humanplayers cvar, so the baseoa client (point 4) will be able to list them correctly even if "only humans" is active. Point 3 remains unaffected.
Am I right?

[Gig]

Ok Sago, I did a rapid test.

I launched a dedicated server running the BFG10K Arena mod for Q3A.
Added a bot.
Launched an OpenArena client and connected to the server.
Checked on dpmaster web page:
- With the oa_ded.exe provided with OA 0.8.5, it says Players 2/16 and g_humanplayers
0.
- With the od_ded.x86.exe just downloaded (v. -18), it says Players 2/16 and g_humanplayers 1.

Thus, the fix seems to work! :-) Nice work, Sago! 

PS:
I had to do the try from dpmaster web page, because of I don't have a second PC to do the check from a second OpenArena client.
I only tried oa_ded.x86.exe, not the other executables...

[sago007]

New binary up today. It has been a while. Has some problems compiling the windows version but at last it compiled successful.

[Gig]

Good. I will try it to check out if it fixes the problem of the missing crosshair when enabling anaglyph 3d mode...

[sago007]

Good. I will try it to check out if it fixes the problem of the missing crosshair when enabling anaglyph 3d mode...

This is not engine specific, the crosshair is drawn by gamecode.

[Cacatoes]

Any idea on how we can get the list of commit descriptions from a revision to another ? I'll search, I'd like to get an idea of a changelog.

Secondly, I've seen ioq3 has accepted a few patches, some by Simon McVittie, which help in making ioq3 and OA compatible. For instance, one allows to set protocol number on command line.
Wouldn't it be wise for OA to profit that flexibility, and is it already the case ?

[Gig]

Good. I will try it to check out if it fixes the problem of the missing crosshair when enabling anaglyph 3d mode...

This is not engine specific, the crosshair is drawn by gamecode.

Then, could you please take a look to it?

PS: also some HUD info on the upper right corner are messed up.
http://images4.wikia.nocookie.net/__cb20100616171047/openarena/images/a/a3/R_anaglyphmode_1.jpg

[fromhell]

Still can't apply my renderer patch?

[sago007]

Still can't apply my renderer patch?

No

I might go throw it in the weekend and apply it by hand if I can find the time.

[Neon_Knight]

I don't know if you replied this, but... what about opening a googlecode account for this? There's already one for OAX and one for OAStat. Do a googlecode account cost something?

[Cacatoes]

Nah it's free, like most of the opensource forges.

Normally you wouldn't open several accounts for a single project's use. I think you can have like separate trees if you need to work on several parts of a project.

[sago007]

Still can't apply my renderer patch?

Applied manually in 0.8.x-21

[fromhell]

No more deprecated builds?

I mention that because currently thanks to ipv6, there's no way it can run on Win9x or Win2000 not even with Kernelex on 9x. Even worse, there's no error message explaining why, even in stderr.txt. Just fails right after the video init. Windows 2000 complains about a missing function in ws2_32.dll (windows sockets 2).


Darkplaces still works on Win9x as of the March 2011 builds (as well as it is still working on Voodoo2s). A technically superior engine working makes this situation look funny.


Currently i'm installing MinGW/Msys to build OA again.

[fromhell]

OK a little more testing under win9x with the NON-deprecated build

- Kernelex must set the compatibilty mode to Windows 98SE to bypass the psapi.dll error
- You need an OLDER SDL.dll

[smcv]

Hey Sago,
Just to let you know: as a result of <https://bugzilla.icculus.org/show_bug.cgi?id=4962>, ioquake3 now supports two protocols simultaneously: protocol 68 from Q3 >= 1.32c (which OA currently re-labels as protocol 71, to avoid OA clients trying to join Q3 servers and vice versa), and Thilo's new protocol 69 (which fixes some DoS vulnerabilities).

I wouldn't necessarily recommend merging from ioquake3 right now in any case, because it seems Thilo might be making more changes in protocol 69, but presumably you'll want to catch up once the protocol has settled down. In future builds (after merging r2075 or later from ioquake3) you'll need to set PROTOCOL_LEGACY_VERSION to 71, define LEGACY_PROTOCOL in q_shared.h, and set PROTOCOL_VERSION to some new value (perhaps 10069 or something?).

The new protocol does include the client and server's idea of sv_heartbeat in the handshake, as an alternative way to tell you whether you're incompatible, so you might even be able to leave PROTOCOL_VERSION set to 69 and rely on comparing sv_heartbeat. I haven't tried that out yet.

In Debian I plan to continue to use a shared ioquake3 engine to run OA, and set com_legacyprotocol and com_protocol on the command line to match the values you use in your standalone builds. So, I'll avoid uploading a newer ioquake3 to Debian until you've confirmed what values you're going to use!

[sago007]

I have read a little about this new protocol and I have always been interrested in it. Especially for OpenArena a better protocol could be very useful. I would not like to include a protocol that is work-in-progress.

The protocol was actually not changed to prevent joining Q3 servers but because it was the only options known at that time that could separate incompatible versions (a big problem for 0.6 and 0.7(.1) servers) and allow them to coexist on the same master server.

[fromhell]

Merging the renderer bits shouldn't be a problem though. In my working copy the only real renderer changes between OA and IOQ3 right now is the preliminary IQM support and the new JPEG library (which I didn't apply since it breaks Windows compiling, for some reason)

I almost feel like I could maintain the renderer/ part of the code project myself and commit it to oax or so, and I wonder if there's a possible way for multiple renderers in one place too (i'm thinking renderer_dx9, renderer_soft, renderer_ogl2)

[smcv]

I would not like to include a protocol that is work-in-progress.

Sure, I just wanted to warn you that this change was on the way!

separate incompatible versions (a big problem for 0.6 and 0.7(.1) servers) and allow them to coexist on the same master server

The new protocol addresses this by comparing sv_heartbeat (aka HEARTBEAT_FOR_MASTER), as well as the numeric protocol ID. It seems OA currently uses QuakeArena-1 as its heartbeat string (before ioquake3 r1815 it wasn't made very obvious that changing it in standalone games was desirable), and changing it now would probably be a compatibility break, but next time you break content compatibility you could set sv_heartbeat to OpenArena-0.9 or something, and appear as a different game on the master server.

[sago007]

It should be noted that if you are using a binary from this thread and especially if you are running a *nix variant that you should not use a binary from before 0.8.x-22 as they contain a severe vulnerability. See http://archives.neohapsis.com/archives/fulldisclosure/2011-07/0338.html for details.

[smcv]

The new protocol addresses this by comparing sv_heartbeat (aka HEARTBEAT_FOR_MASTER), as well as the numeric protocol ID. It seems OA currently uses QuakeArena-1 as its heartbeat string

Following discussion with the author of dpmaster on <https://bugzilla.icculus.org/show_bug.cgi?id=5099>, it seems OA was right all along - QuakeArena-1 is part of the heartbeat protocol and shouldn't change per standalone game. Recent versions discriminate based on com_gamename (formerly cl_gamename) instead, and use the DarkPlaces heartbeat protocol. I've been keeping up with ioquake3 bugs and trying to advocate as much backwards-compatibility as possible, so OA can stay compatible with 0.8.x without having to fork the engine.

Thilo apparently still wants to make some changes to the VoIP code, so it's still not a good time to rebase onto current ioquake3. I'll let you know when the situation changes...

[fromhell]

Cleaned up my cgame fx changes. Unfortunately this is not a diff/patch file, but it applies to beta 48.

The UI change is just to add a new 3d element for the new missionpack menu

[Gig]

Hi guys! Some questions:
Will OpenArena 0.8.8 come with the at-the-moment-latest executables (version 22, of july 2011), or will you create a newer executables set? I don't know what new fixes/features ioquake3 added in these last months. But I can imagine, if there would be something "big", that it would need a good testing before the release! Maybe some of those changes risk to break compatibility?

In any case, remember to compile execuables for Windows, Linux (both 32 and 64 bits) and Mac for the release (someone told in 0.8.5 Mac executable was not updated).