well it's a shame then, I'll probably have to find another solution to the problem. I'm not sure exactly how this works because I have a platform which has clip brushes on it that works, but when I tried to block off the doorway in the same fashion it doesn't clip. 

he means you can have clip brushes in func_items, but only if you have textured brushes within the same entity. hence the clipped plat working (whereas a plat made entirely of clip wouldn't work) 

Hmm, I will have another look at that to see if it can be made to work. If all brushes are clip then there will be no brushes for the entity in hull 0. There's probably a way to make that work...

Are you sure you want a func wall that blocks movement but not bullets? That's what clip will do. 

the reason being is that one side the corridor will be blocked off by boxes to the level (for deathmatch) but on the other side will be the singleplayer entrance. It's not even a big deal, I thought I could make it dual-function but it's not like anyone really plays DM that much these days. 

I've made duplicate brushes for the doorframe and put the clip brush in the middle and it seems to work now. A weird solution to the problem but it works so I wont need to release the same map twice. 

I think it happens because the bounding box is based on the visual model when it is loaded by the engine, and the engine only checks collision within the bounding box. 

Sort of, but I think qbsp actually generates the bounding box. And the engine just accepts what qbsp generates.

I tried fixing this in the bmodel loader in fitzquake but it never seemed to work quite right and i moved on to other things. 

You can find my attempted fix in the fitzquake source as Mod_BoundsFromClipNode(), which is currently commented out because it didn't work. 

Yes, I think it's not possible to fix the bounds in the engine because the necessary information was thrown away at compile time. The fix in qbsp is actually pretty trivial. Fixed for TyrUtils version 0.7. 

@FifthElephant: Give this snapshot a try. 

Running light on a very small map as a test. -extra works fine but...

* Could not execute the command:
"C:\Program Files\Worldcraft\quaketools\tyrutils-0.6-35\bin\light.exe -extra4" "c:\quake\id1\maps\h1b"
* Windows gave the error message:
"The operation completed successfully."

I... I... I just don't know what to say (the operation completed successfully is an error? WTF is THAT all about? I think Windows is drunk again). The map then loaded just fine in Quakespasm minus light being run at all (fullbright). So then I tried -soft 2 and had the same result. Just to narrow it down I ran just light on the compiled .bsp using the command prompt bypassing WC 3,3's automatic compiling and it worked fine. I don't if that's something that you can fix or not but I thought I'd mention it. The extra features are very nice though.

Wc3.3 set up using the Quake Adapter. Your light v0.6.35 (the last snapshot that you put up). Note that -extra worked just fine using WC's compiling console. 

Ok, that's pretty odd. Can you paste that info into pastebin so it's not cut off on the board. Not sure if you somehow had quotes around the util and the command line parameters, which would cause problems. E.g.

"light.exe -extra4" "C:\...\blah.bsp"

vs.

"light.exe" -extra4 "C:\...\blah.bsp" 

Ok. I forgot about F_M's cutting off of long paths. To recreate it was:

In Worldcraft 3.3 what I did was to go to:
Tools > Options > Build Programs > RAD Executable and put in (spaces are added before each "\" for here):

C: \Program Files \Worldcraft \quaketools \tyrutils-0.6-35 \bin \light.exe

This is what WC normally generates in it's built in compiler when you set it up and it works just fine.

To that I added [space]-extra4

Then I went to File > Run and made sure that the extra option was turned off (normal was ticked instead) And it failed to generate a lightmap and gave the warning that I mentioned above:

* Windows gave the error message:
"The operation completed successfully."

In the WC window that normally appears during a compile.

The same thing happened with [space]soft[space]2

It worked fine when I used the command prompt. Just to be clear here's what I did in that case:

I made a separate folder named c:\Qtest and copied the map named h1b.bsp and your light.exe as well as the related .pts file just in case that was an issue (the map itself doesn't leak but better safe than sorry right?) and ran light in the command prompt using:

CD: C:\Qtest
light.exe -extra4 -soft 2 h1b.bsp

on it and it worked just fine.

The map itself is very small with only a few entities, none of them outside of the vanilla Quake standard except for one (multiple brush item) func_detail that works just fine (that's why I was playing around with it in the first place) and a light that has "no falloff" selected in its properties. 

I should add that [space] is just a space and not actually entered as [space]. 

I just got things working in the cmd window and made a batch file. I find it easier than using the hammer compile setup.

An interesting thing I found today. Works on win7 with multi core cpu.

c:\windows\system32\cmd.exe /C start /affinity 1 yourbatfile.bat
Uses processor 0
c:\windows\system32\cmd.exe /C start /affinity 2 hammer.exe
Uses processor 1

Could be used to build your map on one cpu and hammer on the other. You could compile and use hammer without making it too slow.

Just an idea 

that's cool, i usually just go into the task manager and remove a checkbox on one of the cores.

i should build something like this into the compiling gui. 

You could also right click the VIS process and set it to a lower priority. That way when you're using Hammer, it will fade into the background and when you're not it will get Windows full attention.

Or it should work that way, anyway. 

yeah, I do that too. :)
That's actually better because windows will manage the priority itself so when you aren't doing anything it's using closer to 100% instead of ignoring a core completely. 

I could make vis set it's worker threads priority to low by default.

@quaketree: the problem seems to be with Hammer launching the light utility, not the light utility itself. If I get time I'll try set up Hammer here myself to see what's going on. 

That's what I kinda figured, I only mentioned it here so that you could put that into your light readme as a known issue with Hammer and those extra -commands if you wanted to. 

Just go to "Below Normal". I think if you go to "Low" it starts to only get processing when there's NOTHING else to do, like OS or anything... 

I haven't had chance to look at the clip entity snapshot, sorry Tyrann (I solved it by messing around with brush shapes, ironically I might not even need it now since I have expanded my idea).

Anyway, is there any way of getting water to not be fullbright? Is it possible to get them to accept light and shadow? 

slime and lava too... maybe lava should always be fullbright, but then why not just use _minlight to achieve this? 

I believe (and someone correct me if I'm wrong) that they are handled by the engine and not the compiling tools as far as fullbrights are concerned. The only thing that gets done by compilers is to create a vis\bsp portal (not unlike a hint brush) unless you use -wateralpha (or whatever that command is in some qbsp programs) to make it transparent which simply removes the portal and in some cases takes away the fullbright. 

what quaketree said. engine is responsible for the 'lighting' of water (and sky).