What is it that the player sometimes seems to block a lift/door/train for no apparent reason (no obstacle in the way)? In most cases the engine only reports an 'unstuck' message, but sometimes it's more severe and the player's health is drained rapidly or he dies if the func's dmg value is high enough. This keeps happening even if all surrounding geometry is clipped off. 

I mean I never tried modeling (knew from the start I was too ugly man), but you have to sculpt each frame individually dont you? Whereas skeletal animation - your just saying where each 'bone' is going. Wouldnt that make creature creation easier and faster? (Not really for Quake purists though) 

Erm, I played a level called The Harb!ngeR of Fish's 'Assault' level collection. Or assault.zip to every other Quaker. It is quite creative with func_trains, and there's a shuttle which you have to climb in. You always get gibbed in that! I died about 10 times, without doing anything! Eventually it crash landed as planned and I survived though.... 

Darkplaces supports it's own file format called dpm, which uses skeletal animation. Models for this format are compiled from smd files, the same ones that are used to create HL1 models. There are ways to create these files from max, gmax, milkshape and probably many other programs.

The reason why it's not widely used is that at the moment there's no way to control individual bones, all you can do with the bone information is read the orientations of the bones. That's useful for, say, attaching weapon models to the players hand, but little else. The plan as I understand it is to get csqc working first, then you will be able to blend animations/rotate bones manually. Of course, that means we could still be years away from it becoming useful.

Even if you aren't using a skeletal format, it's still possible to use bones in the creation process, it's the easiest way to make animations. You just calculate the position of each vertex per frame when it's time to export the model and ignore the bones themselves. Hopefully nobody sculpts each frame by hand in anything complicated. 

When you're talking about a game as old as this it doesn't really matter if it supports bones or not, most modern games only have limited bone support, because as an animation system its excellent but for a programming system to understand it is a ballache.

The only game I remember as using bones well was Undying.

Don't ask me about 'joints' fucking stupid crap.

Any animator with the right mix of sense / laziness / psychosis making a creature for Quake is going to do it in their favourite 3d package then export it frame by frame.

My animation is bad, but I remember suffering over cell animation for weeks in uni; anyone who enjoys putting themselves through that kind of thing isn't going to be bothered by doing a few extra exports, at least one of which needs to be done anyway. 

Where you stick rubber balls with sensors in on specific places on your body, and then carry out movements with a sensor picking up where the balls are moving, and then use that data to create the animation?

Hehe, thats got to be quicker than frame-by-frame animation!!

I wander how many thousands of pounds it costs for that sort of rig? :P

Kinda loose that whole hobbyists charm aspect aswell.... dontyouthink? 

OK, I'm trying to spawn monsters by hand and having a hard time. I can get them into the world at the location/rotation that I want but I can't seem to activate them (aka make them hostile towards the player) without them doing bizarro stuff.

I do something like this:

local entity SS;

SS = self;
self = spawn();

monster_army();

self.origin = origin_i_want;
self.angles = angles_i_want;
self.fixangle = TRUE;

monster_use();

self = SS;

This is not my exact code, but close enough. The problem that I'm having is the "monster_use" function. This makes them hostile towards me, but they don't turn to look at me and I can't hurt them (bullets hit them but don't hurt them). If I don't call "monster_use", everything is fine except that I have to shoot them to get them angry.

Does this ring a bell for anyone or do I need to slog through this over the weekend? 

You've fallen afoul of one of the most common problems with spawning monsters, although in one of the most damaging ways I've ever seen :-).

The key to this problem lies at the bottom of the function monster_army, where it calls
walkmonster_start ();
There is a second function called walkmonster_start_go() in monsters.qc, which fixes all of the problems you are having with your monster, giving them a turning speed and making them damagable for instance. What walkmonster_start () does is sets walkmonster_start_go() as the think function for the monster in question, to be carried out some short time in the future. This delay is put in so that not all the monsters start at the same time, which makes the first frame much less demanding.

Normally when you spawn monsters like this, you end up with monsters that are undamageable for a fraction of a second, before walkmonster_start_go() kicks in and they start up. However, this minor glitch that only really affects nitpickers and telefrags is then compounded by the second thing you do.

monster_use() wakes the monster up, but in doing so it also changes its think function to the first frame of its running behaviour. This of course overwrites the previous think function of walkmonster_start_go(), and so the monster is never properly initialised.

So how do you fix it? It's luckily nice and simple. Add a call to walkmonster_start_go() right after your call to monster_army().
This skips the delay, but that's fine because the world is already spawned so there should be no problems with running both functions back to back. Then the monster_use() (probably) overwrites the call to walkmonster_start_go(). I say probably, because it's possible that the monster won't be woken up, if they have a ring of shadows or notarget on. You might want to call self.th_stand() before the call to monster_use, so that they behave straight away if the player is hidden. They will behave after the walkmonster_start_go() call anyway, but this is a little quicker and avoids going through that twice. 

THANK YOU! :) You've been invaluable, Preach. I'll give this a try tonight.

"You've fallen afoul of one of the most common problems with spawning monsters, although in one of the most damaging ways I've ever seen :-)."

When I go down, I go down hard. Heh. 

Of course, professional game animators use skeletal animation to create their work regardless of whether the game itself supports it. And even qME has some half-assed bone system which you can use to animate before exporting to the skeleton-free mdl format.

But a lot of modern games DO support it, and there are two main benefits --

1. reduced disk space usage. Skeletal animation can be seen as a type of compression since there are many more verts than bones on most models.

2. adding/combining animations. Games with skeletal animation can add multiple animations together, such as a walking animation that only affects the legs, and a shooting/gesturing animation that only affects the upper body.

Fun fact: the Medal of Honor:Allied Assault human skeleton only had individual bones for thumb and index finger, and the last three fingers had to share bones. So the characters could point, make a fist, and hold a gun, but could not spread their fingers apart, count from 1 to 5, or do other useful gestures. 

The wonderful low poly TF2 models found at
http://boards.polycount.net/showflat.php?Cat=0&Number=261922&page=0&fpart=1&vc=1
use a similar idea, this time only modelling the thumb and forefinger separately, while combining the three lower fingers into a single polygon to keep the counts low. This is mainly an excuse to share the joy of these models with the rest of the folks here, they are pretty cool though. 

OK, so let's say I put this into defs.qc:

.float blargh;

Then, in ToeTag, I add a key "blargh=666" to an entity. Then I add a "dprint( ftos(blargh) );" to the spawn function of that entity.

I would think that 666 would find it's way into the blargh variable - right? Instead, Quake prints "0" in the console. What's up with that? 

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.