<!-- 8 Mar 2000 -->
	<P>Palisade's away for a bit.  He should be back sooner or later but
	until then things are a bit muddled---sometimes life doesn't leave
	us with the opportunity to prepare for a need to become scarce for
	awhile.  Since the show must go on regardless, the project's core
	coders have been picking up some of the administrative tasks 'till
	he gets back.  Bear with us, it ain't exactly our department.

	<P>This update will probably not be as frequent as many of you might
	want.  I'm going to stick to development issues mostly, but I'll
	cover them in detail.  Usually after the fact.  But it will be
	updated.
	
<H2>How stable is stable?</H2>
	<P>Pretty damned stable from what I'm hearing, unless you run win32.
	Sorry about that, I don't do windoze so it didn't get tested.  I
	have and will apply pretty soon a fix for that.  Look for 0.1.2 to
	be released.  Want a release date?  Tough, I know better than to
	offer you one.  We'll make sure it gets spammed to the usual sites
	when it's ready believe me.

	<P>If you have a patch for something you want to go in to stable,
	send it to me!  Now's the time to do it.  I have patches for the
	cache mismatch bug planned.  Our newest win32 coder, Tonik, has a
	fix for the win32 stuff in my inbox right now.
	
<H2>How unstable is unstable?</H2>

	<P>Well, dispite some problems with COM_Parse() that are screwing
	with QW, unstable works rather nicely.  taniwha is working on it,
	should be fixed soon.
	
	<P>raptor has been playing with volfog again and has it replacing
	the water brush for testing purposes.  Give Necropolis a very nifty
	effect by grabbing yourself a watervis'd map and trying it out.
	raptor recommends r_wateralpha .3, r_volfog .0009, and r_waterripple
	5.  Be forewarned that the volfog code currently uses the stencil
	buffer which is almost guaranteed to not be hardware accellerated.
	Expect a FPS drop.  Using the stencil buffer is really not a good
	idea and raptor will fix it if I don't first.  He's got other visual
	toys in mind too.

	<P>We've decided it's time to kill the UQUAKE and QUAKEWORLD defines
	in common.  Some of them won't go away, but many of them will.  And
	soon.  This brings us one step closer to a single unified game.
	Before that can happen though, we need to be able to build a UQuake
	dedicated server.  Remember unixded?  Of course you don't, it's
	ancient and it sucked.  Well anyway, it needs to be able to be built
	and used once again so we have a point of reference for putting a
	server inside the QW clients.  These two things are the last major
	hurtles to a unified game and tree.  Everyone is encouraged to help,
	whether they're actually part of the project or not.

<H2>Standardize this!</H2>

	<P>QuakeForge has joined the QE.. uh, right.  QuakeForge has joined
	the QSG mailing list to hash out standards with other projects.
	We've generally agreed that we've all gotten a few nifty features
	implemented while we've been getting used to the new codebase (and
	in QF's case, rewriting it in the process!)  We're just about at the
	point that we're starting to talk about where to go from this point
	to establish and maintain working standards.  More news on that will
	become available as soon as we figure it out for ourselves.

