light_torch_small_walltorch ()

[Cobalt]

In my mod, I am randomly giving these torches health so they can be shot off the walls, and also they will inflict damage when a takedamage ent contacts them. Using DP I was able to give them an orange modelflag that enhances their light a bit....though I am finding that modelflag seems to be angle or PVS dependent. Not much a problem, but I noticed some of these, depending on the map are having a lightstyyle assigned via the map ents using .style and .light to make them flicker, usually the ones placed in enclosed roomas /caves. So if I shoot a torch, it falls the ground, does a flameout using the explosion sprite, then remove (self). Works ok, except the light still stays up where the torch was. Not really a HUGE issue per say, but I thought maybe during the th_pain frame or the kill frame, I could flicker that light and remove it, however it does not seem to be possible. If I alter .style nothing happens, and I cant assign .light during the "quaked" loading of the map ent in the torches spawn , even with a new declaration, there already is a light () function, which gives a compile conflict error. Is any of this possible another way? I guess the map has to be recompiled or "relighted" ? Once the lightmap is done, there is no altering it ??

[mankrip]

The lightstyles defines how the map's lightmap should be animated. Once the map is compiled, those lights don't belong to the torches anymore, they belong to the map's lightmap.

I don't understand much about light interaction in Quake, but you can probably take some clues from how the light switches at the end of E1M1 works. Only in your case, instead of turning the lights on, you're going to switch them off.

[Cobalt]

[ceriux]

i'm not sure if you can do this with premade maps. the lights are kind of baked into the map on compile. i think you would have to set it up on a custom map with your changes already compiled into the map. an ON flag and an OFF flag. i'm not sure but you might be able to do it with dynamic lights. but then it would be broken if someone wanted to play your mod on lower settings.

[Spike]

angle -> angles_y
light -> light_lev

the two special cases of entity parsing.

a light with a targetname will be assigned a .style value by the light util, which will then write back to the entity lump or something. lights with the same targetname will have the same .style field, and thus will all switch on/off at once.

non-switched lights will just use whatever .style value the mapper assigned. this means that if you try switching one of those off, *ALL* will switch off.
the lightstyle builtin affects all lights with that style. that's just the way it works. any other way would limit you to only 255 lights per map, and that's simply not viable (its also more expensive, as you'd need to mix more lightmaps, and there's a max of 4 styles per surface, would be far far worse if it was 4 lights per surface).

you can add realtime lights instead of static ones, and directly control each one (instead of relying on .style only). however, this can decimate your framerate.

[Cobalt]

Good info , thanks to all.

Did some more checks, looks like the torches (not the flames) use either style 1 or 6 so far checking the start and e2m2 maps. ID coded the maps very consistently, so I will assume the rest of their levels that have torches that they want flickering use the same lightstyle.

Unfortunately, removing the "style" or "light" reference in the torches that have these fields does nothing.....so I guess those are "baked" into the lightmap via the light util, and the engine does not override....even with an engine named: Darkplaces .....

So I changed lightstyle 1 & 6 to "a" (total darkness) for now, and made 2 new lighstyles with those same strings to possibly support reassigning to the torches using the TENEBRAE_GFX_DLIGHTS extension later in my experiments.

Maybe I will wind up recompiling the maps later if I see a conflict , but for now at least when a walltorch is shot, the flickering light behind it is no longer there.

Another idea along the same lines are the fluorescents on the base style maps, but those definately mean recompiling the map, placing I guess a trigger field on the surfaces of the textures that when killed no longer emit the light. I also suppose the textures would be better removed, and func_walls put in to replicate those textures, and have damage skins.

Similar idea for the stained Glass windows on some levels....except for Elder God Shrine and I think one other where they made the windows func_wall ents. With DP you can now assign them a health and other effects that will show up when tye are broken, and also a alpha level for transparency....

[frag.machine]