When I used TreeQ with -noents it pointed to all the holes in the BSP before it pointed to the outside entities.

Having entities that are accessible to the void is the definition of a leak. So you should probably not have entities outside the map (brush entities are okay, point entities are the problem) 

The point is that I can't verify if it's a bsp leak *or* a void entity if I can't -noents, besides TreeQ and vis aren't signalling problems, just Tyr's latest version. It's all a bit weird to say the least.
Kind of having a problem with degenerating brushes for my terrain too, it's really odd. I'm losing interest in the map now, need to get it working as best as I can so I can move on. 

of using double precision floating point numbers in Tyrann's tools. It snaps vertices to integer coordinates if they are off by less than 0.0001, whereas TreeQ snaps them if they are off by less than 0.001. So if you have two vertices which are off by, say, 0.0005, they will be snapped to the same position by TreeQ, but not by Tyrann's tools. The result could be a microleak I think. 

with microleaks! ;)

I'm using TreeQ atm and I'm still getting weirdness. It's probably due to me using cubes rather than triangles for this tri-soup business. Honestly I'm fairly clueless, but the map seems to be holding up ok... just hope people don't laugh too much at me when I release the .map file! 

and indicate which brushes (line numbers) cause problems Incan probably give you a hint on what is going on exactly. 

I know exactly where the weird brushes are in the current iteration of the map, but it's stable and vising properly (except if you noclip to the bottom there are tiny little rooms between the brushes).
Honestly it's just the way I've done the terrain. I'm not redoing the whole thing a third time as triangles now, it would probably drive me to murder. I thought of another possible way of doing the terrain just as I went to sleep last night but again I just want to get the map out as long as it vis's right now. 

But it would still be useful for me to see where what TB shows you differs from what QBSP will produce. 

you an email with the file with an explanation. 

On one map world brushes dont showing up (if they are compiled at all, not sure)- only funcs show up;
other compilers (txqbsp, hmap) compile same map fine.

Func_detail usage creates pretty much broken PVS.

Made in Netradiant. 

confirmed: happens when you move brushes between ents involving func_group, moving back to world doesnt help - they still dont get compiled, but moving to other funcs makes them appear.

As said, other compiler do fine
netradiant 

and probably cause netradiant leaves empty brush ents in .map

"classname" "func_group"
}
// entity 230
{ 

@slapmap: Weird. Can you send me a .map which shows the problem? 

This is something in bjp tools that I always used. Your light says it is not supported, though the lighting doesn't seem very different.

Also, I had an error about a missing face if I used light after newskip, but not when I used bjp light. Does your bsp support skip now, because if it does, I guess I can probably just switch. I'll probably want it for detail brushes anyway :)

_selfshadow and _shadow are awesome though! Thanks! 

sent 

@slapmap: Thanks for the test maps. Should be fixed now - try the new snapshot

@than: Yeah, my qbsp supports skip but I only just looked at newskip now and realised that it has water/slime/lava skip as well. That shouldn't be too hard to add. Will look at what is going on with lighting newskip'd maps... 

@than: does this give the expected results?

tyrutils-0.6-52-g4625245-win32

It's not 100% identical to the bjp tools when it comes to treatment of "local minlights", but it should otherwise just make minlights additive. 

thanks for that. I'll try to test it as soon as I can. 

I tried -anglescale (and -anglesense) 0.01 and 0.99 and sunlit area looks identical. Shouldn't it be dimmer with higher value or faces hit at non 90deg? 

@slapmap: oops, missed setting the sunlight variable from the command line. This should fix it:

tyrutils-0.6-53-gee2dc38-win32.zip 

does this actually work? I was experimenting the other day with setting it to really high amounts to see the effect... and even at "-gate 100", there is nothing apparent. My assumption would be that this would make the map very dark with harsh cutoffs. Am I confused on how this works? (I understand that it's intended to be used with very low settings)

Using the released 0.6 tools. 

should work - only affect 1/x, 1/x^2 lights though. Doesn't affect lights with the default linear falloff. 

Updated to affect linear lights as well in the next release (which I should do soon). 

Updated to affect linear lights as well in the next release (which I should do soon). 

Hmm, I still get no visible difference, even took screenshots - nothing. Sunlight is even no matter what value I use http://imgur.com/4GNXAzC

I use "light -anglescale 0.xx mapname.map"
to compile.



Again, thanks for quick updates 

I get a clear difference here - what keys are in your worldspawn entity?

-anglescale 0.5 (default)

-anglescale 0.0