i've noticed problems with using clip brushes in a bmodel. It seems like it ought to work; is there anything you can tell us about why it doesn't? How easy would it be to add this functionality to qbsp? (i know, i could probably look at the source myself, but it's late and i'm tired and you might know off the top of your head.) 

Good idea you have !!! Thanks a lot for this advice.. I'l try it as soon as possible...
Another more question: do you think these kind of problems are coming from QuArK bug (especially during map file writting) or from TxQBSP compilation that pass throught it ?? 

In brush.c there is a specific check for texture clip in the visible hull (0), same area as the check for liquid brushes in clip hulls (1/2).

I don't know why it's there, my assumption would be that the engines don't like it (maybe you could check that).

Anyway, why is this a problem at all? 

I didn't quite understand your explanation of the cause of the problem so I can't say with the information at hand.

This is one of the reasons why I asked for the map, then I can see for myself what the problem is, a possible cure and if there are other issues that you haven't spotted yet.

I'd be glad to help, but I need the zipped map+wad to investigate further. 

OK, sorry for my poor english... I have to improve it too ;-)
I'll try to send you a zipped map+wad file as soon as possible.. (next Monday later...) but it will be the corrected map... I didn't saved the corrupt one... :(
Anyway, I hope you can give me advices about my mapping way.. that may be not as good as "pros" can do...
Thanks... 

Your English is fine. Your syntax and word choice is intelligeable to any English native. I think aquirRe was referring to the technical nature of your explanation. Believe me, you sound like James Joyce compared to an unmentioned else person. 

Oh... it's great for me to hear this... thanks a lot... 

Sometimes it's very difficult to describe 3D-issues in plain <insert language here>. Combined with fluent Q1 tech speak, it probably sounds like gibberish to the man on the street ... 

...pourqoi est le peuple d'un pays tr�s grandes
si volunt� responder les questions dans un autre langue, quand ils comprende le bon mot...

one day you'll return, Pink Panther 

based on your description, it's obvious that the checks are for when to ignore a brush -- liquids aren't used for collision (hulls 1/2), and clip isn't ever visible (hull0.) But, does that make any distinction between a bsp model and the world?

The specific problem case i have is a fake ladder (one of those really steep clip staircases on top of a visible ladder) which is a func_door so that it can slide up out of the floor. 

That poke was for the Beavis and Butthead poem many moons ago. Yes, I am petty that way. 

Well, if all brushes in a bmodel are invalid (for that hull), Brush_LoadEntity will return NULL and that will generate the Entity with no valid brushes ... error message.

Since the world usually has more brushes than a func_door (sic!), it's more likely that the world will actually have at least one non-clip brush so hull 0 is OK.

I haven't tried any of this, but I guess that if you only have clip brushes in the world entity, you'd get that error message too in hull 0. Correspondingly also in hulls 1/2 if you only have liquid brushes.

Maybe an upcoming speedmap theme? Or not. 

Blocking out the clip check only results in a visible clip brush (that also works). However, using the standard qbsp and a func_door with one normal brush and one clip brush is a bit strange.

No complaints from qbsp, there is no visible clip brush in-game but it doesn't seem to be there either (hull 1). The normal func_door brush is there as always.

When moving close to where the clip brush should be, the engine (FQ) behaves a bit jerky, I don't know how to describe it. 

make one func_door for the visible ladder and another one for the invisible stairs... and for the second one use this thing instead of a clip brush:

http://www.suspenlute.com/01/skippy-00.zip 

Yeah, i thought of that (actually, RPG thought of it.) It works, but it seems like a clip brush OUGHT to work, and if we can figure out the fix, i'd like to have aguire add it to qbsp. 

i'm looking through the quake source to see if this could somehow be caused by engine code. In the past I've noticed that some physics routines actually use hull 0 for specific things, so maybe this is another case of that happening. 

As I mentioned above, you can use any standard qbsp with bmodel clip brushes as long as there's at least one non-clip brush in it (which doesn't even have to be visible).

So I don't think a change in the compilers is necessary (or at this point, even desired). But it would be interesting to know what's causing the engine behaviour above. I tried Tyr-Quake also and it seemed to behave similarly. 

maybe i didn't explain it clearly -- I already DO have clip and non-clip brushes in one func_door, and it doesn't work. Anyway, i'm still looking. 

I have successfully had clip and non-clip brushes in a bmodel before.. without a problem. 

...but maybe it has something to do with whetherthe non-clip brushes are touching the clip brushes? 

the brushes were not touching in hull 0 but they were near one another, so it's possible that they melted together in the clip hulls. 

Hello,

Is there a tool that can help to check map file before any compilation ? This in order to avoid crashes, HOM, leaks, etc... It will be helpfull to detect any warnings/errors/problems (like off-grid polygons, unaligned textures, etc..) before starting to build bsp files..

Thanks 

Try MapSpy:
http://mapspy.gamedesign.net/

It's designed for Quake 2, but it checks for all sorts of other brush problems. Just ignore the Quake 2-specific stuff.

...

After re-reading your post, it sounds like MapSpy isn't really what you want (it doesn't check for unaligned textures or HOMs, and I'm pretty sure it doesn't check for off-grid polygons or leaks). But it's a small download, so you might still want to try it out. 

QuArK, there are a few things in the Search menu that can help in finding potentially bad brushes, e.g. Find Microbrushes. Just be careful when using some auto-fix option, make sure you have a backup before.

For texture alignment there are several helpful things in the right-click menu of a selected face, e.g. Wrap texture from tagged.

Otherwise I think it's the compilers that offer the most useful checks since they are actually the tools that translate your map into bsp.

Compile now and then to see that the map is OK and always save various generations of your map so you can recover if anything bad should happen. 

Thanks for the link and these infos about QuArK... I wil try to test the stuff tonight...
Bye..