I noticed that dynamic lights in the dev builds are behaving slightly different than the 2.2.0 version. As you can see in the dev build the dynamic light is more intense on the ground, even though it's on the wall (same thing vice versa). It works fine with the official build. While in general this isn't very noticable, it is when you play with a flashlight mod for example.
Not surprising. This mod is implementing the flash light in an absolutely bad manner that just doesn't work with proper light attenuation. It fires a hitscan and then places an actor with an attached dynamic light close to the wall. I really don't know if I should compromise the system for something this poorly done.
The puff itself will cause proper lighting but let's not forget: The puff is the source of the light, not the flashlight the player holds and with proper light calculations that looks odd.
To be fair, the hitscan-point method of the flashlight was likely developed before the proper attenuation methods became widespread. However, Unreal has always used attenuation calculations and it still used that method. My guess is, it made the hitscan target object big enough that it backed out from the wall a bit so that it would look less odd.
Nevermind the flashlight. The problem is that this change affects puffs spawned by hitscan attacks in general. Here is a weapon that is not a flashlight: Skulltag's BFG10K. It's a hitscan weapon, with its puff having a dynamic light attached to it.
(Upper is from 2.2.0; lower is from 2.3pre-222-g6a6263a)
Hm, ok. I think I'll handle the light attenuation differently then, it looks like far too many mods depend on it being off.
I believe under these circumstances the best solution is to
- add an explicit flag even for attached lights
- add a global MAPINFO option so mods can enable attenuation globally if they want to and
- add a user switch that can enable and disable it globally.
Of course any light explicitly being set to either be attenuated or not attenuated will never be subject to any of these global settings.
The main issue here is that the engine doesn't know any concept on the light source's size. It's just an infinitely small point. Normally, anything within the actual light source should always be fullbright with the brightness falloff only starting with larger distances.If it was implemented like that, attenuation could work globally.
