Provided aguirRe doesn't mind? 

Okay, well i did a lot of testing and code diving, and i found out exactly what the bug is, and what is causing it.

The bug occurs any time a clip brush in a bmodel extends past the bounding box of the visible portion of the model in any of the six axial directions (north, south, east, west, up, down.) If this happens, you can pass through the part(s) of the clip brush(es) that extend. The reason for this is that physics code uses the bounding box of the visible model (hull0) for culling -- if the player is outside of that box, quake doesn't bother doing collision calculations (which would use hull1) for it.

I haven't quite decided the best way to fix this in code. I also am not sure if the fix should be engine-side or compiler-side. However, if you are a mapper and encounter this problem, the solution/workaround you should use is to add extra visible brushes to the bmodel to extend the bbox as far in each axial direction as any of the clip brushes extend. 

I'll email you a small map+wad so you can see the HOM effect. This problem isn't very likely to happen, but it's quite an interesting effect. If anyone had showed me that symptom before and asked me why it happened, I doubt I would've found the cause.

Mike: Of course I don't mind, just pass it along to who ever that might find it useful. 

My map likes to crash. At first I thought it happened because of edicts, but it crashes even in deathmatch mode (with no monsters). I'm completely disappointed.

But it still runs fine in Tyr-quake (software), but crashes in glquake, winquake and telejano. At least I tested it only in these four engines.

aguirRe, can I bother you once again and e-mail it to you?

btw my comp has been down for two weeks, I wanted to ask it before, but couldn't 

Sure, just send me the zipped map+wad (no bsps please, I'll rebuild it myself). 

that's the same map, you already have that wad. 

i'm not sure if this is usefull or not, but:

in nesp06, i made a little fading light thing... for that i would manually assign one of the 'style' that are highup which is usually reserved for the light util... then, to change the style, all you do is change the intensity via (in qc):
lightstyle(#of style, " *letter of intensity* ");

the way normal light works is the compiler assigns a "style" to the light then the qc code does:
lightstyle(self.style, " *letter of intensity, so m for on and a for off and swaps between the two when triggered* ");

um... i don't know if that's helpful at all, or even what you were looking for... i'm tired. :P 

the style is global, no matter what lights are targeted, if the style is being changed, all lights with that style are being changed... 

I'll have to check more tomorrow, but first impression is that I think it's entity related. After a normal build (no vis/light) it crashes FQ 0.75 immediately, TyrQuake can handle it but with entity flicker.

After a fast vis it still crashes FQ after a few rooms as you said.

After adding compiler options -solid -noents, FQ seems to be fine even without any vis. Therefore it appears entity related (noents removes all entities except world and players). I'm not so good at tracking down entity problems though.

Metl: FQ crashes at 0x41aac5 (access violation) every time, can you see in the FQ map file where that is? 

what are you trying to accomplish, aguire? i seem to have forgotten... 

necros: he's busy unraveling the secrets of the cosmos. let the man work. 

Therefore it appears entity related

Hmmm that's bad, it seems like it's not simply edicts overload. 

Hello,
I would like to place a invicibily artefact above a well (to force the player to catch it and then falling down into the hole...) but, while testing the map, the artefact seems to "slip" down to the weel ground (gravity effect ???)
Is it possible to preserve the artefact position without this fucking "gravity" effect ??
Thanks 

...there's probably a tute somewhere, but basically:
1. Fill the well with a func_wall
2. Give the func_wall a name
3. Place a trigger_once at the player_start
4. Have the trigger "kill target" the func_wall by name
5. Place the PP on the func_wall

The effect is that the player arrives in the level, causes the trigger to function thus removing the func_wall but leaving the PP floating.

PS: that must be one very big well if the player can't jump over it? 

No, the well is not really big, the basic idea is that if player doesn't take the invicibility artefact, he die into lava at the ouput of the well... sorry for him...
Perhaps placing the artefact lower into the well will be more efficient to avoid "little sly" to take the item without falling down into the well... hmmm I think it will be better like this...
Thanks for the advice...
Bye.. 

sorry for him...

hehe, why am I not convinced =) 

... because you didn't try swimming into lava... it cannot be done without pain... don't you know ?? 

...just a language thing. 

I didn't understood the language subtelty... English is not my native language... sorry... 

Is this the same map you've been working on for a while now? I'm looking forward to see what you come up with. Good Luck 

Yes, that's the same map (my first one...)... I decided to restart from scratch after very interesting discussions and advices with aguirRe. He point up some major problems/errors that causes undetected leaks in the map (like off-frid brushes, unaligned textures, etc.. not reported during compilation...some beginner big scrappy and awfull errors in fact...) These ones were also very difficult to detect if not corrected early... Furthermore, he gave me some good basic advices about how to build a "good" map (with his point of view...), thanks aguirRe ;-)).
As I told him, an external point of view about my work was very usefull, and very encouraging, even he point up my mistakes... What does not kill you, make you stronger... no ???
So I hope now to map in a better way now...
To give you a quick status, I rebuilt 80% of the expected map... I'll post a message when it will be finally released...
Bye 

I'm trying to understand how the switchable lights are supposed to work as they're a collaboration of Light and the engine.

I've noticed several inconsistencies in the logic that sometimes generates confusing results and I'd like to fix this.

While checking many existing bsps, it seems like mappers have had problems with this functionality before.

You also noticed that a qbsp -onlyents run has always disabled the switchable lights and that is also something I'd like to fix.

Btw, did my attempt to fix the problem work for you? 

that I already gave up on that grey/blue perssp3 map since it involved the exact same scenario JPL is describing. :) Good luck man. 

Sorry to copy the idea, but I didn't know it was previously used... grrrrr.... 

I've now compared the original ne_sp06 bsp with one that I've run through my new light -onlyents feature.

The QC coded new lightfade entities still seem to work as the original but now the source entities actually get their correct style set which they didn't originally.

There are also two switchable lights (targetnames monspawn7 and necros1, GL and silver key) that now works, whereas they don't in the original.

I don't know if you manually disabled them (by invalidating their style) or if they got accidentally disabled by doing a qbsp onlyents run but maybe you can clear that up?