OK, so in the Elder arena I have those gratings that run over the lava at a few points. The gratings are func_walls so I can remove them at higher difficulty levels.

However, monsters would NOT cross them so I covered them with clip brushes in the hopes that they would.

Still no dice.

How can I convince the monsters that, yes, it's safe to walk across the scary gratings? 

That sounds correct, qbsp doesn't know that.

But I can't see how normal clipbrushes (that are world brushes) can help against clipnodes from brush ents, especially since the latter can be moving. The CSG process will only merge stuff within the same model.

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

Filling the holes with skip func_walls would be the most reliable way. 

Does Quake support skip brushes? I thought it was just clip and trigger... 

I don't think there are any compilers that do this, and I suspect that there is no way to hack it in. You can't create new buffers to store strings in without engine extensions, and there's no way to access the individual elements of a string from QC. A string in QC is really just the pointer to where the array of characters is stored. These arrays are either loaded with the progs, loaded from the map data, or accessed from the 16 char array allocated for each player's name. The last one is about as dynamic as strings get in quake.

What could be hacked into a compiler is some kind of keyword/macro thing called _tokenize(string n) or something, which would do all the work of calculating the corresponding character index for each character in the string you feed it, and then send each byte as MSG_ALL or MSG_ONE. It would still only be useful for fixed strings liked "killed " above, not loaded frlom map data. But it would keep the code looking shorter and neater.

A slight step in that direction would be for each fixed string in the progs, create an array of floats, so killed would become
s_finale_killed[7] = {107,105,108,108,101,100,12}

Then you'd have a loop

while(i<7)
{
WriteByte(MSG_ALL,s_finale_killed[i])
i = i + 1;
}

which writes it, which looks a bit better than a row of 7 WriteByte statements, and is certainly nicer for longer strings.



Additional: The idea of sending strings byte by byte is done to a huge extent in Pyrdon Gate, which is where I first heard of the idea. The source to v1.5 of this mod can be found here:
http://mindart.quakedev.com/code_crazy.zip

Look at menu/print.qc for a good idea of how it's all done there. One of the most valuable tricks you'll see is once you have a function
p4(float a,b,c,d)
which sends those four floats as bytes over the current channel, you can do stuff like
p4('D', 'a', 'm', ':');
which converts the characters to numbers for you, in this case printing "Dam:". This might be a frikqcc only trick, but it's worth a look. 

You need metl's skip tool (which removes all "skip" textures from the visible plane, thus making the func_wall invisible): http://www.celephais.net/files/newskip.zip

I don't know if the monsters were be able to walk on the grate if the clip brush was part of the func_wall. Skip is a safer bet. 

Be warned, if you do fill the holes with skip brushes, then they will also block grenades/rockets from going down the gaps, the holes are blocked in all but the visible hull. 

that way the monsters will be smarter for not walking over the holes.

There could already be fireballs coming out of the holes, I haven't looked at that map yet ;P 

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.