 |
My conclusion (2) above is wrong: it seems all routes to turning off an entity light call both tdm_light_holder::LightsOff() and idLight::Off() at some point, because the different routes call one another. response_extinguish() joins the party too with calls to both, Off() via idLight::fadeOutLight. So this could be fixed in the game code OR the script object. grayman has been here before and has ensured that On()/Off() always get called at some point by all the methods. If we do this in the script object, we'll want to add a script event idLight::Event_GetShader() to match idLight::Event_SetShader(), so that entity lights that change their blendlight during runtime are supported too. NB there are ways to turn combined entity lights off without LightsOff() being called, if (1) it's a def-attached light as opposed to an idLight with a model (flames, basically) and (2) the spawned light entity is addressed directly. But it's hard to imagine a developer doing (2), going to some trouble to deliberately bypass the light holder, while still expecting the associated shadow light to turn off. |
 |
Regarding (1): There is a script function setShader which allows to change the light texture of a light, but no method getShader. I suggest adding it. |
|
|
Yes, I noticed the missing getShader. We decided to fix this issue in the game code instead in the forum discussion linked below, but I'll raise a separate tracker for getShader(). Easy to implement, and setShader() is not really useful without it. http://forums.thedarkmod.com/topic/16351-shadow-lights-on-combined-entity-lights/ Patch for the shadowlight issue is ready, which I'll commit once the svn trunk settles down. |
|
|
committed rev 6051 |
- Anonymous
