Graphs as text

Blueprints, materials, animation graphs and Control Rigs are node graphs saved inside binary .uasset files. To read one, you open the editor and follow wires by hand. PinWright can turn these graphs into readable text. We call these text formats text IRs. Your assistant reads and edits the text, and you can review a change as a few lines instead of a screenshot.

Why text helps

Your assistant works best with text. When it can read a whole graph as text, it sees what is already there, changes the few lines your request needs, and writes them back into the asset. That is faster and less error-prone than placing and wiring nodes one at a time. For you, a change to a graph becomes something you can read.

Event BeginPlay

Print String

In String"Hello"

Is Valid

ObjectMyRef

Return

Branch

ConditionIsValid(MyRef)

True

skips to Print "Done"False

Set Score

Score100

Print String

In String"Done"

In the editor: a Blueprint BeginPlay graph with a Print, an IsValid check, a Branch, and two paths that rejoin at the end. You read it by following wires across the canvas.

The same graph as textbpir

entry event BeginPlay() {
    call PrintString(InString: "Hello")
    %valid = call IsValid(Object: $MyRef)
    %b = branch(%valid) [true -> @ok, false -> @end]

@ok:
    set Score = 100

@end:
    call PrintString(InString: "Done")
}

Diffable in version control: A change to a graph becomes a few changed lines in a pull request, instead of a binary file nobody can review.
Reviewable like code: You read what changed in plain text, so you can check an edit to a Blueprint or material the same way you check a code change.
Easy for your assistant to write: Each graph type has one consistent, line-based format. Your assistant picks it up from a few examples and writes whole graphs reliably.
What carries over: The graph itself carries over: nodes, connections, property values and node positions. For formats that write back, they carry back into the asset too. Editor cosmetics do not: node colors and editor list order are left out, and most formats drop comment boxes. The per-format table below gives the exact boundary.

Two kinds of format

Every format reads a graph out as text. Some also write edited text back into the asset, so your assistant can make changes through the text. The rest are for reading: your assistant uses them to understand and explain a graph, and you use them to review it.

Read and write Your assistant reads the graph as text and writes edited text back into the asset.
Read as text Your assistant reads the graph as text to understand it, and you can review it. Writing back is planned.

Read and write as text

Your assistant reads the graph, edits the text, and writes it back.

Blueprint graphsRead and write

Events, functions and control flow. Format: BPIR.

Material graphsRead and write

Materials and Material Functions, node by node. Format: MGIR.

Animation BlueprintsRead and write

State machines and blend logic. Format: AGIR.

Control Rig graphsRead and write

Rig graphs and the bone and control hierarchy. Format: CRIR.

Read as text

Readable text for your review and your assistant’s context.

Behavior treesRead as text

Composites, decorators, services and tasks. Format: BTIR.

Niagara graphsRead as text

Systems, emitters and module scripts. Format: NIR.

MetaSound graphsRead as text

MetaSound Source and Patch graphs. Format: MSIR.

Sound Cue graphsRead as text

Classic Sound Cue node trees. Format: SCIR.

PCG graphsRead as text

Procedural generation nodes and their connections. Format: PCGIR.

What each format keeps

The shared rules above are the minimum. This table lists, per format, how nodes are identified, whether layout and comments come along, and what is not supported yet.

Format	Direction	Node identity	Layout	Comments	Known unsupported
`BPIR`	Read and write	Kept when written back	Authored `@(x, y)` kept	Dropped	Unusual composite and plugin-defined nodes use a generic form, so check them after a write
`MGIR`	Read and write	Expressions keyed by qualified class path	Authored `@(x, y)` kept	Dropped	Node colors, editor list order, layout-only reroutes
`AGIR`	Read and write	Node GUIDs kept in `guid=`	Authored `@(x, y)` kept	Dropped	Node colors. Verified on a narrower engine range than the rest of PinWright; see the AGIR page
`CRIR`	Read and write	Struct paths plus `%localId`	Authored `@(x, y)` kept	Comment nodes round-trip	Curve, connector and physics hierarchy elements show as a `# TODO unsupported` marker
`BTIR`	Read as text	Node names as the asset stores them	`@(x, y)` emitted	Captured per node	No write-back yet. Nodes not reachable from the root show as `orphan` with a warning
`NIR`	Read as text	Node identity lines inside script graph bodies	`@(x, y)` recorded for reference	Not emitted	Referenced module scripts show as paths. Unknown node types show as `# unknown-node` with a warning
`MSIR`	Read as text	Local `n1`, `n2`… for each read	`@(x, y)` recorded	Not emitted	Unresolved node types and wire ends show as warnings
`SCIR`	Read as text	Node names as the cue stores them	`@(x, y)` recorded	Not emitted	Nodes used more than once and unreachable nodes show as warnings
`PCGIR`	Read as text	`N1`, `N2`… in graph order; numbers can change after an edit	`@(x, y)` recorded	Not emitted	Subgraphs show as a path; read them separately

For the read-only formats, “kept” means the detail appears in the text, since nothing is written back yet. Byte-for-byte identical output is promised per format: where a format guarantees it, its own page says so and in what scope.