thks i will try but i think it gave me some errors the last time i use it... fuck me up the hole .bsp :\ so might not work! 

Skip tool would effectively to be refined in order to avoid to generate an HOMs-full map in certain cases.. 

I think skip is much safer on func_ entities than it is on the actual map, seeing at they don't have the same vis calculations performed on them, and won't ever have to be the surface that's between the player and the void(assuming the map is sealed). 

it is impossible :S

although, if the sound was really short, like say 0.1 seconds or something, then you could probably achieve the effect just because it probably wouldn't be noticed that the sound is starting back at the beginning all the time if you adjusted volume every 0.1 seconds.

in fact, you could maybe do that unless the sound was like say 30 seconds long. if it's 2 seconds, then change volume every 2 seconds, if it's 0.7 do it ever 0.7 etc... 

Oh dear, I thought this may be the case. It's deja vu recurring again once more! 

Aguire can u change Txqbsp.exe to accepted the the clip textures in entities? i want to put clip texture in a func_door :\ 

or is a engine problem? 

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).