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. 

I run my maps on a non-gaming laptop that overheats pretty quickly with even fitzquake due to the C/GPU usage.

Most of the original Quake architecture is based on you having a crappy PC, or is just completely outdated in terms of software (as Mh says).

Its why a monster pc that doesn't have any problems with, say, Crysis, has problems with some of the bigger Q1 custom maps even though you're looking at a fraction of the poly counts, texture quantities and texture sizes. 

It doesn't matter if you have a good or bad system to run the engine on - it'll still be incredibly slick. 

Gotta also remember that Quake's original software design was based around a software renderer running on an MS_DOS machine with a p60 and 8 MB of RAM. That was then crudely ported to run on $25,000 OpenGL workstation cards, and then crudely ported again to run on first generation 3DFX cards through a Glide wrapper.

So a lot of the design decisions made back then either don't work well (immediate mode), don't work at all (gl_ztrick) or are just plain dangerous (writing to the front buffer) on more modern GPUs (and by that I mean any consumer-level hardware from about 1999 or so that has a full native OpenGL driver).