Thanks 

Have a Q1map, which makes account of :
prepare used textures => 26 textures
Compiling it makes account of 29 textures.
Did'nt use animated textures.

What happened?
Pretty queer, because the map is 1.87Mb and won't run for 1.89Mb

Grandwoofer, help! 

Building hulls sequentially...
Processing hull 0...
------ Brush_LoadEntity ------
----+----\
WARNING: Couldn't create brush on line 602 with 6 faces, metal2_8
WARNING: Couldn't create brush on line 593 with 5 faces, metal2_8
----+----+
731 brushes read

Has anyone encountered this before? How to find and fix this. Occurred on elmdm5.

as 

Open the map file back into your editor.. it should remove the dodgy brushes. Resave and recompile. Note it's the file with the '.map' extension you want, not the editor-specific one like .rmf/.qle or whatever. 

if you use gtkradiant: edit the .map file in edit or notepad or whatever, go to line 602, (or 593 as well) and find out what brush # it is.
now go in gtkr, and use the search for brush and search for the brush #. then you can delete it and remake it or whatever you chose to do.

otherwise, if you don't use gtkr, and can't find it in the editor you DO use, simply delete the entire reference to the brush in the .map file manually, then compile and find out what you took out. 

replace the texture (metal2_8) to something obvious so you can delete it in your editor (what ive done, esp in areas with lots of brushes) 

You've got mail 

Thanks for the info. I use quark, not interested in GTKR until it fully supports q1 maps, too much hassle. I'll stick with quark's one click loading. FYI, ELMDM5 is simple map, yet lot of fun to play. Quark wouldn't let me use groups with the bsp file. So, I had to decompile and recompiled it, just over 20 mins to compile.

I found that when I turn off "write float coords" in options, it causes a bunch of errors. Any suggestions how to configure quark to int coords without errors?

Also, decompiling and recompiling the map added 764 new faces, yuck. I'm learning quite a bit about it's put together. Almost finished completely relighting with tylite and adding some eye candy. Not ready to make a map yet.

as 

if you already have a map in there, then turn off floating point, quark simply rounds all the coordinates to the nearest integer. so you get lots of hairline fractures and offset brushes.

aguire made a pretty cool program that attempts to correct most of the problems that you get from converting floating point to integer coordinate maps. it's not completly succesful -- you'll still need to fix a few brushes, but for the most part, it saves tons of time. 

I don't know if you are still having a problem with fullbrights but you can get rid of them in TexMex 3.4:

1. uncheck Use Full Brites in the Preferences/Workspace tab

2. import the .wad file

3. select the texture with the fullbrights

4. click the Adjust Brightness button, click Remove Brites, click apply

Repeat for all necessary textures. Save .wad.

I've used this on David Gurrea's rock textures -it's fast, 40 textures took me 2 minutes to convert i.e. it's as fast as you can click. 

I was trying to make a map but all of a sudden many of the entities became nonsolid, buttons, doors e.t.c. You can walk right through them. There has been no warning from the qbsp program.
Does anyone know why this happenss. 

If you're having trouble with clipping errors in your Q1 map (player walking/falling through solid brushes), you might be interested in the following procedure.

Compile the map with one of my compilers (http://user.tninet.se/~xir870k) and add the options "-solid" and "-hull 1". The first one just disables all liquid brushes and makes the sky solid and the second makes the player clipping hull visible. The build time will probably be longer than usual.

Then load the bsp into an engine, turn on gl_clear 1 in the console and noclip around in the map. Don't worry if the map looks a bit different than usual, all brushes are expanded a bit so it will look rather cramped at places.

If you notice something that looks like a HOM effect, then that area is likely to have clipping errors. After identifying the problems spots, inspect those areas carefully in the editor. There are probably some brush misalignments there. When the HOM effect disappears, the brushes are OK. 

When will you add the negative lights support in your light tool? 

I'll have to give this another try when I get my editor back up and running.

Note that 'gl_clear 1' will turn off the HOM effect and you'll just see a solid colour instead (red in normal GL Quake, void grey in FitzQuake/TyrQuake) 

As you already know, I've had this option for quite some time but I just discovered a couple of days ago this connection with clipping errors.

Normally one has to tediously move around in the map bumping every wall to discover the nasty clipping errors. This really helps in that process.

I must point out though that there could still be clipping errors even if there is no HOM, so it's no Magic Bullet.

PuLSaR: Sorry, no current plans on Antilights. 

could this be used to find spots where a player will get stuck on the joints of a 45� ramp? 

because one big reason for clipping errors is two or more brushes that meet in a non-axial manner and that are also not aligned properly.

I'm right now trying to use this "feature" on a large number of maps that I've had problems with to see how it can help finding spots that the compiler apparently has some difficulties to handle.

Typical causes are very tiny brush gaps, overlaps or faces, either directly on the proposed brush or in an adjacent one. Most of the time it's in a non-axial junction.

But as I mentioned above, it doesn't catch all cases and it's certainly no guarantee that there is an obvious problem spot where the HOM is found.

Still, I find it a major help in tracking down these evil map-traps. 

#935 posted by necros
>if you already have a map in there, then turn off floating point, quark simply rounds all the coordinates to the nearest integer. so you get lots of hairline fractures and offset brushes.

Thanks all, this will help.

> aguire made a pretty cool program that attempts to correct most of the problems that you get from converting floating point to integer coordinate maps. it's not completly succesful -- you'll still need to fix a few brushes, but for the most part, it saves tons of time.

I didn't see it on:
http://user.tninet.se/~xir870k/

Where is it?

as 

It has several conversion/fixup modes, but its original purpose was what necros mentioned; to convert a float map into an integer one with as little accuracy loss as possible. Check out the readme for details.

But if you use QuArK, I'd recommend that you don't disable float coords in map file, you'll just end up in Qoole hell. Load the decompiled map file into QuArK, roll up your sleeves and start the repair job (it might take a while).

Also, notice that there are many compiler warnings that you can safely ignore. 

I've now gone through a lot of maps armed with the -solid and -hull 1 options, looking for HOMs and thereby clipping errors. I find it very useful because there are normally not so many of them, so you can easily go through them one by one, checking if they're worth fixing.

Some maps can't be built this way right now; when loading the bsp, the engine aborts with a cross connected doors error. I suspect it to be two normally separated doors that melts together in hull 1.

In the next version of my compilers, I hope to have an option -noents that removes all entities from the map except world and players. This takes care of the door problem and furthermore, it makes it a lot easier and faster to navigate the map (especially a big one).

No more worrying about monsters chasing your tail, triggers that set off in your face or you accidentally stumbling into a teleporter or change_level portal. Freedom at last ...

Checking the map visually in hulls 1/2 also has another unexpected bonus. If your map is big and you're close to the max clipnode limit (32767), you might find that large parts of the map are not filled in hulls 1/2 due to brushes melting together.

With some simple modifications, you might be able to fill those areas and thus lowering the # clipnodes significantly without changing the appearance at all. 

i'm still not quite clear on what it means to compile with the hull1 or whatever... how does that relate to clipping?
*confused* 

someone would ask ...

Every Q1 map has three hulls 0-2. Hull 0 is what you build in the editor and is normally what you see in-game. This visual hull is not what the player (or other entities) is "clipped" against, i.e. checked for collision so you can "feel" the wall.

This is due to speed reasons, it's easy to clip a point sized (infinitely small) entity like a rocket against hull 0, but for bigger entities like the player, there is a bounding box around it that defines its volume in space. When Q1 was made in '96, it was probably considered too processing consuming to clip the entire bounding box against hull 0 in the game engine so another solution was made.

If the qbsp compiler would, instead of just building hull 0, automatically build two other hulls (1 and 2) by expanding all brushes in hull 0 outwards the same distance as the bounding box for player or shambler sized entities, it would be much easier for the game engine to clip the bigger entities. It then only has to clip the mid-point of the bounding box against one of the other hulls to see if they collide. This is the same thing as clipping a point sized entity against hull 0.

So each time you look at the compiler output, you'll see something like Processing hull # three times. This is when the compiler builds your map, first the normal visible hull, then automatically generating hulls 1/2 by expanding the brushes in hull 0. The end result is three separate hulls in each bsp that the engine will load and use while playing.

What I've done via the -hull # option is to trick the compiler to build hull 0 the same way as it does for the other hulls, by expanding the brushes a bit, thus making one of the other hulls "visible". First I did this for educational purposes, to better understand how a bsp is built and, like you, get a clearer picture of what these other strange hulls were.

I didn't know then that by inspecting the map in the shape of one of the other hulls, you might use certain visual anomalies (like HOMs) to identify areas with problems. After identifying the area, you just make a closer inspection of that area in the editor and hopefully find the cause of the problem (typically some kind of brush misalignment).

If all this still seems confusing, just build one of your own maps (preferrably a small one) using the -solid and -hull 1 options and load the bsp into an engine and I'll think you'll understand better. 

thanks for the explanation!
very useful :) 

i just tried hull 1 thingy on my map! oh my! it looked like bloated dungeon of fat evile! :) it was funny :)
and it's indeed useful, ispecially when you're not sure if player is able to get into some area, this option helps very much.
yet i've found the reason of weird clipping behaviour in some place thanks to this.

thanks again, bengt :) 

i just tried hull 1 thingy on my map! oh my! it looked like bloated dungeon of fat evile! :) it was funny :)

Yeah but what did it look like *with* the hull 1 option? ;-p