Odd. Those skinny bastards. Shambler and Ogre in my test map had no problems. BBox-related? 

Unsure. I'll run some more tests as time permits. Maybe I'll just turn them into regular geometry and be done with it. Monsters who can chase you is better for gameplay than having gratings that disappear on Hard skill. 

You could also use trigger_monsterjump, of course. 

But I can't see how normal clipbrushes (that are world brushes) can help against clipnodes from brush ents...

Sorry, i meant to say add a clip brush to the entity, which encloses all the visible brushes... not add it to the world.

And qbsp doesn't like clip texes on ent brushes ...

I wouldn't say it doesn't like it, it's just that the model bounds are calculated incorrectly and the in-game physics cullboxes end up being too small (if the clip brushes extend outside the bounds of the visible brushes.)

It seems to work just fine with stock compilers and engines as long as the clip brushes stay inside the bounds of the visible brushes. 

have e.g. a door with only clip tex, then qbsp will spit out something like "entity with no valid brushes".

I don't know what'll happen if the door consists of several brushes and one of them is a clipbrush, maybe that's what you mean. It's probably a very unusual case, so behaviour might be unexpected ... 

true, brush entites need at least one visible brush.

In my experience, adding clips to a brushmodel that also has visible brushes works, as long as you follow the restriction i mentioned above. If you don't, the collision between the player and the entity will be buggy. (i think this might fixable in qbsp, by the way, by fixing the model bounds calculation.)

I've used clips on funcs in Antedilivian on a number of doors/bars to smooth player collision, so you can't climp up onto the lip, or into a recessed panel, etc. 

are we talking qbsp hull clipnodes (world) or those AND the entity clippy things whatever they are, added together?

Obviously the entities like func_wall or doors can't enter the hull forming process since they can move or disappear. 

I initially thought of monsterjumps as a work around, only problem arises if the jump is blocked by something on the other side. Hehe, the dumb Quake monsters don't look before they leap so they could potentially end up in the stew. 

qbsp generates a seperate bsp tree for each brush model, which includes hulls and nodes and stuff. Though, all the data ends up being stored together in the bsp file. 

...a clip brush? 

It's a brush with the "clip" texture on all faces. It doesn't show up in game, it only collides. Allows you to smooth out rough edges so the player won't get snagged. 

To funnel monsters sometimes as well.

A skip brush doesn't exist, really, but as mentioned before if you run metslime's skip tool on a map then it removes the visible face of all brushes that have a texture named skip. The difference being that the brush remains part of world collision - so grenades will still bounce off it and monsters have no problem walking over it. 

Really - I dont get the difference. The only difference seems to be that you need to use a skip tool for a skip-brush but you only have to use a texture to make a clip brush... ?!

Or would I be right in saying that a grenade will fall through a clip brush but collide with a skip, but you can walk over both?

P P P P P : - D 

"Or would I be right in saying that a grenade will fall through a clip brush but collide with a skip, but you can walk over both?"

Right. 

OK, so I wote a quick utility in Cocoa that lets me type in strings and it spits back the necessary QuakeC to emit that text to the finale screen. I'll release the source once it's fully done and Qonquer is using it without issues.

http://wantonhubris.com/blog/2008/03/05/quakec-char-emitter/ 

But you should have made me a blood splat progs. :-(

(facetiousness is a virtue) 

I'm not that clever. It's, like, 20 lines of code. :) 

I used to program BBC basic (I wasnt bad at it either, I managed to make a top down scrolling racing game once, sort of pong-style stop-the-ball from-falling-out-of the-screen-type-stuff)

And I can do html, css and a bit of xml

Maybe I should try a bit of Quake C.

Honestly though, it looks well hard! 

QuakeC is a heavily stripped down version of C. If you have prior programming experience, the syntax is easy to pick up.

What is more difficult is learning how to do stuff within Quake. It's the same with any system or API, of course, but that's your stumbling block,

"Why doesn't that line of code work?"
"Why won't the monster turn to face me now?"
"No string concatenation, WTF?"

Once you get comfortable with what Quake does and how you can access it, you're golden. A few tutorial reads and a few posts here for Preach to answer, and you'll get it. 

I was wondering if anybody needed a small base style map for anything? It could be easily turned into a start / skill select map or joined onto an existing base map, the reason is that I just don't have the time to finish this one sadly...

http://daz.quaddicted.com/images/fitz0017.jpg

Maybe the basepak or quoth2 or something needs a start map? Let me know if anyone is interested. 

It looks really cool ! go map and finish it... or do a DM with this one ;) 

Somebody turn it into a Qonquer arena. :) 

use it as a start map for the base pack! 

clip: players/monsters collide, but bullets/rockets pass through. Doesn't cast shadows or consume lightmaps. Doesn't affect vis time or r_speeds. Can be used to cover up normal brushes and you'll still be able to see the normal brushes underneath.

skip: it's really just an ordinary polygon that is invisible. It uses lightmap space, it cuts up the bsp and affects vis time, it blocks bullets, it casts shadows, etc. It can cause HOM due to the fact that when brushes touch, the touching surface area is removed.

Here's why: the bsp contains three independent "hulls," which are each built using the list of brushes in the map file. Hull 0 is the visible hull, a giant mesh of polygons that you see as you walk around the level. It is also used for collision for point sized entites and line-of-sight calculations. Hulls 1 and 2 are never visible, but used for collision for larger entities -- player sized entities use hull 1, and shambler-sized entities use hull 2.

clip brushes (clip must be an an entire brush, not just a face) are completely excluded from hull 0, but included when building hull 1 and 2. That's why they don't affect the visible stuff at all, or point entities, or bullets.

skip faces (since skip can be added to individual faces) are part of hull 0, and simply hidden from the engine so it doesn't render them. That's why they block bullets, cast shadows, affect vis, etc. 

Maybe release it as GPL or something - whatever you do, just don't waste it on the Base pack.