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). 

Tyrann: you are awesome.

just in case you didn't know. 

Doesn't -transwater affect performance? 

It does insofar as it makes the water surface not block visibility, so everything beneath it is being rendered whereas it would've been visblocked if compiled with opaque water. Depends on how much additional detail there is underwater. 

Hmmm, it may just work - it looks like the software engine might actually render the lightmaps if the light util generated them. Not sure about glquake. Surface subdivision might cause problems. I'll try an experiment. 

Yeah, it appears it can't be done with tools changes alone. Oh well. 

Cheers for looking into it! I still haven't checked out the latest snapshot... probably will do for the next map since everything is stable and I'm close to finishing... 

Tyrann, do you think that it's possible to make a *liquid do what a sky can do in regards to sunlight only upwards instead? Particularly ones that start off with *slime and *lava? At least then it would make some visual sense that they are fullbright. Obviously they would need .lit support and wouldn't be on by default. Maybe put it in the worldspawn. _mangle support might be nice if someone wants to do something funky in their maps. Just a thought.