But when you look at it you can see that they're at the minimum level of compilability.

Which means each of those maps must have undergone loads of iterations to reach that level, probably starting with something resembling Escher vomit.

Like Willem says, after ten years of trial and error with bsp it's impossible to make a comparison. 

I constructed a terrain map with triangles.
After fitting all polyhedrons well tight the light seem to cast all kind of rare shadows.

Is there a way to avoid this odd behaviour? 

depends.

if you're using aguirRe's light
i found -soft will make these shadows a lot. even if the faces are perfectly connected. obviously, not using -soft is a solution, but not a good one. if this is a preview compile, and you have -soft and -fast, usually not doing -fast will reduce it.

it's always there though, afaik. smooth transitions of angles like terrain don't seem to go over well with any of the quake tools. :P 

one thing, you can try using _anglesense 0.1 on lights hitting the terrain (and _anglesense on your worldspawn for sunlight). setting angle sensitivity way down like that will make light not attenuate much on different angles. this makes it look very shitty and weird (faces not really facing the light will still be bright as if they are directly facing it) though, so it may not be a viable solution (i haven't tried it) 

I made a polyhedron from a cube and cut of a pyramide on top.
After some punctual accurasy it can be used for terrain maps.
Point is that after placing it on grid and changing the topangles also replaces the cube foot after forcing it to grid.
So if I don't force to grid the lightning looks well.
After forcing it to grid the slopes cause black shadows.

I will try your light options. 

anglesense either, but according to AguirRe it will give a softer, more diffuse lighting effect.

shadows on triangle geometry are always a problem - AFAIK they cannot be solved 100% - but I've never had the problem. So far. 

My map compiles with no issues, but when i goto open it with my client i get an error of "too many static entities" any ideas of what this means? 

Not to state the obvious, but you've gone over the static entity limit for Quake. You'll either have to reduce the number of static entities in the map or play it on an engine that has a higher limit... 

whats the limit then? I'm running ezQuake as a client... I've looked around and most sources said its a limit of 128 is that true? then i noticed a post by rick earlier and by reading his post it said that he has 625 light in his map... how is this possible i think mine is 172 if im not mistaken... 

yes, 128 static entities is the limit.

not all light are static entities. essentially, only an entity with a model can be made static, so this only includes flames and torches. normal lights with no entities are not counted.
try to replace your torches with normal lights and use light textures instead if you can. 

damn.... kinda defeats the mood of the map im creating.. looks awesome with all the torches... thank you for the help... 

one more thing... is the 128 limit going to effect my backpack and flags too? because they have a model attached to the entity... 

you could look into other custom engines, i suppose, although curiously, a fair few custom engines which do have bumped up limits still have the old 128 static entity limit.

both fitzquake and aguirRe's glquake allow many more static entities, but as you're using ezquake, you may not be satisfied with those engines because they stick pretty closely to the original glquake. 

cross posted, re: 9096

there's 2 types of entities in quake.

static and dynamic. dynamic is most types of entities like monsters, items, doors, triggers, etc. these are also called edicts, and you can have a maximum of 600 edicts in a map.

the only reason torches are made static is because they never move, and never interact with the environment in any way. 

Correct me if I'm wrong.

1. You can't trigger a trigger_monsterjump.

2. A trigger_once can't have a killtarget or it won't trigger it's actual target?

3. Clip brushes can be part of a func_door and will push monsters.

4. The model limit is 256. 

1. nope (trigger_monsterjump has no use function)

2. nope
killtargets are processed first, before targets are.

3. i know it definitely pushes the player, so probably monsters

4. yep 

Well, I though clip brushes didn't affect monsters since they won't cross gaps filled with them. Maybe that's a game logic thing though. 

that happens for a different reason. ai decides how it moves based on the visual hull (hull 0) while collision is based on the respective hulls (1 and 2). a monster could walk over a clipped service and wouldn't fall, but the ai decides not to. 

For a clip brush to be part of a door it seems like the clip brush has to be surrounded by regular brushes, or maybe the door model has to be bounded by real brushes. Something like that. I had a door with two regular brushes at the ends of a long clip brush (looking from above) which pushed some scrags upward and it worked. I removed one of the real brushes and then it didn't work. 

but i believe that the clip brush must be within the mins/maxs bounding box of whatever bmodel. 

Clip must be 'inside' the normal brush model or they won't collide.

BBOX explanation - the space is defined on the grid with three negative and three positive numbers. so -1 -1 -1, 1 1 1 gives you a 2sq cube.

All objects work like that, including triggers. So don't expect a L-shaped or diagonal trigger to have an Lshaped or diagonal area of effect.

The only trigger that can be triggered in standard quake (I think) is trigger_teleport - useful for the classic black box monster spawning or auto-porting the player when a condition is met (eg. kill an enemy). 

I made an elevator in the corner of my map to bring you to the top of this little bunker, but it seems to always start moving upwards just before you get on... Is there a way to decrease the 'sensitivity' of it so i can get on first? 

func_plat activation trigger is based on mins/maxs of the bmodel in question. the only alternative is to use a func_door + trigger_multiple combo instead which would allow you to set a custom trigger size (or change the func_plat). 

This has been covered before I'm sure, probably in this very thread, BUT...

I've downloaded GTKRadiant 1.5 for my Windows BootCamp partition and it's running fine ... except I don't understand where to put my WAD files so it can see them. Any hints? Their documentation is equal parts missing and abysmal. 

OK, after reading way back in this thread I see I need to put WADs into Quake/ID1 but that seemed to be crashing GTKRadiant this morning when I tried that on a whim. I guess I'll try it again tonight. Weird.