Okay people, Q&A time:
About ... right now.
That's a good question. It'll be back hopefully soon.
Debugging the code, trying to put back some of the speed that has been lost in the GL renderer. Essentially, I've just been busy all around and haven't had time to write down what we're doing because I've been too busy making sure it gets done.
We follow it to the letter. And what's more, we respect its spirit as well. You won't find us doing anything to compromise the basic freedoms the GNU GPL works so hard to ensure. Everyone has the right to our source code and to make whatever changes to it they want provided they observe the same terms we do.
That's because it is QW only. We still maintain the old tree for that reason - it has a version of netquake called uquake which does a great job for single player games and should be compatible with Id's netquake/winquake if you want to play a LAN game with it or something.
After newtree QW is finished, we will be working on a project to obsolete both it and uquake in oldtree.
Immediately afterward. There's a saying that coders spend 90% of their time and effort making 10% of the code work right and the rest is just there. A lot of the stuff we've been trying to get stable within newtree is in that 10% of the code and that part just happens to need only a small handful of changes for netquake (and might even work with our uquake merge as-is, but we're most likely to start fresh as with newtree QW..)
After that's done, oldtree can be mothballed, pulled out of CVS put someplace where people can get if if they're curious what has already been tried.
Well at that point we'll have two versions of Quake, both much more current and wil a lot of bugs fixed. But both of them are kinda limited. Netquake rocks for single player or network games with low latency. It can deal with modem games where a packet may be lost. But it can't cope with high latency at all. On the other hand, QW can cope with the latency but sucks if you have even one lost packet. QW has no support for single player games (though we can pretty easily change that..)
The solution is a new network layer designed from the ground up to be tollerant of both PL and reasonable latencies for average (ie, crappy) modem connections. Since doing that is not really within the scope of either netquake or QW's design, we almost need to turn a new direction in development. Let me anticipate a few questions below:
No. Unlike our work with QW and netquake, this thing would need new clients to play new servers.
You'll still be able to load and play Quake-based games such as the original game, the mission packs, TF, MegaTF, and the like with it, but you're probably going to need to recompiled progs unless we find a convenient way to convert progs at load-time. We haven't worked much on the design yet (we're not working on this till we're done with what we've started) and it's still in the concept stage so it's too early to tell if we'll have to port things ourselves.
Things we can get progs source for (Quake, QW DM, TF, etc) will definitely be ported if necessary. Mega will very likely be ported to the new engine so Ambush can play with the new toys we'll be able to offer.
Not sure. I'm guessing the rcon protocol is likely to become somewhat different though so probably not. We'll either have to write a replacement or find the people who did QWAdmin and get them to either update it or let someone else update it. It may end up possible to support QW rcon though.
Games like Unreal and now Half-Life too have their network performance greatly enhanced by clientside prediction. This is the same kind of prediction used partially by QW now, but the client is much smarter because it's essentially running the same progs the server is, or at least a reasonable subset of them.
An example of something that the game currently does badly is firing a rocket or a nail. The server currently updates where the rocket is and when it was there. You can greatly speed that up if the client knows how a rocket moves by simply having the server say "(time), (person) at (origin) shot a rocket in (direction)" and leave it at that. Of course, the client needs to make sure the server doesn't have to repeat itself, but that sort of thing is easily enough done. This is the kind of thing that proxies like Qizmo can compress.
Not unless a new version of Qizmo is made for it. That'll probably happen if there's much demand for it.
If the progs on the client are trusted for anything, all a person has to do is change them and they could theoretically use the results to cheat. So we won't let them. You'll have to download progs for the client every time you connect.
In QW, downloading is pathetically slow because files are sent in tiny packets over UDP, each of which must be acknowledged before the next is sent. Sending over TCP (like websites use) is a lot faster, I mean more than 10 times faster.
For the most part, answers to questions about the new stuff we are planning are going to be variations of "We don't know" for now. As I said, we're working on QW for now because that's what people need to work right now.
Oh, forgot one that's been asked a dozen times already:
(I'm glad I remembered this one, it's important!)
As many mod-makers know, QW is a hack. A complete, total, evil hack. It just can't do many of the things the original Quake did, to say nothing of things Quake could have done such as lerping the model frames like Quake2 does. It required real effort and many painful hacks to get view height adjustment and fly movement for players into QW. Almost anything we try to do is going to amount to the same kinds of hacks and we really only have space for a few more of them before we no longer change things without breaking protocol compatibility.
So we'll break it now and make sure we have all the room to grow we'll ever need from the outset. Already I've been talking about replacing current health, ammo, etc with an inventory system made up of 128 bit flags, a bunch of integer numbers, and a bunch of floating point numbers. Enough to handle anything really. It'll be cool for players, but even more cool for mod makers. That's the idea.