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. 

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