I wrote a lengthy history, but - what ijed said.

Lengthy history might appear at blog. 

I noticed that DirectQ has a network protocol 778 which is referred to as the "Remake Quake protocol", but the RMQ engine has 999 as its official protocol. Are these two protocols different, and which one is going to become the final RMQ protocol?

Also, MH, was there ever at protocol 777 and if so, is it only present in older builds of DirectQ?

I ask because I've seen some demos in the Rubicon2 thread that were recorded in 778, and wondering if this is now a protocol that needs widespread support since people are distributing demos with it. 

778 is an oddity; I'd been using DirectQ for protocol experiments at one point and unfortunately it got released. I'm pretty sure that the only difference between it and Fitz is that it uses floats for coords and angles everywhere. I'd say let it die; DirectQ itself is going back to 666 as the default.

777 did exist and was GB's original RMQ protocol, which I'm almost certain was identical to 666 but with the number just bumped for future modification (and possibly with shorts for angles, I don't remember). Don't think it was ever released publicly, but it may have been privately circulated at one point.

999 is the intended "final" (whenever that may be) RMQ protocol. As it's WIP nobody should be releasing demos made with it, and it's always been clear that anything RMQ is subject to change (999 has already had one change since the demo release). The nature of this means that interim versions of 999 will get out, but the alternative option is to create a whole bunch of interim protocols all of which would probably need to be supported. What I'll probably send up doing is adding a "ProtocolFlags" uint to both server and client, and use that to communicate differences between successive revisions. Bleagh.

If nothing else all this makes me appreciate even more the route you took with 666 (although I do wish you'd bumped coords to float and angles to short; many of the maps need both pretty badly). 

If nothing else all this makes me appreciate even more the route you took with 666 (although I do wish you'd bumped coords to float and angles to short; many of the maps need both pretty badly).

so does this mean standard FQ will never have extra precision angles? :S 

> so does this mean standard FQ will never have extra precision angles? :S

Unless metl bumps the protocol in the future, it can't. Well, I tell a lie; it does for the player viewpoint, but not for other entities. 

but in order to do that, he'd have to either make a new protocol or previous demos and such wouldn't work anymore, right? 

Speaking of precision, and from a standpoint of zero technical knowledge but; since part of your aims with RemakeQuake is to expand on the engine and tech, what about importing more features of Q3 BSP and such into it (for example less fiddly restrictions on brush shape and precision). You already seem to be making maps that pretty much need your engine to run properly anyway :)

I've no idea how hard such things would be to do, just thoughts :E 

Actually, 999 is the WIP protocol number for RMQ - a dev protocol, and it should be understood as such. As in, 999 isn't 1000.

There will be a protocol 1000, perhaps as a Quake Standard Base protocol (that was the thought behind choosing 999). But since RMQ is years from a full release, an RMQ-(and thus Fitzquake 666-)based QSB protocol is way in the future.

The only other candidate for a QSB protocol would be DP7 I think, but 666 is just better documented and seemed more portable to me when I got to pick the engine to base RMQ on. :)

BSP format etc. concerns are a recurring topic in RMQ discussion and elsewhere, but please understand what we are pushing right now. We have no capacity to stem all at once (well, only almost - I read on the trac today that RMQe now has a basic csqc implementation, not to mention the recent addition of a video capture method, go figure).

It will all come together in due time, and everything will hopefully be documented and portable and crossplatform and as friendly as possible; and as solid and ruggedized and sane as we can make it.

As for an updated Fitzquake protocol, I believe 777 was only in discussion for a short time as far as I know, so both 777 and 888 should still be free.

And yeah, some RMQ maps break protocol 666 badly. 666 still has the original map size limit for example, which is broken already. 

so does this mean standard FQ will never have extra precision angles? :S

Fitzquake might support this by either adding support for other people's protocols (like RMQ) or by introducing a new one of its own with a new number. As you point out, i can't change 666 without breaking compatability with everything that already exists. 

in non-tech terms? just curious. 

The main things that break are demos and servers. If you record a demo using protocol A and try to play it back with an engine that doesn't support that protocol, you'll get the dreaded "illegible server message" (an error that will be very familiar to anyone who's ever done protocol work). If you have a client that doesn't support protocol B and you try to connect to a server that only supports protocol B, you'll also get the same error.

Tech-wise in RMQ the major requirements for a BSP format are extended capacity (particularly in vertexes, but to a lesser extent in marksurfaces) and detail brushes. These are priority and any consideration of alternate formats must address these before anything else.

Protocol-wise, 999 has had two revisions since the demo was released, and both of these break compatibility. The most recent one is the last one that will ever break compatibility though, as 999 now has the ability to be extended and adjusted at will while retaining compatibility throughout all iterations of it. 

demo conversion is always a possibility though right? i remember aguirre released a utility for converting demos recorded in his engine (which used its own protocol iirc) so they could be played in regular ones. 

Convdem only works for protocol 15 and 10002. The tool can't process any of the other ones. 

You're right, it's a possibility. However, the question is if someone would be willing to modify the tool to work with the other three big protocols as well. 

It wouldn't be difficult to extend the tool (or to write a new one) for other protocol versions, but there are messages in some protocols that just don't even exist in others (I'm thinking alpha as the most obvious example).

The intention with 999 is that at it's most basic level it is identical to 666, with the exception of an extra writelong (on the server) and readlong (on the client) following the version. Conversion from 666 to 999 is just a matter of adding that extra long and making sure that it's 0. If it's not 0, then things get interesting as the value of it will define what's different (that part is still WIP). 

ta, thanks for that. Although I was actually wondering about the precision thing you guys were talking about. 

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.