Quake Info Pool - Classic Quake - Tool Bugs

Back | Last changes: 2002-02-28 | Contact Maddes

# Quake Tools Bugs & Suggestions

## Bug categories: Quake / QuakeWorld / Map / Demo / Tools / Not researched yet / Wishes

## Index

- Quake Tools Bugs & Suggestions

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.

- red = bugs, crashes, which disturb gameplay
- black = bugs which do not affect gameplay
- green = old and fixed bugs

Recommended replacements for the original id tools:

- Mr. Elusive's MEQCC (QuakeC de-/compiler)
- Frika C's FrikQCC (QuakeC de-/compiler)
- QuakeStuff's PakExplorer
- TreeQBSP / TxQBSP new versions by Bengt Jardrup, original TreeQBSP by Greg Lewis
- BSP Entity Extractor for extracting entity lists out of BSP files
- Mr. Elusive's BSPC, a map decompiler
- Tyrann's TyrLite and RVIS+
  TyrLite 0.92+ has .LIT support (use -lit parameter) and all features of Argh's ArghLite (which can only be found on 3DArchives)
- Q1RAD, another interesting LIGHT tool with LIT support
- OneLight, a BSP30 to BSP29+LIT converter
- TexMex for creating and cleaning WADs
- Wally for creating textures and WADs (in co-existence with TexMex)
  Includes an newer version of ReMipDLX for enhancing mipmaps of textures/WADs
- QuArK for creating WADs, maps and lots more
- AdQuEdit can be useful for many tasks, but do not use AdQuEdit for creating WADs

## 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.
reason 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
Additional 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-2022 by Maddes