Hi,
After upgrading our engine from version 5.4 to 5.5, we encountered an issue where certain Niagara effects are incorrectly spawning at the world origin (0,0,0).
Upon investigation, we found that this occurs when the Initialize Particle module has its Position Mode set to Unset. We suspect this may be due to a change in Niagara’s default coordinate space—from local to world—in version 5.5.
We are currently extending UNiagaraValidationRule and using NiagaraSystemAuditCommandlet to automatically list Niagara systems that are misconfigured or potentially problematic. As part of this process, we attempted to identify systems with Position Mode set to Unset, but while we were able to access the Static Switch pin data, we couldn’t find a way to retrieve the actual overridden module values from the emitter.
We’d like to ask two questions regarding this:
- Could you provide some insight or the relevant CL (change list) regarding why Niagara’s default coordinate space was changed in 5.5?
- Is there a way to access overridden module values from the emitter within a UNiagaraValidationRule?
This issue can be reproduced by modifying the Position Mode of the Initialize Particle module in the built-in Fountain Niagara template emitter to Unset.
Thank you!
Hi! Thanks for reaching out to us about this! I was able to replicate the behavior just as you described.
- This was an unintentional change, so I unfortunately don’t have a specific CL to provide at the moment. Here’s a link to the bug ticket: https://issues.unrealengine.com/issue/UE-273246. It might take a few days for the ticket to be visible to the public, but once it’s approved, you’ll be able to check on its status there.
- Accessing that data is most likely possible, though potentially complicated. I’m looking into this a bit more, but I wanted to reply to your first point in the meantime.
Hi, here are some updates!
The issue is being worked on, and the issue link will be updated with info about which version of the engine will include this change, etc when complete. I’ll aim to update this case with the CL once it’s available, too.
To follow up on Point 2 from your original post: You could use the Stack Query API; the header is currently in the internal directory, but if you’re building from source, you could move it.
For example, here’s what an automated test excerpt looks like:
`TNiagaraStackQueryResult ModuleItemResult = FNiagaraStackRootQuery::EmitterStackRootEntry(SystemViewModel.ToSharedRef(), “TestEmitter”)
.FindScriptGroup(ENiagaraScriptUsage::ParticleUpdateScript, FGuid())
.FindSetParametersItem(BoolInput.GetName())
.GetResult();
if (TestQueryResult(ModuleItemResult) == false) { return; }
TNiagaraStackQueryResult ObjectResult = FNiagaraStackModuleItemQuery(*ModuleItemResult.StackEntry)
.FindFunctionInput(TestDataInterfaceInput.GetName())
.FindObjectValue()
.GetResult();
if (TestQueryResult(ObjectResult) == false) { return; }`Each query object exposes Find functions for items in its scope, which allows you to do things like System->FindScript(SystemUpdate)->FindModule(InitModule)->FindInput(MyInput). If anything along the way is missing, it’s handled and won’t crash. The query result returned has a pointer to the stack entry if it was found, and an error message if something went wrong. This should allow you to get to any data that’s visible in the details view in the system editor. Please note, though, that this isn’t a typical/supported workflow.
Hi - This issue has been fixed, and is expected to be included with 5.6. If you’d like access to this change before then, it’s GitHub Commit 41956238.
Have a good day!
Hello,
Thank you for your reply.
Please let me know if there are any further updates.
Thank you.