Blueprints

Split by whether they change your project. Read-only tools are always safe to try.

Reading

• Describe Blueprint — Parent class, graphs, variables, components and COMPILE STATUS of a Blueprint. Check the status first: a Blueprint that is Dirty or Error looks fine in the content browser and fails at runtime.
• List Blueprint Nodes — Nodes in one Blueprint graph, with a node_id you can pass to the authoring tools, plus title, class, and how many pins are connected. Use this to understand a graph before changing it.
• List Blueprint Variables — Blueprint member variables with type, category and default value.
• List Node Pins — Pins on one Blueprint node: name, direction, type, current connections and default value. You need this before wiring anything, because connections are made by pin NAME.

Writing

• Add Blueprint Node — Add a node to a Blueprint graph and return its node_id. The new node is UNCONNECTED - wire it with hf_connect_blueprint_pins, then compile. Supported kinds cover most graph work; anything else still needs the editor UI.
• Add Blueprint Variable — Add a member variable to a Blueprint and verify it exists afterwards. Does not compile - call hf_compile_blueprint after. Leaves the package dirty; call hf_save_object to persist.
• Compile Blueprint — Compile a Blueprint and report every error and warning. Always compile after changing a Blueprint - an uncompiled change does not take effect and the asset still looks fine.
• Connect Blueprint Pins — Wire one node's pin to another's, validated by the Blueprint schema. A rejected connection reports the schema's own reason, such as a type mismatch. Compile afterwards.
• Delete Blueprint Nodedestructive — Remove a node from a Blueprint graph. Its connections go with it. Undoable; compile afterwards.