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. 

The engine isn't intended as a general purpose Quake engine. It's purpose is to run RMQ content and to act as a sample implementation of engine changes needed for RMQ content. The longer term intention is that the RMQ engine will become obsolete.

With that in mind, issues relating to general purpose usage of the engine (especially with other maps and mods) are quite low priority, and the recommended solution is normally going to be something like "use another engine".

All the same though, I'll check it out and see why it's crashing as it may be relevant for RMQ. 

I just tend to use it to play everything to get the decent FPS.

Fastvis is now good enough - even not vising doesn't take that much of a hit performance wise. 

i struggle to use anything else now. it's essentially quakespasm with coloured dynamic lights, contrast slider, better performance and higher limits. just the contrast alone made it hard switching back to QS for rubicon2 (it was metl's first map that crashed for me)

another map crashed it the other day too, forgot what it was though. 

Something to do with particles, apparently. I'm looking at the diff and I don't understand it, though... 

Careful with this - I know most people these days have multicore cpus and geforce 8 bajillions, but crucially, not everybody does. Quake's beauty is that it still runs well on "that old POS collecting dust in the closet." 

Well the key point here is that high-end hardware is not actually a requirement. The renderer has been completely restructured to allow for more efficient geometry processing (look up GPU batching on Google sometime). In fact in some cases fast vis may even be faster than full vis as the BSP tree can be simpler (traversing it can be a huge CPU bottleneck).

This can be a bit counter-intuitive because you have to throw out everything you know about how the Quake engine works and what it's good or bad at. wpoly counts become more or less irrelevant, wide open and complex scenes are no longer a problem, heavy dynamic lighting comes almost free of charge, and so on.