i am constantly amazed at the amount of hackery you can accomplish without touching a single line of code. 

It is not a bug, it is a feature ... 

Heh, cheers. I just should not have touched how id built it I think. Works like a charm, thanks. :) 

What is it that allows HellKnights to wade across knee deep lava but Ogres do not? 

space?
bounding box and stuff... 

but monsters with large bboxes are more limited in movement. they require bigger surfaces for their movement checks. i don't exactly understand how the movement checks work, but that it has something to do with the size of the horizontal area of the bbox and the gap and heights. :S
i'm sure an engine coder could fill you in on the movetogoal code. 

If you make it so that the brush of lava is sticking up, and the ground is level across the boundary to the lava(so you have a random floating box of lava on a flat surface) will the ogre wade through it then? How about if you make some steps down into the lava as it is? The hellknight uses a different bounding box to the ogre(player size vs shambler size). So it might just be that hull 2 monsters get clipped again lava differently in the navigation algorithm.

On the other hand, I think it's more likely that the ogre is just too large to navigate the drop down into the lava in the first place(presumably if it's knee deep it's in a channel with a knee deep drop). For instance, in e3m2 you can get ogres to wade through the various pits of shallow lava there, and at the end of 3m6 the vores will walk through - they are also hull 2.

I've noticed there's a problem with models that have a hitbox larger than their physical hull for clipping and MOVETYPE_STEP. I think what happens is when the monster tries to move down the steps the hull moves over the edge of the step and so drops down. But then the engine tries to trace the bounding box to it's new position, and as it's larger than the bounding box it detects a collision on that, so the monster gets moved back up. The end result is a monster that hovers around the edge of a step without descending for a while - eventually it drops down when it moves far enough beyond the step in one go, so that the bounding box clears it too.

I don't know for sure that's what's happening in the engine, but I was having this problem with a monster until I shrunk the hitbox back to the hull size in the x-y plane, and then it stopped happening straight after that. Then again, I recall the ogre having a a fitting hitbox, so this probably isn't the exact problem you're encountering. 

I had placed the lava as a 'barrier' to monsters and as I had only tested it with Ogres, it seemed to work OK.

Then I decided that this area needed some more monsters and drafted-in a couple of HellKnights. It was a bit of a surprise when they suddenly jumped into the lava and waded across.

I suspect that you are all correct and that it is to do with the bbox: it is a narrow channel 96 units wide and the lava is 24 units deep, with a slight slope dropping four units.

Even without the lava, the ogres will not cross the gap but the HKs just stride straight across.

Oh well, as JPL said earlier, not a bug but a feature. I'll leave it in, maybe it will catch someone (who doesn't read this board). 

The new tricks thread has how to create an invisible entity that blocks monsters but not players, in fact it seems to use the same tricks that have been causing problems for trinca. You create a brush with clip texture, and hide a regular textured brush in the wall below. Then make the pair of brushes into a func_wall. Because the clip part of the brush is outside the bounding box of the regular brush, it doesn't clip the player(or monsters moving by flight/ leaping).

However, as MOVETYPE_WALK is a rule unto itself, it actually takes notice of the clip brushes there and won't move monsters across. I have a theory that if you made a thin brush and had a monster that walks far enough to completely pass through the brush in one frame, it could skip the monsterclip. But I've not tested it, it's just intuition.

Now, this all started because the ogres were blocked by the lava but the hellknights weren't. What if you wanted to use monsterclip, but still have the hellknights able to pass through it? Or what if you wanted to reverse the situation and have only the hellknights blocked and not the ogres? Or make a visible func_wall that blocks the player but none of the monsters? It turns out all of these things and more are possible, and I'm gonna post how in the new tricks thread... 

afaik there is no limit to numportals anymore (at least in aguirRe's tools). 7700 is nothing to be worried about; the other limits are definately more important. 

could you tell me all the other limits as i've forgot them, been awhile since my last map, the new map feels smaller in away but is even more detailed then the last so i suppose i'll hit some limit sooner or later. 

I am having trouble keeping tabs on all of my monsters in the editor. I was thinking of puting all monsters of each skill level into a separate Group so that I can work on each skill level independently by turning these Groups on and off as required. This would mean that if a monster was to appear in all three skill levels, I would have it three times in the map instead of once.

Clearly this would mean that for the sake of me having an easy time of it in the editor, I would 'bloat' the .map file and the .bsp file.

How bad would that be for a map that has (say) 100 on Easy, 150 on Norm and 200 on Hard: that's 450 monsters in the file instead of maybe 200 when using conventional methods i.e. using spawnflags?

Is there any effect on the engine or is it all down to file size? 

The skill setting flags are done engine side rather than QC side, so the entities aren't ever loaded into memory if they have the right spawnflag set. The only thing I'd think would result is a bit of a longer loading time as it checks all these monsters when the map loads - and that's going to be pretty fast. It will also bloat the bsp file, but not by a lot, the entire entity section of e1m2 is 40kb in size, and the bsp is 1.3mb. 

Thanks. In that case I'm taking the easy option. 

i don't know all limits by heard, but the ones you should watch out for primarely are marksurfaces and clipnodes (both 32k), as well as the entity limits (e.g. 128 static ents, 256 bmodels and so on) 

what couses this???

Sz_getspace: 8002 is > full buffer size

if map is in id1 drectory no problem... but in Quoth give me this error... any idear why? 

Too many entities. Reduce their number. Try to combine some b_models into one where possible. 

why do I always get the message backup past 0 in one place in my map? AguirRe's engine, -developer 1 option.

And I get monster in wall message when monsters spawn high over ground (to avoid accident telefragging them).

Can anyone explain? AguirRe? 

i think the droptofloor doesn't drop monsters if they are too high above a floor, this means that when the monster is checked to see if it can walk or not (ie: stuck in the floor or not on the ground) it will return false, and thus give the error message.

this used to happen in quoth for spawning monsters from func_hordespawn, because i chose to not make spawning monsters droptofloor (in case you used flying monsters) but the error check would come back that they couldn't move (because quake physics hadn't started on them yet and made them fall to the floor). 

Backup past 0: I don't know, it happens occasionally without any obvious problems.

Monster in wall: I also don't know, if the monster behaves as desired, ignore the warning.

I think both things can be QC issues as well. 

The monster in wall check is just like necros said, it's a QC side thing, in the function walkmonster_start_go. The way the QC tests for a monster stuck in a wall is to call walkmove(0,0), the function for walking monsters on the ground. This function returns a float value of 1 if the movement was successful and 0 if it wasn't. If the movement fails then the error message "walkmonster in wall at: " is printed.

The problem is that walkmove can fail(return 0) for three reasons. One is that the monster is stuck in a wall, which is the behaviour the code assumes. The second is if the monster can't physically move that far, like when there is a wall in the way. This cannot happen in this case though, as we are walking the monster 0 units. So you only end up in a wall if you started in one.

The third reason it can fail is if the monster isn't on the ground, as walkmove is only for monsters that are walking on a surface(surprisingly enough). So if the monster is spawned in the air it's going to fail this check. Usually the preceding line of code in walkmonster_start_go drops the monster to the floor first, but if your monster is too high to drop(more than 256 units above a surface) then it won't work.

Since you mentioned avoiding telefragging as the reason the monster is so high, there is another possibility why droptofloor isn't happening. I'm guessing that you're using some kind of spawnflag teleporting, rather than the ID setup of info_telport_destination and teleporters outside the level. Some code(mine included) modify walkmonster_start_go to ignore the droptofloor call - precisely for the reason you're giving, so that the monster teleports in from where they are placed, which is allowed to be in the sky. Of course, then the code should really skip the "monster in wall" check too, as it'll always fail even when the monsters are not stuck. I guess I should contact inside3d about correcting my teleport flag code then... 

for some reason remove_skip doesn't work on my map. it always stops after saying "bsp is version 29" without removing any faces. could this be related to fact that i'm very close to hitting the marksurfaces limit and have exceeded clipnodes by 10k? compiler is treeqbsp-bjp by the way. 

skippy tends to trash the bsp and cause all many of problems. 

i changed the object in question to a health trigger. thx 

...I have just added 20+ monsters without making any changes to brushwork. Marksurfaces have risen from 31065 to 31665.

If marksurfaces are created as a result of the way the brushes are split in the qbsp stage, does it mean that monsters can cause a different split? And if so, is there a benefit to keeping monsters off of the ground in the mapping stage.

I ask because I have at least another 80 monsters to go and am in danger of exceeding the marksurface limit, and I want my map to be playable in FitzQuake.

(I am probably getting too tired/old to adhere to the critical technical disciplines of Quake mapping these days)