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. +