website/sotc/2000/0308

65 lines
3.2 KiB
Plaintext

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