Kim if youre using:

http://ericwa.github.io/tyrutils-ericw/

...turn that wall into a "func_group" and add "_phong" as a key with a value of 1.

This will smooth out the lightmaps on that specific wall. 

http://simonoc.com/pages/articles/rockwall1_1.htm

Looks like a good start, I'd try to stick with quads rather than triangles and maybe make the scale a bit bigger 

Hey everyone, I'm doing some BSP2 mapping for hexen 2 and I ran into a little snag that's driving me crazy.

I have a fairly decent sized level, and the amount of detail requires I use bsp2, but I'm getting "reached occupant at <coords>" whenever I try to add this new area

http://i.imgur.com/FPsiXoR.jpg

There's nothing different about it construction wise, it's not off grid, it's connected to this main area here:

http://i.imgur.com/rd3OGON.jpg

The cliff wall on the left, I cut the brush in two and started making a hallway.

Now it throws reached occupant and points to an entity on the other side of the level, and loading the pointfile it does not draw a line to any hole.

At first i thought i was just missing the hole, but if i move the new room away from there and section it off and put the wall back together, it compiles fine!

I tried making a smaller cave-type entrance in the same spot with there being more wall, and that compiles fine too!

It's literally if i just connect the path using the same sky, and I'm really confused as to why this is happening 

 

...by making this cliff face on the other side of the map a func_wall

http://i.imgur.com/a2UU7WL.jpg

???

Could it be the way the brush was constructed and the verts were positioned were causing qbsp to shit itself? Early today I got a couple QBSP crashes too randomly until i restored a backup 

QBSP shitting itself would not be a big surprise. I've had brushes that should be fine cause issues before, although that's often because I got too ambitious with stretching them out to thin points and other bad ideas... 

TB's Vertex editing makes it easy to create invalid brushes. Might be a very short edge or just too many faces. Make sure to check the issue list, too. 

What's a better way to construct an irregular outdoor area? Starting as a box room and adding in rock brushes and func_details over it to produce the illusion of a round area? Or cutting up your brushes that are touching the void and modifying their shape directly?

Or is it down to preference? I've been doing it both ways but I'm not sure which is better 

Func_detail shouldnt touch void. Throw a brush behind any that do. 

My Method is to start by grouping each brush to keep things workable and then cut them in half longways (http://i.imgur.com/iqJiGyt.png), make one side into a func_detail and then cut like so: http://i.imgur.com/CyZOHmx.png

and then etc. etc. for your detailing. I make sure my floor/ceiling brushes extend out to meet the outer walls.

It takes a bit of practice to make stuff look good but effects like phong with the lighting go a long way to a good looking finished product. 

Trying to compile a test map in Jackhammer, getting the following error:

************ ERROR ************
Error opening C:\Quake\Id1\cb_deco.wad;C:\Quake\Id1\cb_obj.wad: Invalid argument

Bullshit, invalid -- the files are in the directory. There was something you had to do to link the .wads to a map back in the Radiant days, wondering if it's needed still? 

Try "wad" "\quake\id1\cb_deco.wad;..." maybe. 

Well, that information's already in the mapfile:

{
"classname" "worldspawn"
"sounds" "1"
"worldtype" "0"
"mapversion" "220"
"wad" "C:\Quake\Id1\cb_deco.wad;C:\Quake\Id1\cb_obj.wad"
"_generator" "J.A.C.K. 1.1.1064 (vpQuake)"
{ 

Reinstalling TyrUtils (which I thought I was using anyways) apparently solved the problem. Sigh. 

Getting an issue with qbsp:
************ ERROR ************
Degenerate edge at (0.000 0.000 0.000)

However even after seeing nothing suspicious - and moving everything in the area to be sure - it persisted. Some searching revealed it's apparently an issue with the editor accidentally creating a brush with a size of 0 in all dimensions, and that most editors should have built in tools to remove it. How do I go about doing this in Trenchbroom? 

Huh, nevermind, the issue is gone after I removed my rock wall to have a crack at making one following the guide ericw posted. 

Huh, nevermind, the issue is gone after I removed my rock wall to have a crack at making one following the guide ericw posted. 

In Quake 1, is it possible to have a func_train damage and kill players when it touches them, without having to push them into a wall for the damage to actually be applied? It seems like it will only kill the player when they've been pushed into another surface. 

I'm not really able to test it, but it could be as simple as adding
"touch" "train_blocked"
as a key to the train. 

There's a hack that *kind of* does that, but it's not entirely reliable.
If you add "touch" "hurt_touch" and a sufficiently high "dmg" value to the func_train, it'll kill the player when he actively touches it. Actively means the player needs to move towards the train in order for the damage to be applied; just standing still will make the train push the player as usual.
Preach probably knows a way to do it more reliably. Depends on what the whole thing is for really, and if there isn't another approach. 

@czg

Thanks! That did exactly what I wanted it to do. I didn't know I could just add that keyvalue to the entity. 

I made these out of brushes + _phong for a swamp and I was quite happy with the result

http://www.youtube.com/watch?v=ksL2sIViaFs

They are quite detailed and I made sure to fix any non-integer verts that popped up, but how feasible is this for BSP2? Would I be able to fill up a decent sized level with these? 

At this point you may prefer a .map to .mdl converter. 

I had made a large group of trees as one func breakable with negative health so they would be like a group of trees with accurate collision. Is having them as ents that way still a problem?

I could convert them to mdl no problem and use skip for collision, it just helped me save on temp ent limit problems that would be caused by too many tree entities in one visleaf