| Back | Last changes: 2002-02-28 | Contact Maddes |
| 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. |