Re: Distributing Quake maps (long-ish, wordy and rambling :)

Tom Lees (
Sun, 10 Mar 1996 08:06:26 +0000 (GMT)

Date: Sun, 10 Mar 1996 08:06:26 +0000 (GMT)
From: Tom Lees <>
Subject: Re: Distributing Quake maps (long-ish, wordy and rambling :)
In-Reply-To: <>

On Sun, 10 Mar 1996, Tom Wheeley wrote:

> At the minimum I am proposing is a tool not dis-similar to DeuSF or DeuTex
> which is run locally by the end user. This will process a list of textures
> which the program `statically links' into a final BSP file.

This is a good idea, but it shouldn't be too slow, otherwise we will get
'binaries' distributed versions of levels as well as 'source' versions.

> This control file could be designed in 3 ways.
> . structure based, and thus virtually unmaintainable by humans, but easy
> for programs to fiddle with.
> . text file, for the most part using the `texture numbers' (for more info
> on how the textures are referenced, see Quake Specs). This would be
> created by the map editor, which would interface with the user with
> the texture names
> . text file, but uses the texture names when specifying sources. This
> would be the slowest (but not that slow) to process. It would be easily
> maintainable by humans though :)
Or, it could be structure based, but created from a file using the 3rd
format, for the best of both worlds.

> Unfortunately, the only magic which can be tested for is for the BSP files and
> so no-way could be established for checking that a miptex lump _is_ a miptex
> lump (without checking the size difference of the offsets, possibly). Thus
> raw .MIP (or whatever) files would have to be outlawed, they would have to
> start with the very simple multiple MIP header (as per the beginning of the
> miptex lump) of size 1.

Why not use a different format completely (like BMP or GIF or something)?
This would probably result in minimal work for level designers and level
editor programmers, and make the distributed level format more portable
in the case of the Quake structures changing format.

> This idea of processing at the users locale could possibly be extended to the
> creation of the various abstract stuctures which comprise most of the rest of
> the .BSP file.

However, I think that this would slow down the local processing time too
much, leading to separate binary and source distributions.

> The MakeTex itself would be in the PAK as Entry 'MakeTex'. Other (possibly
> standardized) entries could be made such as `Author', 'Description', 'Licence'
> etc. These could be displayed by the MakeTex program.

I'm not sure if this is completely necessary. If the format of the levels
within the distributed PAK file is going to be different than in standard
Quake BSP files, why not simply put the data as part of the new
distribution level format?

> There is then the small dilemma of whether to have MakeTex work on the
> distribution file directly (save disk space) or create a new file completely.
> If there is sufficient reason for the first option, then perhaps the
> distributable file would need to be structured almost exactly like a BSP file,
> and the new textures simply appended. This, imho, is not as neat.

If the full version of Quake supports more than a single PAK file, a nice
option would be for the user to be all his or her favourite levels in one
PAK file, which could then be loaded every time Quake starts, then access
to all the user-created levels would be simple. However, I don't think
there is any call to directly modify the distribution files, other than
that it keeps the directory structure and files in the Quake directory

Tom Lees (