I have no support (nor any plans) for coloured lighting in my light tool. TyrLite is probably your best bet here. The only other coloured light tool I know is TomLite, but I think it's based on an earlier version of TyrLite. 

Is it possible to have a lift/door go down on one button and then up again on another, then on and on and on? 

How would I go about doing the following:

Player steps into a trigger_once, thus triggering a bunch of lights to turn on and playing a "lights turned on" sound. Wait 1 sec. Another bunch of lights gets turned on with a "lights turned on" sound. Wait 2 seconds, another even is triggered.

Some parts I do understand how to do. However, I don't know how to make the delays in triggering the lights and how to make an appropriate sound play once it's triggered. 

...if it's just one level down and one level up then use door for the lift and check the 'toggle' flag. 

...trigger_relay is your friend in this instance. You can give them all the same name but have them target different light groups with an increasing 'wait' time for each one.

But be very careful, as Quake will very quickly crash if you try to overlay too many light sources on a face. 

Woo, made the mod, and a short test map to demonstrate it. All in the following zip
http://www.btinternet.com/~chapterhonour/tele2.zip 

Wonderful! This worked perfectly. Now how would I go about having a sound that would play only once when it's triggered by something? Do I need custom QuakeC for that? 

That is perfect just what I was after, thanks 

Seem to have encountered a problem, I put the bsp in the mod folder and use monster_shalrath_tele in the map and for some reason it doesn't spawn the other monsters. I have it so that once you kill the monsters the shalrath_tele gets spawned in.

I am using -game from, run, and yourmap worked fine. 

sound that would play only once when it's triggered by something

mail me your zipped QC source and I'll hook you up ;) 

sent you an email 

Did you name the other monsters as normal? I didn't change anything besides the code for the shambler and vore. Don't call the other monsters monster_ogre_tele or something, give them all their usual names. Other than that I can't say what's causing it, try some of the ID maps and see if the monsters work in those... 

I have 480 entities in my map according to TreeQbsp, of which 360 are lights. How many monster can I expect to place (there are none at present) before I hit problems?

How does a dead monster's back pack affect this count?

Can anyone tell me how to calculate the position of the info_teleport_destination to allow me to teleport more than one monster at a time (I haven't tried it but am thinking two monsters, not touching, in one trigger_teleport box) i.e. in top view, does the info_teleport_destination brush line up to the centre of the trigger_teleport or maybe the left hand corner etc?

I am going to need to teleport monsters in and I thought that I could save on entities somehow - I can't use the progs.dat that I used previously as that is banned in SM40 comp rules. 

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.