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 ... 

interesting, but I've just sent you e-mail with my thoughts.

So is it a brush problem, not entity? 

it's likely to be a visibility issue; too much is visible from some angles and that probably includes both architecture and entities. The architecture (or rather, layout) is too interconnected, which looks nice but comes with a price tag.

If you perform a fastvis, it will printout the position in the map where the highest # leafs are visible. This is a place that you should check out with TyrQuake and the r_draworder cvar enabled.

I'll read your email and get back to you. 

send me the bsp, i'll check it out. 

The idea was to jump to catch the pentagrm, climb into a well, and fall into a lava "bath" to progress into the map... so without invicibility pentagram, you die immediatly..
Anyway, yesterday night I tested the method given by distrans (thanks distrans), and I had some problems to perform what he recommended me... (sorry distrans) but I solved the problem with another turnaround.. Perhaps I used some bad method (I'm a beginner in Quake mapping)...
Perhaps there exists a method to preserve item position with an additional field, in order to avoid "gravity" effects...
Bye 

http://www.cdrom.com/pub/idgames2/planetquake/quakelab/float.zip

This is the tute I mentioned for floating entities. 

http://www.fileplanet.com/dl.aspx?/planetquake/quakelab/float.zip 

...I lurv the VoreLord. 

Thanks for the URL.. but what about this file float.zip ?? 

I think all the Quake Lab Links, at least the cdrom ones would be dead.
Just change the URL by adding

fileplanet.com/dl.aspx?

to the front of the file path, eg

http://www.cdrom.com/pub/idgames2/planetquake/quakelab/float.zip

would become

http://www.fileplanet.com/dl.aspx?/planetquake/quakelab/float.zip

same thing as what you do with alot of the other broken PQ links