View previous topic :: View next topic |
Author |
Message |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Tue Nov 17, 2009 11:26 am Post subject: |
|
|
Baker wrote: | 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. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Wed Nov 18, 2009 6:03 pm Post subject: |
|
|
Does standard
#define svc_fog 51
conflict with FitzQuake's
#define svc_fog 41 |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Wed Nov 18, 2009 8:05 pm Post subject: |
|
|
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? _________________ What's a signature? |
|
Back to top |
|
 |
metlslime
Joined: 05 Feb 2008 Posts: 177
|
Posted: Wed Nov 18, 2009 11:53 pm Post subject: |
|
|
r00k wrote: | 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. |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 909
|
Posted: Thu Nov 19, 2009 12:44 am Post subject: |
|
|
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. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2004 phpBB Group
|