Documenting protocols

[mh]

Nothing really to say except that I find the fact that metlslime is documenting the protocol to be epitome of the advancement of Quake.

Aside: If only this were done for ogg vorbis support (argh! more complicated than I thought. Streaming! Memory!), zip instead pak support, dynamic memory management (DP, FTE) and things like LHNET.

Zip instead of Pak is easy enough; just rip it from Q3A.

I could do dynamic memory management but it would be very platform-specific and would largely be a copy and paste of my own code. Besides, I don't know what the Linux equivalent of VirtualAlloc is, if it has one.

[r00k]

Does standard
#define svc_fog 51
conflict with FitzQuake's
#define svc_fog 41

[Spike]

All I can say to that is:
#define svc_updatestatubyte 51 // [byte] stat [byte] value
and:
#define svc_setinfo 51 // setinfo on a client

To which standard do you refer?

[metlslime]

Does standard
#define svc_fog 51
conflict with FitzQuake's
#define svc_fog 41

A couple notes about this:

1. fitzquake has three undocumented server messages that have been in there for years: svc_fog, svc_skybox, and svc_bf. They are not included in the 666 "official" spec because they don't represent a completely-thought-out mechanism, they probably need quakec builtins to make sense as a spec (since otherwise quakec has to hand-write the messages, which means the quakec has to be tied to a specific protocol, which is a terrible idea.)

2. svc_fog that i implented is slightly different i think in that i add a duration at the end (to be used for smoothly fading between values.)

3. #defined values for svcs don't actually need to be universal, there's no reason they can't be different per protocol. Unless, of course, you want your quakec to be able to write those messages itself, which is still a problem because even if all custom engines supported the same standard, unmodified clients don't.

So in conclusion, ignore those for now, they aren't part of the spec and i'm not sure what to do with them. They only make sense as implemented if you want to make a mod that is tied to a specific engine, like that FitzKurok thing.

[mh]

Ahhhh, that clarifies a lot of things. Your svc_skybox is actually identical to the standard (Nehahra-derived) one used elsewhere, so no concerns there, svc_bf didn't seem to make sense given that there was already a "bf" command that could have been used, but your "svc_fog" thing had me confused as it's quite different to the Nehahra implementation (which I guess is as good a standard as any). In the end I decided to just gobble the message but not react on it.

I like the idea of being able to fade between different fog styles though, that's pretty neat and does deserve to be in a "standard" implementation.