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

Tom Wheeley (tomw@tsys.demon.co.uk)
Sun, 10 Mar 96 01:40:28 GMT

Date: Sun, 10 Mar 96 01:40:28 GMT
From: Tom Wheeley <tomw@tsys.demon.co.uk>
To: quake-editing@nvg.unit.no
Subject: Distributing Quake maps (long-ish, wordy and rambling :)

Reading both Raphael's recent article in rgcqe and the Quake specs, it seems
to me like we do not want hundreds of textures cluttering peoples maps.

Now, I don't know:

a) How close people are to anything resembling level editors. (Not close, I
should think, seeing how many `lookups' there are to be calculated in the
maps/*.bsp files.

b) How much Quakes handling of textures (`surfaces') will change between this
test version (qkspec30) and the wondrous mythical `Final Version'.

However, my thoughts on these are:

a) If we agree on something now, perhaps with a bit of source, then a
standard for distributing levels can be set before we get rogue levels
making the rounds of the ftp/www sites...

b) I am assuming that having the textures in each map will not change to
references.

There is also the issue of including id's textures in distributed levels.

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

Using the 3rd format, it would look something like this: (The names are
complete fabrications!).

# Quake `MakeTex.cfg' file.

#StoredName Source file Entry name
RedBrickWall maps/test1.bsp IDREDWALL # Search a BSP file
Stuccoish maps/test1.dir/entry02.lmp IDSTUCCOISH # Search multi MIP lump
SecretSrc maps/test3.bsp =12 # Entry 12 in a BSP

# End sample MakeTex.cfg file

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.

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.

Finally, I think the _easiest_ way to distribute the rest of the data would
be within a PAK file, possibly renamed LEV or QL (or .TOM ;-)). Then each
BSP lump would have an entry in the .PAK file, along with new mip textures
(referenced in the MakeTex file as ``NewName PAKentryname'' -- 2 tokens).
The reason each mip texture would have its own PAK entry, rather than a
simgle MultiMIP entry is that it would make processing simpler (extracting
and searching one archive rather than 2)

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.

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.

I would like to thank both of you for reading this far ;-) I would like
other's opinions on this. (I can tell I've missed something obvious... :)
I have done a bit of preliminary coding for MakeTex, but there's no point
going to far with it if the idea is flawed. I am using, abusing and
extending the QEU files to do this. (mainly q_*, f_bsp, f_pack and my own
skeletal f_miptex)

-- 
* TQ 1.0 * The 'Just So Quotes'.
I know you're supposed to take life one day at a time -- but lately several
days have attacked me at once.