That'll do nicely. 

in gtk radiant 1.5 for quake 3 engine i tried trigger_counter but it doesn't work aand if i put wait the value -1 it will do exactly what the manaul sais : "wait : number of seconds button stays pressed (default 1, -1 = return immediately)." 

So I'm dabbling with the dark arts and trying to make some rotating stuff, and I've got a nice door opening and closing but it's insanely jittery, as though the axis of rotation is bouncing up and down... Any idea what I've done wrong? :E 

sounds like one of two things:

you did not target an info_rotate with your rotate_object

or

your compiler does not support rotating entities (very unlikely at it would have to be a compiler made before the hipnotic mission pack came out).

so make sure you add in an info_rotate that should be placed somewhere in the center of your rotating brushes.
next, add a 'targetname' to it.
now, for all the rotate_objects applicable, add a 'target' that points to that info_rotate. 

hrrmph. At the moment I have a func_rotate_door targeting a rotate_object. The object is rotating around the rotate_door. I can't find an info_rotate in my entities list :/ 

Duh, I think I've worked it out. The rotate_object has to target back at the rotate door. Duuuh... 

you will need to create an entry for info_rotate if you don't have it.

rotate_objects don't rotate around info_rotates.
info_rotates are used explicitly in the bsp process to define the origin of the rotater, otherwise the rotater's origin is simply '0 0 0'.

try this: make a rotating door right on the '0 0 0' origin of the world and it will work perfectly without an info_rotate.

it has to do with quake's angle accuracy (or lack, thereof). as you know, the farther from the center of a rotation you are, the bigger the gap between one degree to the next.
quake has a pretty low resolution when it comes to angles, so once a bmodel is far away from the origin, rotating it makes it 'snap' to the next angle.
targetting object_rotate to an info_rotate tells qbsp to move the bmodel onto the origin with the info_rotate as the center. 

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.