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? 

on the light util, i haven't had the chance to try it yet as i haven't been mapping these past couple of days, when my map has finished vising (8 more hours, whee!) i'll try it out.

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.

huh? the thing with those entities is that the style key was set manually by me in the editor instead of letting the light util do it.

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

honestly, i have no idea... it's probably a bug... i never made much use of the lightfade ent even though i thought it was really cool at the time... :P the only ones i remember working (and remember putting in) are in the long hall way at the start where the brown shamblers come out, and in the small bloody room where you get ambushed by 3~4 or so fiends.

ok, and here's my guess on how the switchable lights work...

you put the ent in with the flag set with only the targetname and a trigger to activate it...
light comes along, calculates the area of effect of the ent, assigns it a style key and goes away.
in the game, depending on what flags were set, the qc then decides what intensity letter (from a (darkest) to m(brightest) (past m is overbright i think)) to assign to the switchable light.
when the light gets trig'd, qc changes the style of the light to a different letter, the lightstyle command tells the engine to upload new data to that particular style.

yeah. i still don't know if i'm just repeating stuff you know already or not,... i thought it was worth saying.

lates 

entities still work because you manually put their style keys into the entity section and they don't conflict with other switchable lights.

Since you assigned them styles 63-64, the risk of interference is minimal. Light will not remove any style keys but may reassign them as required.

You only have 2 "normal" switchable lights, those I mentioned above. The spot over the GL should turn off when grabbing the weapon but it doesn't in the original.

The one triggered by the silver key is more strange. A light is supposed to appear in one corner of the big dragon arena when you grab the key down the river (far away). I can't see how anyone would notice that.

And the lightfade ent I checked was actually the one just before the "brownies" appeared and it works in both versions.

Your description of switchables seems basically correct, metlslime described something similar. I can't comment on the details though.

Thanks for the ne_sp06 tip. This new Light feature is a bit hard to test. 

hm, last times when i have enormously sized leak (forgot to insert a brush) qbsp reports the leak, creates pts but when i start the map everything is gray. but i still heard the sounds etc. only compiling with -hull 1 option helped me to see the map and find the huge sized leak. is that normal? looks like huge leak confuses qbsp :) 

did that happen in fitzquake? i had a similar problem with a map of mine where all i could see was the void (either HOM or grey if gl_clear 1), but i could still move, shoot and hear things like monsters waking up and doors moving... 

yeah, it's fitzquake and yes, it was gl_clear 1 

sometimes and I'm not sure exactly why. I have a theory that it's related to the hull filling (FillOutside).

Did you perhaps use the -noents option when it happened? I had to insert some dubious code to prevent some other bad behaviour when using that option with a leaky map.

You know the No entitities in empty space ... message, I had to shortcircuit that test when using the noents option.

My guess is that if hull 0 leaks and qbsp can't make out what's inside or outside, then the filling will run amok and remove the whole hull. The other hulls can very well be OK so you can walk around but you can't see the actual hull 0 (entities should be fine, though).

If you're using the noents option, try removing it next time it happens. If not, I don't really know ... 

i don't think it's a compiler problem.

that problem only happens in fitzquake. when i had that problem, i went into tyr-glquake and i could see the map fine.

also, when i sealed it off, the problem went away in fitzquake.
metlslime and i were trying to track down the problem but it never got very far. i found just keeping the map sealed kept me out of trouble. the map didn't even have to be vised. (also, at this point, unvised, the max wpoly is around 13000 and fq still handles that) 

i didn't use -noets option.
but i've got one idea, that leak was under the water completely, maybe this is the reason of the weird qbsp behaviour? 

It wasn't "previously used", that's why it is amusing. ;) I can't think of any maps where you need to swim through lava except e1m8 and rrsp1. 

I don't think that liquid would change anything but you could try adding the option -solid which will remove all liquid brushes and see if anything changes.

What about TyrQuake, same or different behaviour? TyrQuake is so far the most robust engine I've seen so it's very good with leaky, troublesome maps. But FQ is IMO the obvious choice for actual playing. 

Update on the crashing map: I loaded the map file into QuArK, fixed a broken brush that probably occured in the conversion process and then rebuilt.

Suddenly, the map doesn't crash anymore in FQ, not even without fastvis! There are packet overflow aplenty and entities disappear now and then but it doesn't crash.

Hmm, this is weird ...