in order for a monster to take a step, it has to have it's 4 corners of it's bbox 'on ground'. the monster is allowed some leeway, but if the steps are too short, it would have to 'skip a step' which makes the vertical distance too far down.

essentially, the big monsters need bigger steps. :P 

obviously, without seeing the map, i can't be sure, but i don't think it's a ceiling issue.

the check when walking up a step is different from when walking down.

it is allowed to step up more than it is allowed to step down. 

Aaah yes, I think you might be onto something.

When stepping up, the front corner(s) need to be moving into something, and have a place to stand that is less than maxstepheight (there is a cvar for this, default is 18).

When stepping down, however, it's something like the middle of the box needs to be above a point that is no more than maxstepheight away, while the back corners are still on the top step.

This suggests that the only thing that will work, is either a smaller bounding box, or wider/shallower stairs. 

"in order for a monster to take a step, it has to have it's 4 corners of it's bbox 'on ground'. the monster is allowed some leeway, but if the steps are too short, it would have to 'skip a step' which makes the vertical distance too far down.

essentially, the big monsters need bigger steps. :P"

Are you sure? Ogres can navigate standard sized stairs in most maps that I've made. I've never had a situation where I needed to make stairs deeper to accommodate the bigger bounding box ... or maybe I've been doing it just automatically and not running into this. I dunno! 

So I guess that I'll stop trying to get the ogre to walk down the spiral(!) staircase then.

Mind you, he looks quite funny when he is twizzling on a couple of stairs (he sort of dances between them) and I may leave him there just to give the player a laugh before he blasts the ogre's head of with both barrels.

Thanks for your help everyone. 

That clears it up :) 

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?