I loaded the rmf file, the pillars were definitely not touching the floor.

The Copper mod is a nice mod that keeps the original feel of Quake, whilst fixing some bugs and adding a couple of nice features.

It has become quite popular:

http://lunaran.com/copper/ 

SetQdirFromPath: no 'quake2' in E:\Quake Engine Games\Kingpindev\Kingpin\Main\maps\215.bsp
#### Finished with exit status 1

I have Trenchbroom compiling Quake 2 just fine.
It's Kingpin and other games giving me this problem

If I just "test" the map this is returned:


#### Using working directory 'E:\Quake Engine Games\Kingpindev\Kingpin\Main\maps'
#### Exporting map file 'E:\Quake Engine Games\Kingpindev\Kingpin\Main\maps\215-compile.map'
#### Executing '"E:\Quake Engine Games\Kingpindev\compiler\bsp\kpbsp.exe" 215.map'
#### Executing '"E:\Quake Engine Games\Kingpindev\compiler\vis\kpvis.exe" 215.bsp'
#### Executing '"E:\Quake Engine Games\Kingpindev\compiler\rad\kprad.exe" 215.bsp'

I can find no leaks, it's just a box with a light and player start.

I don't know why it's telling me no 'quake2'
The map compiles and it runs but 'kprad' is not working

#### Using working directory 'E:\Quake Engine Games\Kingpindev\Kingpin\Main\maps'
#### Exporting map file 'E:\Quake Engine Games\Kingpindev\Kingpin\Main\maps\215-compile.map'
#### Executing '"E:\Quake Engine Games\Kingpindev\compiler\bsp\kpbsp.exe" 215.map'
---- qbsp3 ----
entering E:\Quake Engine Games\Kingpindev\Kingpin\Main\maps\215.map
0...2...5...7... (0)
0...2...5...7... (0)
writing E:\Quake Engine Games\Kingpindev\Kingpin\Main\maps\215.prt
Writing E:\Quake Engine Games\Kingpindev\Kingpin\Main\maps\215.bsp
0 seconds elapsed
#### Finished with exit status 0

#### Executing '"E:\Quake Engine Games\Kingpindev\compiler\vis\kpvis.exe" 215.bsp'
---- vis ----
reading E:\Quake Engine Games\Kingpindev\Kingpin\Main\maps\215.bsp
reading E:\Quake Engine Games\Kingpindev\Kingpin\Main\maps\215.prt
8 portalclusters
18 numportals
0...1...2...3...4...5...6...7...8...9... (0)
0...1...2...3...4...5...6...7...8...9... (0)
Average clusters visible: 8
Building PHS...
Average clusters hearable: 8
visdatasize:84 compressed from 128
writing E:\Quake Engine Games\Kingpindev\Kingpin\Main\maps\215.bsp
0.0 seconds elapsed
#### Finished with exit status 0 

In Trenchbroom. At a glance it looks like the map compiles, but the game didn't start? Check the game path. 

I didn't read the whole post.

Can you run the tools from a command prompt, and see what works manually? 

E:\Quake Engine Games\Kingpindev\compiler\rad>kprad 215
----- ArghRad 2.01 by Tim Wright (Argh!) -----
Modified from original source code by id Software

----- Settings -----

************ ERROR ************
SetQdirFromPath: no 'quake2' in E:\Quake Engine Games\Kingpindev\compiler\rad\215 

so I didn't think I would need any switches 

I mean, try putting it in a folder with ‘quake2’ in the name? 

but would like to solve the problem rather than work around it. Thanks though 

 

penis 

Is it on-grid? Are you SSUUUUREEE it's on-grid? 

I apologize for the inappropriate language in a prior post under my account name. I was in the middle of a lenghty question when I was pulled away from the computer I was using. During my absence, a coworker of mine thought it would be amusing to put a childish remark. Again, you all have my deepest apology. 

OK let's try this again... ALthough I'm new to mapping for Quake, I have been using worldcraft/hammer/J.A.C.K. for over twenty years. I've come accross pretty much every compiiling error that you could possibly think of. I'm very aware of the main culprits when it comes to leaks (entities in the void, func_detail/func_wall not sealing the map, actual holes etc...) The problem I'm having seems to defy all logic. I'm getting leaks in areas of the map that I have essentially completed and have done exactly zero modifications to in weeks. I can compile that map and everything goes according to plan, then I will open up a new room or pathway, I'll do some work in that new area and then BOOM, a leak in some random obscure area that I haven't touched in ages. If I copy and paste the isolated problem area to a new file and compile it works just fine. I can replace a brush that the pointfile indicates, I can shuffle brushes around, I can completely rebuild the area in the exact same way or in variations that seal the map, nothing seems to work. I've had to resort to putting brushes behind seams in order to fix some of my problems, which after decades of experience I know it is a really bad fix. I feel like my map is quite literally a sinking ship. Efforts to solve these issues are really slowing down production. Any help would be greatly appriciated 

There can be a lot of reasons why a sealed map suddenly starts leaking on places that make no sense. Almost every time a leak traces to a light or entity it gets really hard to find the abused polygon.

One thing I am surprised about is.., that tricky outcome with different compilers. I mostly use Ericw tools, but not long ago I had the same embarrassment with an old large map that suddenly started leaking. It fainted on me and it really did hurt. So I left it behind.

Then, some months later, I compiled it again and I used another compiler version, and to my surprise it compiled fine.

It isn't always the construction of your map, sometimes the compiler version gets screwed. 

Thank you! I was starting to have my suspicions about the compiler being at fault (ericw tools 0.18.1). I am, however, very grateful for the hard work put into his compiler. 

Then I discovered that some of my brushwork was on an 0.5 x 0.5 grid, instead of a 1x1 grid. I changed that brushwork to go on a 1x1 grid, and the map stopped leaking. 

Although it doesn't help you fix this, I can at least provide a bit of insight to why it can happen. The first thing is to realise that faces in your map get stored as floating point values in the BSP. Floating point format is subject to rounding errors when the face is angled, and that could produce a leak.

The other important point to realise is that your entire map is an interconnected structure. Decisions made in one half of the map can cause splits to be built in a different way elsewhere. The exact way the splits are built could cause one calculation to round a float differently compared to the previous compilation.

This explains why:
- a leak appears even though you didn't change the brushes in the area (the other areas in the map had a cascading effect that changes how the compiler handles the earlier sections)
- the leak doesn't appear when you compile this bit in isolation (that eliminates the cascading effect)
- changing to a different compiler can make the leak vanish (the chain of cascading calculations could be different in each case)

I think that local mitigation is probably a sensible move, rather than bad practice. Boxing your entire map is obviously no better than leaving the leak unfixed. Having simple cuboid brushes sealing things up behind complex brushwork is more pragmatic. It might even help the compiler make better choices about how to do the calculations, as if they insulate this area of the map from changes cascading in from elsewhere. The backup brushes get culled as if they weren't there, but that doesn't mean they were redundant. 

Excellent explanation, Preach. Thanks!

I'm not the person who asked the question in #20892, but this is really valuable knowledge. 

Can you use an engine to edit create .lit without the map source and re-compiling?

I know you can make rt lights in DP but I am looking for a way to make a .lit file from existing bsps and hopefully add some colored lights here and there. 

There was a tool made by MH which would automatically generate colored lighting on existing BSPs from the greyscale lightmaps, by using nearby textures for color hints. It does not allow tweaking or editing AFAIK.

Called "MHColour", it's not easy to find. These seem like it:

https://www.quaddicted.com/files/tools/WinMHColour2010.zip

https://github.com/dsvensson/mhlight 

Whoa. That's pretty wild. Thanks. Will try this out. 

If the light entities are still in the map, could you:

1) extract the entities as plain text into a .ent file
2) add color keys to selected light entities
3) merge the .ent file back into the BSP file
4) run the BSP through a coloured-light aware light.exe tool to generate the .lit

I know there are tools out there that can do steps 1) and 3), but will have to let someone else remember exactly what and where they are. Also worth considering that without knowing the exact light.exe tool and settings used on the original compilation, you may not get exact fidelity when re-lighting the map. Probably can get close with some trial and error I imagine, and in some sense changing the lighting is the objective...

One last worry is that the .lit file may only be compatible with your recompiled map, but not the original BSP file - please don't assume that without testing! 

Good info. Yeah there are quite a few options to extract and "inject" .ent files into BSPs. EntEd, AdQuEdit and Quark to name a few.

Over on Discord Woods made me aware of a commandline option in ericw's tools to extract .lit data from a BSP. I'll be working on this over the weekend so I can report back.

All of this might make it into a video as well. 

Hello! I was wondering if someone could take a look at my map to figure out why it's leaking. I've read through the Quake 1 Tool Tips and have tried replacing the broken brush, but it still leaks at the exact same spot, no matter how I change the brush.

The QRK for the map and QuArK's output files (.map, .bsp, .lit, etc.) and a tool log can be downloaded from here: https://ufile.io/togmlnky 

Sometimes it's not the leaky brush itself that's the problem, but the brushes surrounding it.

In this case, the brush that the pointfile travels through (the north wall in the nailgun room) looks fine. But there are a few brushes nearby that don't seem to be on-grid, notably the little octagonal recess housing the flame, as well as the cylinders in each corner. If you set your map grid to the lowest setting and zoom in on the vertices, or the points where the cylinders intersect the wall, they don't always line up:

https://ibb.co/7kFb5RM
https://ibb.co/jzwJ1Vf

This doesn't always break things on compile, but it can do. Assuming QuArk has some kind of vertex tool it might be worth tweaking them. Moving each cylinder so the center of the brush lines up with the corner of the room might help, too.