So are you saying that (hypothetical example) and older RMQ client that supports 999.1,990.2, and 999.3 will be able to play a demo recorded with the newer 999.4 protocol?

If not, it doesn't seem like you'd gain anything from the normal concept of protocol_version that we have now. 

the floating point cooordinates and angles provide a couple things:

1. you can travel beyond +/- 4096 in world space without wrapping around

2. rotating doors/trains/etc. (especially large ones, or slow-moving ones) have smooth motion rather than jumping from position to position.

3. slow movement is smoother, instead of moving in discrete 1/8th pixel steps. (Admittedly, the only time i can even notice the discrete steps is if I stand on the ramp at the beginning of e1m1 and zoom in at a wall. As I slowly slide down the ramp, I can see the stepping motion of the wall moving past the crosshair.) 

> So are you saying that (hypothetical example) and older RMQ client that supports 999.1,990.2, and 999.3 will be able to play a demo recorded with the newer 999.4 protocol?

From this day onwards, more or less yes. Previous versions of 999 will remain incompatible, but current and future versions will be able to play demos and connect to servers using any prior revision of it. I haven't got forward compatibility working yet (that requires the client to send some stuff to the server on connection and the server to downgrade it's protocol for the client), but full backwards compatibility is there.

So say we release the next RMQ pack in June. Someone records a demo using it. Then say we release another in November with a revised protocol. The November engine will still be able to play the June demo and connect to servers running the June version of the protocol. That means that content and servers will be protected against any future revisions of the protocol, which makes it easier and more feasible to extend the protocol without introducing a whole mess of mutually incompatible versions.

> 2. rotating doors/trains/etc. (especially large ones, or slow-moving ones) have smooth motion rather than jumping from position to position.

This one is critical for RMQ as there are rotating brush models that are both large and slow-moving.

Extending the coords is also critical as there is at least one map that exceeds the +/- 4096 limit. 

Two, probably 3 maps in episode 1 alone will break the old +-4096 limit. e1m3rq already does, e1m5rq is highly likely to break it (look at the numbers):

http://spawnhost.files.wordpress.com/2010/11/e1m5rq_8.jpg

and e1m4rq might do as well (very deep underground lake plus very vertical structures). 

I'm actually quite shocked that e2m1rq doesn't break it too; that must be some fairly tight mapping. 

Im counting vertexes. 

I can see how a server could negotiate the right protocol for a client, but isn't it too late when trying to playback a demo that's already recorded? 

> I can see how a server could negotiate the right protocol for a client, but isn't it too late when trying to playback a demo that's already recorded?

Not with this one; it just works (just tested it by toggling features on and off while recording and playing back demos, not a bother).

Server sends version.
Server sends flags indicating which additional features it supports.

Client reads version.
Client reads flags.

Client now knows which additional features it needs to support.

The flags are stored in the demo file too, so the client can interpret them correctly from there. It's like having multiple protocols in the one version all of which can coexist peacefully with each other, and to add a new feature you just add a new flag, test for it in your code, and do whatever else you need with no fear of breaking compatibility with anything that's already out there.

void MSG_WriteAngle (sizebuf_t *sb, float f, int protocol, unsigned int flags)
{
if (protocol == PROTOCOL_VERSION_RMQ)
{
if (flags & PRFL_FLOATANGLE)
MSG_WriteFloat (sb, f);
else if (flags & PRFL_SHORTANGLE)
MSG_WriteShort (sb, Q_rint (f * 65536.0 / 360.0) & 65535);
else MSG_WriteByte (sb, Q_rint (f * 256.0 / 360.0) & 255);
}
else MSG_WriteByte (sb, Q_rint (f * 256.0 / 360.0) & 255);
}

The really cool thing is that these flags can also be cvar-ized for server admins in MP games. 

post 470 is pretty damn exciting, especially the idea of an e1m5 that breaks limits and e1m4 with a "very deep underground lake." hell yeah. 

very deep underground lake

It does make things interesting - $player will need a way to breathe down there, since when it comes down to it you can't hold your breath very long while diving in Quake.

Detailed architecture under water will also be interesting - because there needs to be air inside, but water outside. That's either a fuckload of tiny water brushes - or a func_air. 

wait, but if you update the protocol by adding new flags, how can an older client know what those flags mean?

Or are you saying that it would simply recognize it can't play the demo, and display an error to the user? 

> wait, but if you update the protocol by adding new flags, how can an older client know what those flags mean?

The point is that the older client doesn't; it works the other way around. Newer clients can connect to older servers and play older demos. 

i don't really know much at all about engine coding, so maybe i'm not fully grasping what you mean, but it sounds like what you've done is basically obsoleted protocols in general.

which, you know, would be fucking great. i hate seeing 'demo is protocol x, not y, sucker! go load another engine' :P 

okay, so that seems more like what i expected, i think i had misunderstood your earlier posts.

It seems like the old system of having svc_version to indicate a protocol version covers most of this already. (for example, aguirre added 3 new versions and his newer engines could always read older demos and talk to older servers.)

The thing that your plan for 999 seems to add, is that you can mix and match N features without having N^2 different protocols. Which is nice, I admit. I'm not totally sure how many of those combinations are really useful, but I see the value of staying flexible.

For example, I can see the idea of floats for coords/angles being a real trade-off, where sometimes you want smaller packet sizes for internet play, and sometimes you want higher accuracy for the best single player experience. And i could see how the engine could just automatically handle the choice, based on whether your maxplayers == 1, or... serve small coords to remote clients but large coords to the local client.

I guess the downside to this system, if there is one, is that the end user has less of a clear idea of what they need. For example, if a my engine can't play a demo and says "this demo uses protocol 10002", i can go find an engine that supports it. In the case of 999, an engine that advertises full 999 this year may eventually become incomplete, when a newer 999 featureset comes out. In that case, the engine will say "it's 999 but there's some bits i don't recognize, try getting a newer engine" which is still pretty straightforward, but it means the engine has to advertise "i support these subset of 999 features, which at the time of this writing, is all of them."

So maybe you should have well-defined subversions (999v2, 999v3, etc) which people can implement as you roll them out, and then users can say "demo says it requires 999v3, i need an engine that supports that or higher."

Which is almost the same as just using different protocol numbers... they are intended as "versions" after all :) 

It gives me:

RMQ engine 0.85 (feb 16 2011) Server (16646 CRC)
bad maxclients (65) from server

Host_Error: illegible server message, previous was svc_serverinfo"

Anything I can do to get it running? :E 

Can you post one of these demos anywhere? 

The demo is of gb testing my map. I can email you the map if you like :) 

I probably used an earlier build to record them. A matter of figuring out the revision and building that I guess. 

four exes and none play it, so bleh here yer go :P

Map:
http://www.zealousquakefan.com/junk/zqfarrival_test.zip

Demos:
http://www.quaketastic.com/upload/files/demos/gbzqfdemos.zip

If you've got a build dated feb 16th that might help. I've tried dec 23rd, jan 25th, feb 1st and feb 21st :E 

Oh yeah requires Quoth. I always forget to mention that guh :p 

I have an idea about the grapple. Maybe it could be used to pull certain power ups towards you? 

With pushable objects, and currently attaches you to monsters.

The behaviour against monsters isn't very clear just yet - it does no damage and they're always assumed to be heavier since most of them are.

Powerups would be weird since they're mystical things. Maybe for ammo or health though, that makes sense. 

To see if mh took a look at those demos :E 

cvar scr_crosshairscale is broken

also for some reason it crashes trying to load rubicon2 maps 

I think, metslime's 2nd one. Not sure why.