spiral, yeah. monsters have even more trouble navigating down stairs that are at an angle. even if all the steps are 45 degrees.

remember that bboxes don't rotate, so when the square bbox hits, say, a 45 degree angle, his leading corner will be even further out than usual (owing that it's a diagonal relative to the 45 degree step). you need to make your steps even bigger in that case.

note that if your steps are in an L shape, they can have trouble on the corners of the steps as well.

willem: now that we know that the map has spiral stairs, it's probably more owing to the non-right angled stairs, but you can see this for yourself by building a stair that is 16 units high and 16 units long. small bbox monsters should still be able to use it, but large bbox monsters will treat it like a ledge. 

http://img202.imageshack.us/img202/287/fitz0017.jpg
http://img94.imageshack.us/img94/3716/fitz0018.jpg

"He was twizzlin' away, 'till the closing of day, and singing a smoke-twizzlin' song. There was an aeroplane circlin' but he didn't notice at first, 'cause it was so cunningly disguised as a dragon." 

trigger_monsterjump (or whatever it's called)

SOLVED! 

Make a pillar so the steps closest to the internal bit of the U aren't so short - the outer width of the steps looks fine for even fatboy to walk down them.

Alternative2:
http://www.mobility-superstore.com/stairlifts/

Might be tricky setting up the func_trains though. 

That's just what I need, never mind the Ogres! 

A large bounding box? 

...oh yes, my box bounds large.

I got round the 'problem' with my ogre by setting the path_corners right next to the right hand side of the stairs where the tread is widest. He goes up and down with a slight twizzle on one step. The downside is that he does not appear to walk on the stairs, he looks as though he is floating above them.

But at least in gives that degree of randomness associated with wandering monsters.

Onwards and upwards, as they say... 

Anyway - I didn't think of the path_corners - you can already tell him where he supposed to be.

Looking forward to it, always liked shallots. 

How come the Ogre stops, when there's a 16 or 32 gap on its pathway?
I tried the OldOgre , but he always stops as soon here's a 16 unit gap.
I even tried a clipbrush of 8 units.
To make the screenshot I had to force the Ogre on the midle of the path.

http://members.home.nl/gimli/OldOgre.jpg 

monsters use the visible geometry (hull 0) to do pathfinding checks. So even if the collision hull (hull 1 or 2, depending on the monster) is flat and continuous, the monster will stop if there is a visual gap. (visual gaps that are 16 or less units deep are okay because they are treated as a step down.)

So, clip brushes won't help because they are not included in hull 0.

Func_wall with a skip texture might work, through. 

I wondered why I couldn't let him walk the hallway, while in the old screenshots it does. 

like a viking ogre or something :) 

hehe weardo :) but look sweet!

Ogres and Vores are my favorit monsters of Quake!!!

Awesome to dance with! 

 

I made him a new shield.
Now my God help me with the shielding code!

Something else... I'm so far I have made a level finished. Now I'm troubled with the wrong outcome of monster-count.
I have 168 monsters, the end count is 150.
I deleted the swimmonster_start ,which is double coded in the rotten_fish code.

Where can I trace this error? 

We have at least two coders on the team, you know? Why not ask them?

Just thinkin'. 

if you have 18 fish, perhaps they are not counted. Maybe your fix for swimmonster_start is incorrect. 

@gb - you're right.

@metlslime- I assumed in the FISH.QC the part of the swimmonster_start is used twice.
First after the frame count, and later at the last line.
So I deleted the ones after the frame count.
And indeed, I used 18 fishes. 

well, that is correct, there is originally a total_monsters = total_monsters + 1; //the fish bug in both swimmonster_start and swimmonster_start_go. if you deleted one, that should fix the problem, so maybe you accidentally deleted both? 

there's a lot of redundant crap in all three of the XXXXmonster_start and _start_go functions.

these days, i like to make a function for setting up the XXXXmonster_start stuff, and then another one to set up walk targets in XXXXmonster_start_go.

this makes adding in new stuff really easy, cause you can just dump it into those functions.

probably most people do that already, but i thought it'd good to mention it in case. :) 

FISH.QC
line 21: void()swimmonster_start; (I deleted)
line184: swimmonster_start ();

Maybe I should turn it back in.
Can't remember where this hack was about. 

monsters.qc 

line 185:void() swimmonster_start_go =
line 229:void() swimmonster_start =

I added the line 21 in the fish.qc but I'm left with 18 monsters untraced.

Which line in monster.qc is the cause? 

void()swimmonster_start; is a prototype, deleting that would probably just give you a compile error somewhere else. 

You might already know this, add the " // "into monster.qc as shown below. You'll still have a duplicate line (not commented out) near the end in monster.qc



void() swimmonster_start_go =
{
if (deathmatch)
{
remove(self);
return;
}

self.takedamage = DAMAGE_AIM;
// total_monsters = total_monsters + 1;