Cannot compile in GTKRadiant 1.5 for Quake. Anyone know how to fix this for GTKRadiant 1.5? 

Try the "search on this page" option while vieuwing all posts of this thread upwards with the word GTKRadiant. 

but helpfull. 

just looking around at the quake sources.......

how the fuck did they get any of that to even compile? o.0 

I know it's easy to point and laugh at the original Quake maps but those guys built some pretty cool levels with technology that was changing on a daily basis. That's tough to do. 

Not to mention the primitive tools. QuakeEd was ... pretty rough. 

i'm not laughing. i'm serious. the original qbsp was incredibly finicky which is what taught me to map with incredible precision making sure everything lined up properly etc etc.
looking at maps like e2m2, it's almost like divine luck or arcane power that would have allowed it to compile without exploding. 

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.