website/sotc/sotc1.html

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