DOCUMENTATION

Cooked projects

Common mistakes on cooked projects: searching for Blueprints and getting a small, confident answer, and edits that stop the editor because the asset's editor data was stripped. Each entry says what you see, why, and what to do.

What cooked content is and what MifBridge can do with it is on cooked-projects. This page covers the traps.

A cooked asset keeps what runs and loses what is edited

A cooked asset loads and behaves correctly at runtime. Its editor-only data was stripped. Anything on the editor side that reaches for that data finds nothing, and how it fails depends on how defensively that part of the engine was written. Several of these stop the editor instead of returning an error, so ask "does this asset have editor data?" before the operation, not after.

Asset What is gone How a write or copy fails
User-defined struct The editor data the struct tools need Fatal: the engine cast-checks it and stops the editor
Material The expression graph Honest: list_material_expressions answers numExpressions: 0, cooked: true
Niagara system The editor data that copying re-runs Duplicating raises an access violation inside the engine, with no MifBridge frame on the stack
Static mesh, duplication The mesh description a rebuild needs Fatal assertion inside the engine's mesh build
Static mesh, simple collision The mesh description every shape generator fits against Access violation: the engine reads the mesh description with no null check

What you see: the editor closes and the log's last frames are engine code, not MifBridge.

What to do instead:

  • Read through reflection. get_property and list_object_properties walk cooked assets, including deep paths. A cooked Niagara system's exposed parameters yield names and types, and a cooked static mesh's bounds, LOD count and materials all read.
  • Use the tables that survive the cook. Cached material parameters survive, which is why list_material_parameters works on shipped materials where the expression listing cannot.
  • Call the runtime surface. add_function_call reaches Blueprint-callable functions.
  • remove_collision on a cooked static mesh is fine. It only touches existing collision primitives, never the mesh description.

MifBridge refuses the dangerous cases before they run: struct edits on a cooked struct, duplicate_asset on a cooked Niagara system or static mesh, and add_simplified_collision on any static mesh with no mesh description. If you get one of those refusals, it replaced a crash.

Other writes that cost the editor

  • A cooked landscape. Its heightmap and paint layer textures lose their source data. The landscape endpoints (export_landscape_heightmap, sample_landscape, sculpt_landscape, paint_landscape and the other landscape writers) refuse such a landscape before changing anything, naming the component. Use diagnose_landscape and trace_ground to read it.
  • A cooked texture. There is no source image, and the engine's exporter stops the editor on one. export_asset refuses it, answering cooked and hasSourceImage: false, and names render_thumbnail, which renders it from its platform data.

find_assets {class:"Blueprint"} finds almost nothing

What you see: a search for Blueprints returns a small number with ok:true, and nothing suggests the answer is wrong.

Why: cooking registers a Blueprint under its generated class (BlueprintGeneratedClass, WidgetBlueprintGeneratedClass, AnimBlueprintGeneratedClass), not as a Blueprint. On a cooked game's Blueprint folder:

Query Count
class:"Blueprint" 26
class:"BlueprintGeneratedClass" 915

Under 3 percent, delivered with confidence. bRecursiveClasses does not rescue it: a Blueprint and its generated class are different hierarchies, not parent and child, so recursion never crosses.

It is worse than a plain miss, because the few that do come back are mostly assets the bridge made itself in the session. Anything newly authored is uncooked. A small answer made largely of your own scratch assets looks like a real, small result set.

What the bridge does about it: find_assets re-runs the count with the generated-class spelling and reports generatedClassCount and cookedClassNote, only when the other spelling is genuinely bigger. The re-count applies your nameContains, pathPrefix and origin filters. An uncooked project gets no note.

Do instead:

  • Search both spellings: class:"BlueprintGeneratedClass" as well as class:"Blueprint", and for widgets and animation Blueprints their own generated-class names.
  • For discovery, use list_blueprints. Every row carries cooked: true|false, and cookedCount totals them. It deduplicates by package, because an uncooked Blueprint is registered under both spellings. On one cooked game it returned 3227 Blueprints where a query of Blueprint alone had shown 1818.
  • Never write "this project has no X" from a zero. A 0 from a Blueprint query on cooked content is not evidence. Ask the generated-class spelling, or follow the parent classes.

A cooked Blueprint has no graphs

list_graphs, list_nodes and find_nodes cannot read a cooked Blueprint's graphs, because the editor-only Blueprint object is gone. They say so, rather than answering "not found" or an empty list.

What you can do:

  • list_components reads the component tree.
  • describe_package lists the objects in the package and whether it is cooked.
  • create_editable_child mints an editable copy, but needs an engine function that exists only in the engine build MifBridge was developed against. On a stock engine it refuses with a named reason. See cooked-projects.

Two copies with the same node GUIDs

Some modded or cooked assets load as two copies whose nodes share identical GUIDs. A lookup by nodeGuid alone may land in the wrong copy. Pass graphId alongside the GUID. get_node accepts graphId for exactly this.

Where to go next