Build a Blueprint with AI

A guided example that creates a Blueprint, adds a variable and a function, wires an event graph, and compiles it, all through cfa commands.

This builds a working Actor Blueprint end to end with cfa: a spawner that reads a count from a variable, runs on BeginPlay, and prints how many actors it would place. Every command below is real and copy-pasteable. With the AI skill installed your assistant issues these itself, so this is what it is doing under the hood.

Before you start

An Unreal Editor must be open with the plugin enabled. Confirm with cfa health_check, which reports the project it reached. If more than one editor is running, pick one first, see Multiple Editors.

1. Create the Blueprint

Any parent class works, C++ or Blueprint, by short name or full path. If you are unsure what a class is called, search first rather than guessing: the create call fails on an unknown parent.

Find a parent class by name:

bash

cfa search_parent_classes --filter Actor --max-results 10

Create the Blueprint:

bash

cfa create_blueprint --name "BP_Spawner" --path "/Game/Blueprints" --parent-class "Actor"

2. Add a variable

The flags are --variable-name and --variable-type. Making it instance editable is what puts it in the Details panel, so a designer can change the count per placed actor without touching the graph.

An editable integer with a slider range:

bash

cfa create_blueprint_variable --blueprint-path "/Game/Blueprints/BP_Spawner" --variable-name "SpawnCount" --variable-type "int" --category "Spawning" --instance-editable=true --slider-min "0" --slider-max "50"

Object, struct, and container types take a second flag. A few shapes worth knowing:

An object reference:

bash

cfa create_blueprint_variable --blueprint-path "/Game/Blueprints/BP_Spawner" --variable-name "Target" --variable-type "object" --type-path "Actor"

An array of structs:

bash

cfa create_blueprint_variable --blueprint-path "/Game/Blueprints/BP_Spawner" --variable-name "Points" --variable-type "struct" --type-path "Vector" --container "array"

A replicated variable with a RepNotify:

bash

cfa create_blueprint_variable --blueprint-path "/Game/Blueprints/BP_Spawner" --variable-name "Health" --variable-type "float" --replication "repnotify"

3. Add a component

Components attach to the Blueprint's component tree. Pass --attach-parent to nest one under another, otherwise it lands at the root.

A billboard so the spawner is visible in the level:

bash

cfa add_component_to_blueprint --blueprint-path "/Game/Blueprints/BP_Spawner" --component-class "BillboardComponent" --component-name "Marker"

4. Add a function

The flag is --function-name. Inputs and outputs are added separately, which lets you build the signature before wiring anything.

Create a function that returns a value:

bash

cfa create_blueprint_function --blueprint-path "/Game/Blueprints/BP_Spawner" --function-name "GetSpawnBudget" --return-type "Integer"

Give it an input:

bash

cfa add_function_input --blueprint-path "/Game/Blueprints/BP_Spawner" --function-name "GetSpawnBudget" --param-name "Multiplier" --param-type "int"

5. Wire the event graph in one call

This is the part worth learning properly. Rather than adding nodes one at a time and connecting them afterwards, build_blueprint_graph takes the whole fragment, nodes and connections together, and lays it out for you. Nodes are given a ref so connections can name them before they exist.

BeginPlay reads SpawnCount and prints it:

bash

cfa build_blueprint_graph --json '{"blueprint_path":"/Game/Blueprints/BP_Spawner","nodes":[{"ref":"bp","kind":"event","id":"BeginPlay"},{"ref":"get","kind":"var_get","id":"SpawnCount"},{"ref":"print","kind":"call","class":"KismetSystemLibrary","function":"PrintString"}],"connections":[{"from_ref":"bp","from_pin":"then","to_ref":"print","to_pin":"execute"},{"from_ref":"get","from_pin":"","to_ref":"print","to_pin":"InString"}]}'

Do not pass positions

Auto layout is on by default and arranges only the nodes you just added, in a clear area to the right of anything already there. Existing nodes are never moved, so appending to a graph somebody else built is safe. The moment you pass pos_x or pos_y on any node, auto layout turns off and your coordinates are used instead.

Two other node kinds come up constantly. A bound widget event, and calling an event dispatcher:

A button click in a widget Blueprint:

bash

cfa build_blueprint_graph --json '{"blueprint_path":"/Game/UI/WBP_Menu","nodes":[{"ref":"e","kind":"bound_event","widget":"PlayButton","event":"OnClicked"},{"ref":"p","kind":"call","class":"KismetSystemLibrary","function":"PrintString","pin_defaults":{"InString":"Play!"}}],"connections":[{"from_ref":"e","from_pin":"then","to_ref":"p","to_pin":"execute"}]}'

Broadcast a dispatcher from BeginPlay:

bash

cfa build_blueprint_graph --json '{"blueprint_path":"/Game/Blueprints/BP_Spawner","nodes":[{"ref":"bp","kind":"event","id":"BeginPlay"},{"ref":"call","kind":"call_dispatcher","dispatcher":"OnSpawned"}],"connections":[{"from_ref":"bp","from_pin":"then","to_ref":"call","to_pin":"execute"}]}'

Tip

A widget must be marked as a variable before a bound event can reference it, and the Blueprint has to be compiled once after that. A dispatcher must exist before you can call it, see create_event_dispatcher.

6. Compile and check it

Nothing takes effect until the Blueprint compiles. Compile, then read the graph back rather than assuming it looks the way you intended.

Compile:

bash

cfa compile_blueprint --blueprint-path "/Game/Blueprints/BP_Spawner"

Read the whole Blueprint back: graph, variables, components:

bash

cfa read_blueprint_content --blueprint-path "/Game/Blueprints/BP_Spawner"

Check execution flow and find unconnected nodes:

bash

cfa analyze_blueprint_graph --blueprint-path "/Game/Blueprints/BP_Spawner"

Reading back is the step people skip, and it is the one that makes an AI assistant reliable rather than hopeful. The agent can see that a pin did not connect, or that a node landed in the wrong graph, and fix it before telling you it is done.

When it does not work

Unknown parent class. create_blueprint fails rather than guessing. Run cfa search_parent_classes --filter <partial name> and use what it returns.

A connection silently does nothing. Pin names are exact and case sensitive. Use cfa describe_node to see a node's real pins before wiring it, and cfa search_nodes to find the node type in the first place.

The whole call was rejected. build_blueprint_graph takes rollback_on_error, so a bad node in the middle leaves the graph untouched rather than half built. That is usually what you want.

The graph looks tangled after several appends. Run cfa arrange_blueprint_graph to re-lay out every node in the graph. It is idempotent, so running it twice changes nothing the second time.

Where to go next

The full parameter list for every command here is in the Blueprints reference, or run cfa describe create_blueprint for one command at a time. For structs, see Blueprint Structs. For the UMG side of the widget example, see UMG Widgets.

Loading…

PreviousThe Editor Chat Panel NextAuthor a Material Graph