Date: Sat, 20 Apr 1996 21:16:22 +0200 (METDST)
From: Uffe Friis Lichtenberg <uffefl@diku.dk>
To: quake-dev@gamers.org
Subject: Re: Quake map distribution: speed vs. legality
In-Reply-To: <199604201755.TAA17252@marvin.nero.uni-bonn.de>
On Sat, 20 Apr 1996, Bernd Kreimeier wrote:
> Distribution of MAP files is useful if one wants the level to
> be modified and edited by others. Automatic generation of
> MAP from BSP is a nice task we could tackle along with
> generating MAP from DOOM level descriptions.
Having the .map follow the .bsp file all the way would be optimal. This
way both level-editing and level-playing would be supported. I propose to
designate an entry "_mapfile.zip" were a zip-compressed .map
representation of the .bsp file could be kept.
This way an editor would only have to deal with .bsp files (and thus
avoid confusion for users). If the user wants to play the level he starts
it up using the console command "map whatever", and if he wants to edit
it he loads up an editor with whatever.bsp.
This I propose because I find the idea of a completely self-contained
(immidiately 'playable') .bsp-file very attractive. Instead of the
typical Doom-multifile-zip-distribution each level would have one, and
only one, file associated with it. The typical readme.txt could also
easily be added to the .bsp-file as "_readme".
Now, as earlier stated, a user might have to run an external utility on
the .bsp-file (to get all textures right) to get the full experience, but
basically it is playable right-away.
Hmmm... I'm rambling, let me summarize:
* A distributable .bsp-file contains none of ids textures, but
"_texture" entries that tell a preprocessing utility how to
build the right .bsp-file from the distributable .bsp-file.
All the surfaces that should have had one of ids textures, are assigned
a dummy texture in the distributable .bsp-file. This assignment is
changed by a preprocessing utility according to the
"_texture" entries.
The preprocessing utility should also be able to reverse this process,
so you don't have to keep the distributable file as well as the
playable one.
* To help map-editing a .bsp-file builder should, as a post-processing
step, zip the .map-source-file and include it into the .bsp-file in the
"_mapfile.zip" entry.
This way an editor could work on .bsp-files only (and even save editor
project information in the .bsp file as "_MYQED:varname=value" or
similar; as long as we keep the MYQED string unique for each editor and
editor version) and rebuilding .map-files from .bsp-files wouldn't be
necessary.
Also, a level author who doesn't wish other people to use his levels as
a base, could easily mark this be _not_ including the "_mapfile.zip"
entry.
* The level-information, copyright and so on, could be placed in a
"_readme" entry, which the previously mentioned preprocessing utility
could show to the user while processing the .bsp-file.
It would be especially nice if we could agree this early on, on a
general layout of the "_*" entries. Even though we aren't even (thinking
of :) building .bsp-files from .map-files yet, it would be nice to agree
on a standard of sorts.
> Distribution of BSP files w/o mipmaps lump requires a lookup
> assigning indices (as used in surfaces, generated by qbsp) to
> textures (as defined in the MAP file). It is no good idea
> to distribute this lookup separately. The current proposal is
> to add
>
> "_texture" " 1 WALL54_0"
>
> lines to the entities lump in the BSP. These will not be
> deleted by qbsp, and will be ignored by Quake. To use this
> approach with qtest1, these lines would have to be deleted
> after adding the mipmaps, to prevent warnings or errors.
I haven't tried it, but does qtest1 complain when encountering "_*"
entries?
Zonk,
Uffe. [uphfe]
uffefl@diku.dk
-- "This .signature hasn't been left unintentionally void of blankness"