I just gave it a brief test in your qarena map: You can make the monsters cross the grate by making the clip brush part of the func_wall entity. The brush must stay within the volume defined by the visible brushes. 

Preach

That looks usable. Not great, but under the circumstances it seems like the best option.

Thanks again! 

neg

I put a clip brush into the func_wall before and it didn't work but I'll try making it smaller so it just fills in the holes. I'll try that tonight. 

But did you also make it part of the entity? 

Yeah, it was all part of the same func_wall - the regular brushes and the clip brush. The knights wouldn't set foot on it. 

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.