I know nothing about, but if:

- it was a Q1 map
- fullvis was slow
- by "not vised" water you mean transparent

then I'd say thet you've a leak that the compiler isn't telling you about, a very common error in old build tools.

If the map format is reasonably similar to Q1, you might be able to try one of my qbsps, just to see if it finds a leak.

Otherwise it's probably time to pull out the old leak hunting tricks, e.g. put big solid blocks over parts of the map and rebuild until you've nailed the leak. 

I guess the hexen bsp-format is very similar to quake1
I will try it 

TreeQBSP v2.04 -- Modified by Bengt Jardrup

Input file: ./maps/mymap127.map
Output file: ./maps/mymap127.bsp
---- LoadMapFile ----
*** ERROR 03: Line 17: Invalid brush plane format

Elapsed time : 0:00

Peak memory used : 1.4 MB

!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!
Build failed, because it did not create the (+BSP) file: C:\appl\spiele\hexenII\
UhexenII\tmpQuArK\.\maps\mymap127.BSP
Build failed, because it did not create the (+PRT) file: C:\appl\spiele\hexenII\
UhexenII\tmpQuArK\.\maps\mymap127.PRT 

my qbsps can't read the format, you may be able to export the map from the editor (e.g. QuArK) to Q1 format and then rebuild.

Or if you can find more recent tools that can build HexenII bsps, maybe they'll work better.

You can also verify that your map leaks by noclipping outside, if you can see the textured outside of the map, it leaks in hull 0. 

indicates that the brush face format is incompatible with Q1. Since I see you're using QuArK, try exporting the map to Q1 format if possible.

If you can't proceed, send me the zipped map and I'll see if I can figure out what's going on. I don't have HexenII though, so I can't check it out in-game, but I've QuArK. 

I can't see the textures outside the map.

Maybe it has something to do with:

a) It's a big outdoor map
b) It's the map I started mapping so almost everything is off grid 

Its the grid; It's a bastard to fix as well because the errors can be all over the place.

I'd advise adopting a preferred grid size in future for all walls / floors and sticking to it, only going smaller for details or different mapping techniques - curves, terrain etc.

I don't know QuArK much but I'm assuming theres a vertex manipulator - that'll allow you to snap everything to grid, although it'll be a gruelling task.

Another option would be to cut out a piece of the map and copy paste it into a new file, correct it and make sure its not leaking and then c+p the next section until you've got all the important features. Fairly primitive way of doing it but you'll be sure to have a very clean mapfile. 

the mymap127.prt file, again if it's similar to Q1 then there are two numbers on the first two lines of the file. The first is #leafs and the 2nd is #portals.

If they're high (>10000), then you've probably too much solid detail and need to simplify or turn into func_walls or similar.

Having a messy outdoor map is a good start to a major vis headache ... 

tidy up the mess end compile it later and also with other tools. Apart from the off grid there are a lot of microbrushes too
(There is a lt of work to do)
I might ask later if that does not fix the problem

Thanks a lot for advice :) 

How to avoid trigger_relay to emit a sound ? I have 4 choices in QuArK (i.e 0: none, 1: secret, 2:beep beep, 3: large switch). I selected the "none" option, but I still have a "beep beep" like sound ingame... Is it the normal behaviour, or am I missing something ? 

Don't put anything in the "message" field. Right? 

But 0 should work - different editor. Maybe try editing the .map direct with notepad.

Another question, similar;

How do I stop a door_secret playing its touch sound after it's opened? Using in the case of ones that remain open.

If all else fails I can just embed it in a wall recess or clip brushes. 

I checked the .map file, and the sound filed is set to "0"... pretty weird.. any idea where it could come from ? 

 

Yes, it has a message field... is it the cause of the "issue" ? 

Oh, and one of them doesn't have, but the beep beep sound is here BTW 

when they have a message field, unless it's completely empty ("" no space).
If yours also beep without, check the trigger/button firing them. 

OK, I have a single trigger_realy that causes the issue: it is generating a beep while triggering a sound, and it is not really the effect I wanted... I have this one to check particularly: thanks for the info ;)

BTW, as I already launched a fullvis run, is it possible to hack the BSP to remove the message field, or is it mandatory that I recompile all the stuff from scratch in order to obtain the wanted effect ? 

Set the trigger's sound field to an invalid value then, like 4.

You can easily recompile the map with -onlyents if you only edited entity flags. Remember to run light -onlyents too if there are switchable light styles in the map. 

I'll try it... and even if it doesn't "work" as I want, I can launch again my fullvis, as it was running only since 12 hours... so not a big waste of time...
Anyway, thanks ! 

Sorry for flogging a dead horse:
Would it be too much work to add support for detail brushes to Qbsp? After all, it has been done before by Alexander Malmberg - the source code is available too http://quest-ed.sourceforge.net/files/mapc/qutils_2_src.zip
Are there obvious reasons why this would be unfavorable, technical issues or the like?

Func'ing architecture does work, but it has disadvantages too. Detail brushes (not splitting geometry) might be better in certain situations. 

those versions, they're introducing new file formats (e.g. map and prt) and AFAIK require modifications of all tools (possibly engines too).

I don't like messing with the original formats; I want to keep the stuff open-ended so you always can use whatever step that works best for you.

There are already "Q1" maps/mods that require specific tools and/or engines to work. 

...could not be compatible with the stock quake engines, as far as I know.

One thing that could work is having func_walls or func_illusionaries that cast shadows on the world and on themselves. I guess you'd have to have a flag or key that tells light.exe which bmodels you want this feature for. Then, you'd need to run each light trace through both the world BSP and every shadow-caster entity's BSP, and see if it collides on any of them before reaching it's target.

Obviously this would only make sense for entities that don't move. 

recently i've noticed a few problems when lighting rocky/terrain areas:

http://www2.jameson-h.com/fr/ftp/rj9k/img/light1.jpg

http://www2.jameson-h.com/fr/ftp/rj9k/img/light2.jpg

using tyrlite v0.92...

anyone have any tips on how to avoid these? is it just a case of dodgy brushwork or are there other light utils that fix it? 

Had something similar when I did not add -etp to the Qbsp.exe