website/sotc/2000/0622

	<P>Okay people, Q&amp;A time:

<H2>"When are you going to update SotC again?</H2>
	<P>About ... right now.

<H2>"Where did the SotC history go?"</H2>
	<P>That's a good question.  It'll be back hopefully soon.

<H2>"What have you been doing the past month?"</H2>
	<P>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.

<H2>"I heard QuakeForge isn't following the GPL, is that true?"</H2>
	<P>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.

<H2>"Does QuakeForge support single player?  Your newtree stuff seems to be
QW only."</H2>
	<P>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.

	<P>After newtree QW is finished, we will be working on a project to
	obsolete both it and uquake in oldtree.

<H2>"Will you be doing a new netquake when newtree QW is done?"</H2>
	<P>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..)

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

<H2>"What then?"</H2>
	<P>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..)

	<P>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:

<H2>Will it be compatible with QW/netquake?</H2>
	<P>No.  Unlike our work with QW and netquake, this thing would need
	new clients to play new servers.

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

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

<H2>Will things like QWAdmin work?</H2>
	<P>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.

<H2>How do you plan to improve net play without QW-style networking?</H2>
	<P>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.

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

<H2>Will it work with Qizmo?</H2>
	<P>Not unless a new version of Qizmo is made for it.  That'll
	probably happen if there's much demand for it.

<H2>How do you keep people from making cheat progs for clients?</H2>
	<P>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.

<H2>Isn't that slow?</H2>
	<P>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.

<H2>Will you be doing .... ?</H2>
	<P>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.

	<P>Oh, forgot one that's been asked a dozen times already:

<H2>"Sounds like a lot of work.  What real-world benefits will it give
mod-makers?"</H2>
	<P>(I'm glad I remembered this one, it's important!)

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

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