no, only one sky texture will end up being displayed, regardless of how many you use in the map. Either the first or last to appear in the .map file, can't remember which. 

Seems to be the last.

Oh well, thanks for the confirmation! 

Look at my rotating entities testmap. The .map file is here:

http://shub-hub.com/files/misc/rottest.map.7z

This is NOT a playable map. But you'll see how the rotaters are set up. I used quoth and I suggest you use that, too. Look at the func_movewalls especially and the target/targetname stuff on the rotate_object, info_rotate, func_rotate and func_movewalls. Always try to envision where the axis of rotation is. Experiment with the "angles" key until it does what you want.

Simple rotating doors or fans are rather easy to setup. For fans etc, you don't need the movewall stuff at all, just put a trigger_hurt with enough damage. 

I want to run an idea by you for its feasibilaty before actually screwing around with QC, if it is destined to be a waste of time.

My idea is to create a realistic door model (.mdl), have it swing out as if it were hinged. Is it possible to have an animation sequence accomplish this, and then kill the bbox so a player can go through the portal it previously blocked? It seems some games (NOLF I believe is one)use a method like this where the door becomes a nonsolid, and it isn't detrimental to the game play. 

n/t.


Ok, kidding. The easiest way to do this is with a func_togglewall, look at the source code from the hipnotic mission pack for how to do that. They do some really weird stuff to make the entity nonsolid though - moving it 8000 units on every axis so that it's outside the playable space in quake. You could achieve the same thing by just removing the blocking entity if you're ok with it never returning. 

I forgot about that. Reminds me, there is a similar entity type in the Extras package as well that switches out bmodel brushes to simulate affected conditions (a submarine hull getting squished due to an air pressure collapse is one set up I got working quite well). I'll get to work on this. 

Teleporter that waits for trigger, then works normally. My info_notnull experiment didn't work out.

I could probably use a func_wall to cover it or something, but that'd be crude... is it possible with info_notnull? 

The problem you're running into with the info_notnull is that you're creating a teleporter with a targetname. trigger_teleport with a targetname always wait to be triggered before they will teleport anything. So there are two fixes depending on whether you need monsters to be able to take the teleporter or not. If not, then the solution is quite simple - add another info_notnull which will create a trigger_multiple on the same location as the trigger_teleport, and which targets the trigger_teleport.

If you need this to be a full teleporter then you need a pair of trigger_relays repeatedly targetting the trigger_teleport(or does this work with a singe one targetting itself?). At a frequency above 5 times a second the trigger_teleport should stay on all the time, 0.1 seconds between triggers would probably be best. 

more thanks to you :-)

A trigger_relay flipflop. Cool. 

a clipnode?

(I will get round to looking at these other two releases ASAP but im too busy ATM :P ) 

Im only askin' cause ive got 28023 of them and I know I'm only allowed 32762, and I want to know what a 'clipnode' is so I can make sure I dont have any unnecessary ones. 

To avoid clipnodes you should use vertex editing instead.
28000 clipnodes? Wow! I average like 400-500 in my maps. 

I use the clip tool all of the time. I used to use the carve tool, i.e make a brush in the shape of the part I wanted to clip off, then carve it into the brush I was wanting to shape. But the clip tool is really great when you realize what it does.

I thought I was gonna hit marksurfaces first. But ive got 275## of those, and more clipnodes.

I have trouble understanding what these things actually are. I know I can reduce marksurfaces by lifting things 1 unit off the ground, or 1 unit away from walls.

And I know that the world model is made up ultimately of triangles:

Is one triangle one marksurface?
Is a clipnode part of the model, part of the mesh?

Im guessing "not" for the latter of the two questions in the above sentance, as czg, you say its more to do with the way you shape your brushes using the clip tool.

Confusing. 

 

 

Awesome. 

? 

After all of these years........ 

In looking around the web, I found this:

struct clipnode
{
// Index into planes lump
unsigned int plane_idx;
// If > 0, then indices into clipnodes; otherwise, contents enum
unsigned short children[2];
};

So, it would seem, a clipnode is a split in the BSP that either results in a list of more splits or a content leaf.

To reduce them I guess you would use less brushes or do whatever you could to reduce cuts. 

This is GROSSLY oversimplified and I probably got it half wrong, but the gist of it and how it works in practice is this:
http://czg.leveldesign.org/stuff/clipnodes.png

Place clip brushes over places the player can't get to. For instance if you have built some fancy brushwork up in a ceiling somewhere with lots of beams and trims and shit, block it away with a clip brush unless you need to player to rocketjump up there for some reason. 

to make details that stick out of walls be func_illusionary... (They don't clip) 

in my experience, that's how i've reduced clipnodes as well.

interestingly enough, in early versions (and probably still now?) of aguire's glquake, you could load maps with >32768 max clipnodes, but some areas would be non-solid. :P 

with newer versions of aguiRe's enhanced glquake, you can play maps up to 65536 clipnodes with no non-solid areas. Anything beyond that though, and the map will start to freak out. 

With regular engines, clipnodes can be exceeded by roughly 10k before problems occur (e.g. monsters slipping through floors, being trapped on the outside). At least this was true for my qte2m6 - it may vary depending on the structure of the map.

Func_illusionary and other func entities don't reduce clipnodes, they add to them, especially if they are made of complicated brushwork or multiple brushes with spaces between each other (e.g. spikes in a tunnel). 

Func_illusionary and other func entities don't reduce clipnodes, they add to them, especially if they are made of complicated brushwork or multiple brushes with spaces between each other (e.g. spikes in a tunnel).

Hmm, but i bet the same clip brush trick works on funcs as well... you could put an entire func_illusionary inside a cube clip brush, and then that model would have very few nodes
...

anyone know if that's true? :)