Well, I can't find what setting it might be that's making it not like the proximity, but the hinge is on the other side of the area the player stands as it falls so it looks okay and works fine, ta for yer help :)

Will hopefully have some kind of playable prototype soonish. Trying to make something different from the last one...slower and more complex...But designing decent puzzles makes my thinker hurt :E 

5/8 of the time, when a monster teleports in there's no tele effect.

Can this be fixed by editing the entities on the maps? 

If it's not happening then either you've got 00's of teleports happening at the same time or you're running a mod - Quoth has an option for this. 

Doesn't take 00's of teleports. Sometimes two or three at the same time are enough. I might be mistaken, but some engines allow increasing the number of particles, so you could try running the game with -particles 200000 (or some equally high number). 

I'm working on a total overhaul of an old Quake map I made. It was originally a DM map that I added single player to. There are lots of triggers, monster_jumps, teleports etc. that are irrelevant in DeathMatch. Should these be flagged as deathmatch only? Like a trigger that fires a teleport that beams in a monster. The monster isn't there in DM, do I need to flag the trigger and teleport also? 

but some engines allow increasing the number of particles, so you could try running the game with -particles
the stock glquake engine allows this :) 

Because of RMQ :)

Rick - only if you want it to be incredibly clean and fast. Which you probably do for DM, but the saving will be pretty small. 

There are lots of triggers, monster_jumps, teleports etc. that are irrelevant in DeathMatch. Should these be flagged as deathmatch only?

You need to flag these as only in Easy, Normal & Hard, and leave the flag for "Deathmatch Only" as blank. Rather than the other way round. This way those items will only appear in singleplayer, and wont appear in deathmatch.

Tip: You can place func_walls which only appear in either singleplayer, or only in deathmatch. This way you can have slightly different layouts for either game-modes. The map still needs to be sealed without the func_walls, they are only to be used within the sealed map, but you can have them passing through walls in some situaltions.

e2m1 does this, try loading the map, then type "gl_clear 1", then noclip outside of the map and look down on it. If you keep bobbing in and out of the map, you will notice that some of the walls dissappear and then reappear as you keep crossing the edge of the map (solid entities don't appear when you are outside of the map). 

note that the flags are !skill as in, not in easy, not in normal, etc.
so rick was initially correct that he'd need to flag those entities as not in deathmatch.

that said, i have to wonder just how much performance you're going to get out of that especially considering modern machines. 

... Thanks but your zip is 'corrupt' and is 0 Kb :) 

I'll probably leave most of them alone, I was only concerned because I was getting a move_type push error in DM and I thought it was possibly caused by some trigger that didn't need to be there, I later found a zero brush trigger (due to a quirk/bug in gtkRadiant) that seems to have been the actual problem.

I've been using Radiant for a couple of weeks now, and I really like it. I was doing a compile on my mapping machine this morning and I fired up Worldcraft on another computer and was kind of annoyed because I couldn't remember how to do anything at first. Also, it seemed to run a little sluggish compared to Radiant, and its on a 3GHz Core2Duo while Radiant is on an old Athlon XP 2200. 

Sounds more like a func_ without a brush. To be safe, load the map in Bengt Jardrup's enhanced Glquake in developer mode - if there are rogue entities, it will show a console warning. 

Sometime ago I found some weirdness in Quake. I could push entities, such as ammo and medkits, through solid walls using doors. Well, now I've found another. I'm trying to lower monsters on a door through a trigger_teleport. It works fine for the smaller ones (knight, hellknight, scrag), but the bigger ones (ogre, fiend, vore) don't work. When they hit the trigger they immediately flip from 0 to 270 degrees, the teleport particle effect fires, then the monster dies. It plays the damage sounds like they're getting crushed. Weird.
I'm using Fitzquake 0.85, but it also happens in GLQuake (the one modified by Bengt Jardrup)
I guess I'll try pushing them through sideways. 

sorry, I update it.

^v^ 

that's odd, but why not just delay trigger the teleporter instead of lowering it through a normal teleporter? would avoid having to use a door entirely. 

The idea was to have monsters flying out of a teleporter one after another, multiple monsters using the same teleport destination.
I tried pushing them through (well, sliding through on top of a sideways moving door) but I got the same result (again, only with the larger monsters). Interesting discovery was that scrags wouldn't ride the slide walk and the next monster in line wouldn't push the scrag. When the door eventually moved out from under that monster, it fell to the floor. That monster happened to be an Ogre and by pure luck I happened to have a copy of the trigger_teleport down on the floor, and lo and behold Mr. Ogre ported. So that was the solution to the problem.
With the teleporter on the floor, I just lined the monsters up on top of the door in the order I wanted them to port in and everything works. The monsters begin bunching up against the wall as the door slides out of their holding room and as the door moves out from under them they begin dropping into the teleporter, one by one.
You can control the rate they port in by changing the speed of the door. They will however telefrag each other, the assumption is they will be immediately moving after the player and get out of the way of the next monster. I put a trigger_monsterjump at the teleport destination, just to help them along :)
The only problem would be with scrags, since they won't fall. If I decide to keep them I think I could just add a little pusher bar to the door and arrange them their own trigger_teleport.
Pretty nifty little construction I think. 

One of the reasons I'm really enjoying using Quoth is that it is very easy to recreate Doom style monster zergs. Because it can easily spawn monsters active in a far off box, they will automatically run toward the player. Put a teleporter on the wall facing where the player would be, and doors or forcefields between the ranks of monsters that block their progress. If you make the teleporter the height of the wall, flying enemies should also go through.

Quoth also allows you to flag teleporters as preventing telefragging, so they might bounce around on the teleporter trigger for a while but they won't just gib each other :) 

Thats a great entity for "teleporting" a bunch of enemies into your map :) 

I think the (now pretty dodgy looking) fgd I have doesn't include the hordespawn. It has a 'groupspawn' I think, but I tried it and didn't do anything.

Not particularly fussed though really. And seeing the ranks of enemies lined up is kind of fun :) 

for Quoth 2.1? I found preach's one here:

http://www.btinternet.com/~chapterhonour/quoth2.fgd

But it doesn't contain func_hordespawn. 

why do you need a func_hordespawn???

just leave it alone...... 

Thanks. Yes, that's a way to do it. Perhaps I misunderstood the BSP tutorial, but I thought the idea was to use the sky texture on the brush that is supposed to cast the shadow.

But this is a cool effect nevertheless. I'll keep it in mind. 

is less useful in quoth2 as preach broke the code that makes monsters wake up (the trigger_awake spawnflag is equally broken).
so when you use them, the first monster spawns but subsequent ones won't until the first monster is awakened by sight.

this is why the hknights that spawn in the end battle of ne_tower spawn on a little pad outside.
they originally were supposed to spawn inside the tower that the walkway connects to and run out chasing after the player. the idea would be that you'd never see where they came from, as if they were just charging out of the tower instead of teleporting in. 

i don't blame preach for either accidentally or intentionally breaking the monster wakeup code as the implementation in quoth was very very bad. 

in e1m5, i think there's a "Q" made out of solid brushes, inside a sky brush. The sky doesn't block light, but it does prevent you from seeing the Q shape in the air.