func_movewall collide in exactly the same way as a door does. The player can stand on one, and when it moves they move with it. As usual for a door, once you just off it, you don't take any momentum from it.

The idea behind them is to make an approximation to the rotating object out of small pieces, each of which can move separately. Since the solid collision hull of objects in quake can't be rotated, the idea is that each small piece is moved in a circular path, so that its centre is in the same place relative to the rotating object. If your pieces are suitably shaped, this should approximate the shape of your rotating object both when it is stationary and when it is in motion. The best shape for each one is probably a cuboid, although you could make them cylindrical with more than 4 faces if you liked/needed.

One image you might want to think of is the carriages on a Ferris wheel. While the wheel turns, the carriages stay the same way up the whole way round, but they trace out the path of a circle. The most useful thing you can do is to apply spawnflag 1 to your func_movewalls. This will make them visible, so that while you are building your map/testing out the idea, you can see what they are doing. Then hide them once you have the rotation working.

One nice thing about the way they work currently is it makes it very easy for a person to stay standing on top of something as it rotates(assuming you make the. In real life the player would have a sense of balance that you can't get from just playing with a mouse and keyboard. Making it easy for them to keep their footing is a good decision, which is why I'd recommend keeping the top surface of each movewall flat.

That sounds like a bug that could be fixed in something like Quoth.

It certainly could be made to happen without too much code, but it won't be changed. One reason is that it would annoy everyone who's used to the quake physics as they are. The other is the sense of balance argument again. Momentum not being imparted to a player might be because of the way quake handles motion on platforms(sticking their feet to the floor and updating their position when the physics is run on the platform). But it might also be a conscious decision, because it's much more natural to control the player like that. 

(assuming you make the top of the movewall a flat surface) 

That was really what wasn't clear to me, that you should put the movewalls inside the rotating model.

I made a test map with some visible movewalls and the lightbulb went on in my head when I watched the doors from various angles. Very interesting to see the stairstep effect... incidentally that means I could use the back of a "drawbridge" type door as a ladder, since I was using 16 unit high movewalls that somehow didn't remain perfectly vertical in a perfectly vertical door brush. Gosh. Since my editor only lets me adjust things to a 8 unit precision, this isn't fixable (OK, perhaps in a text editor.) I'd need to use a func_togglewall as a momentary clip brush when the door is up. Or something.

The only thing that doesn't work is a rotating lift, at least it doesn't work "well". This is because the movewalls on which the player is standing go into the stairstep effect when the lift is rising, and this stair is rotating while the player stands on it and the whole thing raises, making it a very rough ride. I decided that rotating lifts are stupid, I just did it to see if I could :-P

The collision will probably be good enough to do all kinds of traps, machinery that isn't touched by the player, levers, cogs, and doors and hatches.

It looks like rotating trains are not very useful. Most kinds of rotating doors seem like overkill,too, when the novelty wears off... machinery seems good though...

I'll upload the map when it's finished.

By the way it seems like rotating things are lit in position, not at 0 0 0 (or was it worldspawn?) because I saw some shadows that exactly matched doorposts etc. Suspicious. I used Tyrutils. 

For the record, so it will be findable in the internet in the future, as it's not mentioned in the readme.
When using q1rad to light maps, add the sky texture in the lights.rad, then make a point entity with name
"light_environment"
with fields _light, pitch, angle
And let every sky you want to emit light see it.

My lights.rad includes this line:
SKY9_1 255 0 0 75

And my map has a point entity:
light_environment with the fields
_light 200 200 200 200
pitch -60 -60

This functionality is NOT DOCUMENTED ANYWHERE. Big thanks to Asaki for helping me out on this, for the second time through.
(He adds that "Pitch and angle are both one number." which makes sense of course) 

Does anyone other than Neg!ke and Efdat use Quest? is it awesomer than WC? 

/*QUAKED light_environment (0 .7 .5) (-8 -8 -8) (8 8 8) START_OFF
Used to create sunlight or outdoor lighing with Q1rad. Must be placed near a sky brush.

Keys:

"_light" sets brightness
"pitch" sets the vertical angle (-90 = straight down)
"angle" sets the horiztonal angle

*/ 

Lights.rad is optional and is only required if you want surface lighting (of course, this might be a very good idea with sky brushes!)

Here's the info from the readme, this part at least is documented:

Now, in order to use surface lights, you must create a file called "lights.rad" You can optionally create a file called "levelname.rad" with "levelname" being the name of your level without the .bsp extension. In that file are the surfacelight descriptions. To edit it, feed it to your favorite text editor. Each line should contain the following format

<texture name (capitalized)> <red> <green> <blue> <intensity>

So if you wanted to make the texture +0slip a strong red with 200 intensity, you'd add:
+0SLIP 255 0 0 200


So that for any lights you want to be surfacelights. 

but the skylight part is not documented in the docs that come with q1rad and the internet is devoid of such documentation as well (until now in this thread finally).

(I use WC and not radiant). 

Yeah, I figured as much but I was posting that info for those that don't have it. It's quite possible to have q1rad.exe without the readme (there's some zipped versions floating around without it).

At least Riot had a link to the VERC page about light_environment, but as you know it's dead now. Pity he didn't put the actual info in the readme. Thank you for posting it for those that don't have the knowledge. 

Since it is very hard to find I uploaded it:
http://www.quaddicted.com/files/q1rad.zip

That's the full zip with readme and example map.

I already forgot who gave it too me in the end but thanks again! 

IK used it too.
I guess Quest is just as quirky and confusing as WC when trying it for the first time. Takes some time getting used to it. I prefer its view modes. You can use the standard three-window view most editors have (albeit not forced to 2D mode exclusively) or one large window and switch between 2D and wireframe or shaded/textured/lighted view. Unlike other editors this one has a stronger focus on the 3D wireframe view - I find the fixed 3-axis 2D view of other editors to be awkward and inflexible, though it's probably a matter of taste.
I grew to really appreciate it's 'click-brush' (brush drawing) feature and the pretty accurate leak detection.
However, one has to learn quite a few key shortcuts to use it proficiently and since it's more or less a DOS program, there might be some compatibility issues. Always ran fine on my XP (apart from rare freezes). Unfortunately my new graphics card doesn't like Quest's palette, so I have to run it on Linux now. :P
http://negke.quaddicted.com/images/quest000.jpg
http://negke.quaddicted.com/images/quest001.jpg 

The map looks cool: is that a Doom-ish map ? 

I also use Quest and have become quite fond of it. It has some little features like selecting 20 func_movewalls and setting spawnflag1 on all of them, and more stuff like that. Also texture locking which is useful, and texture rotating, scaling etc.

The key shortcuts are nice and configurable.

The screenshots from mine are very dark though. I mean _really_ dark.

The downside to Quest is the crappy UI, the fact it is no longer developed and some random crashes, I use the save function really often. 

JPL: no, it's quakish :P

I forgot to mention, even though it doesn't have hardware support, the texture view is pretty precise and in combination with the (admittedly extremely slow) polygon mode, which let's you align multiple textures on different planes by visual offset, allows for very neat texture work.

gb: I never use texture locking though. I hate how it changes every face to some strange values even if you just move the brush slightly. If you have slanted faces or rotations, it totally screws up the aligning. I often pressed it by accident only to find out later on when a good chunk of the map suddenly looked borked. 

I often pressed it by accident only to find out later on when a good chunk of the map suddenly looked borked.

Haha, I know that :-)

I use texture locking for crates etc. when I copy-paste them. It seems to work for me. Anyway, the face mode (texture alignment) is rather comfortable, so doing it manually isn't too bad. But when I have 20 crates it gets tedious.

I was SO glad when I found out how to set spawnflags and targetname for multiple entities at once. ^^ The 3D view is rather comfortable I think, I do most things in that. Like selecting brushes and faces. Even copy and paste.

I haven't found out how the group stuff works, do you ever use that neg!ke? Does it let you hide or copy and paste groups? 

Yes, groups are useful in large maps with complicated brushwork or if there's a considerable amount of DM/SP-only stuff. ALT+G opens the group window. Select some brushes (or entities), press ALT+G and "create group". You can change their colors and hide them. Not sure about copy/paste.

Btw. you can align multiple faces in the same plane with the regular face edit window. It always uses the texture and settings of the last selected face. 

See here: http://quest-ed.sourceforge.net/doc/manual/questdoc.html

If you flag "s", selecting one brush from the particular group will automatically select all its brushes (then c/p). 

Useful stuff. So creating groups works like creating models. 

Cool shots - SP or DM in mind? 

pf_precache_model: overflow

-> segfault...

bspinfo says I have 211 models, is that already too much? Isn't 256 the limit?

I could use some help here, I'm stuck until this is resolved. 

The brush drawing feature sounds pretty cool. Don't think I'll be picking up any new editors though, since I'm too comfortable with wc.

PS - nice shots, as always. 

dude, that balcony looks badass. 

BspInfo only tells you about the brush models (e.g. doors) in the bsp, it doesn't count all the alias models (e.g. monsters) that in the engine will be added from QC.

So already 211 brush models is pretty much and apparently is enough to put you over the limit. With my engines, you can see how many models that are required.

I've just also noticed that the limit is 256 for precached models, but only 255 for sounds due to a bug in the server code. 

Is there a document that explains what are the maximal limit values in quake, like edicts, maxsurfedge, maxmarksurface, entities, etc... ? 

Presumably the 256th model wouldn't ever display in game, as it would have modelindex 0, which is the invisible model...