On a thread in the I&S forums, Jinx mentioned an idea, and I thought it out from an actual mapper's perspective. Basically, a map where the light level raises and lowers depending on the RTs capped.

Im thinking, you can do it even just with mapping techniques, but to stay within a decent runtime entity number, you'd have to really go easy on the railings, alien infestation, all those things that add detail. Plus, your lightdata would likely be fairly high, and you'd defintely have to play with dynamic lighting turned off (the actual lights turning on and off look a bit faker, because they don't bounce like normal lighting).

But i'm taking to the idea already. This could turn out pretty awesome. Think about a basic but solid layout, metal, veil, lucid, tanith... where every room was fairly simple but effective gameplay architecture, and each room also had four different light settings, 1-2-3-4, plus minimal, scary-as-hell texture lighting (some places maybe more... but these would be the transition rooms, the hallways).

I wrote out how you could do this with a math_counter (or non-Source equivalent) just now, but then deleted it after because i realized a much easier way to do it. When any of the four nodes closest to MS are built, each one, on its 'spawn on build' field, trigger its one specific lightbulb in every room. And then turn off when its destroyed. You could even mark the four 'lightnodes' specially on the minimap with a little border. Perhaps even have them the lights 'walk' toward the hive, so the first two nodes have better lighting than the next. Imagine playing Veil like this, where a skulk running past the marine offensive and killing both Topo and West puts the rest of the map into added darkness? I dont think a mapper can differentiate between what team the node is for (though in Source you definitely can), so aliens building the node would have to trigger it too. Ninja's would become real ninjas.. though they would still light-up like a neon marine to the aliens. Damned if it wouldnt help alleviate the Cargo-rushing-marine-on-veil Syndome. Reloc's would be interesting. And Electrification Strat would get a... strange boost.

Lighting can create some fun atmospheres, and I tried to do a bit of that in some rooms in my map Nexus. Specifically one where the huge dome on the floor, with the rt in the middle, pulsates slowly, and the room around follows suit. Though the some in the competitive community would s*** themselves over this, this map brightening/darkening concept could really create a new, and very unique, experience.

Remember too that the mapper's artistic touch would matter enormously in terms of getting the lighting levels to an appropriate, balanced level.

Looks like my next map, tentatively called ns_stage, will have to be the guinea pig

I'd love to see if you could achieve that. Would be a great idea for... ns 2 or ns on the doom 3 engine. It's probably worth knocking up a model set of corridors to check it all works first, but yeah go for it.

What would hold it back though, even on HL1? Have four nodes that each trigger and untrigger 4 sets of lights, in say 8 affected rooms. Thats only an extra 32 entities, and lightdata. Heck, people could even recompile current maps with this gameplay facet in them.

You'll hit some "too many lightstyles on a face" and the associated blobs of black that result from it if you aren't careful. Some advice, based on my experience with the dynamic lighting in moira:

bounce 1. I used bounce 2 in moira... looks great I think, since I use a lot of reflected light, but mixed with dynamic lighting it's hell. My lightdata is up near 80%. Rad takes forever. And this is all in a measley combat map.

Do not you -nodynbounce. Looks like crap. You make it look good, and you sir are a genius. But honestly, it's simply too harsh for the high contrast of an NS map. (I tried this just to see how moira would look. Light data was down to like 30-40% or something.) To think... before zoners tools, this is what hl maps had to use...

Also note, testing becomes very time consuming. Unlike geometry and entity changes, you need to do a full compile every time to figure it out, and given how much long this makes rad run, you better have good hardware to compile it on.

Good luck, hope it works well though!

hmm he could just run recompile with just rad after a first successful compile. saving time on csg/bsp/vis, baring in mind he doesn't change any of the geometry. But then again Rad does take a long time using dynamic lights and nodynbounce is indeed not an option with lots of them...

Yeah, so long as you aren't adding or subtracting entities, you can just run rad... likely a good idea with an ns-sized map. A co map will run through csg, bsp and vis in such a relatively small time compared to rad I found that I may as well compile the whole works!

BigD:

The reason i capped the 'level of lighting' at 4, is because thats the max number of lightstyles you can have on a face. Ive never had issues with Dynamic Bounce being off, especially through well placed point lights (spotlights are tricker to have looking decent with nodynbounce). As such, each room could easily have 4 dynamic lights apiece, with no (foreseable) repercussions. And you can raise the lightdata amount to pretty high and maintain stability, though i think you'd still only need an extra meg or two.

And about compiling... ive said this a hundred times already it seems. Do you mappers not use Cordon Bounds?! When you're not checking for leaks, this tool is amazing! just section off the map and compile. Compiling a single, fully built room only takes like 2-15 mins, depending on complexity (im taking this from Nexus, which has some complex rooms ).

Now see, here's something I definately need to learn a bit more about. I've just got to thinking, what exactly constitutes a light style? I need to go google up some more info on this because I just realized that I think I've been doing it wrong all this time. Somewhere early on, I was told that so long as the colour, brightness, and appearance was the same between lights, you could have as many as you want shining on a face.

But, now that I think about it, if they all switch on at different times, that makes them different too, as the face that is lit up is incrementally different with each light. This is where I've run into problems with the blotchiness and the like. Plus, I didn't take into account the original static light that was there already (making lightface 1 I assume). Each of my switchable"lights" is made up of a switchable texture light on a func_wall prop and a light spot. Looks good but is that giving me two lightstyles right there?

Also cordon: I recently started to use it while creating new areas... I found it to compile the "outside" though so never bothered trying it on the larger chunks of my maps. I assumed "that's the way it works" and never gave it much thought otherwise.

Sorry, i think we were both misusing the word 'lightstyles'. I dont even know about that error, and have never seen it, even with the dozens of types of lights ive had in Nexus.

I meant the 'too many dynamic lights' or whatever error. You can only have 4 dynamic lights touch any one face, so cap the dynamic lights in any one area at 4, and turn off bounce. Works like a charm.