I thought all editors worked like that?

Nope. All the Quake editors I've tried have separate methods for placing point and brush entities. Points are simply selected from a list and placed on a grid intersection, or placed on a grid intersection and selected from a list; hence the 'pin in a map' analogy. No brushes are involved. 

you can have 256 static ents (unusual to exceed this limit)

I wish it was so unusual for me... 

... I have now played around with this transporting lark a bit more. And using the Ogre as an example:-

1. the trigger_teleport does not need to surround the monster entity in its out-of-the-way room. It works when any part of the trigger is overlapping any part of the monster's bounding box. I don't know if that is of any use?

2. the ogre spawns 10 units above the lowest point of the i_t_d, so the i_t_d can be placed on the floor of the map

3. the ogre's bounding box is 64 units square and it needs just one unit either side to manouvre after spawning, but nothing behind. The i_t_d can be placed with its centre 32 units from the rearmost obstruction.

4. the ogre's bounding box is 88 units high and he needs 99 units above the lowest point of the i-t_d (which is 88 units for the ogre, 10 units for the fall in item 2 above, and 1 unit clearance.

The above is when considering the centre of both the Ogre's bounding box and the i_t_d to be the same in the top view, and when the lowest part of both the Ogre's bounding box and the i_t_d are on the same grid reference in the front or side view.

An' I thank you. 

My current project (a Q1SP map) has 463 entities of which 371 are lights and I haven't even started placing down monsters yet... 

488 of which 370 are lights, and I am just about to start placing monsters. I'll let you know how I get on. 

I think most modern light compilers remove static light ents from the map after generating the lightmap, but I could be wrong. 

Are my emails arriving ok? I've sent quite a few recently :) 

Yes, I've received them. I'll get back to you. 

Not really a burning issue, but something that has always intrigued me: in the QC, what does the "th_" prefix stand for on the monster ai functions? (like .th_walk, .th_die etc.) 

I get an error message in QBSP that goes something like this:

WARNING: Brush with duplicate plane on line XXX

What does it mean??
I get like 50 of them all on diffrent lines.
Will it cause trouble? 

Those are function pointers to their respective ai functions (th_walk is walking, etc). Its like 'when i am told to die i go to the function that is enforcer_die()' (or whatever). Sort of like a finite state machine. 

Lol, yes but what I meant was: What is the historical significance of the "th_" prefix? Or more specifically, what is "th" short for? 

 

what kell said. 

Yes, that makes sense. 

During polishing my entry to SM40, I moved a couple of brushes and now have a leak through a solid brush.

I have used the -nosortface option and no longer get a leak reported. Clip-nodes are not an issue as I had already made good use of clip-brushes. I have fast vised and it looks OK in-game.

What does -nosortface do and why should I not use it all the time? (You probably know why I am getting the leaks - you've seen the map before allbeit that it didn't have the SM40 bits in it)

Ah, I see from the time that you are probably building up the alcohol levels at present so hopefully I will hear from you sometime next year! 

Take a look at my Q1 ToolTips document at http://user.tninet.se/~xir870k (link bottom right). It contains among other things
explanations on some of the warning/error messages from the tools. 

-nosortface just disables the automatic brush face sorting before build. This is done to make builds more consistent, since some editors (e.g. QuArK) shuffles the faces around between builds.

Theoretically, the face order shouldn't make any difference, but it does (as you've already noticed). Apart from the consistency, the chosen order is also an attempt to improve build quality by putting faces on opposite brush sides next to each other. Don't ask me why this helps ...

Normally, I definitely recommend to keep the automatic sorting to avoid e.g. leaks popping in and out between different saved map versions. If you choose to disable the sorting, there's also another face order you can try (if the current doesn't help). Just use my ConvMap utility to reverse all faces in all brushes, e.g. convmap -r -i sm40. See the readme for more details. 

OK, thanks. 

Nice txt file by the way... q1 is lucky to have you. 

Q1 is even luckier to have mappers still creating new material. 

Hang on, what's the implication here? If the light entities are removed from the map (.bsp file), does this mean I can put more monsters in?

Where, or when, is the entity limit significant? Do the compilers baulk at large numbers of entites or is it just the engine? I have 597 fixed or modifiable entities in my version of SM40, of which 392 are lights. I would happily put more monsters in as I get the distinct impression that players like lots of opposition when playing.

I am just about to do a final, full overnight vis, so any answers today will be appreciated. 

... Light before Vis or Vis before Light? 

Really duzzn't mattah! 

All light entities are stripped out when the level loads, with two exceptions:

1) Switchable lights, because these need to hang around so that they can be "triggered".

2) Lights with models (torches etc.) However, these get turned into static entities, and therefore do not contribute to the edict count.

Bear in mind that there is nothing significant about light entities that distinguishes them from other entities. By this I mean (although there's not much point) you can give any entity a "light" field, and the light compiler will light the surrounding area accordingly. This is why most light entities are stripped out on level load; they just act as placeholders for light information, and do nothing else.

In conclusion, you could have thousands of light entities in your map, and it would cause no overhead if they all get stripped out at startup.