Change it to
dprint( ftos(self.blargh) );

The key values are added as fields of that entity, which self points to during spawn functions.

You might also fall victim to some of the limitations of early qc compilers here. It used to be the case that you needed to do
local string debug;
debug = ftos(self.blargh);
dprint(debug);
dprint("\n"); //add a newline too
fteqcc and probably frikqcc add these temporary variables in for you, so there's no need to worry about it. 

Actually, it DOES seem to work ... the value isn't there at spawn time but it's there in gameplay because the mod code is acting properly for me. Weird.

Thanks for the answer! I'll keep an eye on it. 

someone replay me plz... i hav a problem... . at the first i open gtkradiant it ask me wat game then i click "Return To Castle Wolfenstein" then it say error,then i close it and reopen the program it ask engine path, wat should i choose?? and how to return to the first setting?? 

someone replay me plz... i hav a problem... . at the first i open gtkradiant it ask me wat game then i click "Return To Castle Wolfenstein" then it say error,then i close it and reopen the program it ask engine path, wat should i choose?? and how to return to the first setting?? 

How do you enable fog in fitz etc? 

Either in the worldspawn, or with the console.

Command line fog <density> <red> <green> <blue>

density/red/green/blue in 0 to 1 range. In order to adjust red/green/blue, use the wanted value bewenn 0-255 and divide it by 256... and experiment ;) 

Func_movewalls.

How do I use them correctly? Atm I don't understand how many I need for a given rotating object, how large and what shape they must be...

I can make a rotating "shell" and even cope with the lighting and texturing issues. The collision is the problem. I experimented with visible func_movewalls, but I couldn't make heads or tails of their behaviour in game.

I had a horizontally rotating platform, that should rotate while the player is standing on it, endangering the player to slide into some lava underneath or at least give the feeling. The platform itself was just a 256x256 flat rotate_object. It had the toggle flag set and was triggered once, to rotate slowly, then retriggered by a trigger_relay with a matching delay, to stop it rotating after it turned about 20 degrees.

I got the rotation working as intended, but the func_movewall behaviour was totally weird. I basically duplicated the platform and turned the double into a func_movewall, which I then placed smack on the top of the brush. When testing, the func_movewall moved up through the sky and out of the map in a very trippy manner. It seemed to move faster than the platform, and continue moving even when the platform stopped rotating. And then it just flew out of the map at some weird angle. :-P

I gave up on the rotating platform plan then... it seemed so weird.

but I'd still appreciate an explanation of func_movewall behaviour, and how they should typically be applied when making rotating doors etc.

I'm a bit lost here. Is it possible that the func_movewall ignored the toggle flag/trigger event?

Is there a way of setting spin-up and spin-down time independently? It would be good if the object could start turning slowly, accelerate and then stop abruptly. I guess this isn't possible?

I'm using Quoth/hipnotic here obviously. 

It's a bit weird indeed. It seems you have to make the clipping volume consist of multiple smaller pieces (each an individual func_movewall entity) depending on the rotating object's shape and axis. Try r_showbboxes (Fitzquake) to get a better idea of how it looks in your map (and other maps) and check the hipdocs thing I linked above. 

Movewalls don't rotate, but they move around the info_rotate in an orbital pattern, so you can't use a brush the same size as your visible rotating model because even though it rotates, it's collision won't. Refer to czg's tutorial embedded in the Quoth1 doc's, it's not very easy to follow (probably because the rotating system is a motherfucker) but you'll get there in the end. 

in The Hand That Feeds You, because:

a - signon buffer was maxed out
b - not really worth it cause the only way you could reach the fan was via a secret anyway, which isnt realistic anyway.

So you can walk straight through all of the rotating entities in TheHand without getting hurt!!

:P 

are fucked anyway in that department. For example jumping up on a horizontally moving platform, you're suddenly horizontally stationary relative to the world, which means you move backwards relative to the platform. And shooting grenades when at speed, you catch your own grens etc...

So I don't know what would happen even if you got the clipping to work, gb. 

neg!ke, thanks, I'll check that out.

Ricky, yup, I have fans in some other map and I came to the same conclusion as you :-) very practical. You could just use a clip brush/trigger_hurt combination in the air duct I guess, if there is a possibility the player might touch the fan. Or just a trigger_push/trigger_void Alien 3 style :-P rather mean.

Ijed:

they move around the info_rotate in an orbital pattern

does this indeed mean a spherical pattern that doesn't follow the shape of the object?

If so, how can the player stand on a func_rotate_train, or can't he?

even though (the model) rotates, it's collision won't.

That's what I feared. That sucks. It means my rotating platform won't work.

However it seems that while the model rotates, its collison moves in some completely trippy way.

Well, I'll try to find some map sources to look at... maybe decompile some hipnotic maps. ^^ gosh I like doing stupid, repetitive things :-P I'll reread czg's doc, but it isn't terribly clear on the collision part.

For example jumping up on a horizontally moving platform, you're suddenly horizontally stationary relative to the world, which means you move backwards relative to the platform

That sounds like a bug that could be fixed in something like Quoth. Not the grenade thing though.

So I don't know what would happen even if you got the clipping to work, gb.

I kinda put my money on the fact that you can stand on a lowering door aka door used as lift... and you can stand on the lowering door in the hipnotic start map, and even let yourself be lifted and squished by it.

Whoever owns it should release the hipnotic map sources ... I think Ritual went belly up though... 

As I remember you can stand on a rotating - there's one used in one of the hipnotic maps, but it's cheated past the broken physics by sticking the player to it - so they don't adopt the momentum of the thing they're stood on.

The reason to have lots of movewalls is that they're inside your rotating model, so as it rotates around the axis the movewalls are orbiting around it at the same pace, making them more or less inside the model constantly. 

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 ?