Blueprint - Set Attenuation Radius on Spotlight does nothing

I’m Spawning SpotLight actors into my map. Setting intensity works fine; setting attenuation radius (and outer cone angle) does nothing. Observing the Spotlight objects in the editor while playing reveals the radius is at the default 1000.

Here is how I am spawning and setting the spotlight variables:

And here is an example (they are all the same) of a spawned in SpotLight instance:

Any help is appreciated.

I have the same issue.

It seems that Set Attenuation Radius node only works on Point Light Component.

Does anyone confirm this?


Same issue here on 4.15

Hey everyone,

You’ll need to ensure that the Spot Light component is set to Movable in order to change its attenuation radius.

Hope that helps

I’m not sure of the exact issue of the person who posted this thread, and I can understand why the light needs to be set to movable because blueprints are dynamic, but in my case I’m using a blutility to spawn point lights into the scene, therefor they can be static since they are added to the scene before run-time, plus I can’t change the mobility in the settings of the light since it’s not an exposed variable.

Hey Night Watcher,

If you are spawning the Point Lights in a blutility, when are you attempting to set their attenuation radius? Would you mind providing a screenshot of your setup so I can take a closer look?

Set Intensity and Color works fine, the attenuation radius does not

So after spending some time looking into it and discussing with some other members of the team, it looks like this just isn’t intended workflow. What I’d recommend doing if you need Point Lights is to have them already in the level or attached to an actor, and then have them turned off by default. That way when you need them you can turn them on and adjust the parameters as needed.

Would that solution work in your specific case?

Not really, I’m building a script that generates a level using blutility, then it will place lights in the level which can easily reach hundreds of static lights. Placing them manually is not an option. Turning the lights into dynamic components is not a needed cost.

Unfortunately, the only way to edit the attenuation radius at runtime like you’re trying is to have those lights set as movable. Otherwise, you will not be able to edit it. I discussed this with other members of the team and we’ve come to the conclusion that this is currently working as intended.

I don’t want to edit the attenuation radius at runtime. The whole point of Bluetilities is to run in editor before run-time (with out hitting the play button). Therefor it’s working as intended if it was a blueprint, but not as intended since it’s a bluetility.

It is the same behavior in a blutility because you’re still attempting to access the value dynamically. The point light spawns with a default Attenuation Radius of 1000. Then, in your editor-callable event, if you try to set that Attenuation Radius it won’t work because the light is not set to movable. You’re still accessing that property and attempting to edit it without having the light set to movable, which by current design isn’t intended to work.

Let me know if I’m misunderstanding something, but from what you’re saying and from the screenshot you’ve shown I would not expect this behavior to work, whether at runtime or in-editor using a blutility, as the base functionality is the same in both cases if the light is not set to movable.

You’re not misunderstanding it. The thing is I’m guessing it was implemented this way on purpose because when it was made Bluetilities were not a thing, and therefor it would not make sense to change the light parameters unless it’s a dynamic light, since the engine cannot bake the light a run-time. But now with the introduction of blutilities the lights can be spawned before run time, and therefor they can be baked.
A workaround would be to spawn the light to the scene as movable, change the values, then select all and change to static. Though there is no way to change the mobility setting of a light in blueprint (unless I spawn it as a component), so doesn’t work :confused:

Anyway, Thank you for your time and the clarification :slight_smile:

I’m also hitting this issue. I’m doing some arch-viz stuff, and I need to be able to generate a couple hundred lights that I can tune from a master object. My blutility does a good job on just about everything I need, but for the ability to set cone size and attenuation radius.

I’ve tried a couple of different paths. For example, I know that I can modify these values regardless of object mobility from the light’s Constructor script, but I can’t seem to trigger the constructor on the lights to execute without moving the light directly, which doesn’t scale well over hundreds of lights. I can’t set the mobility of the light in script (which I guess makes sense), even in a Constructor (notably, the tool tip on “Get Mobility” says it’s only safe to set Mobility in a Constructor, but I still can’t figure out how to get blueprint access to it). And when I created a new Blueprint class based on the Spot Light Actor, the mobility of the inherited spotlight component cannot be edited within the blueprint editor. It can only be changed per instance, once the it has been placed in a map, which, again, doesn’t scale well over hundreds of lights.

What I’d really need, given the restrictions on changing these properties on non-Movable objects is the ability to either temporarily set mobility to Movable, make my changes, and then restore the Stationary state, or the ability to request a Constructor script run, even if only from another Constructor. Or just some other way to “promise” that this call isn’t happening at run time.

Here’s a Constructor of a child blueprint of Spot Light Actor that correctly updates these variables, regardless of the mobility of the light, at edit-time. BP_LightActor is my control object that holds tuning values for every light it knows about. I can get these tuning updates to happen if I open the spot light blueprint and manually hit the compile button, but it feels like this should be something that can be fully automated. Certainly, it’s not a workflow that the lighting designers I’m working with would feel confident about using.