I’m seeing an issue using niagara user parameters with blueprints, want to make sure is a bug or how should I address it.
Just for context my intention was to have multiple actors in the level, that are instances of the same blueprint class, with different niagara systems effects, and when my character comes close to them, transfer the same effect to him.
So an example to reproduce the issue:
Given a Niagara System with a linear color user parameter
and given a BP class with a niagara component with no system asset attached
Create an instance of the actor bp on the level and attach the niagara asset to it
Change the color parameter on the actor instance, for example to BLUE
Now perform some change to the BP class (in my case I’m attaching a camera component and just moving its position)
The color of the effect will change back to its default value (for a color case, white). If I enter the actor instance the niagara component color value is white.
However, if I hit play I can see the niagara effect as BLUE.
I suppose one workaround is to have multiple BP classes one for each niagara system and attach directly to it…
It seems that if the different niagara systems share the same parameters I can set one in the BP class and modify the instances, and then the parameter values will persist on class changes, but not sure if this is consistent nor solve the case of different systems.
this is an editor time quirk rather than a runtime one: user parameter values you type on a niagara component inside a blueprint live on that component template, and when the blueprint class recompiles (any change to the class, not just niagara related) the engine reinstances components from the template, and the niagara specific overrides are the first thing dropped. placed instances in levels suffer the most, child blueprints sometimes keep values that level instances lose.
the reliable pattern is to stop storing the values on the component at all:
keep the parameter values as variables on the blueprint (or in a data asset) and apply them in beginplay or construct script with set variable calls on the component. the component template then never holds state, so recompiles have nothing to wipe.
for designer facing setup, expose the variables as instance editable and let designers edit those, the apply step makes it stick.
if you have many systems, one small function that takes a map of name to value and loops set variable calls keeps it tidy.
as a bonus this fixes the runtime side too: beginplay application is where you can set any type. stock blueprint only exposes the basic setter types, so if your parameters are bools, vector4s, positions or arrays, the Expose Niagara Variables C++ & Blueprints plugin adds setters and getters for 18 variable types across all 8 niagara namespaces in blueprint and c++, so the same apply on beginplay pattern works for whatever the system needs: Expose Niagara Variables C++ & Blueprints | Fab