... 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. 

The func_hordespawn doesn't appear in the fgd because it's been "rebranded". Because it's a point trigger, not a brush, the official name for it now is the info_groupspawn. The func_hordespawn name still works for legacy maps.

And yeah, I broke the awake monster code, so sorry about that again! 

Any chance of a release of the quoth sources?

:D 

i remember arguing over that with kell.

his reasoning was that infos are point entities and func_s are brush models.

my reasoning was that funcs accomplish a function (ie: do something) where infos are merely for positions and such (player starts and teledests and all that).

:P 

I miss him. 

There 's a copy of the quoth.qc on my harddrive.
I'm not sure if it is what you search,
only that I agreed to not share it on third parties.
It's from 2005, when quoth was released. 

madfox is talking about http://qexpo2005.quakedev.com/booths.php?tag=necros which is the Lost Chapters source code. it contains (iirc) the drole (pre-nerf), flying polyp, night gaunt, voreling and the vermis as well as some other sundry code such as spawning.
i would recommend not basing a mod off that source as my coding was extremely shoddy in those days. it still is, in some ways... -_-
it's really rather embarrassing, especially when we've got some professionals running around here. 

I'm sorry but I never asked about Quoth sources... I guess you are not addressing this post to the correct guy (who's name is jt_).. I guess you misread :P

Anyway, thanks a lot for the support to my "incomplete clone" ;) 

That's too bad. 

my specs..,