probably off grid brushes creating errors. quark does that a lot. use a better editor :) 

.. I'm not able to check anything now: I'm at office :( grrrr...
So I'll take a look this evening trying each solutions you gave me... hoping at least one will works...
aguirRe, I will send you zipped map and wad if I don't find any turnaround... thanks for your contribution..
Thanks a lot everybody.. 

mention that you don't need a pts file to find the problem here; you fall through it ... The dotted line would probably only pass through this brush anyway.

Also note that in many cases, it's not the actual penetrable brush that is the culprit. Often it's a neighbour brush or in some cases even a bad brush junction that's not in the immediate neighbourhood.

It can certainly be a challenge to fix. I'd appreciate the map even if you do find a cure; there's always something new to learn from it. 

I will do my best to solve the problem myself in a first time... If I find the problem, I'll send you a mail for further explanations if you like... or a post here... anyway...If I can't solve the problem this evening, I'll send you the files.. hoping it's only a mistake coming from me and not from the tool...
I will see this in a few hours now... 

if the player start is stuck in a floor brush if it falls through or is just stuck... maybe. 

.. placed too near a brush make the player stucked.. and a possible HOM problem as well... The player can be blocked partially inside the brush and can't moove, he can just rotate left, right up or down... but walking is impossible... I made this mistake in my first trys... 

I got the same problem. I found a solution, by sealing the the brush over the HOM-creating area with another one. I don't know if it works with a floor. 

I solved my problem, thanks everybody who helped me and gave me the good lucky "inspiration"...
In fact, it was a minor problem not detected by TxQBSP... (I don't know why, but it seems to be normal..)..
I had two brushes (a platform and a wall) orthogonaly placed, enclosed each other by a corner of each one face... It results in a "one dot separating line" between floor and wall... (don't know if it's clear...) TxQBSP didn't see this and never found any warnings or errors... (No holes found, no off-grid brushes, no bad aligned textures, etc... TxQBSP works correctly because the map seemed to be correctly build... ) but during the game, the player fall throught the floor !!! The map leak... shit ....

So after many trys, many investigations, walking slowly to detect clearly were is the leak.... falling many times, dying a lot as well... I finally found it...

Lucky I was trying to increase a little the size of the 2 brushes, in order to overlap each other... and the miracle occurs: no more leak, it works !!!
Sure it was a beginner error, but happy I am to find it by myself...
Bye... 

do not use quark :> 

... my best with what I have... But QuArK seems not to be as bad as someone think... QuArK required perhaps more care than other tools during mapping effort... Perhaps you only need to be more precise using it... Furthermore, it is a pretty good editor to start mapping with... that's my beginner opinion... 

that you fixed the problem. However, there can be more such clipping errors and they might not be as obvious as this one. E.g. walking into a corner and falling into a position where you'll have to noclip to get out.

Look in my ToolTips in the "Hull Explanation" section for more info. To make the clipping errors more visible, add the qbsp options -hull 1 -solid -noents and watch out for HOMs in the map.

The HOMs indicate areas where the compiler has problems with the player clipping hull. 

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