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

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.

This is beautiful, but it's missing the lesson about texture lock. 

Writing it on my hand now. 

Know that you can overlap brushes. And know that it doesn't matter if the intersection points are off-grid (99% of the time).

You can waste a lot of time cutting things so that they don't overlap, but there's really no need. And it's good practice to keep brush vertices on-grid, but the points where they intersect, they don't need to be on-grid.

But yeah - NEVER use the Worldcraft 'carve' tool, no! 

Like how you'll eventually wind up with textures offset by 1 after dragging them all over the place? I thought that was a Radiant/QE3 specific bug. 

Radiant can do some weird stuff when texturelock is on, and can do weird stuff with entity angle keys. Getting scientific notation for something rotated 90 degrees is o_O

Otherwise, texturelock is perfectly fine, especially when copying things around. What you DON'T want is to make a brush, then turn on texturelock, and rotate the brush to get a rotated texture. Make the brush with a known slope, and you can just use arctan to figure out the rotation. I have planks in my jam map that are at a 1/8 slope, so that's a 0.125 slope, arctan(0.125) = 7.125 degrees. 

Thanks, RickyT23. I was actually wondering about that too.

I recently looked at the sources of apdm3 and bbelief2008 and brushes sometimes overlap in both those maps ... so I started to suspect that I was wasting my time cutting things and making sure they line up perfectly. 

Make the brush with a known slope, and you can just use arctan to figure out the rotation. I have planks in my jam map that are at a 1/8 slope, so that's a 0.125 slope, arctan(0.125) = 7.125 degrees.

This would have been very useful in the past two weeks.