you might be right. I have been using aguirre's tools for a long time now, can't remember what the original tools did and didn't do. 

yes, that's correct about onlyents on light. it was added to address the problem where doing onlyents with qbsp would break switchable lights. 

qbsp:
...
Opened WAD: \program files (x86)\worldcraft\textures\tech1.hlwad
*** WARNING 15: \program files (x86)\worldcraft\textures\tech1.hlwad isn't a wadfile
*** WARNING 01: No valid WAD filenames in worldmodel

And seriously???:
*** WARNING 06: No info_player_deathmatch entities in level

vis:
Seems okay. I love the resume feature.

light:
I'm getting a TestLineOrSky: tstack overflow

Bengt's light 1.43 gives me everything fine. Here's my light info:
454 entities read, 333 are lights, 40209 faces, 500M casts

Unless I'm missing some compile parameter, then I'm going to be sticking with ol' Jardrups light. The vis is wonderful though, thanks Tyrann! 

Not sure about the invalid wad file - can you email me a zipped copy?

Tstack is trivial to increase, will do that for the next release. 

Oh wait - TestLineOrSky has been removed for a while - make sure you're using the latest versions - http://disenchant.net/utils/ 

Does your light compiler support _sunlight2? If not is it possible to add that? 

The only version available on your website is 0.10. I have version 0.6 which is posted at the top of this forum. And sorry, I didn't realize that the wad name was cut off. They are .hlwad's since I'm using Worldcraft 3.3 with the quake patch. It's just the standard quake wads converted to hlwad...well with my own additions and modifications that is, scavenged from various places.

What version is the latest? and does it support hlwad setups? 

After applying func_detail to brushes in my map I noticed with r_showtris that areas behind were showing up. The detail brushes were allowing vis to see through the brushes that intersect the func_detail. I found func_detail cannot be used like func_wall where you block the back and your good. The solution I found was a small void gap between areas.


Qmaster: Version .10 supports hl wad files and format 220 valve maps. Use Utils hompage link above.

Tyrann: the download link points to old version .6 

is actually just a wad3 .wad. AFAIK you cannot load this into TB. So either convert them to normal .wad using TexMex or download the .wad from somewhere (I suggest quaddicted's ftp). 

Version 0.10 is greater than version 0.60? Is this 0.6 + (4 * 0.1) = 0.1 ?? Version maths, what can you do *shrug*. Anyways, thanks, will try.

@FifthElephant: Gotcha, thanks! 

 

Using version 10 now :)
....hlwads load good...
CSG... everything fine
6183 brushes
35535 brushfaces
yadda yadda
---- SolidBSP ----
1...37 38 39 40 41 42 43 44 45 46*********** ERROR ************
Mixed face contents in leafnode near (140.00 40.00 0.00)

no bsp made

This mix point (140, 40 ,0) is a corner where 4 brushes meet. The two walls tjunc. The floor tjuncs with the walls. And a lava brush tjuncs with everyone else. And then qbsp gives me this juncky error. I don't get it, compiles fine in txqbsp. I'll see if I can reproduce it with just those brushes in a dummy map. 

 

I think that's not the junctions, just that you've got a sky brush touching a liquid brush.

Leave a gap between them, filled with regular brushwork if that'd cause a leak. 

Well qbsp finally worked. Wierd output though.
Seems I'm getting 352% for SolidBSP with every other % in between. After 100% they all run together.
....
57 mergedfaces
---- SolidBSP ----
1 2 3...... 94 96 98100101103105107108
110...347 349 350 352 200 split nodes
71 solid leafs
...

I'm still psyched up about having new compile tools! This is great. Multithreaded vis was way faster than my old one. Even between versions Tyrann has made improvements. Version .10 vis was about 8 minutes faster than .6 on a map with 6000+ brushes...surrounded by a cheater's cube!! :P

Tyrann's lighting was also much faster than my old bengt modified light, less than half as much time. Hurray for multithreading! 

Nearest sky brush is over 1000 units and several leafs away from that corner. But that's a good thought, you know I don't think I've ever tried bumping liquid up to sky before. huh.

Hrrmm... Still can't get tyr's qbsp to swallow this one map of mine. Granted, the map doesn encompass the ENTIRE grid in Worldcraft 3.3, but its only 16MB when compiled...so far.

Tried another smaller map. It worked FINE. 

@quaketree - no _sunlight2 support right now, but I'll add it.

@mechtech - I think you are seeing this effect (and it's normal - just fill in the cavity to remove the overdraw).

@Qmaster - Yeah it's not obvious, but the '.' in the version string is a separator, not a decimal point. The old treeqbsp progress counter is a bit whacky and will be getting replaced. Happy to take a look at the compile problem if you send me a .map and any wads I'll need to compile it.

I might make a discussion thread for the utils because we're not really talking about version 0.5 anymore :) 

Tried it on another large map of mine.

I sent you an email with my .rmf and .map files and the log that qbsp spit out zipped up in city_src.zip 

@quaketree - no _sunlight2 support right now, but I'll add it.

Spiffy. I'm guessing that adding features that other popular compilers already support can only boost the use of yours. 

@Qmaster: cheers, will take a look over the weekend. 

Qbsp support for displacement to brushes automatically with a command parameter of dispheight to set the thickness to automatically offset from a displacement surface's normal (negative normal that is) from hammer.

Oh and a command param to disable it such as
-nodisp 

Looks like I've got the same mixed face contents in leaf error.

The map is unsealed though, so will fill in the gaps first.

Comes under the same specifications as QMaster's map - the sky is nowhere near the brushes in question, although there is liquid there. 

The tools don't support non-rectangular liquid brushes. If used then they produce the 'mixed face contents in leaf node' error and don't build the bsp. 

That's pretty weird. Let me test that... 

Not just non-rectangular.

ijed: got a fairly simple test case which show the incorrect mixed face contents problem?