I am working on an editor utility widget that automates the process of creating Niagara Systems. I am using the “Create Asset” node to create the Niagara System assets. From there, I have JSON files that contain data for each system (spawn rate, color, etc) that I want to set after creating the system.
Typically when setting property values for assets, I would use the Set Editor Property node. However, I am finding that this method does not seem to work for User Parameters in Niagara Systems. Keep in mind that I am not trying to change the value for an instance of the system in my level, but instead the default value for the property in the Niagara System itself.
Any help on this topic would be greatly appreciated.
set editor property struggles on niagara systems because the values you want are not uproperties on the system asset; they live in emitter/module data the editor exposes through its own interfaces. what works from an editor utility:
user parameters instead of raw module values: if the JSON drives spawn rate, color, size and so on, make those user parameters on the systems. then your EUW does not need editor property walking at all: set the user parameter default on the system asset through the niagara editor library surface (python exposes asset-level parameter access directly; blueprint gets a subset through the editor utility palette). this is the maintainable route, module graphs stay untouched.
property walk route when you must touch modules: get the emitter handles off the system asset, then per emitter get the emitter data, then find the module script by name and set its property. this is what the niagara editor library python API does; from blueprint the surface is thinner, so for arbitrary module values python inside the EUW (execute python command) is often less fighting than blueprint reflection.
editor-only lifetime: all of this is editor time, the cooked game never sees it; the values you set must end up baked into the asset (save the asset after modification) or in user parameter defaults read at runtime.
hybrid recommendation: treat your JSON as the source of truth for user parameter defaults. EUW creates the system, applies the parameter defaults, saves the asset. at runtime everything reads user params, and if the runtime also needs live overrides, user parameters are settable from blueprint per component anyway (with the standard namespace caveat, or a plugin that lifts it).