what about making the entire hill a func_wall? 

those are some good tips sock, but how am I supposed to learn how to do lighting properly?

I would recommend you find a map you like the look of (light wise) and then check out the source map file to see how it was done. Break the example map down into a small sections with light entities and gradually remove the lights one by one until you see what difference it makes.

Learning lighting for old BSP compile engines is the most time consuming thing because it involved compiling and waiting for the results. The best advice is start with lots of small test maps and try to find some good source map examples. 

WARNING: Mixed face contents (Sky, Empty) near (x y z)
WARNING: Mixed face contents (Sky, Empty) near (x y z)

I have like 20 of those when running txqbsp. 

When I compile the map without light there's just a smooth surface,
so the error isn't the misfitting brush.

the bsp structure around all those brushes probably looks like complete mulch. I'm not surprised light.exe has no idea what to do with it.

take metlslime's suggestion, make the whole thing a func wall. and put skip brushes behind it so it doesn't leak, of course. 

This is old now but stands true on most cases:

http://user.tninet.se/~xir870k/tooltips.txt

It should you understand whatever errors you're getting. 

Processing hull 1...
*** WARNING 09: Couldn't create brush faces
*** WARNING 09: Couldn't create brush faces
Processing hull 2...
*** WARNING 09: Couldn't create brush faces
*** WARNING 09: Couldn't create brush faces

I started getting these after removing a brush that wasn't closed. 

* Use different compilers, see if the problem disappears
* Contact compiler author if there's no obvious remedy - maybe it's a tool problem or can be fixed through a code change.

@ModFax :
Is the eMail address in your func_user information still accurate ? 

http://tomeofpreach.wordpress.com/2014/06/26/unusual-func_door_secret-angles/

That's how you do a func_door_secret that moves up last. Hardly even feels like a map hack, but there it is! 

Neat! 

To quote a household name, thks Preach ! 

@mtlslm- turned it into a func_wall but nothing changed.
I thought func_wall didn't lit light.

@rebb- I can do, but I was wondering why the compiler give normal results, before the error started.
As long as you don't send me mod faxes I'm reliable on that email adress. 

that looks similar to a bug I was helping mfx with: https://sourceforge.net/p/quakespasm/patches/15/attachment/mfxsp17_before.jpg - In that case it was an engine bug, but I think it could also be caused by the light tool being compiled with sse2. which light tool are you using? 

@MadFox, if you'd be willing to send me the map source and compile tools you're using, i'd be interested to poke around and see if I can see what's happening 

it's way. 

your email account wasn't outdated... 

I will definitely be trying this. I've used the func_train method in at least three places. This could free up seven or eight entities (I'm at the 256 model limit right now). 

The door comes out of a wall and there is no light where it starts. This is a problem. With the func_train I just place it where it's going to end up and it moves to the starting path_corner when the map loads. That way it's properly lit.

With a regular door I would use "Starts Open", but that doesn't exist for secret doors. I tried reversing the way it moved but I can't seem to get it to wait between being triggered. It either opens then closes or just stays open.

It would have been nice to free up another dozen or so entities, but I can probably finish the map without them. If I can ever get around to it anyway. 

might be a possible solution to the lighting... though it may be a little flat 

Here's a bonus hack, especially for you Rick. Move your func_door_secret into the open position, and as you do, measure exactly how far you moved horizontally and vertically. Suppose that's -256 in the x direction and 16 in the z direction.

What you now need to do is add another key to your func_door_secret - an origin key. Set the origin to be the vector that negates the movement you just performed, so for the example values above you'd set "origin" "256 0 -16". Negate each value and stick it in a vector, with a 0 for the coordinate you didn't change. Hey presto, lit in the open position, spawns in the closed position!

This trick works on some, but not all other entities - func_door for instance have problems in generating automatic triggers. So have fun, but take care too! 

hm, mail didn't seem to get through, unfortunately. the address in my profile is correct. Could you upload it to dropbox maybe? 

Tried again, and now it worked.
Cheque your emailbox. 

I was actually thinking that origin might somehow work but I wasn't sure exactly how to do it. I'll give it a try when I get a chance. If I can make this work it will be very helpful.

I was afraid I'd have to somehow try to box in the door and light it in place, but that would likely blow my marksurfaces out of the water. I only have about a hundred of those left. 

 

Someday, I'd like to spend enough time learning the bsp formats that I could write a new tool. This tool would take the idea of external bsp models and flip it on its head. The tool would take a bsp file, and would look up all the external bsp models referenced. Then it would add all those models as internal models of the original bsp, and patch all the entities to load those internal models. All the benefit of external models, one convenient file!

Anyone with the know-how already Please, please feel free to steal my thunder and do this so I don't have to! It would solve the problem at hand in a simpler way, and would also let you easily prefab models, which might help with the model limit. 

Easily prefab models that would be lit exactly the same way every time, you mean?

I'd prefer something more like sub-map instancing (like CoD & Source), but that'd require both a compiler change and an editor change to allow for the visualization. But boy, would that be great.