I would like to manage a door like this:

1/ First open the door with a button, and let it open
2/ After crossing the treshold of this door, close it definitevely behind the player..

I made many tried with "wait -1" field and "trigger_once" function, but I was unable to reach my expectations... Is there something I missed ? Can somebody give some good advices to achieve it please ?? 

add spawnflag 'toggle'
and trigger it with a trigger as soon as u enter the room, it'll close instantly 

and toggle is
spawnflags 32 

OK, I understand now why it was not working, thank you very much :) 

I had yesterday night a ClipNodes problem i.e ClipNode Number (33015) exceded engine limit (32767)... and I found many informations about this kind of problem in the amount of previous post ;) For eaxample how to reduce significantly ClipNodes number...

Nevertheless, I have a question: Does ClipNodes number can produce a map leak ? Or is there something else I missed ? 

as I know, but leaks in hulls 1/2 will increase clipnodes significantly due to no filling of outside in those hulls. So excessive clipnodes indicates that you might have a leak, but is not the cause. 

to make sure u have no leak but clinodes excess, clip some recesses/alcoves in your map, i.e. make less clipnodes (lower the amount which is supported by qbsp), if the number of clipnodes will be lower than critical and you'll still have a leak error, then you got the leak, go seal it. 

So there is something mysterious here: I only added some walls, and in order to test texture alignements, and how it looks with shadows, etc.. I tried to compile the map, and sunddenly, the map leaks, while it didn't before the modifications (and these modifications were not impacting the map sealing...)

Anyway, I will try to add clip brushes in order to reduce ClipNodes (particularly on terrain part), and I'll try to recompile and see what will happen... using your tools tips ;)...
BTW, when loading the prt file in the map, I can see the "point" going throught the middle of a wall... It's something weird because there is no "hole" in the map ! o_O 

Thank you, that's exactly what I'm going to do (see my previous post)... They crossed each other ;) 

like a leak in hulls 1/2. Check the brush and its neighbours and make sure they're aligned. If the leak is in hull 1, you can often verify the leak by walking/falling through the brush.

Btw, it's the pts (point) file you load into the game, the prt (portal) file is used by vis when the map is sealed. 

I didn't be able to walk/fall through the brush... I will check the map this evening (with your "magic" -hull <1/2> option)... Thank for your advices ;) 

Ooops I forgot to mentionned that, If I remember well, leak occured in Hull 2 (reached occupant etc.. after Hull 2 start in TxQBSP...), so what am I suppose to look for now ?? 

can be tricky to find and fix. The first thing I'd do is to inspect the brush and its neighbours where the pointfile goes through the hull. Look for tiny misalignments (zoom in real close), especially in non-axial junctions.

Try expanding or otherwise change one or more of the brushes in all directions to find the culprit. Building with the -hull 2 option may help if there are HOMs in that area but it's mostly useful for finding clipping errors fully inside the map (which don't cause leaks), see also ToolTips. Use the -starthull 2 option to speed up the turnaround time (to quickly see if the leak is fixed; abort if not).

If you can't sort it out, send me the zipped map (no wad yet) and I'll see what I can do. Please also include what compiler options you're using. 

Im having trouble with brushes dissapearing during compilation. they are in the editior (Gtk 1.4) but when i run BSP (treeQBSP v2.00 -- Modified by Bengt Jardrup) i spring a leak! i run BSP after mapconv. perhaps mapconv is screwing up? i donno. 

updating to 2.01 and adding option -q2map, this will eliminate the need of a conversion tool. I doubt that the conversion is at fault though.

From the compiler log, in what hull is the leak? 

i have the opposite problem. brushes that don't appear in the editor appear in the map!
:P 

Turn off editor hiding of func_wall brushes! 

they're normal brushes. :P 

it's some kind of bug in gtkr that makes the editor not load up a brush if it's 'broke' but the bsp compiler must fix the broken brush as it compiles the map. 

You've probably tried all sorts of things to fix it, so pardon me if this is redundant, but have you tried checking it with MapSpy? It's a really great tool that's useful in tracking down bad brushes in any Q-engine based game. 

the problem isn't a large one and only shows up once in a long while, but the next time it does, i'll try it out. it's certainly more efficient than going through the .map file and removing the offending brush. 

if radiant doesn't load it, why don't you copy and paste all your brushes into a fresh .map? 

The leak occurs in hull 0 (i think) That is to say "processing hull 1" comes after the leak warning.

Ill try 2.01. 

guess it was the conversions fault. 

how would that fix anything at all? O_o