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!

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

QuakeForge 0.1.1

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

What needs to be done for QF 0.1.1:

• 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.
• There's another generic report of a segfault. It may be the above bug.
• 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.
• 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.

  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.

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

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

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

0.2 development

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.

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. ;> Currently the shared objects must be in the dir you run from--taniwha is working on a path cvar which will be searched.

 
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.

Celebrity advice

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

Here's what he's had to say so far:

• The SVGALib code is an evil hack. [We knew this.]
• 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.
• He says he's going to see about merging Q3A's X11 mouse code into our tree. It'll do us wonders.
• 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.
• 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. =>
• 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.
• 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...]
• 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.]

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.