There are several limits that can cause you problems. In normal engines you can have 256 static ents (unusual to exceed this limit) and 600 "edicts" (which I believe is similar to ents).

In my engines you'll get warnings when exceeding these limits. You can always check current edict amount with the edictcount command (first number). Always check while playing on Hard and in god/quad/RL mode.

Regardless of these limits, you can have various engine overflow issues (e.g. packet overflows or invisible ents) before or after vis. 

Can anyone tell me how to calculate the position of the info_teleport_destination

You seem to misunderstand: info_teleport_destinations ( or any info_ entity ) are point entities, not brush entities. That means you should place them in a map exactly as you would the info_player_start or a monster_ of some sort i.e. like sticking a pin in a cork map board.
Keep its origin at least 64 units from any walls and 32 units above the floor.

Because of this, any two or more monsters teleported to the same info_teleport_destination simultaneously will immediately telefrag each other. Count the gibs! :D
This has occassionalyl been used intentionally for effect, as at the end of one of the Prodigy SE maps where a bunch of zombies were telefragged to rains gibbage over the player.

However, as a means to limit the entity count in your map, it will not work.
What you would need to do to have several monsters appearing at the same destination is to stagger their teleporting by a few seconds each. Or, more simply, use more than 1 info_teleport_destination near ( but not too near ) each other. 

Thanks, you have answered the main point of my question in that one cannot teleport two monsters from the same trigger_teleport box.

The other question still remains and I'll try to explain in more (but still not technically correct) detail. I am not interested in the programming side of things, only relating the editor to the game.

The info_teleport_destination entity is a fixed size when displayed in the editor, regardless of how big the brush is from which the entity is created. The trigger_teleport box can be as big as you like and generally is made to be slightly larger than the monster to be tranported. The monsters each have their fixed-size box when displayed in the editor.

So, when the monster teleports into the game, from the editor's point of view, does the centre of the monster line up with the centre of the info_teleport_destination ? You clearly know that the origin needs to be 64 units from the wall and 32 above the floor - but why? I don't recall ever placing the info_teleport_destination above the 'floor' level except where I wanted monsters falling from above the player, and through simple experiment, I know that the ogre still teleports OK even when the i_t_d is up to 8 units BELOW floor level.

I am trying to find out how the monsters bounding box relates the position of the i_t_d in the editor. The i_t_d is 40 units tall and if you place it on the floor in the editor, the monsters still drops maybe 8 units(?) when it teleports in. Therefore the monsters head must also be higher.

Ordinarilly, this is not an issue as space is available in the game's environment. However, where space is an issue, it's important.

I relise that I could have worked all this out in the time it has taken to type this post: I only asked in the first place because I'm not into re-inventing the wheel and I thought someone would know the answer off the top of the head.

And I would still like a judgement on the likely number of monsters I might achieve and whether monsters back packs affect things. Non-teknikal now :-) 

The info_teleport_destination entity is a fixed size when displayed in the editor, regardless of how big the brush is from which the entity is created.

This is the confusion; there isn't a brush for an info_teleport_destination, only a colored box that gives an estimate of the size of the player. Only func_ and trigger_ entities have brushes.
Unless your editor is somehow unable to represent point entities as anything other than brushes or you are using a custom version of the info_teleport_destination.

What you should be seeing is a solid-color box about the size of the player.

Here is a screenshot of GtkRadiant:

http://kell.spawnpoint.org/screenshots/info_teleport_destination.jpg

In the 3D view, the i_t_d is selected and highlighted. Next to it is an info_player_start which is exactly the same size and shape. It is likewise a point entity.

The center point of the i_t_d rests on the grid crosshair in the center of the red selection outline as seen in the 2D views - this is the point where I placed the entity, and this is where the game will position a monster when it teleports. 

Different editors, different phraseology, same thing.

In the 3D view I can see a model of the player, not just a bounding box (and my editor is 6 years old!). I can only see a wire-frame version of the i_t_d. In the top, right and front views, the player is 32 units square and 48 units tall. The i_t_d is 16 units square and 40 units tall.

In your screen shot, the centre of the i_t_d appears to be on grid x128, y0. My question was, will the teleporting monster land also centred on x128, y0?

The bit about 'the brush from which the entity is created' is just that as you click and drag the mouse in the (say) top view, you create a brush and it appears in the 3D view as you draw. You fix that brush by pressing Return to de-select it. But if before you press Return you select the Entity list (press E) you can turn that brush into an entity, which will immediately resize to its default if it has one or remain at the drawn size if the entity size is variable. Hence, 'the brush from which the entity is created' - just phraseology.

So anyway, what about the likely monster count? 

If I want to turn an existing brush into an entity, let's say because it happens to be the right size for a door and I want to add a door where the brush is, left-shift and left-click to select it, E for the entity list, select func-door, press return and the brush becomes a door.

I thought all editors worked like that? 

Ah ok, it was a matter of terminology. That's cool, as long as it's clear now :)

My question was, will the teleporting monster land also centred on x128, y0?

Yes, the origin of the monster will be placed exactly on the origin of the i_t_d. Which is why I stated those values - 32 above the floor and 64 from any walls. The ceiling should be a good bit more above, just for aesthetics ;)

Regarding monster counts: it does depend on which engines you want your map to be playable in, since they have different limits for total entities on mapload and also for what could be handled on screen in any given combat.

I don't really know these sorts of values exactly, that would be for an engine coder to answer accurately. But as a rough guide, my Contract Revoked maps had up to 101 monsters plus lots of walltorches and ran in GLQuake without choking.
I think PuLSaR's more recent Menkalinan had a few more beasties than that and ran perfectly well in FitzQuake.
Kinn's latest map, otoh, contains a veritable army and so far doesn't run so well in FitzQuake, though it does load.

I'd say generally, when you reach 100 monsters in a single map, you should already know where the end is. 

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.