Development > Programming & Scripting Python Programming & Scripting > AI Pipeline & Plugins > Editor Scripting
Niagara’s node-based internal logic is difficult to provide to Codex or Claude Code. Screenshots show only fragments of a graph, while standard Unreal Editor APIs mainly expose integration-level information rather than complete module stacks, nested graph relationships, and Scratch Pad implementation details.
Since January, I have used a Python export workflow across multiple Unreal projects, ranging from simple prototype systems to more complex FLIP fluid simulations built with Niagara Fluids.
The workflow exports a Niagara System through Unreal’s native text exporter. It preserves the complete raw .t3d export and produces a smaller, project-specific .txt version for the AI agent to read first. The filtering rules are customizable: each project can decide which compiled data, editor state, embedded resources, and other information should be removed. If the filtered context is insufficient, the agent can request the raw export or additional project information.
The NS_Fountain text files show the expected outputs from a simple fountain particle system. They show the size reduction from filtering. Check them out by throwing them to AIs.
- Raw .t3d: 363,587 bytes
- Filtered .txt: 41,200 bytes
- Size reduction: 88.7%
The current read process can be automated: the exporter can be called by AIs using Unreal’s commandlets, after which an agent can read the generated text. The write process remains hybrid. The agent can analyze the Niagara structure and generate HLSL, parameter definitions, namespaces, and module-order instructions, but the user still creates the Niagara parameters, pins, Scratch Pad module, and graph connections manually. I have included the specific prompt template that I use here, using the fountain as an example:
I have a Niagara system that uses the default fountain. I want the system to read an actor's position in the level and use that position to apply a constant pulse to the particles within a radius range. That pulse should switch between an attractive force and a repelling force. Give me the new user-exposed parameters needed, the HLSL code for the custom scratch pad, the input and output variables of the HLSL code, the map-get and map-set parameters for the scratch pad, the simulation stage where I should put the scratch pad module, and the order of the modules inside the simulation stage. Do not write comments in the HLSL code. Map-get pins should clearly label the namespace for each parameter. HLSL output pins will go directly into Map-set. No calculations or logic happen between the HLSL node and Map-set.
The complete MIT-licensed package includes the exporter, tutorial, expected outputs, screenshots, and reference project:
Workflow, tutorial, and Python exporter
I would like to hear whether this approach is useful for you guys, what information or functionality feels missing, and what you guys can do with this workflow.
Thanks for reading.