How are pointfiles generated and where do I load them from? I am mapping for Quake 2 by the way not Quake 1. 

qbsp3 saves it when it detects a leak. It should be in the same directory that it writes the bsp to.

It looks like the Q2 compiler generates a .lin file instead of the .pts that the Q1 tools do. Try loading the .lin in TrenchBroom. 

Ok I am THIS close to finally having a working map! I was able to get the bsp compiler and vis compiler to work but I am having a problem with the rad compiler. I get this error from it:


#### Executing 'C:\Users\Sveinn\Desktop\quake2compiler\ppro\qrad3.exe stroggbbq.map'
----------- qrad3 ----------
original code by id Software
Modified by Geoffrey DeWan
Revision 1.04
Compiled for Pentium Pro processors
-----------------------------
gamedir set to C:\quake2\baseq2\
reading C:\quake2\baseq2\maps\stroggbbq.bsp

************ ERROR ************
Error opening C:\quake2\baseq2\pics/colormap.pcx: No such file or directory
#### Finished with exit status 1


There is no folder inside my quake 2 directory called pics nor did I find anything called colormap.pcx. I am using the steam version of the game. 

It looks like qrad3 needs that colormap.pcx to be extracted from the pak file.
Found a copy of it online:
http://www.quake2.com/qworkshop/files/colormap.zip

try putting that in a "pics" folder in baseq2 

That did the trick the map compiles now! But for some reason it's completely dark and the lights (those green boxes called lights) don't seem to work. Do lights work differently than in Quake 1 (when I made a quake 1 map the green light boxes worked just fine)? 

Is there something wrong with the Daikatana texture "mtn2"? When I texture a brush with it in TrenchBroom, the editor treats it like a clip brush. So far it's the only texture I've found where this happens.

Or is it a TrenchBroom issue? Or something to do with the name of the texture?

Here is an example of what I mean. The brush on the left is textured with clip, the brush in the centre is textured with "mtn2", and the brush on the right with "mtn" (which behaves normally). 

I recall seeing an issue on the Github tracker for something like this. It is an editor bug and at first glance a very weird one.

I think it should be fine in game, if you can stand having it look like that in TB.

Are you using the latest RC? 

Are you using the latest RC?

Yup. I searched the open issues on github before posting here, and couldn't find anything, but I guess I didn't search very thoroughly. 

It's a bug. I looked for an open issue a while back and had no luck myself. It won;t affect your map though. Just annoying. 

I submitted it as an issue on Github just in case. 

The "View" -> "Show X brushes" (hint, skip, clip, etc) system was broken in TB2 RC4. This is the same code makes clip brushes semitransparent. It's fixed in git / will be fixed in the next RC. 

Probably a long shot if anyone knows this one-

In Hexen 2, water brushes (or rather, any brushes that are rendered underwater), have this really ugly warping effect. It basically arbitrarily warps the vertices of the underwater geometry around in a wavy fashion, which is a neat idea, but it makes clipping errors and texture stretching.

As far as I know, the variable for this is called r_waterwarp 1. I tried turning this off in the console (r_waterwarp 0), and in autoexec.cfg, but it claims "Unknown command".

I'm a little confused because I tried a couple other vars from the console commands, like "r_transwater 0" should remove transparency on water, but it also claims "Unknown command"

Here are (supposedly) the H2 console commands

https://www.quakewiki.net/archives/console/commands/hexen_2.html

Would anyone know why they don't work? I'm using glh2.exe, from Steam 

Ah, ok. Thanks for clearing that up, ericw! 

I'm pretty sure I've used Pak Explorer via Wine before, but can't get it to work any more. Any recommendations? I'm using Linux Mint 64 bit. 

I think the preferred .pak tool is Pakscape, which I've used with Wine in a Linux distro before. Maybe try that? 

If you just want to rip stuff out of a pak file and are comfortable with Python, I made this module a while back: https://github.com/neogeographica/expak 

damage_inc: Thanks, that did the trick!

Johnny Law: Thanks for the link. I'm not comfortable with any programming/coding language, but I'd like to be. Made a note of this; I might try to use it later just as a learning experience. 

All righty. :-) BTW if you do install that module, it also installs a command-line utility http://expak.readthedocs.io/en/latest/simple_expak.html so you don't need to write any Python code to do simple things with it. 

Noted, thanks very much! :) 

Here are shots of the 'clipping' with Hexen 2's water warping effect (which I assume, to be related to "r_waterwarp 1")

https://i.imgur.com/Pn1jag1.png

https://i.imgur.com/2AS3Dei.png

As you can see it warps around the tris of any underwater geometry. I'm not sure if this was in Quake (Quake 2?) also, but I'd like to disable it. "r_waterwarp 0" in console returns "Unknown command" but I am fairly sure that's the right variable

If no one ends up knowing about this one though then I'll have to live with it :-) 

this ugly warp effect and the fact that r_waterwarp is ignored are both problems in GLQuake as well. It's fixed in a lot of modern quake ports but perhaps not in the Hexen 2 port you are using? 

What does Port mean in this context? I'm using vanilla Hexen II, well, glh2.exe. Back in the day (when I had my disk) I remember there was just a "h2.exe" but the Steam version only comes with glh2.exe 

"Port" as in source port, modified engines made by the community.
http://uhexen2.sourceforge.net is the Hexen 2 one I know of. 

I'll have to patch that then, looks like they fixed a lot, thanks : )

I've run into another water-related problem and I'm very confused now. It seems that if your map has leaks, then VIS will not run, and water will look weird -- That is, it will look weirder than it is normally supposed to look. It will be 100% opaque instead of transparent, and you can see other parts of the level if you look into the water... Pictures work better here:

https://i.imgur.com/cDSzy8L.png
https://i.imgur.com/iZaaPXK.png
https://i.imgur.com/8tq80zP.png

The water is definitely not supposed to look that way. It's 'supposed' to look like this:

https://i.imgur.com/2AS3Dei.png

A note -- whenever the water appeared opaque like that, that was an indication that my map had leaks. I was fairly sure I didn't have any... but I slowly 'chunked off' entire parts of the map with giant wall chunks, and deleting any lights, etc that would've been outside the map, to try and find where the leak was. I eventually enclosed the entire map with new, giant brushes, enclosing the large map to a single hallway -- made a test water brush, and it still didn't look right (which means VIS isn't running, I guess)

I thought, then, maybe my map file is corrupt, and I made a new map. Single room, 6 sides, 1 light, 1 playerstart, no leaks, little barrier in the corner with 1 water brush inside ... that's the room pictures in the first three screenshots. Water STILL looks incorrect. What is happening here?

I should reiterate that this wasn't happening before, and water looked transparent and looked totally correct (aside from the vertex manipulation warpy effect of the engine). I'm baffled as to how this could still be messed up on a brand new map? 

Screenshots 2 and 3 look like a map that were QBSP'ed and VIS'ed without transparent water support - the vis data is culling stuff beneath the water surface when the player is above, because it thinks you can't see under the surface, but the engine is using transparency so you can see through and it looks glitchy.

The fix is to run QBSP with transparent water support. I'm not sure which tools you are using but check the docs for a "-transwater" command or something like ythat. If your tools don't have it my quake compiling suite does by default: http://ericwa.github.io/ericw-tools/ ; it supports hexen 2 with the -hexen2 flag added to qbsp.

but I slowly 'chunked off' entire parts of the map with giant wall chunks, and deleting any lights, etc that would've been outside the map, to try and find where the leak was.
This works but there are easier ways; TrenchBroom and JACK can load the pts file which should draw a path that goes through the leak. I think you can also load the leak in the engine with the "pointfile" command (in Quake at least).