"light" "10"
"_sunlight" "110"
"_sun_mangle" "300 -65 0" 

@slapmap

Those keys look okay. Just check the light.exe output and make sure you're running version 0.6-53-gee2dc38. Otherwise, if you email the .map to me I'll try it here and see if I can tell what's going on. 

Would it be possible to have separate vis for water,slime and lava? This way you could have a controllable form of occlusion culling to help keep r_speeds low. 

r_wateralpha applies to all fluids, so you'd need to have some engine cvar that applies only to water in order to use that properly, otherwise you'd get HOM effects on the lava and slime that were blocking vis if their surface transparency was using the wateralpha setting :/ 

Nothing too earth shattering if you've already been using the snapshots, but if you're still on v0.5 or v0.6, there are some nice worthwhile changes:

* Unix man page documentation for the main tools (qbsp, light, vis)
* HTML and text documentation is generated from the man page sources
* qbsp: added support for using WAD3 texture wads used by Hammer
* qbsp: include clip brushes when calculating bmodel bounding box
* qbsp: enable creation of clip-only bmodels
* qbsp: recognise and remove *waterskip, *slimeskip and *lavaskip surfaces
* qbsp: added hintskip texture support
* qbsp: fixed some bugs parsing empty func_group/func_detail entities
* light: implemented self shadowing and full shadows for brush models
* light: implemented the "-soft" command line option
* light: implemented the "-addmin" command line option
* light: implemented the "_anglescale" (aka "_anglesense") key and cmdline
* light: remove support for negative color components (never worked properly)
* light: removed the "-nominlimit" option (now the default behaviour)
* light: removed the "-compress" option (a bad idea from long ago)
* light: make -gate command line affect linear falloff lights as well
* vis: changed the default testlevel to 4
* vis: added the '-noambient*' options to disable auto ambient sounds. 

So I decided to have a look at using your tools for making my deck remake into a singleplayer level (along with using the new version of trenchbroom) and all I get is constant errors about leaks that weren't present when I used TreeQ to compile the map.
I've tried to fix verts and such but to no success, the pointfile doesn't point to any leaks... 

To save Tyrann some time, can you send him the MAP file so he can debug it? :) 

Ok, I've forwarded the email that I sent to SleepwalkR as that contains the details. I've included the .map, the .log and the .pts file. Doesn't seem to point to anything with the confines of the map. Bear in mind that this fully compiles using TreeQ, I'm not sure why it doesn't compile with your new tools because I'm not so familiar with mapping for quake. 

I loaded the .map included in the download in Hammer got 20 brushes that could not be loaded. the missing brushes cause leaks. Loads fine in Trenchbroom and compiles without leaks using Txqbsp.exe 

Did Hammer say anything about why those brushes could not be loaded? 

Hammer gives no usefull info

Any way to get the map line number from selected brush? I found the missing brushes but how to pass on the info. 

Changed the texture in trenchbroom and saved. As long a brush order was not changed on save. brush starting at line# 15116-15127 and 15128-15139 are two that will not load in Hammer 3.4 build 2363 

Thanks, looking at it now. 

Wow, this is an interesting one!

There are some odd plane definitions, just off the grid like this one:

( 55.9998779296875 103.99990844726562 -72 ) ( 80.00042724609375 128.00054931640625 -72 ) ( 55.9998779296875 103.99990844726562 -88 ) tech04_6 0 0 0 0.5 0.5

But the pointfile my qbsp is generating looks like complete garbage. Might take a while to work it out, but I think it's worth finding out exactly what is going on. 

I only ever bring problems to the table, I'm kind of a jerk like that. But at least you have a complete maniac messing around with all these tools, should make for fun times! 

TB should round the plane points if they're this close to integers. OTOH, the way the vertices are generated, small changes to plane points may yield big changes to vertex positions. 

Getting this error:
---- GrowRegions ----
*** ERROR 43: Internal error: entity->iVertices > entity->cVertices

I'll mail you the map if that's ok? It's made in Worldcraft by the way. 

---- light / TyrUtils v0.7 ----
running with 2 threads
BSP is version 29
using minlight value 40 from worldspawn.
Colored light entities detected: .lit output enabled.
************ ERROR ************
LoadEntities: MAX_MAP_ENTITIES

BSP built with version 0.7
Same map will light with mhlight.exe 

@than:
had this error too.
was skip texture on some surfaces of clipped or vertex edited brush entity. 

somewhere in the map, given the number of clipped or vetex edited brushes in it. I don't see why that would cause a problem though :/

Are you also using Worldcraft 1.6a? I didn't think anyone but me used it these days (I think most people use 3d accelerated 3.3) 

@than, @Stahlkralle, @mechtech

Thanks for the bug reports guys. Both issues should be fixed now - please try the new snapshot and let me know if that's fixed it. 

Map compiles fine now!!!
The func_detail thing is working great. Like getting a new CPU. vis is no longer the enemy. 

---- GrowRegions ----
35%---- light / TyrUtils v0.7 ----
extra 4x4 sampling enabled

GrowRegions breaks with no error at 35% and then light won't run because there is no bsp :/

Did you manage to get my map to compile? If so, maybe there is some problem with the current version. It's currently under all limits and is compiling fine with aguirre's qbsp though. 

@than: yes it compiled here, although without textures - I'll try to work out which wads I need, but feel free to just email them to me if that's easy enough. 

Causes HOM. Works like slime but does the HOM like a worldbrush with skip texture.

Using snapshot from post #235