The DynamicMaterialParameters Niagara module is reset to default when the emitter is updated.

(This is a translation of a [Japanese [Content removed] by Oyamada.)

This issue can also be reproduced in the 5.7.1 Launcher version.

■Issue

When using the DynamicMaterialParameters Niagara module with Float parameters, updating the emitter causes Boolean values such as Index0Float0Write to always be reset to the emitter’s default values. This occurs even if the update is not related to DynamicMaterialParameters. The Float values themselves persist.

At present, because the Boolean values are being reset automatically, existing data is unintentionally corrupted every time the emitter is updated.

I would appreciate it if you could look into this.

Thanks.

[Attachment Removed]

Hi [mention removed]​,

Sorry about the delay. I was just assigned this ticket now. I will look into it now and should get back to you soon.

Best,

Francisco

[Attachment Removed]

Hello [mention removed]​,

I tried reproducing this in UE 5.6 and 5.7.2 (launcher) by setting custom values on the Dynamic Material Parameter write flags (Index0Float0Write, Index0Float1Write, etc) then making unrelated changes to the emitter and recompiling it. On my end, the write flgas and float values were preserved and did not reset to their defaults.

Could you please share additional details for this issue? If possible, sharing a minimal repro project would help reproduce this locally.

Best,

Francisco

[Attachment Removed]

[mention removed]​

(This is a translation of a Japanese post by Oyamada.)

I have confirmed that this issue can be reproduced in 5.7.1 and 5.7.2 (including the launcher version), but it did not occur in 5.6.

The reproduction steps are very simple as shown below:

1) Create any Niagara Emitter and Niagara System.

2) Add a Dynamic Material Parameter module to the emitter (it can be placed either in Particle Update or Particle Spawn).

3) On the emitter side, change all the write flags to OFF.

4) Open the Niagara System and add this created emitter.

5) On the system side, override the inherited emitter’s Dynamic Material Parameter module by setting some Float values and enabling some write flags

State before reproduction:

On the Emitter side, all write flags of the Dynamic Material Parameter are OFF

On the System side, some of the write flags of the Dynamic Material Parameter are ON

In this state, make any change to the emitter, and then save it

After that, open the system again and you will see that it is marked dirty, and all write flags have been changed to OFF

This can be reproduced 100% of the time.

Just in case, I have attached a sample project.

a) Please confirm that the write flags of the Dynamic Material Parameter in NewNiagaraSystem are checked.

b) Make any update to NewNiagaraEmitter.

c) Please confirm that all the write flag checks in NewNiagaraSystem have been cleared.

(The checks are supposed to remain enabled, though.)

Thanks.

[Attachment Removed]

Hello [mention removed],

Thanks a lot for the detailed repro steps and the sample project, that was very helpful. I was able to reproduce this issue locally in UE 5.7.2 following the steps you described.

I also confirmed the same behavior in a recent UE5-Main source build (CL 49899931) so this appears to be an ongoing issue.

I’ll investigate this behavior further and follow up soon.

Best,

Francisco

[Attachment Removed]

Hello [mention removed]​,

Following up on this problem. I found that this behavior is not new to 5.7. The same problem can be observed as far back as UE 5.5 before the Dynamic Material Parameters module introduced support for Vector2D, Vector + Float and additional input types.

The issue appears to have been introduced starting with version 1.2 of the Niagara module script and strongly appears to be an engine bug. I’ll be submitting a bug report so the engine team can review and address this properly.

As a temporary workaround, reverting the Dynamic Material Parameters module to version 1.1 should prevent the write flags from being reset when the emitter is modified. However, please note this means losing the newer data types and improvements introduced in version 1.2 and later.

You can switch the module version using the version selector next to the module name in the stack. [Image Removed]

Please let me know if this workaround helps on your end. I’ll follow up once I have more information regarding the registered bug.

Best,

Francisco

[Attachment Removed]

[mention removed]​

(This is a translation of a Japanese post by Oyamada.)

Thank you for investigating into this.

I tested switching the module to version 1.1. When reverting the module from 1.2 back to 1.1, all write flags for the parameters that have Write Parameter Index enabled on the system side are forced to turn ON. At that point, existing data becomes corrupted. However, once the module is in the 1.1 state, I was able to confirm that the write flags are no longer reset to default when the emitter is updated.

In conclusion, the write flag data becomes corrupted at the point of reverting to version 1.1, which impacts a large number of Niagara systems. For this reason, adopting version 1.1 as a workaround is difficult for us at the project level.

[Attachment Removed]

Hello [mention removed]​,

I’ve gone ahead and registered this bug with the engine team, including all the relevant information so they can review and address it. You will be able to track the status of the issue via the following link: https://issues.unrealengine.com/issue/UE-363742

Please note that newly created tickets might take some time to become publicly available.

Regarding the workaround involving reverting to version 1.1, I understand that this would result in corrupted assets, requiring you to reconfigure the write flags for each one to avoid further issues.

As an alternative, I tested another method: removing the Dynamic Material Parameter from the emitter and setting it up directly in the System. This also prevents the write flag override and reset when updating the emitter. While you don’t need to revert to 1.1 for this, it does require setting up the module and its write flags again in the System.

Please let me know if this information helps.

Best,

Francisco

[Attachment Removed]

[mention removed]​

(This is a translation of a Japanese post by Oyamada.)

Thank you very much for filing the bug report.

I’d appreciate it if you could let me know once the fix CL and related information becomes available.

Thanks.

[Attachment Removed]

Hello [mention removed]​,

If the bug report becomes publicly available soon, I’ll be happy to share any updates with you. That said, please note that this can take some time before it’s visible and before a proper fix is introduced. For the most up-to-date status, it’s best to continue tracking the issue directly via the public issue tracker link I shared earlier.

In the meantime, does the alternative of configuring the Dynamic Material Parameter module at the System level (instead of the Emitter) help unblock your workflow? I know this would require to reconfigure existing assets.

If there’s anything else you need regarding this case, feel free to let me know. Otherwise, I’ll go ahead and close it on my end.

Best,

Francisco

[Attachment Removed]

[mention removed]​

(This is a translation of a Japanese post by Oyamada.)

Thank you very much for the information.

Yes, closing the issue is fine.

> In the meantime, does the alternative of configuring the Dynamic Material Parameter module at the System level (instead of the Emitter) help unblock your workflow?

As there are a very large number of Niagara systems, I would like to wait for a fix to be provided.

Thanks.

[Attachment Removed]