DFX7xxx --- Provenance, drift and lint

The block between the generated markers is written by .skill/gen-diagnostics.ps1. Everything below a marker is written by hand and survives a regeneration.

DFX7001

Severity error

Message

Asset '%s' carries no DreamFX provenance stamp: it was never generated from this source, or it was created by hand.

Raised by Source/DreamFXEditor/Private/Generation/DreamFXGenerator.cpp:5258, Source/DreamFXEditor/Private/Generation/DreamFXModuleGenerator.cpp:769

Cause. The asset carries no provenance stamp: it was never generated from this source, or it was built by hand.

Fix. Run the build. If the asset is hand-built and should stay that way, do not point a .dfs at its path -- a build would overwrite it.

DFX7002

Severity error

Message

Asset '%s' is stale: it was generated from a different revision of this source. Run the DreamFX build.

Raised by Source/DreamFXEditor/Private/Generation/DreamFXGenerator.cpp:5265, Source/DreamFXEditor/Private/Generation/DreamFXModuleGenerator.cpp:776

Cause. The asset was generated from a different revision of this source. This is the case nobody notices on their own: someone edited a .dfs, did not rebuild, and committed both. A build alone would pass, because a build fixes it.

Fix. Run the DreamFX build and commit the asset with the source.

DFX7003

Severity warning

Message

Asset '%s' was generated by DreamFX %s; the current generator is %s. A rebuild is recommended.

Raised by Source/DreamFXEditor/Private/Generation/DreamFXGenerator.cpp:5272

Cause. The asset was generated by an older generator. The same text can lower to a different asset after a generator change, so the stamp records the version.

Fix. Rebuild.

DFX7004

Severity error

Message

Asset '%s' does not exist: this source has never been built.

Raised by Source/DreamFXEditor/Private/Generation/DreamFXModuleGenerator.cpp:1108

Cause. -Verify found no asset at all for this source.

Fix. Run the build.

DFX7005

Severity error

Message

(built at runtime)

Raised by Source/DreamFXEditor/Private/Generation/DreamFXGenerator.cpp:5309, Source/DreamFXEditor/Private/Generation/DreamFXGenerator.cpp:5314

Cause. R7 drift. The source did not change and the asset did not change, but a module they both depend on now exposes a different version -- so the asset was built against a different module than the one this build would use. Nothing in the source or the asset says anything about it, which is why the stamp records module versions.

Fix. Rebuild to adopt the new version, or pin the module with @<version> to have the mismatch reported at the call site. A warning by default because an engine upgrade hits every source at once and a rebuild resolves it; -StrictVersions makes it an error, for a release gate.

DFX7101

Severity warning

Message

Emitter '%s' simulates on the GPU but declares no FixedBounds. GPU emitters cannot compute their own bounds, so it will use a default box and may be culled unexpectedly.

Raised by Source/DreamFXEditor/Private/Lint/DreamFXLint.cpp:138

Cause. A GPU emitter cannot read its own particle positions back to compute bounds, so without a fixed box it gets a default one and vanishes the moment the camera looks at it from the wrong angle.

Fix. Set FixedBounds = box(...) on the emitter or the system.

DFX7102

Severity warning

Message

Emitter '%s' spawns by rate ('%s') with no upper bound. Set AllocationMode = Fixed and PreAllocationCount to cap the particle count.

Raised by Source/DreamFXEditor/Private/Lint/DreamFXLint.cpp:151

Cause. Rate-based spawning has no ceiling of its own: a long-lived emitter with an automatic allocation estimate keeps reallocating, and a runaway rate has nothing to stop it.

Fix. Set AllocationMode = Fixed; and PreAllocationCount to cap the particle count.

DFX7103

Severity warning

Message

Emitter '%s' uses randomness ('%s') but does not set Determinism = true, so it will look different on every play. Add Determinism and RandomSeed to its Settings if reproducibility matters.

Raised by Source/DreamFXEditor/Private/Lint/DreamFXLint.cpp:164

Cause. Randomness without a fixed seed means the effect differs every play. Fine for ambience, wrong for anything a cinematic or a test compares against.

Fix. Add Determinism = true; and a RandomSeed if reproducibility matters.

DFX7104

Severity warning

Message

This renderer has no Material and DreamFX knows no default for its type, so it will not draw. Set 'Material = \"...\";'.

Raised by Source/DreamFXEditor/Private/Generation/DreamFXGenerator.cpp:4329

Cause. The renderer has no material and DreamFX knows no engine default for its type, so it draws nothing at all.

Fix. Set Material = "...";

DFX7105

Severity warning

Message

MeshRenderer OverrideMaterials is nonempty but material overrides are disabled. Set bOverrideMaterials = true; or remove OverrideMaterials to use the mesh's own materials.

Raised by Source/DreamFXEditor/Private/Generation/DreamFXGenerator.cpp:1852

Cause. A mesh renderer has a nonempty OverrideMaterials array while its final bOverrideMaterials setting is false, so Niagara ignores the overrides.

Fix. Set bOverrideMaterials = true; to apply the array, or remove OverrideMaterials to use the mesh's own materials.

DFX7106

Severity info

Message

pull: %s.%s is stored on the asset and not declared in this text -- skipped. pull adds no structure.

Raised by Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:1755, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:1878

Cause. The asset's store holds a value for an input the text does not write. pull rewrites the literals a call already has and nothing else: adding the argument would change the structure the text describes, which is a different edit with a different owner -- the build safety gate (DFX8017) is what decides whether a rebuild would drop such a value.

The list is long by nature. The engine materialises a constant for every input of every module, so most of these lines are the module's own defaults sitting in the store; on this project's content one system reports 94 of them and 8 are values someone actually tuned.

Fix. Nothing, when the value is the module's default -- a rebuild reproduces it and loses nothing, which is why these lines are information and not a failure. When it is a tuned value (the ones DFX8017 refuses a save over), write the input into the text and run pull again, or export with decompile -NoDefaults, which prints every input a module has. Either way the next pull has a literal to correct.

DFX7107

Severity info

Message

pull: '%s' already holds every value '%s' stores for the input(s) it declares (%d compared, %d not declared, %d not writable, %d withheld). No bytes written.

Raised by Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2355

Cause. The comparison found nothing to write: every input the text declares and the asset stores a value for holds the same value already. The comparison is by value, not by characters -- the text's literal is lowered exactly the way a build lowers it and the bytes are compared against the store -- so 0 and a stored 0.0 are agreement and are not rewritten into each other's spelling.

Fix. Nothing. This is the fixed point the command is built around: a second -Apply on a file that has just been pulled reports this and writes no byte.

DFX7108

Severity error

Message

pull reads a .dfs and the Niagara system it names: '%s' declares a %s document.

Raised by Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:907, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:924, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:935, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:949

Cause. pull needs a Niagara system to read values out of, and it takes the path from the text's own Name=/Root= -- the same resolution a build uses, so that pull reads the asset this text writes. It fails four ways: the file declares a Module, Emitter or DynamicInput document rather than a System; the root token does not resolve; no system exists at the resolved path; or -Asset= named something that is not a Niagara system.

Fix. Build the text first when the asset has never been built, or name the asset you meant with -Asset=. Note which asset an export names: plan-v4 writes every export into the Decompiled/ namespace, so an export names its MIRROR -- pulling the values someone tuned in the original is -Asset=/Game/.../NS_X, and that is also the only spelling of it, since a Name= can only point at one of the two.

DFX7109

Severity warning

Message

pull: %s: %s. pull rewrites literals inside a structure both sides agree on, so nothing in this stack was addressed.

Raised by Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:1211, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:1978, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2027, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2066, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2220, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2241

Cause. pull addresses an input by matching the text's statement to the asset's node at the same position in the same stack, and refuses the whole stack when the two do not line up: a different number of nodes, a node that is a module call on one side and a folded assignment run on the other, a module call whose asset is not the script that node runs, an as <name> the asset's node does not carry, or an emitter or stack the asset does not have at all.

The refusal is the feature. A correspondence that might be off by one rewrites the wrong literal, and a wrong literal in a text file is silent corruption -- the message therefore prints both sides' node names, which is also the diagnosis one line further on.

Fix. Build the text, which is what makes the asset match what the text describes, then pull. When the two are meant to differ structurally -- an edit that has not been built yet -- pull is not the tool for the values inside that stack.

DFX7110

Severity error

Message

pull: the rewritten text does not read back (%s), so '%s' was left untouched.

Raised by Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2411, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2545, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2553

Cause. The write half failed, and nothing was left half-done. The same code covers the three ways it can: the rewritten text does not parse (pull parses its own output before touching the file, and splices only over the byte range the parser recorded for the literal, so this is a defect in pull rather than in the text), the backup could not be written, or the file itself could not be written.

Fix. Report it when the message says the rewritten text does not read back: the file on disk is exactly what it was, and the byte range pull replaced is the only information needed to reproduce it. The other two are an environment problem; when the last message names a backup, the bytes the file held are there.

DFX7111

Severity info

Message

pull: %s is declared but was not written back: %s

Raised by Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:1081, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:1655, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:1795, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:1966, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:1994, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2049, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2085, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2108, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2122, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2253, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2274, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2289

Cause. The text declares the input, the asset stores a value for it, and pull still would not write it. Each line names which of the reasons it is:

• the value is not a literal -- a link, a dynamic input, an hlsl { } block, a curve { }, a data interface or an object reference. Changing a value MODE is an edit, not a write-back;
• the text's value does not type-check against the input, which the build would refuse for the same reason;
• several inputs, or several arguments, share one identifier. The DSL drops spaces, hyphens and case, so the value input Scale RGB and the inline edit condition ScaleRGB that gates it are one name to this language. Which one a written value MEANS is decided by its type, the way the generator decides it; pull only reports when it cannot tell;
• the same parameter name is stored in two scripts with different values, so which copy the engine reads is not something pull can determine;
• the stored value has no spelling in this language (a struct that is not int/float/bool/2-4 packed floats);
• the stack is an OnEvent or Stage stack, which v1 does not address -- those are read through a focus slice, a different mechanism from the six fixed stacks.

Fix. Each line names its own reason, and the first two are about the text rather than the asset. For a shared identifier, spell the intended input in a way that cannot be read as the other one, or change the value so its type decides. For the event and stage stacks there is nothing to do in v1.

DFX7112

Severity info

Message

pull: %s: %s

Raised by Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:1614

Cause. One line per structural edit -Structure applied: a module the asset has and the text did not (the line that was inserted, verbatim), or a statement the text has and the asset does not (the line that was removed).

Fix. Nothing. This is the record of what the run wrote, and it is the only place the inserted line appears in full -- the summary counts the edits, and the console list would otherwise be the sole copy of a line that is now in a file.

DFX7113

Severity warning

Message

pull: %s: the asset has %s that the text does not, and the text has %s that the asset does not. The two lists line up uniquely, so -Structure writes that difference; it adds and removes lines, so it does not happen without the switch. Nothing in this stack was addressed.

Raised by Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:1302, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:1606

Cause. The text and the asset describe a stack's structure differently, and pull would not write the difference. Two shapes:

• without -Structure -- the difference is located (the node lists align uniquely) and is deliberately not applied. Adding or removing a line moves modules in the execution order, and the values inside that stack are addressed by position, so the whole stack is left alone.
• with -Structure -- the difference could not be written at all: a module whose inputs include a data interface or an object reference (the call cannot be reconstructed from what the store holds), a Set Parameters module the text does not declare (pulling a run of assignments out of a fold is a different edit), a statement with no recorded byte range, a statement that shares its line with something else, or a stack whose closing brace the parser did not record.

Fix. The message names which. For the first, re-run with -Structure if the edit is wanted. For the second, build the text first (dfx build), which makes the two structures agree and leaves the value write-back available.

DFX7114

Severity warning

Message

pull: the baseline could not be used (%s), so every value this text declares was compared from scratch.

Raised by Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2442, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2448, Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2484

Cause. The state of the dirty set, said once per run rather than guessed at:

• no baseline on disk -- the first run after this feature arrives, or after the file under Saved/DreamFX/Pull/ was deleted. Every value the text declares is compared, exactly as it was before the baseline existed, and a following -Apply records one.
• the baseline could not be used -- unreadable, or a line that is not a record. The same full comparison happens, at warning severity, because the file being there and unusable is different from it not being there.
• the baseline could not be written (-Apply only) -- the values were still written; only the record of what the asset held is missing, so the next run compares everything again.

Fix. Nothing, for the first two: they describe a run that did the conservative thing. For the third, check that Saved/DreamFX/Pull/ is writable.

DFX7115

Severity info

Message

pull: %s differs from this text but the asset has not moved since the last apply, so the text's value stands.

Raised by Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:1030

Cause. A declared value differs from the asset's, and the asset has not moved since the last -Apply recorded a baseline for it. That makes the TEXT the newer side -- somebody edited the literal rather than the editor -- so the text's value stands and nothing is written. This is the whole point of the dirty set: without it, pull would hold the asset's reading above a text edit that deliberately contradicts it.

Fix. Nothing, when the text edit was meant. To make pull write the asset's value anyway, move the value in the editor (which is what the baseline is watching), or delete the baseline file to fall back to comparing everything.

DFX7116

Severity info

Message

pull: %s: %s -> %s

Raised by Source/DreamFXEditor/Private/WriteBack/DreamFXPull.cpp:2377

Cause. One literal the text writes differs from the value the asset stores for that input. The diagnostic's own file(line,col) is the line the literal sits on, and the message gives <module>.<input>, the literal as written, and what it would become. Raised once per literal by dfx pull; the value compared is the asset's rapid-iteration store, not the resolved pin -- that distinction is the reason pull exists at all (NS_Effects1_Mesh stores Sprite_Atlas_Size.MeshYaw = -90 while every read of the pin returns 0.0).

Fix. Nothing, unless you asked for it: without -Apply the run is a dry run and writes no byte. dfx pull <file> -Apply writes them. Two things are worth checking when a line is a surprise: whether pull read the asset you meant (an export names its mirror, so pulling the original's values needs -Asset=), and whether the asset stores this value at all -- the run reports the store's own contents, and a text whose asset never held the value has nothing to pull.