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. 

I finally got the sliding secret door to work. It gave me brain damage though, I guess because seems to work backwards from how I expected.

Apparently the door is lit in the position set by the origin key, but then moves to the position it was actually placed in the editor when the map is loaded.

The door is 320 units long and moves to the right (positive X) and then up (positive Z). I had to make the origin key -320 0 -16.

It does work though, slides out of total darkness lit perfectly for where it ends up. 

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

Yeah, but because it's lit independently, you'd have the freedom to give them "generic" lighting - like the ammo models do. Particularly if it's a moving model like a door, where you can't do anything better than general matching of the ambient light. 

Has solved my headaches in this department. Especially good for getting rid of black polys and for lighting glass. 

What is going on. 

 

 

Updating to tyrqbsp v0.15 fixed it. 

After having spent days using the clip tool to painstakingly carve brushes to look like rotated objects, I only now realised TrenchBroom has a "rotate" tool and I could just have, you know, rotated those brushes. You may all now point and laugh.

On a different topic: is it possible to have the player start a map with no weapons or ammo except for the axe? If so, how? 

Sometimes it's safer to clip than to rotate, though, because the latter can give you some quite ugly and offgrid results. Rotating a crate should be fine, rotating an entire room less so.

Also, yes. 

Preach is the wizard with those tricks.

Probably something to do with spawning onto a box of shells with negative ammo 

He�s a genius in QC tricks. yep.

And staying on grid should be your 1st goal, advice from former �bernewbie. Better clip. Or rotate 26.66667 degrees?

You get it. 

Clip is better 'R' in Trenchbroom does produce bad results - I have several objects built in my current level which crash the editor if I try to rotate them.

Having said that I rotate loads of stuff. Like OTP says, just do it on props, not entire rooms. Unless you're doing something cool

ALT-ARROW however rotates orthographically and is 100% safe. 

Learning how to build a whole room tilted 45� with everything on a 3:3 ratio and all the textures scaled 0.75 is almost as important a skill as learning how to build a whole room tilted 22� with everything on a 1:2 ratio.

First you learn not to carve, then you learn not to scale, then you learn not to rotate. The enlightened zen of mapping is to never start the map in the first place. 

Wow, thanks for all the fast responses. 

Where's that bug report ;-)