Short version:
Is there a way to share user parameter definitions between Niagara systems, modules and scripts?
Long version:
Let’s say I want to create a bunch of Niagara systems for bullet impact effects on different surface materials. I want to set common user parameters such as the bullet velocity and impact angle from code, so that the systems can dynamically adjust their behavior. I want to be able to access these variables in the systems themselves as well as custom modules and scripts. So it would basically work like a Niagara parameter collection, but on a per instance basis.
The closest I have gotten to this was to use a Niagara parameter definitions asset. It works well in the sense that I can access its parameters on systems, modules and scripts. The problem is that I still have to define identical user parameters on each system and overwrite the definition parameters in the system update step.
Unfortunatelly the Niagara documentation is pretty lackluster and it’s hard to find good information about Niagara parameters online. So any help would be highly appreciated.
short answer: the engine gained the real mechanism for this in 5.3, niagara parameter definitions. you create a definition once (name plus type, project wide), and then any system, module or script can add a parameter of that definition. renames and type changes propagate everywhere the definition is used, which is exactly the bullet impact across many surfaces scenario: define ImpactSpeed, ImpactNormal, SurfaceType once and every impact system references the same definitions instead of each hand typing them.
things to know with that route:
the parameter still has to be declared in each asset (added from the definition), it is not injected at runtime. so existing systems need the pass where you add them, new ones get it in two clicks.
for pre 5.3 or for keeping asset variants consistent, the old discipline still applies: keep one master impact system and duplicate per surface, and a naming doc, since nothing enforces consistency.
one more layer worth knowing: at runtime the setter side is also uneven in stock blueprint. set variable nodes exist for the user namespace and a subset of types only, so pushing the same parameter set into twenty impact systems from one function gets clunky. the Expose Niagara Variables C++ & Blueprints plugin exposes 18 variable types across all 8 niagara namespaces with getters, from blueprint and c++, which turns that into one generic function that writes impact params into any impact system: Expose Niagara Variables C++ & Blueprints | Fab