Thank you very very very much! :) 

...Does anyone know how to get GtkRadiant 1.4.0 working for quake mapping... I already read the Tuts by Tig and Necros (thanks a lot guys) but they're both for version 1.2... Anyone has a clue? I'm a complete newbie, so the question could be very stupid..... 

to necros@rogers.com 

thanks for the awesome feedback, Scampie! 

Your map finally finished vising:

---- Vis 2.22 ---- Modified by Bengt Jardrup

File: e2m1a.bsp
6117 portalleafs
22174 numportals
Loading state file: e2m1a.vis
testlevel = 4

average leafs visible: 552
max leafs visible: 2336 near (-2885 -1736 1184)
c_chains: 2789094431
visdatasize: 1169545 compressed from 4679505

Elapsed time : 5h 45m
Session time : 346h 1m

The bsp actually works, too (at least in FQ). Max wpoly is about 3500 near the power plant tower (the coordinates above).

I sincerely hope that you can reduce the fullvis time from its current 14 days ... 

I may be doing something wrong, but how can I put in a parameter for the BSP program in Worldcraft 1.6? I've got 4 different BSP's: WC's, Tyr's, Tree and W. I'm having the problem with 45 degree angle texture misalignments. I've tried the paramter under Tools/Options/ and in the BSP path field... with some BSP programs it throws an error in the process window and continues to compile, in some it just builds with no error.

Or am I just better off BSP'ing manually? I had fixed this issue a long time ago, but I think it may have been a modded .FGD actually. Also, is there a certain FGD you would suggest getting that I may be better off with regardless? 

dont use the worldcraft process window, just open a dos window (start->run->command (or cmd if running 2000/XP) and compile from there.

and -alternateaxis is probably what you want. as long as the texture is aligned in wc it will show up fine w/that 

fgds shouldnt really mean anything to your compiling other than where items are placed, use czg's it has fixed item-offset bugs iirc:
www.planetquake.com/greyvoid/quake.fgd 

http://www.planetquake.com/greyvoid/quake.fgd 

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?