Message Boards

I agree...

Also, you may want to include masking, maybe 2 32-bit fields for 64-flags that it can be kept simple. The Server list the main page doesn't care for scores and all, maybe send RQ_SERVERNAME and just get the server name back, same can also go for launchers (i.e. partial refresh instead of a full one) then send the mask back of what is actually in that packet data. Can also save some space for useless stuff like in DM who cares for team scores yknow?.

Omission/inclusion of fields based on masks can complicate:
1) We may or may not include a field in the next protocol version (eg included/removed team scores), then we have to say that the flag is available/not
2) If that were the case, we would also have to maintain a list of flags supported for each protocol version in the current minor version we are working with

However, you are right in that it would leave more space for certain game modes to have more information available later on.

It isn't necessarily a bad idea and it can always be added in later on (thanks to versioning)

EDIT: I found an article today which is "similar" to what we are discussing here: http://blogs.msdn.com/johnmil/archive/2006/01/11/511527.aspx

Here it is (in odt format)

Ralphis and I think it's a good idea to merge the deathmatch, teamplay, and usectf/ctf cvars into one cvar: gamemode.

Its a good idea, but there are 2 problems, we have a ccmd named gamemode (which looks dated) and there is also variable in doomstat.h named gamemode.

gamemode (int) - Common cvar. (Read-only for client) Distributed to launchers as an integer. (Will require protocol bump)

Read-only for client, why?

And I don't think it will require a protocol bump, we can just translate it before sending it to keep compatibility.

gamemode 0 - Coop
gamemode 1 - DM
gamemode 2 - TDM
gamemode 3 - CTF
gamemode 4+ - New gametypes. (Would show up as "unknown" for outdated clients/launchers)

Looks good, I would have suggested keeping the old variables and have it change this one, but I have researched this and it looks far too complicated (function cvars calling eachother resulting in recursion, latching not working correctly etc)

This would eliminate the hassle of juggling multiple cvars (deathmatch and teamplay do what for usectf?) while paving a smooth way for potential new gametypes.

Sounds good, we'll have less problems as a result too.

I'm usually on the co-op servers a lot. Only problem is that I usually end up breaking the maps on accident leaving them unfinishable.

(That's the third one this week)

Some wads just aren't made for coop and it has to be the good ones :(

As of r974, a proper fix has been made.

An updated version of this can be downloaded from the same url in Ralphis' post

We have another problem.. What do we do with stuff like BEGIN_CUSTOM_CVAR (.. ?

I've figured it out, I have designed some macros named CVAR_FUNC_DECL and CVAR_FUNC_IMPL that have a similar effect to a normal function, ie:

cl_cvars.cpp (location of all client cvars)
CVAR_FUNC_DECL(vid_winscale, "1.0", CVAR_ARCHIVE | CVAR_NOENABLEDISABLE)

hardware.cpp (location of cvar implementation)

CVAR_FUNC_IMPL(vid_winscale)
{
    code
    ...
}

I have not fully tested these, but they appear to work in game without any problems.

Okay, as from discussion on irc, we have a problem.

Firstly, Cvars are console variables, which reside on the client and server, they are the ones that affect gameplay and other things.

The problem is: our current implementation.
As of late commits (below r951), we send all server cvars to the client, which results in perfect sync of the client side values. This is what was needed to be done eventually.

However, we have a naming problem, the freelook bug is a good example of this: we have a cvar named allowfreelook, which existed on both client and server, but the clients version was affected by the servers version "through proxy" by changing the sv_freelook cvar, the client could toggle freelook on or off using cl_freelook.

There lies the problem, we now send allowfreelook, which is used by the client and server, it is a variable in the common codebase as well.

We can't:
a) Stop sending allowfreelook (its has a CVAR_SERVERINFO and is needed), that is downright hacky as well.
b) Remove cl_freelook and sv_freelook, then the server would force freelook on or off, depending on its setting.
c) Countless other ways that results in hacky/buggy code.

Now, you may think this only affects freelook overall, but it doesn't, it affects a LARGE amount of other things as well, so what I and others of the team propose is this:

A) Put every single cvar in a single file that exists in the common codebase.
B) Bring back namespaces (cl_* and sv_* prefixes) for cvars (we could use CVAR_SERVERINFO and CVAR_CLIENTONLY instead, but I have not thought this through completely)
C) <add anything else>

There is one disadvantage to all of this, we break alot of older cfg's, BUT, because we aren't at 1.0 and not stable, we can do all of this.

Suggestions, opinions, criticisms?

You can try the information given in http://odamex.net/bugs/show_bug.cgi?id=482

This has to be an SDL(_mixer) problem.