Have you considered func_movewall, which is used to emulate collision on rotating objects?

I am not sure what you are trying to do with clip tex on doors so if this suggestion is out of line, just ignore it. 

you can have clip brushes in a func_door volume as long as they're encompassed by visible brushes, e.g. a clip brush with a border made of textured brushes. it only doesn't work if the door consists solely of clip brushes or the clips exceed the actual door volume. 

I don't know about engine issues, but the compiler doesn't accept an entity that has brushes specified, but where in a certain hull (here: hull 0), all the brushes are removed.

The same applies for the world; you can't have a world entirely made out of clip brushes.

To just get the compiler to build, try adding an extra brush (e.g. hidden inside the wall) with a normal texture to the entity.

It still might not work in the engine according to neg!ke's post. I think metl did some tests on this before. 

I have a question about elevators.
I need the following:
Quakeguy encounters the elevator in its lower position. Quakeguy drive upwards with the elevator. Elevator remains in its upper position. Quakeguy walks around and kills monsters. Quakeguy returns to the elevator. Quakeguy drives downwards with the elevator.

I spent quite some time during my speedmap session with it and gave up (neg!ke, don't show anyone what I did instead, *shame*). I assume I could do it with some triggers, but don't know how. 

I think you could do it by making the "platform" a func_door with the toggle flag set. You have a button you can use once at the bottom of the lift, and another one at the top that you can't get at to press. When you kill the monster, you remove whatever was blocking off the button, and press that to make the lift descend. 

why cant i make a func_door with clip texture? grrrrrrrrrrrrr

I don't know about the compilers, but there is an engine bug which makes the clip brushes on a func_door sometimes nonsolid. The bounding box of the func_door is generated from hull0 brushes, so if clip brushes are outside that bounding box, you can often pass right through them.

A func_door that is entirely clip would have a zero-sized bounding box, so you might never collide against it. 

might be able to use a null modelindex hack or something to make a normal brush invisible. Not sure. 

thks metlslime i will add a small box in func_doors and try ;) 

does it mather how high the numportals go?
just asking as vis sais i have over 7700 of em on my recent map 

I discovered the important part of this hack a month or so ago, when people wanted glass windows for the base pack. I didn't post it then because there's a drawback to the function you need to use that I felt was too problematic. However, after metl's post there I thought of a neat fix to this problem, so here we go. Note that it still doesn't fix trinca's problem as it'll only work on func_walls(well, entities that don't have think/use functions, so you can have those invisible ammo crates you always wanted too...)

Ok, make a func_wall, and add the following keys:

think info_teleport_destination
nextthink 0.2

That's a pretty cunning function there, for no good reason the info_teleport_destination spawn function has a line setting self.model to "". Still, this bit of leftover code has given us a great hack with only a single drawback. If you compile and try it now, you'll find that you func_wall is invisible, but 20-odd units higher than you left it. And if you try to stand on top of it you'll get stuck - what happened?

Well, in order to stop people getting stuck in the ground when they teleport, the info_teleport_destination is moved 22 units up when it is spawned, by directly changing the origin of the entity. Doing this on a point entity that is just being spawned is safe, but doing it on a brush entity that was spawned 0.2 seconds ago breaks quake's internal physics state.

So this is why I didn't post it before, but there's a solution - use another function that will reset the origin using the setorigin function. In fact I suspect if you just undid the displacement of the func_wall then physics would be fixed, but I don't know of a hackable function to do that, and in any case we might as well do the proper method :-). Ok, add these two keys:

targetname wall
use SUB_CalcMoveDone

That's pretty much it, SUB_CalcMoveDone sets the entity's origin to self.finaldest - but all brush based entities start at '0 0 0' regardless of their bounding box, so we don't have to set finaldest to anything. In fact, you might find some other creative use of this function on other entities, it's basically like a free teleport to self.finaldest. As an added bonus, the entity will then execute the function stored in self.think1.

One final thing, we've put this function in self.use, which doesn't get called automatically like self.think does, so we need another entity to call the think. Knock up a quick info_notnull with fields

think DelayThink
nextthink 0.4
target wall

As long as it thinks after the wall becomes invisible then it'll work, but you want to do it all fairly fast so the player can't encounter the wierd physics anomaly. Now, I'm gonna go play with this new function for a bit, see what else it can do... 

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)