DFX8xxx — Decompiler

14 codes in this family (10 error, 4 warning). The message is the format string as the compiler holds it: %s, %d and %c are substituted at runtime.

DFX8000

Cause. The asset path resolved to nothing, or to something that is not a Niagara System.

Fix. Check the path. dfx decompile /Game/FX/NS_Spark takes a package path.

DFX8001

Cause. The system's emitters could not be read.

Fix. The inner message is the adapter's. A system that fails to load at all reports DFX8000 instead.

DFX8002

Cause. One emitter could not be exported; the rest of the system still was.

Fix. The export is incomplete for that emitter. dfx coverage reports the same information across every system at once.

DFX8003

Cause. The Export .dfe entry point was reached with nothing selected, or the selected asset failed to load.

Fix. Right-click a single UNiagaraEmitter asset. Emitters that live inside a system are not separate assets -- export the system instead.

DFX8004

Cause. Reading an emitter needs an owning system: every reader in the Niagara external edit API addresses through one. The throwaway host under /Temp/DreamFX could not be created.

Fix. The inner message is the adapter's. Nothing under /Temp is written to disk, so this is an in-memory failure -- usually the Niagara plugin failing to initialise rather than anything about the emitter.

DFX8005

Cause. The emitter could not be copied into the host system. Niagara's AddEmitter rejected it as a template.

Fix. The inner message is Niagara's. An emitter asset saved by a much older engine version is the usual cause; opening and re-saving it in the Niagara editor upgrades it.

DFX8006

Cause. The emitter was copied into the host, but its topology could not be read back.

Fix. The inner message is the adapter's. dfx coverage exercises the same read path across every system and is the fastest way to see whether the problem is this emitter or the read path itself.

DFX8010

Cause. Adopt refuses an asset that has features DreamFXLang cannot express. One line is raised per feature.

This is the gate that makes adoption safe. Adopting means the text becomes the only source of truth for that asset, so adopting with a known gap destroys whatever did not survive the first rebuild -- silently, and with no diff to show for it.

Fix. Use Export .dfs instead. It writes the same text, does not touch the asset, and lists the gaps in the file header. To see which buckets are open across your own content, run dfx.ps1 coverage.

DFX8011

Cause. Another .dfs already declares the same target asset. Two sources generating one asset take turns overwriting each other, and whichever built last wins.

Neither source can detect this at build time -- both succeed. The only place to catch it is here, before the second one exists.

Fix. Edit the existing source instead. Its path is in the message and in the toast.

DFX8012

Cause. The asset was adopted and rebuilt, but re-exporting the rebuilt asset does not reproduce the file that was written. The first differing line is in the message.

Because DFX8010 already ruled out every known gap, a mismatch here is a real defect in the generator or the decompiler rather than an expected loss.

Fix. The source file stays on disk and the asset was rebuilt from it, so the text is authoritative either way -- nothing is lost. Report the differing line: a round-trip that is not a fixed point is exactly what DreamFX.Corpus.RoundTrip exists to prevent, so a case that reaches this is one the corpus does not cover yet.

DFX8013

Cause. The file lives under the Decompiled Output Directory (DFX/Decompiled by default), but its Name= resolves to an asset outside the Decompiled/ content namespace. Building it would write over the asset it was exported from -- usually third-party content the author only meant to read.

Almost always this is an export written before the plugin started rehoming exports: those files named the original asset, and the whole decompiled tree was kept out of the build to compensate. The tree is ordinary source now, so the check moved onto the file itself.

Fix. Re-export the asset (right-click > Export .dfs, or dfx decompile-all -Path=...). The new file names Decompiled/<original directory>/<asset> and rebuilds a mirror beside the original, which is what makes it safe to edit and save.

If the intent really is to make this text the asset's source of truth, that is Adopt, not Export: move the file out of the decompiled tree into a DFX/ directory and keep the name it has. Adopt writes exactly that arrangement, and refuses when the export would lose something the language cannot express yet (DFX8010).

DFX8014

Cause. The emitter inherits from a parent emitter asset (VersionedParent on the asset). The export flattens that inheritance --- and what that does and does not lose was measured before this warning was worded (2026-08-11, NE_C/NE_C002 of NS_Spawn_Teleport_Root): an inheriting emitter's own graph is the full merged copy, so the export carries the complete effective stack and the rebuilt emitter behaves like the original. What the flattening loses is the link. The mirror is an independent emitter; an edit to the parent asset propagates into the original through Niagara's merge machinery and silently never reaches the mirror.

Fix. Nothing, if the mirror is a migration snapshot --- the divergence only begins when someone edits the parent. If the parent is still being maintained, either re-export after parent edits (the merged stack picks them up), or keep authoring the original in the editor. A future from "<parent asset>" inherit form that rebuilds the link is designed but not committed; this warning is the record of what it would buy.

DFX8015

Cause. The emitter carries event handlers the export has no text form for. Event handlers themselves ARE supported --- they export as OnEvent(...) blocks --- so this now fires in two narrower cases only:

• the emitter has more than one handler (one OnEvent block per emitter is representable, because the write side reaches an event stack through a single zero usage id);
• the export is a standalone .dfe, which has no sibling emitter for the handler's Source to name (the stored SourceEmitterID is a handle guid no rebuild could reproduce, so the source travels by emitter NAME).

Fix. For the multi-handler case, split the receiving emitter so each one carries a single handler. For the standalone case, export the whole system as a .dfs instead, where the source emitter exists to be named. Either way the gap header names each handler's source emitter and event, so nothing is lost silently.

DFX8016

Cause. The emitter carries a simulation stage the export has no text form for. Ordinary stages export as Stage name(...) blocks and do not raise this; what remains is a stage whose class is not the engine's UNiagaraSimulationStageGeneric (a custom C++ stage), or one whose script object is missing from the asset. The gap header names each one, so the loss survives into code review rather than living only in a commandlet log.

Fix. Nothing to fix in the source file — this is a representation limit. If the stage matters, keep authoring that emitter in the Niagara editor; a rebuilt mirror will not run it.