qf/website
0
0
Fork 0
mirror of https://git.code.sf.net/p/quake/website synced 2024-11-24 05:01:23 +00:00
Code Issues Projects Releases Packages Wiki Activity

Added dated SotC archives for future automated system I'm working on.

Browse source
This commit is contained in:
Jeff Teunissen 2000-04-26 00:29:26 +00:00
parent 463c259c14
commit 6446a22aed
7 changed files with 620 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

173
sotc/2000/0214 Normal file
View file

@ -0,0 +1,173 @@
<!-- 14 Feb 2000 -->
<P>I could give a long speech full of lies, half-truths, and shameless
attempts to get you to support my agenda's various components, but
dammit Jim, I'm a coder not a politician!
<P>So instead I'll just talk about what's going on with the tree so
people who don't hang out on irc know what the fuck is going on for a
change. Maybe Palisade or someone should see that relevant tidbits
make it to the website's news page. What's here's mostly for other
developers and non-novice users so I'm going to feel free to go into
technical details of things the average non-coder may be confused by.
Tough. =&gt;
<H2>QuakeForge 0.1.1</H2>
<P>It's not out yet. In fact, it's not even close to out yet because
I pretty much have become the stable release manager here because like
an idiot I stepped up to the plate when someone needed to in order to
get 0.1.0 out the door.. First lesson: Never volunteer yourself to
do a job that nobody else wants---you'll find out quick why they don't
want it and you won't be able to get them to take it later. ;&gt;
<P>What needs to be done for QF 0.1.1:
<UL>
<LI>There's at least one reproducable bug in at least UQuake
I can find.. go to the start map and walk over to the hard
hallway. Wait for the message about hard skill and take a
hot bath. It's quite likely that when you die, you'll sig11.
Don't try this in an OS less than any good unix folks---a
sig11 is death to your box in win32. I _don't_ know what's
causing this per se other than that it seems to be
reproducable in cases where that center message is on the
screen. However the seg is in Sbar_DrawFace()... I'll
probably add some sanity checks to that routine and see what
happens.
<LI>There's another generic report of a segfault. It may be
the above bug.
<LI>qw-client seems to work fine. At least, I haven't gotten
reports of bugs. qw-server also hasn't got any reports of
problems yet.
<LI>I have a report that under the -3dfx target the oldstyle
status bar is missing the background tile and therefore has
a "void area" around the edges of the statusbar. I _thought_
I fixed this before release but then I only tested UQuake and
then only the -gl and -ggi targets. It's a minor fix and I
know how to fix it if it's still broken.
<P>Mission packs in -gl target all work already, save
hipnotic. -gl dies saying the scrap texture is full. There's
already a fix for this in the code, I just need to enable it.
Currently unstable allows four scrap textures whereas stable
allows only one. Four is overkill (all hipnotic needs is two)
but I figure there's got to be at least one other mod out
there that needs the extra space for tiny textures.
<LI>UQuake noclip mode... If you've tried it in -gl or -3dfx,
you know that if you walk outside the map you get a very
doom-like result (ie, the engine doesn't know what to draw so
draws nothing) rather than quake's nice "void" color. I fixed
this in unstable, the fix was again minor.
</UL>
<P>When I'm satisfied that things are working okay, I'll call it 0.1.1
and make sure archives get made. I'll also upload Debian packages
(since I do that) to potato and woody. They may not ever see potato,
but I'll try since the above would really be just a bugfix release.
Someone who cares will have to make rpms, win32 binaries (if that's
possible in the 0.1.x tree, it may be now and not have been when the
release archives were made I don't know..)
<P>&nbsp;<BR>As a side note, there is talk (since so many of QF's
coders are Debian users and developers) of modifying the UQuake
console version string in 0.1.1 to read "QuakeForge Quack (B-Finn
edition) 0.1.1" or something similar in honor of one of #debian's
most memorable and amusing trolls, B-Finn who always wanted "HELP
FOR PLEASE TO INSTALL QUACK"... He made it clear that he meant Quake
and was obviously trolling (that, stupid beyond belief, or someone's
sick idea of competition to megahal...) It probably won't happen,
but then again ....
<H2>0.2 development</H2>
<P>If you hadn't noticed, a lot is broken lately. Understatement of
the entire 20th Century I realize. We've begun working on the shared
object support. Linux svgalib and X11 work, sortof. X11 is being
broken again because of the seperate input/video things being LAME(!)
and broken anyway, but the results will be cool.
<P>You can thank Mercury for breaking the tree with what he knew was a
badly designed module solution, but he did lay the framework needed to
do it right. He's also getting stuck fixing it which is of course
poetic coder justice or something. ;&gt; Currently the shared
objects must be in the dir you run from--taniwha is working on a path
cvar which will be searched.
<P>&nbsp;<BR>Bad news: Someone broke qw's protocol. Client or server
we don't know, but it's broken. Unintentionally, it will be
repaired. At least, as soon as someone else fixes it or I get a
working -ggi target, timestamped server console, and about an hour to
work on it in.
<H2>Celebrity advice</H2>
<P>Good gods, where to begin? If you don't know it you must have
been living under a rock or something: Zoid has taken an interest in
QuakeForge(!) He's asked for cvs write access and has been hanging
around to answer questions, offer suggestions, and generally remind
us that he thinks we're all insane. (He's right, of course..)
<P>Here's what he's had to say so far:
<UL>
<LI>The SVGALib code is an evil hack. [We knew this.]
<LI>He has no idea why we're merging the two code trees. He
points out that a single player QW game won't work too well
because of the physics differences. Probably we'd have an
easier time of it if we just merged obviously common stuff
like the renderers and called it good.
<LI>He says he's going to see about merging Q3A's X11 mouse
code into our tree. It'll do us wonders.
<LI>The way we're doing input (and probably by this time next
week video and sound and who knows what else) modules is
pretty much exactly how Quake2 does them. He's offered some
ideas and opinions to all of us working on them.
<LI>The brightness control in gl targets.. Just gamma correct
the pallete, not too hard to do. This will work for MANY (not
all) cards and has the advantage of being cheap. No framerate
loss is cheap. =&gt;
<LI>The pixel splatter after a cshift or in certain places
(like the start map's lava) are related to t-junctions. He
explained it to me and if someone is bored and wants to play
with it I'll dig up the irc log. Essentially we need to clip
textures before thee video card has a chance to fuck up
trying to draw them. This only needs to be done at
t-junctions which is why the problem is some places and not
others.
<LI>He's admitted that Quake2 is essentially Quake1 with
shared object renderers, colored lighting (GL only, it's just
not colored in software), and not really a whole lot more
than what we have now in uquake that is #ifdef QUAKE2'd..
[This leads me to believe that it is possible, even
reasonable that we might be able to make QF able to read and
play a game of Quake2.. That would ROCK IMO...]
<LI>Surprisingly, Zoid thinks we should break the QW protocol.
He's got good reasons too: The smurf attack possible with the
current server, the exploit or two which will down any QW
server out there, and the time cheat problem. Turns out that
win32 people running qwcl 2.3x for anything longer than abou
t a day or so are likely to be caught for cheating because
they actually are! They might not even know it either. The
2.40 (source) release fixed this problem, but a 2.40 server
is backwards compatible with older clients. [We'll be
working with QSG to make sure that the protocol changes in
question are supported by everyone. The client will be able
to be compatible with both 2.40 and the new protocol real
easily so we'll probably maintain compatibility there.]
</UL>
<P>We're obviously thrilled Zoid's taken such an interest in our
project. We're very grateful to have him working on the project
where time permits him to and for the advice he's offered to us.

107
sotc/2000/0222 Normal file
View file

@ -0,0 +1,107 @@
<!-- 22 Feb 2000 -->
<P>I'd like to say first off that based on the feedback I've gotten from
my last State of the Code update, I'll probably be doing these more
often. They'll also be showing up on the webpage soon I hope. I'm
keeping archives until that happens. This one's a bit long because a
lot has happened and I should have wrriten this about Friday night.
Sorry for the delay.
<H2>0.1.1 update</H2>
<P>In general, the update for 0.1.1 is coming along nicely. A lot of the
changes I have been working on have actually been committed to thre
tree. If you grab the Release_0_1 tag out of CVS right now, your
version will still say it is 0.1.0, but it should have most of the
bugs fixed. All in all, a very good thing. Here's what I've still got
to do with it:
<UL>
<LI>Report of a segfault somewhere. This should be fixed now, but if
it's not fixed I need to know.
<LI>I don't like my current fix for noclip in unstable and I don't
want to backport it. In a few days I hope I will know if there is
a better solution. I'll fall back on the working solution I have
in unstable if I can't find a better solution. If I change what
I'm doing, it'll be tested on unstable first for quality control.
<LI>Report the backtile isn't getting drawn around the classic
statusbar in the -3dfx target. It gets drawn for all the others
and testing this target isn't easy for me to do, so I haven't done
it yet. Will soon.
</UL>
<P>That's it! Tentatively, 0.1.1 can be ready to roll as early as this
weekend. You can still grab the Release_0_1_0 tag for the current
release, but please grab the current stuff and "test" the hell out of
it. 0.1.0 was pretty good, but 0.1.1 should fix every known issue I've
been told about since then. Break it if you can, please!
<H2>Unstable updates</H2>
<P>If you have been living under a rock and don't know it, unstable works
again! Mostly. Mercury has, in fear for his mortal life, undone many
of the changes made to unstable which caused so much breakage before.
The only target not working again is the SDL target because nobody
else but me seems to be building -sdl and just because I build it
doesn't mean I understand that target. (Remember, my areas are the QF
build system and some of the stuff deep in the engine core!) If you
can fix it, step up and do so.
<P>Win32 support. xC and Endy have Win32 "working" again under VC++, for
some versions of working. xC is working on the problems, but could use
a hand if you can help him. Here's what's broken:
<UL>
<LI>asm code in software (gas2nasm problems?)
<LI>software renderer isn't at the moment
<LI>qw-server seems to be having issues
</UL>
<P>The protocol breakage between the QW clients and server has been
fixed. We are still (unfortunately) compatible with Win32 2.3x clients
with all the problems that invites. We'll probably so remain until
we're done with the merge because we don't want to change the protocol
on win32 people until we know we can support them. Currently we just
don't have enough win32 developers with their hands in the code to
make sure it remains working.
<P>I've begun working on QER/QSG colored lighting in QF. It's the first
QER feature I'm working on in the hope that we'll eventually be
working from a common codebase. That's up to them of course but we all
know the QF tree is superior to the q1source tree. Still, they may not
want to have to work around software renderer limitations, so we'll
see.
<P>The merge continues at impressive speeds. The merge hall of fame has
a new face today as taniwha has proven his insanity by filling the CVS
list with commits of merged files.
<H2>Project relations</H2>
<P>We've been talking to QuakeWorld Forever about their secure QuakeWorld
implementation. I will probably at some point be helping them
implement public key cryptography. I've explored the best way to do
this (Netrek uses a similar strategy) and have a few ideas. We'll see
how they pan out.
<P>As I mentioned above, I'm implementing some QER features and Endy from
QSG has been picking away at a few of our Win32 problems. I generally
consider these two groups to be closely related, but we're going to be
working with them more to make this a truly multi-project effort and
ensure some standardization and compatibility between our projects.
<P>If you haven't heard, you've lived under a rock for quite some time
now. QuakeLives is and has been almost since the project's inception,
in violation of the GNU GPL. They tell us that they did not and do not
have Copyright infringement problems with that license, the GNU GPL.
They demanded we remove any statement saying otherwise from our
website. (Mercury says he left QuakeLives because of GPL
violations---this is noted on our news page.) Since we can prove
otherwise, we've refused.
<P>Speaking of QuakeLives, the MegaTF website was distributing copies of
a release marked 2.54 without source. Slade of QuakeLives told us that
MegaTF was distributing "warez" and later denied making that
statement. We've got logs if anybody cares enough to read them,
naturally. At any rate, Ambush has removed the offending binaries
until he has some idea where things really stand with QuakeLives. He
is not retargetting MegaTF in the meantime. Talk to him, not to us,
etc.

64
sotc/2000/0308 Normal file
View file

@ -0,0 +1,64 @@
<!-- 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.

117
sotc/2000/0318 Normal file
View file

@ -0,0 +1,117 @@
<!-- 18 Mar 2000 -->
<H2>How are things going? Your SotC update is late again.</H2>
<P>Yeah yeah, I know. Okay, first the quick news: Palisade is
back. The website is still under construction but it got a lot
easier to construct since now it updates immediately after a CVS
commit. With Palisade back, it seems that everyone who planned to
vote on the logos has now done so and we should hopefully have a
result soon.
<P>I promised I would keep the crap not related to the technical
aspects of the project short and at the top where they were easy to
skip, but a very important issue needs to be discussed whether it
fits the usual content of this page or not. Here it is:
<H2>Will QuakeForge be able to run Mega2k?</H2>
<P>How many poeple can ask that in two weeks' time? I lost count,
but there were a lot of inquiries. Unfortunately, I have bad news
for you. MegaTF says they're quite loyal to QuakeLives, despite any
legal or other problems the engine team has had or may have in the
future. Ambush says on his radio show that he hopes all of the
engines will support MegaTF though, so we didn't really expect any
problems.
<P>I've been trying for several weeks now to establish a regular
dialogue with Ambush, but people close to the project have told me
that most likely my emails wouldn't be seen, much less answered. So
I mentioned something about trying to connect with him durring or
after the 17 March 2000 MegaPhone show. Several other people from
the team as well as from other teams came as well to help show the
players of MegaTF that indeed we are serious about supporting the
mod fully.
<P>Things remained civil until some of the QuakeLives guys came in,
and things started falling apart then. Attempts to calm the fires
weren't terribly successful until not long before the show's start.
Things remained sane throughout most of the show. Ambush asked for
another small feature to be added durring the show (the console
version string gets in the way and he'd like to get rid of it) and I
wrote and committed the feature he asked for on the spot.
<P>Fires started burning again shortly after the show ended. I'm
not unsurprised, but eventually I did manage to wind up talking with
DyerMaker out of the view of the main channel so there was actually
a chance of talking. The results? I am now aware that MegaTF's
loyalty to QuakeLives extends as far as deliberately shutting out
any engine but QuakeLives from being able to run Mega2k. They've
decided that since Slade will not take part in creating an open and
secure standard for all engines, they can only support his. In
order to do that and do it well, they have to ensure that we can't
run Mega2k. Nothing personal against QuakeForge or anything, it's
just how the politics have played out.
<P>So from where I'm sitting, it looks like Ambush isn't interested
in other projects and engines supporting MegaTF. Or at least, he's
only interested in seeing QuakeLives-endorsed projects support
MegaTF. Nothing personal and no offense intended toward us, but
they seem to be intending whether they say so or not to be
exclusively QuakeLives.
<P>Well, nothing personal, but I have no intention of playing these
silly one-must-win-and-everyone-else-must-lose games. I'm quite
sick of them by now - but I'm surprised nobody else seems to be.
We'll do the best we can to support Mega2k whether they want it or
not. Why? For one, some of us play it. For another, and more
importantly, many of <EM>YOU</EM> play it. I lost count somewhere
not far before 150 people who have asked in recent weeks if
QuakeForge intended to support Mega2k's new features because you
don't run win32 and aren't interested in starting. <I>Yes</I> we
will. It may not happen until after Mega2k's release if the needed
information to do so is going to be withheld from us, but you better
believe it will happen.
<P>Am I being a bit harsh here? Quite possibly. As I write this,
it is now merely 24 hours after what we can all agree was a rough
night for a lot of people. From my perspective, it looks like
MegaTF is refusing to allow Mega2k to run on anything but QL dispite
Ambush saying he wants all the engines to be able to run it and to
work together or interoperability standards.
<P>It seems that's what's going on here, but that doesn't mean it is
what's happening. Chances for misunderstandings have not been
infrequent and it's not unlikely that MegaTF would be absolutely
thrilled to see a project dedicated to compatibility and open
standards like QuakeForge working to make sure not only that we
support Mega2k, but that every project out there can. And even more
importantly, that the user doesn't have to worry about whether or
not project foo's client is going to work with project bar's server.
<P>If that's the case, then all of the above is essentially moot.
We'll do our best to make sure we support Mega2k right out of the
archive the moment it and that whatever it takes to make sure it
does work has already been made available for and incorporated into
every single project we can find, whether they're affiliated with us
or with QSG or MegaTF or the abominable snowman or not. Lack of
standards can only hurt the game. Since that's obviously a very bad
thing, hell yeah we'll do everything we can to keep it from
happening.
<P>So what are you, the players of MegaTF who don't want to be tied
to a single engine and a single operating system, supposed to do
about any of this? Make some noise! And I don't mean go around
accusing MegaTF and QuakeLives of trying to quash all the other
engines either---that's the wrong kind noise to be making. It also
is quite likely not true. The noise you should be making is for
Mega2k to run on your preferred engine. And I do realize for a lot
of you, the engine you prefer happens to be the only one that even
runs on your platform. If that's the case, make sure you're heard!
You can write to me until the cows come home but I'm not the one who
needs to hear from you!
<H2>The actual technical stuff</H2>
<P>If you're still here after all of that, I'm impressed. Release
of 0.1.2 hasn't happened yet, but could really anytime now. Mostly
I have just had other issues on my mind. Plus I don't want to give
too much false hope here, but I really think a release of 0.2.0
isn't all that far off. I've been focusing my efforts in that
direction.

55
sotc/2000/0319 Normal file
View file

@ -0,0 +1,55 @@
<!-- 19 Mar 2000 -->
<H2>The fastest SotC update ever!</H2>
<P>This update is so close to the last one posted a mere six hours
ago that most of you reading it never even saw the last one. Don't
worry, anything important is being retained in this update.
<P>Palisade is among the living believe it or not and we finally
have his votes for the logo contest. He's pretty much it so the
good news is that we should very soon have a new logo!
<P>I also had mention in the last SotC that the website updates
itself whenever any of us checks in a change now. It's very nifty
and is helping us get the new site layout done faster. Something I
didn't mention before is that we have somehow managed to convince
twisted to work with us on spicing up the page a bit while keeping
it functional and efficient.
<H2>QuakeForge and Mega2k, redux..</H2>
<P>We all owe Yanster big for helping us get in contact with Ambush
of MegaTF tonight. He was in #QuakeForge for a few hours talking to
the guys present at the time. Among them were Mercury, Deek, Endy,
and devkev. I was there too, but I was and am half dead from sleep
deprivation so I can't say I'm totally coherent then or now.
<P>The guys in the channel helped Ambush get MegaTF build with qccx,
which was pretty cool I think since qccx is looking like one of the
most interesting quakec compilers out there to us and will probably
become our preference once qcc is released under the GPL.
<P>Mercury was talking with Ambush about support for Mega2k in
QuakeForge. I can't say where that's going yet because the
discussion hasn't reached conclusions yet. Still, the discussion I
thought was so improbable is happening. That's a good thing for the
entire community I think. I'm glad to be wrong this time.
<P>What I said before about making sure that every engine can
support MegaTF, I meant every word of it. I will do everything
humanly possible to ensure that the features needed become
standardized and that all of these engines are intercompatible at
the protocol level. And securely too - what's it matter if all the
rest of this happens if any person can just cheat their way to
highest scores?
<P>Right now what seems to be necessary is time. I still think
people who care should make sure they're heard so MegaTF knows that
Mega support in other engines is important to you. That goes double
if you only have one engine for your platform to choose from.
<H2>The actual technical stuff</H2>
<P>If you're still here after all of that, I'm impressed. Release
of 0.1.2 hasn't happened yet, but could really anytime now. Mostly
I have just had other issues on my mind. Plus I don't want to give
too much false hope here, but I really think a release of 0.2.0
isn't all that far off. I've been focusing my efforts in that
direction.

35
sotc/2000/0402 Normal file
View file

@ -0,0 +1,35 @@
<!-- 2 Apr 2000 -->
<H2>Mega2k support in QuakeForge committed!</H2>
<P>You read it here first! (unless you didn't) QuakeForge now works
100% with Mega2k. I spent several hours trying to tune the flight
physics for the airscout so they work the way people would hope.
<P>While you MAY be able to connect to a QF server running it with a
standard 2.3 or 2.4 Id Software release QuakeWorld client, I won't
recommend it. The first time an airscout goes flying you're likely
going to confuse your prediction code something terrible! As always
our implementation is open to other projects (I've sent Endy of QSG
a copy) and when he gets it working in QWF he'll be making the patch
available to all of the QSG projects which will hopefully make this
a non-issue.
<P>Look for a real playable QF server running Mega2k as soon as
Ambush is ready for beta testing. I'm running a test server now but
you're not going to get a good game going on my DSL connection so
it's mostly been there for testing airscout physics.
<P>I might have to put up a screenshot of dyerfort's ducks, they're
a quack!
<H2>Emminent release of 0.2.0</H2>
<P>You may or may not know this, but I've deliberately held off from
finishing 0.1.2 because I've been busy tracking down bugs and things
for 0.2-d.. The reason? It's time to release. Or at least, it's
time to declare it time to release and fix the remaining obnoxious
buglets. They're not overly complex but there are several of them
to fix.
<P>I won't give a release date because if I do I promise we'll miss
it. Most of the core project people are Debian Linux users after
all. (if you don't get it, don't worry..)

69
sotc/2000/0416 Normal file
View file

@ -0,0 +1,69 @@
<H2>QSG standards version 1 in QuakeForge!</H2>
<P>Everyone needs to upgrade to recent CVS if they're using any
version of QuakeForge 0.2-d after view height offset support was
implemented for MegaTF, how it's done has changed incompatibily.
The good news is that the reason this happened was because of the
intruduction of conformance to the draft of QSG standards version 1
(which hasn't yet been published because we might fit some other
minor stuff in there maybe..)
<P>I don't have a URL for Coderjoe's win32 binaries but I'm going to
post news on the main page about the QSG standard as soon as we hash
out the last few issues this standard version will support (mostly I
think we have to decide if we're even going to touch skyboxes at all
and what we're going to do with them.
<P>Since that's not going to be a requirement for engines to support
in this version, I've gone ahead and done the *qsg_standard key and
set it to 1. We are QSG standards compliant!
<H2>QuakeLives (again)</H2>
<P>People keep asking us to work with other engines (including but
not limited to) <A HREF="http://www.quakelives.com/">QuakeLives</A>..
I'll say this one more time, we've tried. Every major engine project
excepting QuakeLives has been part of QSG for some time now. They've
decided to have BuBBa represent their project in QSG, but if you don't
mind my opinion in here that seems to be a token gesture on their
part. If you've talked to BuBBa you know what I mean.
<P>Despite their promise to <A HREF="mailto:johnc@idsoftware.com">
John Carmack</A>, QL 2.54 is available to beta testers without
source. Of course it's not on their web page but all you have to do
is agree to their beta testing terms and they'll send you a copy
happily. Of course their terms include that you don't ask them for
source and pretty much almost always have.
<P>This blatantly violates the GNU GPL under which Quake's source
was released but so far they've managed to stall, delay, flat out
lie their way out of being sued by Id Software for it. You're
invited to investigate the situation for yourself if this is at all
important to you. A polite message to John with your results may
be a good idea. I cannot believe after all of this they're still
trying to get out of releasing source under the GPL. It's truly
a sad thing to see.
<P>&nbsp;<BR>While on the topic, I got a little (16k) email just an
hour or so ago from someone who either has a copy of the unauthorized
QL source or has far too much time on their hands. It describes in
very good detail exactly how the QL rocket trail effect works. As I
suspected by looking at screenshots, it's a tri strip which works
very similar to the existing particle engine. I'd like to thank the
person properly here for the info but he wishes to remain anonymous
for very understandable reasons.
<P>Why this matters is that I can now implement the effect and it'll
be a genuine clean-room recreation of their rocket trails. If they
would've had any legal ground to stand on for a lawsuit if I'd used
their source (I can't see how since it sounds like a mod to Quake's
particle engine which is GPL'd) they certainly don't have any ground
to sue anyone who might use an implementation done by me for QF.
<P>This is what happens when you try to screw the GPL. Thanks to
the guy who sent me the email, you know who you are.
<H2>0.2.0 remaining issues</H2>
<P>A few target-specific issues and some weirdness with dyerfort's
catapults remain. Other than that we're just about ready for a new
release. Be on the lookout!