doh, cross-posted.

i guess that can work too. you're just replacing info_rotate with the func_rotate_door. the only hard coded thing in qbsp is object_rotate -> target. i don't think it cares what entity you target. 

Well...it seems to work okay anyhow :E

Another question however, train rotates. I've got it set up so an object moves between two points like a normal train, but -1 stops don't seem to work and it never rotates, it just moves. Any ideas...?

If you want an idea for what I'm trying to do, I want to make a draw bridge that drops down in stages (ie has multiple triggers, each one moving it x degrees down), rather than just going from 90 degrees to flat in one motion. ta for help btw this stuff is pretty confusing :p 

have you ticked the 'ANGLES' spawnflag on the path_rotates?

there is a 'bug' where a rotating train will not rotate if the next position is at the exact same spot.

if you have multiple path_rotates on the exact same spot, you will need to move the next one at least 1 unit away.
it's ok if it zig zags back and forth between only two spots, as long as two consecutive paths are not overlapping.

this is because if the origin doesn't change, the QC code just skips over the movement and considers it 'at the next spot' without bothering to check if it should rotate or not. 

first paragraph is a separate issue from the last 3 paragraphs. sorry for confusion. 

I was just about to post that it seemed to be that they were on top of each other... irritating limitation :( If I have them a single unit apart it fires the move but then instantly flicks back to the previous node. Seems to require a minimum of eight units between each.

Guess I'll have to just try and model it so it doesn't looks weird... 

Seems to require a minimum of eight units between each.
no, something else is causing that.
a single unit is enough to fix the bug i mentioned. you might have some settings wrong on the path_rotates. 

#10219 Quad Shadow

I have no tutorial for the Squad Shadow, but here is amap that shows the effect.

http://members.home.nl/gimli/Qshadow.jpg
http://members.home.nl/gimli/Qshadow.zip 

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 :)