A demo is due soon, but if you only need a progs.dat I reckon we can simply upload that. 

I'd like to try out my map.

o_O just realized this. :) 

I'm a lot slower than Gb - but
if you want to be in on the latest updates then you can either join the team or wait a week or so.

The next demo is coming to the boil, but we'll never complain about new blood. 

I wouldn't have much to contribute. New to mapping, the only thing I've done with textures is add some snow to them, and don't know enough quakec voodoo. I'll just wait for the demo. 

To make a bold statement: It should be out this year. 

 

 

Spirit++; 

bitch ad style bitchmaking I'd like to avoid ;-)

other bitchmaking is ok. 

:O 

http://kneedeepinthedoomed.wordpress.com/2010/12/24/xmas-presents-part-2/

This might be already waiting as a news post, but just in case. 

 

thanks ijed/everyone - can't wait to play this! 

You should use -sndspeed 44100 on the command line, otherwise half of it will be lost on you.

isn't this default for rmq engine? if not then it should be!

can't play this or even access trac for the next few days since i'm at my parents. not played the full version with chthon yet so looking forward to it :) 

Following the drama about this project not being covered at Quaddicted and not being in its archive I have a question:

What ultimate goal or vision are you working towards? 

In terms of gameplay. Some have said a spiritual successor to Quake 1 which the strogg game made afterwards and given the same name didn't quite fit.

I spose that's a fair way of saying it, although we are remaking the original maps and monsters. A lot of what we're doing is things that id probably intended on some level at the time but were limited by the tech or monetary constraints.

External to the project we're interested in community support and maintaining the project open source. Things like rotating tech development, Mh's engine voodoo and so on. 

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.