03/18/2000
GenSurf plug in Q3R1.97
Let us not forget this excellent plug in its been done for awhile now but didn't work until the new Q3R well it did work with 187 but most people didn't get that one. Anyway go get it here

Q3 id Employee Bot Files
TheOxygenTank has released a zip containing the bot files needed to use the new id player models in single player. No word on how accurate they represent how the real id employees play.

Curry Plug-in
If you're interested in the Curry Plug-in mentioned in Robert Duffy's plan, here's some info:
The Curry plugin mentioned in Mr Duffy's plan can be found here: http://curry.sourceforge.net

It's a shader manager for Radiant. With it you can preview and edit shaders selected from the texture window or a .shader file. It can also render the shader, giving instant feedback on edits and letting you see shaders without having to boot up q3.

Q3A OSP Tourney
Though their news page doesn't reflect it, the Orange Smoothie Productions beta downloads page has a new beta 0.8 of the OSP Tourney mod for Quake III Arena for download. OSP Tourney adds enhanced match play controls, an additional game mode similar to Rocket Arena, extensive weapon and match stats for all players, an advanced voting system, and more.

Q3A Bot Creator
PhatDC21's Quake 3 Bots Page (midi alert) has a new "flawless" version 1.03 of Bot Creator utility that allows you to easily turn any Quake III Arena model/skin into a functioning bot to play against in the game. As that fate-tempting flawless label suggests, the author feels the new release has worked out any remaining kinks in the program.

03/17/2000
New Q3Radiant

Here's the update:

There is an update to the tools out on our ftp. It contains new executables for Q3Radiant, Q3Map, Q3Data, and the TexTool plugin. It is very hot off the presses so use at your own risk. The change log will be quite large and is not yet included but I wanted to get this out so people could start taking advantage of new plugins. Many thanks go out to Timothee Besset, The Curry Team, David Hyde, Jason Spencer, Jan Paul ( Mr. Elusive ), Eutectic, Maj, Paul Jaquays, and everyone taking part in the ongoing Radiant and Plugin department. The Gensurf and Curry plugins look fantastic as does the upcoming MGS plugin from Timothee.

Some words of caution, brush primitives "should" work fine but they are as always subject to change. They are required for the new grouping to work, but I would not use them or the new grouping yet as both are very much under construction.

The filename is "Q3ToolSetup_Mar172000.exe"

Local Copy is "Q3ToolSetup_Mar172000.exe"

03/16/2000
Q3A Game Source 1.16n Released
As reflected in Robert Duffy's .plan update, id Software has released the game source code for version 1.16n of Quake III Arena. Id ftp source, and here are the details, straight from Robert's .plan:

The game source for 1.16n is available on our ftp and should be appearing on mirrors soon. As with the previous source release this is a Win32 installation.

The code should be compilable into vm's without Visual C headers this time around so lcc (included) is all you need.

Q3A ClanArena
Version 1.6 of Quake 3 ClanArena is now available, offering gameplay in the classic style of Quake (1) Clan Arena. The new version was compiled using the new version 1.16h source code, and features a new directory so clients can download the .pk3 file when connected to a pure server and to allow Linux users to run the mod. Client side files are included in this release which now displays scores in spectator mode, cleans up the text displayed on the HUD, and displays the health/armor of the person who killed you.

New Quake 3 Benchmarking Demo
Hellhound has posted a new Q3 Crush Demo that is supposed to tax a computer system heavily. It's on Q3DM17 with 24 bots. They say that if your system gets over 20 fps then it's very good for competitive play.

03/15/2000
Official Quake 3 1.16n Patch Released
Yes it has been released for all three Os at once this time.
id Software has released the official Quake 3 Arena Point 1.16n Point Release (aka a patch). This one is non-beta folks so you can all finally upgrade! . You can go to Quake3Arena.com for mirrors if one of the links below doesn't work:

All Files  Stomped FTP1 and FTP2   3D Action Gamers   TheOxygenTank  3D Files

TERRAGEN tutorial
I uploaded a tutorial today explains how to make your own sky graphics using Terragen check it out here.

Update from Robert A. Duffy
The 1.16 point release is done. It should start appearing on mirrors soon, in all three flavors. The release also contains the original player models done way back when for Xian, Carmack, Hellrot, Paul Jaquays, Willits, and Brandon James ( now at Rogue ). These are included in the PK3 file. Available separately are the Max files for each as well.

There were only a few changes between 1.16m and 1.16n, the readme details what was changed. I should get the code bundled up and out within a few days as well.

Any problems with the release ( or the game in general ) need to be e-mailed to livehumanfeedback@idsoftware.com, this will ensure the issues get added to our bug database and looked at.

The Mod scene is pretty much exploding, I have a very long list of Mods to look at and play. A few issues have come up that are centered around Mod coding and requested features.

-Config files. The q3config.cfg file IS propogated to each mod directory as a set of defaults. If you want to use mod specific configurations, just use a yourmodname.cfg file and execute it at load time and save it out when appropriate.

-Server side DLL support for pure servers. This would allow pure servers to load DLL's on the server side only while keeping the clients pure. This will likely be possible in a future release.

-Client identification. Cheating is obviously a big issue. It seems that some people just cannot get over the fact that they suck at the game and have to cheat to try and make up for it :-) This along with abusive players has caused quite a few requests for the ability to generate a unique user ID based on the end users CD Key. This would allow servers to ban troublesome players or habitual cheaters. This method would not compromise the CD Key in any way but would provide a unique string that would identify a particular user irrespective of their user name, ip address and so on. Our current thought process is to implement a system very similar to caller ID. This would allow a server to be setup to accept only clients that provide their ID or accept all ( anonymous ) clients. Clients would be able to specify whether or not to provide their ID or be anonymous. Any feedback on this is welcome ( This is NOT in the game at this time but is under consideration )

Tools
-----
There should be a new release of the tools available within a few days as well. The editor is still undergoing quite a few changes but I want to get it out so people can work around the nVidia stipple slow down and take advantage of the new plugins that are about to hit the streets. Tool feedback still needs to go to tools@idsoftware.com.

id Team Bios
Quake3World has been updated with the id Team Bios for Christian Antkow, Kevin Cloud, Robert Duffy, Todd Hollenshead, Paul Jaquays and Kenneth Scott. They are mini-bios but have some information in them that people might not have known. Upcoming Bios include Adrian Carmack, John Carmack, John Cash, David Kirsch, Paul Steed and Tim Willits.

A Kickass Q3Map
I was surfing for maps last night and found this one and I am very impressed with it. Its called LUN3DM1: Coriolis Storm click name to go to authors site and download this one.

Mousepad roundup
3daccelerated has posted a detailed roundup of the most popular new "precise" mousepads including: Everglide Giganta, Everglide Large Attack Pad, Ratpadz, 3M Precision Surface... instead of posting a bunch of separate reviews they decided to combine them so that people can compare the mousepads more easily. Check it out here

03/14/2000
One more Q3a prefab loaded
Check out my prefab page and grab it. Here.

Some good news
My favorite Q3a editing site Q Workshop3 that was made by Lard is handing over the site to a new guy who goes by DrQube so the content will keep on flowing yes.

Quake 3 Map Explorer v1.2
Quake 3 Map Explorer version 1.2. Q3ME is a front-end compiler for Quake3's level editing tools Q3Map and BSPC. Some of the new features include support for running maps from a mod folder, custom gametype option, and other new features and fixes

Q3A Domination
Domination-Q3 Download and Installation page has anew version 1.2 of the Domination mod for Quake III Arena. The new version offers a new Windows front-end to launch both clients and servers, a new HUD with "UT style" display of current point status, and improved Bot support (described as "still not perfect, but slightly more playable").

Q3Fortress interview 
Quake3zone.net has a relatively short Q&A with Locki of the Q3Fortress team. The mod is currently in testing and they plan to release a public beta within the next few weeks. The Q3Fortress website has a bunch of screenshots if you are wondering how TF translates to the Q3 engine.

Brian Hook update
Brian Hook has spilled a little more beans about why he left id, in a Q&A at VoodooExtreme. He goes on to say how much of a genius John Carmack is and how programming under him was hard. 

Q3Log
A new version 0.97 of the Q3Log mod is now available. The new release of this log analysis program for Quake III Arena adds support for custom variables, which allows you to create your own statistics to track, a new full HTML help file, easier setup, and more.

Q3A Challenge
A new version 1.36 of the Challenge mod for Quake III Arena is now available. Challenge adds several tournament-friendly features, including a pre-match warm-up period, and the ability for players on the server to vote on many aspects of game play.

Editing Stuff
There's a new mapping tutorial on Quake3mods.net showing how to create a map with an outer space feel to it.

03/13/2000
Q3A Texture pack
 The Mean Arena site has posted a texture pack for Q3A. There is a set of 96 ready for download now and it sounds like another set of alpha channels are on the way. Check them out here.

New MilkShape 3D released today
Version 1.2.0 of MilkShape 3D is out today. This program will interest any one who wants to convert models from one format to another or for those who want to make their own. This latest version has full .MD3 support. Check it out here.

Q3 Mission Pack
I noticed over on Gamespy's GDC Page that Paul Steed has announced a Q3 Mission Pack. They also released a few screenshots.

New Q3Offline
There is a new version of the Q3 Offline launching program. This is mainly a bug fix release for this program that makes setting up offline games with user defined bots and maps easy.

03/11/2000
Site news
Missed a couple days been working on my dam computer. It works much better now if you care.  On with the news. Check out the links page added custom map sites.

Want three great Q3A maps
Check out these three maps at Fooker

Looking for some CTF maps 
Well look no furthur because Q3Ctf map repository as them for ya

New Z-Axis reviews
Z-Axis has posted 5 new Quake 3 map reviews

03/09/2000
A new Q3A prefab for ya.
I was bored this this afternoon so I made one more prefab for ya go here to check it out.

Analyzing Layered Shaders  (thanks Rust)
EutecTic and Ricebug have combined their talents and posted a new tutorial dealing with "layered shaders." It's a difficult subject, but written with plenty of screenshots so anyone can understand it.

Quake III Camera (thanks Blues)
Completing a trilogy of camera mods, Quake III Camera is now available on the Q3Cam page. Created by the author of QCam and Quake2Cam, this mod brings third-person camera viewing to Quake III Arena games, allowing you to watch games live or record them for later viewing.

A new Q3A prefab for ya.
I was bored this morning so I made one more prefab for ya go here to check it out.

Big Plan from the main man John Carmack

This is something I have been preaching for a couple years, but I
finally got around to setting all the issues down in writing.

First, the statement:

Virtualized video card local memory is The Right Thing.

Now, the argument (and a whole bunch of tertiary information):

If you had all the texture density in the world, how much texture
memory would be needed on each frame?

For directly viewed textures, mip mapping keeps the amount of
referenced texels between one and one quarter of the drawn pixels.
When anisotropic viewing angles and upper level clamping are taken into
account, the number gets smaller. Take 1/3 as a conservative estimate.

Given a fairly aggressive six texture passes over the entire screen,
that equates to needing twice as many texels as pixels. At 1024x768
resolution, well under two million texels will be referenced, no matter
what the finest level of detail is. This is the worst case, assuming
completely unique texturing with no repeating. More commonly, less
than one million texels are actually needed.

As anyone who has tried to run certain Quake 3 levels in high quality
texture mode on an eight or sixteen meg card knows, it doesn’t work out
that way in practice. There is a fixable part and some more
fundamental parts to the fall-over-dead-with-too-many-textures problem.

The fixable part is that almost all drivers perform pure LRU (least
recently used) memory management. This works correctly as long as the
total amount of textures needed for a given frame fits in the card’s
memory after they have been loaded. As soon as you need a tiny bit
more memory than fits on the card, you fall off of a performance cliff.
If you need 14 megs of textures to render a frame, and your graphics
card has 12 megs available after its frame buffers, you wind up loading
14 megs of texture data over the bus every frame, instead of just the 2
megs that don’t fit. Having the cpu generate 14 megs of command
traffic can drop you way into the single digit frame rates on most
drivers.

If an application makes reasonable effort to group rendering by
texture, and there is some degree of coherence in the order of texture
references between frames, much better performance can be gotten with a
swapping algorithm that changes its behavior instead of going into a
full thrash:

While ( memory allocation for new texture fails )
Find the least recently used texture.
If the LRU texture was not needed in the previous frame,
Free it
Else
Free the most recently used texture that isn’t bound to an
active texture unit

Freeing the MRU texture seems counterintuitive, but what it does is
cause the driver to use the last bit of memory as a sort of scratchpad
that gets constantly overwritten when there isn’t enough space. Pure
LRU plows over all the other textures that are very likely going to be
needed at the beginning of the next frame, which will then plow over
all the textures that were loaded on top of them.

If an application uses textures in a completely random order, any given
replacement policy has the some effect…

Texture priority for swapping is a non-feature. There is NO benefit to
attempting to statically prioritize textures for swapping. Either a
texture is going to be referenced in the next frame, or it isn’t.
There aren’t any useful gradations in between. The only hint that
would be useful would be a notice that a given texture is not going to
be in the next frame, and that just doesn’t come up very often or cover
very many texels.

With the MRU-on-thrash texture swapping policy, things degrade
gracefully as the total amount of textures increase but due to several
issues, the total amount of textures calculated and swapped is far
larger than the actual amount of texels referenced to draw pixels.

The primary problem is that textures are loaded as a complete unit,
from the smallest mip map level all the way up to potentially a 2048 by
2048 top level image. Even if you are only seeing 16 pixels of it off
in the distance, the entire 12 meg stack might need to be loaded.

Packing can also cause some amount of wasted texture memory. When you
want to load a two meg texture, it is likely going to require a lot
more than just two megs of free texture memory, because a lot of it is
going to be scattered around in 8k to 64k blocks. At the pathological
limit, this can waste half your texture memory, but more reasonably it
is only going to be 10% or so, and cause a few extra texture swap outs.

On a frame at a time basis, there are often significant amounts of
texels even in referenced mip levels that are not seen. The back sides
of characters, and large textures on floors can often have less than
50% of their texels used during a frame. This is only an issue as they
are being swapped in, because they will very likely be needed within
the next few frames. The result is one big hitch instead of a steady
loading.

There are schemes that can help with these problems, but they have
costs.

Packing losses can be addressed with compaction, but that has rarely
proven to be worthwhile in the history of memory management. A 128-bit
graphics accelerator could compact and sort 10 megs of texture memory
in about 10 msec if desired.

The problems with large textures can be solved by just not using large
textures. Both packing losses, and non- referenced texels can be
reduced by chopping everything up into 64x64 or 128x128 textures. This
requires preprocessing, adds geometry, and requires messy overlap of
the textures to avoid seaming problems.

It is possible to estimate which mip levels will actually be needed and
only swap those in. An application can’t calculate exactly the mip
map levels that will be referenced by the hardware, because there are
slight variations between chips and the slope calculation would add
significant processing overhead. A conservative upper bound can be
taken by looking at the minimum normal distance of any vertex
referencing a given texture in a frame. This will overestimate the
required textures by 2x or so and still leave a big hit when the top
mip level loads for big textures, but it can allow giant cathedral
style scenes to render without swapping.

Clever programmers can always work harder to overcome obstacles, but in
this case, there is a clear hardware solution that gives better
performance than anything possible with software and just makes
everyone’s lives easier: virtualize the card’s view of its local
memory.

With page tables, address fragmentation isn’t an issue, and with the
graphics rasterizer only causing a page load when something from that
exact 4k block is needed, the mip level problems and hidden texture
problems just go away. Nothing sneaky has to be done by the
application or driver, you just manage page indexes.

The hardware requirements are not very heavy. You need translation
lookaside buffers (TLB) on the graphics chip, the ability to
automatically load the TLB from a page table set up in local memory,
and the ability to move a page from AGP or PCI into graphics memory and
update the page tables and reference counts. You don’t even need that
many TLB, because graphics access patterns don’t hop all over the place
like CPU access can. Even with only a single TLB for each texture
bilerp unit, reloads would only account for about 1/32 of the memory
access if the textures were 4k blocked. All you would really want at
the upper limit would be enough TLB for each texture unit to cover the
texels referenced on a typical rasterization scan line.

Some programmers will say “I don’t want the system to manage the
textures, I want full control!” There are a couple responses to that.
First, a page level management scheme has flexibility that you just
can’t get with a software only scheme, so it is a set of brand new
capabilities. Second, you can still just choose to treat it as a fixed
size texture buffer and manage everything yourself with updates.
Third, even if it WAS slower than the craftiest possible software
scheme (and I seriously doubt it), so much of development is about
willingly trading theoretical efficiency for quicker, more robust
development. We don’t code overlays in assembly language any more…

Some hardware designers will say something along the lines of “But
the graphics engine goes idle when you are pulling the page over from
AGP!” Sure, you are always better off to just have enough texture
memory and never swap, and this feature wouldn’t let you claim any more
megapixels or megatris, but every card winds up not having enough
memory at some point. Ignoring those real world cases isn’t helping
your customers. In any case, it goes idle a hell of a lot less than if
you were loading the entire texture over the command fifo.

3Dlabs is supposed to have some form of virtual memory management in
the permedia 3, but I am not familiar with the details (if anyone from
3dlabs wants to send me the latest register specs, I would appreciate
it!).

A mouse controlled first person shooter is fairly unique in how quickly
it can change the texture composition of a scene. A 180-degree snap
turn can conceivably bring in a completely different set of textures on
a subsequent frame. Almost all other graphics applications bring
textures in at a much steadier pace.

So, given that 180-degree snap turn to a completely different and
uniquely textured scene, what would be the worst case performance? An
AGP 2x bus is theoretically supposed to have over 500 mb/sec of
bandwidth. It doesn’t get that high in practice, but linear 4k block
reads would give it the best possible conditions, and even at 300
mb/sec, reloading the entire texture working set would only take 10
msec.

Rendering is not likely to be buffered sufficiently to overlap
appreciably with page loading, and the command transport for a complex
scene will take significant time by itself, so it shows that a worst
case scene will often not be able to be rendered in 1/60th of a second.

This is roughly the same lower bound that you get from a chip texturing
directly from AGP memory. A direct AGP texture gains the benefit of
fine-grained rendering overlap, but loses the benefit of subsequent
references being in faster memory (outside of small on-chip caches).
A direct AGP texture engine doesn’t have the higher upper bounds of a
cached texture engine, though. It’s best and worst case are similar
(generally a good thing), but the cached system can bring several times
more bandwidth to bear when it isn’t forced to swap anything in.

The important point is that the lower performance bound is almost an
order of magnitude faster than swapping in the textures as a unit by
the driver.

If you just positively couldn’t deal with the chance of that much worst
case delay, some form of mip level biasing could be made to kick in, or
you could try and do pre-touching, but I don’t think it would ever be
worth it. The worst imaginable case is acceptable, and you just won’t
hit that case very often.

Unless a truly large number of TLB are provided, the textures would
need to be blocked. The reason is that with a linear texture, a 4k
page maps to only a couple scan lines on very large textures. If you
are going with the grain you get great reuse, but if you go across it,
you wind up referencing a new page every couple texel accesses. What
is wanted is an addressing mechanism that converts a 4k page into a
square area in the texture, so the page access is roughly constant for
all orientations. There is also a benefit from having a 128 bit access
also map to a square block of pixels, which several existing cards
already do. The same interleaving-of-low-order-bits approach can just
be extended a few more bits.

Dealing with blocked texture patterns is a hassle for a driver writer,
but most graphics chips have a host blit capability that should let the
chip deal with changing a linear blit into blocked writes. Application
developers should never know about it, in any case.

There are some other interesting things that could be done if the page
tables could trigger a cpu interrupt in addition to being automatically
backed by AGP or PCI memory. Textures could be paged in directly from
disk for truly huge settings, or decompressed from jpeg blocks, or even
procedurally generated. Even the size limits of the AGP aperture could
usefully be avoided if the driver wanted to manage each page’s
allocation.

Aside from all the basic swapping issue, there are a couple of other
hardware trends that push things this way.

Embedded dram should be a driving force. It is possible to put several
megs of extremely high bandwidth dram on a chip or die with a video
controller, but won’t be possible (for a while) to cram a 64 meg
geforce in. With virtualized texturing, the major pressure on memory
is drastically reduced. Even an 8mb card would be sufficient for 16
bit 1024x768 or 32 bit 800x600 gaming, no matter what the texture load.

The only thing that prevents a geometry processor based card from
turning almost any set of commands in a display list into a single
static dma buffer is the fact that textures may be swapped in and out,
causing the register programming in the buffer to be wrong. With
virtual texture addressing, a texture’s address never changes, and an
arbitrarily complex model can be described in a static dma buffer.

03/08/2000
New site design for Quake 3 Arena the point
Also a new name called E.M.C. short for Exoteric Map Central If you have a map to get reviewed of just want to download some q3a maps go check it out here.

Boomslang 2000 review
3daccelerated has reviewed a boomslang 2200 check it out here.

03/07/2000
Q3 Point Release 1.16m Beta patch
There is a new beta of the Q3 Point Release out on the id Software FTP (also on Stomped) according to Robert Duffy's .plan. Here's the full update:

New Q3A Models
Polycount has posted 5 new Quake 3 Arena models for download. They include; Dark Rider, Piccolo, The Tick, Tommi, and SUW Field.


New QTracker
QTRacker version 2.3 beta 16 has been released. Qtracker is server browser, server launcher, MP3 streaming audio browser, and HTML server list generator for Windows 95/98/NT/2000. The new version adds a "Find Internet Games" wizard, ICMP-based pings, several times faster server searching, Q3A IPX/password support, and Soldier of Fortune support.

Rocket Arena 3 Update
crt has updated the Rocket Arena page with the latest on Rocket Arena 3's development. Here it is:

03/06/2000
Quake III Arena Hulk  (thanks Blues)
Version 1.0 of Reactive Software's Hulk mod for Quake III Arena is now available. Like the namesake comic book series, this mod pits a lone powerful Hulk (randomly selected at game start) against a group of "puny humans," who attempt to gang up on him. The player who kills the Hulk takes the next turn in his place, while doing damage to the Hulk will earn frags for players, with the Hulk increasing his score by fragging the players persecuting him. Thanks Timothy J. Agen.

New Q3A Viz  (thanks Blues)
The El Niño Quake Extensions page has a new version 2.1.5 of Viz for Quake III Arena, written by Quake II VWep author Hentai. This release fixes a few problems with picking up/dropping the ball in rugby mode, and causes the ball to respawn after sitting still too long. A new release that adds more new gameplay features is expected shortly (as Hentai says: "but first I gotta take a shower.").

Q3A Server Console   (thanks Blues)
A public beta (Rev. 430) of the Quake 3 System Management Server offers a replacement for the Quake III Arena default server console. "It allows you to choose which server you want to monitor (if you have multiple servers running on one box), and offers a lot of features that the default console doesn't."

Quake II Demo Tool   (thanks Blues)
A new version 0.3 of Quake2 Relay is now available, promising "demos on steroids," and basically delivering just that, as this utility overcomes some of the limitations of Quake II demo recording, allowing the recording and playback of entire Q2 matches from any perspective, rather than just the recording player's viewpoint. The new release adds Linux support and a tool to convert relay demos to regular Quake II demo format.

New QBind
A new beta 0.86 of the QBind advanced script editor for Quake-engine games is now available (thanks FileClicks). Included in the new version is enhanced support for the latest versions of Quake III Arena, as well as improved Win2K support.

03/04/2000
Gaming Modem reviewed
3d Accelerated.com has posted a review of 3Com's 56k modem. The review can be found here 

Quake3Mods Database Update
The Quake3Mods.net Database has now surpassed the 40 mods mark. If you're looking to find a Quake 3 Mod, it's there. They can be searched as well as arranged alphabetically.

Want a B.A. in Quake? (Thanks Stomped)
We're not quite there yet, but according to this ZDnet article, students at UC Irvine will be able to participate in an Interdisciplinary Gaming Studies Program. I can see the student/parent conversations now "How's school?" "Great, I'm doing some studying." "Sounds like you're playing video games." "Exactly" :)

Tim Willits interview (Thanks Stomped)
Mean Arena has posted a new interview with id Software level designer Tim Willits. The interview is far reaching, with Willits talking on a number of topics. Here is a snip:

New Oni Bot  (thanks Blues)
Version 0.02 of the server-side Oni Bot for Quake III Arena has been released. It's still an early release of the bot, but the author says that the bot can, "find targets in its field of view and attack the target." But he has high hopes for the project, as it is part of a larger scientific research project in Artificial Intelligence, and it utilizes, "the latest techniques in multi-agent systems."

03/03/2000
Q3A Compiler Front-End  (thanks Blues)