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. 

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.