Im generating a location even from spawned particles that i want to attach other emitters onto. For some reason its spawning a trail of meshes/sprites. Anyone know a fix?
Also are there better ways to approach this? I want to make an effect that resembles a minigun, shooting knives.
I haven’t used Event Handler for quite some time already, but if your goal is to synchronize multiple emitters with the same/similar behavior, the best practice is to only use one single emitter with multiple Renderers. If specific renderer requires different behavior (e.g. color), “Set” a new parameter and change the respective parameter binding in the renderer.
I need to use multiple dynamic parameters, so i think it would conflict if it were all in one. Good point about setting parameters to the respective renderer though. Maybe it would be better to spawn them with a blueprint and interpolate position?
No. Abeit possible, it’s quite a hassle to make sure multiple systems/emitters share the exact same seed for all of their random values.
If you want different renderers get different dynamic material parameters, you can set a new Vector4 parameter and again bind the new V4 param to the specific renderer. The only inconvenience is that you can’t see the dynamic parameter name, as defined in your material, directly in the emitter.
I recommend looking into the Niagara Content Example maps. There is one example with “Leader & Follower”.
If I remember correctly, it’s all just done with the Particle Attribute Reader there, not with the location event. Way more versatile and actually pretty straightforward.
I am not trying to make it sound scary, but I didn’t recommend Particle Attribute Reader/PAR initially for few reasons:
It requires “Persistent IDs” for the parent emitter, which is a small extra price to pay;
You will need to create your own custom Niagara module scripts to do that. The built-in “…from Other Emitter” modules set is not built around your specific “1 child strictly following 1 unique parent” behavior, even with “Update Particles from Other Emitter” module: when the parent particle “gives birth” (a very bad and inaccurate analogy) to a child particle, that child will likely lose track of its parent. The custom PAR scripts for achieving your goal are not as complex as other monster scripts, but there is some oddity with Niagara ID/PAR you will need to deal with.
If you stick with the “single emitter” method, you don’t need persistent IDs or to write custom scripts, and no extra emitters which always helps performance.