Easier LAN coop play of classic Quake

[Spike]

you know its intact because the file size matches the size the server sent, and it doesn't have some .tmp postfix.

[Baker]

Your "commented out" svc_stufftext is a gift that keeps giving.

I hate how a coop client doesn't know the skill level the game is set on. Of course, the server sets this only at the start of a level. I'm going to pass along a hint to the client using this trick.

Rewards:
1. It will be possible for a demo to know what the skill level it was recorded on is.
2. The true ability to somehow display the skill level for a coop client in the status bar.

Of course I'll default this to -1 and server doesn't tell the client, it won't make any presumption.

[Spike]

this is what quakeworld's serverinfo is for.

[Baker]

[Spike]

note that NQ has a concept of serverinfo too, in that it has the cvar_s->server flag, and those cvars are potentially visible inside server browsers. Its just not easily available to connected clients, as it requires a disgusting protocol in order to query them all (too many round trips). Still, that info is available even in NQ, but if you do mod your client to query it, you'll probably want to fill in that info as it arrives instead of waiting for it to all arrive beforehand.

The server info is just the set of rules that define the game behaviour, like fraglimit, timelimit, teamplay, noexit, sv_friction, etc.
deathmatch/coop/skill ought to also be in there, but it seems nq tries to keep the count down.

In qw, the whole lot is sent at connection time, and changes to such cvars are sent as required.
QW also has player names+colours+etc going the other way too. A specific flag on cvars rather than hardcoded names. The setinfo command in qw allows the user to specify any setting they want, which gives quite a bit more extensibility (like password protection and message filtering, as well as weapon preferences etc).

I would recommend some standard prefix like "//si $NAME $VALUE\n" instead of just directly the cvar name. Then it can be made visible to csqc etc too, and is more easily extensible (or if nothing else, more compatible with qw).

[Baker]

[Spike]

the more things you bolt on the side, the more things you have to support, which is one satisfying thing with focusing on compat - you can blame someone else when its got some terrible api.