Back Last changes: 2002-02-28 Contact Maddes

Quake Tools Bugs & Suggestions

Bug categories: Quake QuakeWorld Map Demo Tools Not researched yet

Index

You can find the most recent version of this list on Quake Info Pool.
Some workarounds were taken from other sites/people and are not always proved by myself.
If you are interested in QuakeC and/or the Quake sources (Quake utils and engine), then please visit the Quake Standards Group and join the Quake Sourcecode Mailing List.
Recommended replacements for the original id tools:

Quake Tools Bugs & Suggestions

Bug / Suggestion first occurred in (cause) workaround or fixed in
Problems with non-decompilable progs.dat (e.g. odd behaviours in Battler2 from Carl Lloyd-Parker) MEQCC not yet
correction:
I mentioned before that MEQCC does not support "..." for function definitions and escape sequences (e.g. \"). This is not true, it works just like the original QCC. I don't know how I got this problems, sorry.
QCC does not compile "bprint ("(");"
Reported by DrZaius on the Inside 3D Quake forum.
QCC not yet
workaround:
MEQCC compiles this or place any character before or after the bracket.
Many level editors assume that "info_teleport_destination" has to be 24 units above the ground. That's wrong, because the QuakeC code adds 27 to it's origin to let the player not get stuck in the floor. Level editors and "info_teleport_destination" set its relative origin to zero
fixed in URQP 1.05 for QuakeED (incl. Stoneless, QERadiant)
solution for WorldCraft:
@PointClass base(PlayerClass, Targetname) size(-16 -16 0, 16 16 56) = info_teleport_destination : "Teleport destination" []
The attribute order within entities gets inverted when compiling or updating the entity list. QBSP / LIGHT hopefully TreeQBSP / TxQBSP will have this fixed soon (just for me, so I don't get annoyed when creating map fixes)
reason:
Causing routine is ParseEpair() of MAP.C
solution:
entity_t *mapent;
entity_t *lastent; // 1999-11-14 inverted entity list fix by Maddes

void ParseEpair (void)
{
 epair_t *e;

 e = malloc (sizeof(epair_t));
 memset (e, 0, sizeof(epair_t));

// 1999-11-14 inverted entity list fix by Maddes start
// e->next = mapent->epairs;
// mapent->epairs = e;
 if (!mapent->epairs)
    mapent->epairs = ent;
 else
    lastent->next = ent;
 lastent = ent;
// 1999-11-14 inverted entity list fix by Maddes end
 ...
}
"-proj" parameter not implemented QBSP not yet
tip:
Always put the related palette in your WAD2s, this will give you the possibility to always reproduce the original image
WADs ./.
"hit_occupied" never being set correctly
Reported by Greg "Tree" Lewis
QBSP fixed in the enhanced TreeQBSP / TxQBSP, originally encountered by Yahn Bernier of the level editor BSP.
New 2002-02-28reason by Bengt Jardrup:
These bugs are all related to the original QBSP not being able to get the correct coordinates (setting the "hit_occupied" variable) when detecting a leak. The printed coordinates are always (0, 0, 0) no matter what.
As leaks can occur independently in three different hulls (0, 1 or 2), PRT and PTS files are not handled properly. You can end up with various combination of files (zero length or not), which adds to the confusion whether the map was properly compiled or not.
If the leak occurs in hull 0, then the outside void is not filled. You can noclip outside and try to look inside and if you can't, then that is a sign of having a leak in hull 0. (Also reported in the post from Apollo on the QBoard in Mapping techniques #68). However, if the leak occurs in another hull, then the outside may very well be filled and you can't use the noclip method.
In this latter case one could argue if you should call this a "leak" or maybe "corrupt brush". If you load the PTS file in Quake you will notice that the line goes right through a seemingly solid brush and no matter how hard you try, you won't find a hole to the outside void.
Unable to VIS a map, although there is no visible leak.
Reported by Gonzo
QBSP / VIS / Map editor
Leakfiles 0 length and leak position is incorrectly reported.
Taken from WQBSP readme, originally encountered by Yahn Bernier, author of the level editor BSP.
QBSP
Garbage after EndOfString (EOS = first null byte) in texture names, although it is specified that all unused bytes have to be null bytes
In the most id maps it starts at offset 13 of the texture name and contains "3f 3f 3f 4b 40 00"
WAD tools / QBSP solutions:
TexMex can clean existing WADs, just load and save
QuArK does WADs right
TreeQBSP / TxQBSP clean up texture names
a fixed QBSP is available for download
reason:
Many current and early versions of WAD creating tools do not pad texture names with 0x00. Unfortunately QBSP copies the mip textures directly from the WAD files, although it has a "cleanupname" function in WRITEBSP.C.
consequences:
This garbage gets into the BSP file and can cause problems with QW's mapchecksumming.
Renaming textures, like BSPTXREN does, should be done with care, as you can not recreate this garbage.
Unfortunately the whole texture name is used for mapchecking in QW (16 bytes = max. 15 chars + EOS) including the garbage.
Animated textures are not added when texture name is in lowercase QBSP solutions:
TreeQBSP / TxQBSP checks texture names correctly
a fixed QBSP is available for download
If the pointfile command does generate a line, and it gives you a message telling you it only read i.e. 2004 lines, then it may not be able to find the hole, its just that the pts file is too big for Quake.
Found on the QuArK forum
Leakfiles / QBSP / Quake solution:
From the same QuArK forum message:
If the pts file is too big for Quake to read all of it, then you have to start Quake with the parameter "-particles <x>", where x is the number of lines you want it to read. I used 20000 for this number and occasionally had to go even higher sometimes.
tip:
Some QBSPs allow you to set the distance between each particle with a -leakdist at the command line. The default is 2, but if you crank it up to say 16, the pointfile should go longer and be more useful. Although the particles might be a bit hard to find then.
Found in a post from CZG on the QBoard (General Abuse #9553)
Different texture alignment in maps created with WorldCraft (rotation quirk)
Reported by Greg "Tree" Lewis
QBSP fixed in TreeQBSP / TxQBSP (old/alternate axis parameter)
Here's some additional information from Tree:
"This has something to do with how a texture is applied to a wall that is exactly at a 45 degree angle. Textures must always be associated with the axis plane that the wall is most closely aligned with. A wall at a 45 degree angle could go with one of two axis aligned planes. The original QBSP did it one way, and WorldCraft does it the other way, so people were seeing some strange artifacts on their maps."
In id's released QBSP the first found axis is used, WC uses the last found axis.
Memory leaking bug
Reported by Greg "Tree" Lewis
QBSP fixed in TreeQBSP / TxQBSP
New 2002-02-28Additional information by Bengt Jardrup:
The original QBSP had a massive amount of memory leaks. That is why it consumes an insane amount of memory while compiling (for big maps we're talking several 100 MB). The major problem is that for each hull (0-2), a huge amount of memory is allocated but never released and this really adds up in the end.
All major memory leaks are fixed in Bengt's latest enhanced Tree/TxQBSP versions, hence the huge memory savings.
Missing support for transparent water QBSP fixed in TreeQBSP / TxQBSP and check out my transparent water page
QBSP can not access WAD file because of messed up pathname.
Example for "wad" "texpool.wad":
************ ERROR ************
Error opening E:\QUAKE\ID1\/texpool.wad
QBSP fixed in TreeQBSP / TxQBSP by supporting multiple wads, pathes and long names.
hint for original QBSP:
The WAD file has to be in the game directory and not its maps folder. Take care that you only state the name of the WAD file and not its path.

a Quake Info Pool page
© 1997-2006 by Maddes