Skip should have the same collision as other textures unless some compiler has changed this behavior 

droptofloor uses visible hull, no? 

no.
it uses a tracebox, so the hull it uses depends upon the size of your entity (which is kinda what you'd normally expect). 

Having a group of several monsters teleport but only one shows the tele effect. I can't seem to get more than one instance of the effect at one time. Anyone seen this before? Using the latest quakespasm btw. 

try running the engine with -particles 100000. 

Strange that by default quakespasm won't display more than 1 tele effects worth of particles...

anyway, thanks! 

 

So I'm drubbing through the progs dir with qME, and can't find the health box model. Am I a colossal blackhead and missing something? You be the judge. 

b_bh25.bsp 

Maybe qme doesn't display .bsp's? 

qME doesn't display BSPs. 

QuArK does! 

Noesis, Blender 

I decided to play around with the vertex editor in GTKRadiant 1.5, and I noticed that there isn't really much freedom to move verticies as I saw in comparison with 1.4

This just looks weird: http://i.imgur.com/Z6kO8P4.gifv

Anyone know why this is? 

this has always bothered me. wonder if there's a way around it? 

but I thought there was a way to select two controlpoints by keeping the leftmouse down and surround them. 

installed Radiant to see.
It should be: press shift + left mouse surround.
Then both controllpoints move smoothly. 

Yeah it looks gash, but what you are trying to get radiant to do is undefined.

Radiant does not create new planes or split brushes automatically in order to maintain brush validity after vertex manipulation, so in order to keep the brush valid it must move other plane points - and the results are about as useful as you would imagine.

Trenchbroom is a bit smarter in that it creates new faces as required. To be honest though I'm a diehard Radiant fanboy and get by with the clipper and edge manipulation, using vertex manip only on certain shapes where I know the results will 

"...where I know the results will be predictable" 

If you build an entity entirely from clip brushes it doesn't usually work - I remember it being something to do with the bounding box not being enlarged by clip brushes. The workaround at the time I learnt this was to sandwich the clip brushes between thin regular brushes on opposite sides, so the clip lived within the boundaries they formed. Is this still state-of-the-art when it comes to making clip brush models, or is there some new compiler which corrects this automatically?