why cant i make a func_door with clip texture? grrrrrrrrrrrrr 

ok thank you for all your help, ill mess around with the file type for a bit, Good luck and God Bless.

if have any success ill let you know 

Mike: I can't think of any good way to do that with QC, I don't even think something hacky like moving the source entity away from the player to diminish the sound would work. You might want to try asking on inside3d though, they can work wonders over there.

Trinca: I think it's just a compiler restriction. You can achieve nearly the same effect by using the "skip" texture and running the skippy tool on your BSP. Skippy has been discussed here a few times and you can grab it from http://disenchant.net/files/temp/skippy-0.0.zip if you don't already have a copy. The main difference you'll see it that the skip brush will be solid to point sized entities like nails/missiles. 

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