ZDoom

Users should NOT inherit internal dynamic lights. And GLDEFS spotlights don't use any actor properties.

Problem with that is, an actor can also be a spotlight, and that would reduce the usability of the colour field because it would be tied to both the actor's stencil colour if used as well as its light colour, and you may not want those two linked.

Okay coming up with better ideas then, since it is UDMF exclusive, Spotlights can pick their colors from the Color field of the Rendering properties instead of having a separate field as an argument, then that argument which is actually the color field can be the flicker/pulse light periods.

Obviously, but that's GenericLight talk elsewhere. And this is to make the existing stuff work.

While that'd probably work, it seems like yet another hack that doesn't really fix the root of the problem (fields being completely misappropriated) and instead just sidesteps it. It'd also completely break as a solution if GZDoom decides to implement something like light cookies on dynamic lights later on down the line - which I know has been mentioned before (though I'm certainly not expecting it to become a reality soon or anything) - since in that case, roll does matter as it affects the cookie's rotation. The real solution is to come up with something better and more robust so this never has to be dealt with again. The original cause of the angle hack would have been the exact same reasoning - "dynamic lights will never need to use angle for anything".

Would work. Spotlights are UDMF-exclusive anyway.

Gutawer wrote:I've just noticed a fairly major issue with pulse and flicker spotlights. Pulsing/flickering lights use angles for pulse period, and spot lights use angle for, well, light angle. That means that you can't have a pulsing/flickering spot light with controllable angle and period, making them fairly useless in my eyes. No idea how that could be fixed, though - goddamn old ZDoom hacks!

Swap the propery of using Angle with Roll instead? Roll has really no use for actors such as Dynamic Lights even for Spot Lights.

I've just noticed a fairly major issue with pulse and flicker spotlights. Pulsing/flickering lights use angles for pulse period, and spot lights use angle for, well, light angle. That means that you can't have a pulsing/flickering spot light with controllable angle and period, making them fairly useless in my eyes. No idea how that could be fixed, though - goddamn old ZDoom hacks!

EDIT: Oh, and also, looks like I defined DoomEdNum 9854 wrong when adding the actors - it's SpotLightFlickerRandomSubtractive when it should be SpotLightFlickerRandomAdditive.

If only UDMF user variables weren't all just assumed to be integers when parsed, and strings could be passed in from the editor...

It's still a stand-in for the regular args, not some arbitrary parameter that is free for use.

Graf Zahl wrote:Alternatively you can set arg0str to a color name

Where did this thread go where you called it a gross hack to use arg0str for anything else than script name for ACS specials?

Internally they are the same class as the regular lights so their variables need to be the same, too.

Yeah, it's a bit strange but to be perfectly honest I prefer it this way. Makes editing dynamic lights more consistent in ZScript, and also keeps the SpotInnerAngle and SpotOuterAngle variables in tact which have a nicer name than the alternatives (args[1] and args[2]).

Thanks to both of you! I feel kind of dumb now - I wasn't including args[3] (intensity value).

This also confused me in part of my testing:

Graf Zahl wrote:Args[0] is the full RGB color, Args[1] is the inner and Args[2] is the outer angle.

Alternatively you can set arg0str to a color name, this will also work for regular lights.

This seems to only work this way from within the editor. If you want to manipulate the values directly in an actor via ZScript, Args 0/1/2 are still RGB, just like in other normal dynamic lights, and the inner/outer angle must be set via their respective properties.

https://www.dropbox.com/s/eowuj25tztvc3 ... p.wad?dl=0 <- There's a working set of spotlights placed inside a map.