Thanks! 

 

It seems like when _surface_spotlight is set in the entity the actual surface no longer illuminates as it would without. Is there a work around or is this a bug? 

To get a regular surface light in addition to the spotlight, just have two template entities, one with and one without _surface_spotlight set. You can have multiple lights with the same _surface value :) 

Thanks that will work - and it totally makes sense. 

I think dirtmapping should not be applied in points where there's a light close by, 16 or 32 units maybe. The low resolution of the lightmaps makes small surfaces in cramped places close to a light go fully dark. 

Hehe, I was thinking something similar, but it needs to be controllable per light.

Remember you can work around all the issues currently by using _nodirt on a per-light basis. However, that requires more light ents to be added, which may get fiddly and annoying as the map scales up.

A way of doing what you are saying would be to introduce a _nodirt_radius key on a light, which means the light gets "dirty" as normal except on surfaces within (_nodirt_radius) from the light.

the transition between nodirt and dirt needs to be blended in as well to avoid ugly transitions. Ugh, maybe another key is needed to define when the blend starts :/ 

� but _dirt -1 did! \o/ 

sorry I forget the names of the keys, I think they have changed once or twice as the feature developed 

No problem; I'm still using my custom version from when I implemented lit water support. 

change list & downloads:
https://github.com/ericwa/tyrutils-ericw/releases

Mostly bugfixes, except there is a new _sunlight3 that comes from the bottom hemisphere, instead of the top (_sunlight2).
This is mostly for maps floating in the clouds, where you want skybox under the map that emits light. Combine both sunlight 2+3 for light coming from all directions, and use two different colors for crazy effects.

Also, the -parse_escape_sequences option for light is a gimmick that lets you make red text in door/trigger messages, which previously you could only do with custom QC. 

added the _sunlight3 stuff to worldspawn

https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd 

I'd like to see a little demonstration of the new _sunlight3. 

I added to my privately hacked tyrlite branch a "domelight" (this was pre-sunlight2), with control over color and intensity coming from straight up, the horizon, and straight down, blending between them (even though I'm not really working on a map that would take advantage of that.)

There's enough ways to light a world from the sky that moving stuff like this from infinitely numbered worldspawn keyvalues to a light_sun entity would be prudent, except for the "no spawn func" errors it would produce. Does stripping an entity from the bsp seem dangerous or counter to some method of production? How often do people really re-light a BSP without re-BSPing it first? 

info_null is ignored by the game engine, so you could have an info_null full of sun properties.

But is it really better than just putting it on the worldspawn? 

and flag it with a special key (eg _sun: 1) to tell light.exe that this is just your holder for the sun properties and not a normal light

classname: light
_sun: 1
_some_cool_sun_property: 21.463

I have spent maybe 2 seconds thinking about this, so there may be a better way. 

is it really better than just putting it on the worldspawn?

Just feels cleaner to keep the sun properties encapsulated in a single dedicated entity that you can copy 'n' paste between maps easily.

Also, getting a bit carried away with this...but with a sun as its own entity - you could support multiple suns by having multiple entities. 

To make setting the sun angle easy you could just target your sunlight entity towards an info_null, to implicitly specify the direction of the light (the setup would look like a cute little solar system) 

Multiple sun entities instead of _sunlight2, _sunlight3, etc? 

Cool, blending the colors/intensity was something I wanted to try and will probably test out. control for the horizon is a good idea too.

If I'm going to add a new, tidier way to specify sun settings, I would be tempted to do it properly and make new entity types (light_dome for _sunlight2/3, light_sun for regular sunlight), and then strip them out when writing the bsp. Even the way surface lights are currently specified is sort of a hack, it should be a "light_surface_template" classname or something.

If anything is being stripped when light writes the entities to the bsp, it might make sense to make the light tool read entities from the .map file rather than the bsp, this would avoid a failure in case you ran "light" twice in a row. It would also mean you can skip the "qbsp -onlyents" when iterating on lighting settings, which could save a few seconds. 

with a sun as its own entity - you could support multiple suns by having multiple entities.

This is what I was thinking. Although, as someone with experience lighting a map with a fuckload of suns, beyond a very limited point (like two or three, which we have now) the line between imperceptibly subtle and clownishly gaudy seems to get pretty narrow. 

i'd like to have the ability to map lightstyles to sunlights... then you could have 4 'suns' that are always off, and flicker them randomly via QC. 

Yes! For thunder & lightning effects! 

that would be sweet. I think it's easy to do in terms of the lighting code, the only challenge is how to expose it to QC. That's probably another argument for using entities for sunlight, it could work the same as ordinary lights; if the mapper sets "targetname" on the sunlight entity, the compiler assigns it a lightstyle. 

I tried lightning tied to a skybox change a while ago, but every engine's got its own console command for the skybox and they're not consistent :/

You'd hit that 'max lightstyles for a face' limit quick though.