so, clip brushes can't move. anyone got any suggestions for how they... could?
(I have a ladder, func_door, which moves up/sideways, but I want the player to be able to climb it easily (ie normal rapid clip brush stairs) once it is in place. Any ideas? 

but the player is exposed, and would have to be very careful. And I don't want to piss people off or force them to play a certain way. I do that enough already. 

Texture them with skiptex, and skip 'em! ;) Effectively a clip brush which can be funked. 

thanks
that is a very good idea
but, I'm afraid, then the wily (or just curious) player will randomly walk up these invisible stairs before the visible ladder (func_door) is in place? 

actualy wait maybe I'm misunderstanding
if I can func_door a skip brush and make an invisible yet clippable brush which can have entity functions that would so solve my problems. 

Just move the invisible 'func_door ladder' into position at the same time as the visible ladder :) 

you can totally put clips in func_doors. 

This works, but there are special things you need to do.

The main issue is that only the visible brushes of the func_* will be used to generate a bounding box that is used for physics optimization. So if a clip brush sticks out beyond that bounding box, players and monsters will be able to walk through it. If the player enters the bounding box, THEN they will correctly collide against all brushes, including clip brushes.

So, the thing you need to do is make sure you have visible brushes that extend in all 6 directions (+X, -X, +y, -Y, +Z, -Z), so that your bounding box is correct.

For example, a visible ladder that has clip brush stairs -- the visible brushes are already tall enough and wide enough, but the front of the ladder is the problem -- add another brush somewhere (maybe below the floor) that extends forwards as far as your most forward clip brush. This will force the bounding box to be correct. 

Isn't there a catch with clip brushes - that they don't count for the 'extents' of their entity? So you need conventional brushes to mark the outer edges of the entity.

None of this applies to skip brushes though, so that will work fine. Remember that skip blocks rockets but clip doesn't if that matters! 

For the record, I think this is a qbsp bug, but an engine could theoretically fix the data at map load time. 

That's what I was getting at. I even posted the shorter post this time round and still got sniped... 

so if you had custom progs that let you manually set bbox size, you could have clip brushes beyond what qbsp would set as the bbox then. 

Not sure actually... I'd have to check the code to see, but I think the bounding boxes generated by qbsp and used by physics are seperate from the boxes set in quakec using setsize(). But maybe not. 

thanks for the help/explanations guys, I think I have it solved (am about to test map).
I imagine negke (side note: negke weirdness rules) could do some interesting stuff with invisible movers (although it seems like a func_whatever can't be ONLY clip brushes and has to have some normal brush component). 

I just deleted a giant rant, but if anyone is willing to help me with a map or two, deadline QEXPO 2011, I would really appreciate it. Hell log the hours and I'll pay em back next fall. Once I finish my characteristically-Tronyn-stuff, I'm interested in checking out weirder ideas regarding Q1SP. I've loved the ULTIMATE DOOM ULTRA VIOLENCE view til now, but there are many other views. 

 

I am bad at some things and worse at others ;) 

negke would use skip brushes to define the bounds and go nuts with clips within. Remember, it takes only two tiny brushes to make it work.

negke weirdness 101: clip maze!!!

Tronyn: Yeah, what kind of help are you talking about. I mean, not that I would want to help a RANT DELETER... 

I tried the door setup, but it worked even less. When doors and relays had the same wait/delay, the doors wouldn't move at all, changing delay to 0.2 worked but then the animation wasn't smooth. Or something. Pretty messed up stuff. After three hours I gave up and flagged them out. 

tronyn: email me about whatever and we'll see what's up.

negke:
doors have to have a slightly longer time before the next triggering than their waits. 0.1 is enough i think?
you could try adding more frames (doors) to the animation to get that extra time.
also: MOVING clip maze. ha! 

Maybe Glquake just sucks ass and should have been banned from every computer years ago.. 

to edit finished bsps again? I only need to change a trigger_changelevel. 

extract entities from the bsp (which are in plaintext format), save as a .map, edit the .map, then recompile using -onlyents, and remember to also run light.exe -onlyents so the switchable lights will work 

you can edit the bsp itself with a hex editor, this works as long as the total number of bytes doesn't change. So if you're replacing a string with the same-length string, it would work. 

this does it pretty easily too