
Ass is being kicked liberally, as in this e1m2rq shot of a colored dynamic lights – enhanced shambler letting loose at a god-moded, motion blurred mapper, er I mean player, with reckless abandon. Or something.
We’re working on episodes 1, 2 and 3, pineapple came up with a pretty good story and protagonist for episode 4, Supa worked some on cameras, Baker is making the multiplayer stuff more accessible (I heard something about downloading content from the server, and universal servers), and mh took a long look at Spike’s CSQC-winquake and needed very strong coffee afterwards. If you gaze into the abyss, the abyss gazes back at you…
Spike joined as a watcher (which gives him access to code and discussions); he showered us with his CSQC wisdom and is going to and fro over the CSQC stuff with mh. We’re trying to find out what we really need, and how to make it relatively easy to pick up for others.
One question was that of the VM – is the existing qc VM going to be hacksawed to run both ssqc and csqc, or are they kept separate? It looks like for the sake of adaptability by others, for pragmatic reasons and so forth, it is going to be the latter. This would mean a less ideal and elegant solution, but leave the existing VM largely intact and allow to gradually add CSQC support to an engine. This is what mh said:
So the idealist in me says “4a” but the pragmatist says “4c” with either qclib or a copy of the current RMQ VM rewired for CSQC. I think we have a decision here. “
4a being “one VM to rule them all”, 4c keeping them separate and using qclib or something else for CSQC.
Spike’s a cool guy; we got RMQ working properly in FTE – no more unkillable grunts – and even the bots are visible, yay!
Engine support for RMQ is looking pretty good, I think Proquake, QRack, FTE and DirectQ will probably run it, in addition to RMQ’s own FitzquakeSDL-derived engine. I can’t imagine that Darkplaces doesn’t run every Quake mod under the sun, so I hope the two will get along as well. We will probably try and keep our csprogs.dat DP-compatible as well.
The semi-project/idea of QSB (Quake Standard Base) has twitched a little recently, so it might not be quite dead yet. How a new standard comes about, and in how many steps (I’d assume two steps, the first one consisting of stuff that is already existing and/or easy to implement, the second one consisting of a lot of extensions and more esoteric stuff, including a standard protocol), remains to be seen. It could be a sort of document, or it could be simply RMQ kicking down the door and putting down its heavy foot matter-of-factly, declaring “this be the standard”. With a Yorkshire accent.
We are thinking of others, though. Protocol 666 is apparently relatively clearly written and easy to work with, all credit for this of course goes to metlslime, and RMQ’s stuff is basically only flansched on top of it. We’ll see how CSQC support impacts the whole thing, but mh has already said that it needs to be as clean and portable as possible, practically acting as a reference implementation that others can follow.
Some of it is, in mh’s words, “a full hostile takeover” though. Well. He is mh, though, and this is RMQ. So a certain amount of “make it so” is part of the whole thing’s DNA.