Skip to content

Logic Driver Assist ProOnly

Logic Driver Assist is a companion editor plugin that exposes Logic Driver's authoring operations as a registry of named, JSON-in / JSON-out calls. An AI agent (or any MCP client, or your own tooling) can build a machine end to end without ever opening the graph editor: create the blueprint, add states, transitions, and conduits, set node properties, wire variables, and lay the graph out. It can also measure the rendered graph for collisions, capture screenshots of the result, and inspect a running PIE instance. The operations route through Logic Driver's own editor APIs, so the results are identical to a person building the machine by hand.

Experimental, and separately distributed

Assist is an experimental plugin (IsExperimentalVersion is set). The operation surface and payload shapes are still evolving. It ships as a separate companion plugin, not as part of the base Logic Driver install. Download it from github.com/Recursoft/LogicDriver-Assist and drop it into your project's Plugins/ folder. It requires Logic Driver Pro 2.11 or newer.

Manual authoring is still the norm

Most state machines are best built by hand in the graph editor. Reach for Assist when you want an AI agent to build or edit a machine from a prompt, or when you are wiring Logic Driver into an agent-driven authoring pipeline. For programmatic authoring from C++ without an agent or MCP transport, use Graph Generation directly; Assist is a transport-and-agent layer over that same authoring capability.

Why a dedicated operation surface

An MCP tool is self-describing: the agent receives each operation's description and JSON schema at call time and decides how to use it. That is what makes an agent able to author a state machine it has never seen the code for. Assist exists to present Logic Driver's authoring capability that way, as a set of generic, well-described operations, rather than expecting an agent to drive the C++ interfaces or the Slate editor directly.

The surface stays deliberately generic. There are no dialogue-specific or combat-specific operations; those verticals are authored using the generic primitives (add a state, set a property, wire a transition, read it back). This keeps the operation set small and stable, and it means anything you can build by hand you can build through Assist.

How an agent authors a machine

   AI agent / MCP client
          │  operation name + JSON arguments
          ▼
   transport  (console · Monolith bridge · engine ToolsetRegistry · Ultimate Engine Co-Pilot)
          │
          ▼
   USMAssistSubsystem::ExecuteOperation
          │
          ▼
   Logic Driver editor APIs  (ISMGraphGeneration, graph schema, blueprint utils)
          │
          ▼
   structured JSON result  ──►  back to the agent

A single editor subsystem owns the operation registry. Every operation is dispatched by name with a JSON argument object and returns a structured result (success flag, error message, and a JSON payload). The plugin never talks to a model itself; it only answers operation calls that arrive over a transport.

Transports at a glance

The same operation registry is reachable four ways. You pick one based on your engine version and MCP client; the operation behavior is identical across all of them.

Transport Best for Endpoint
Console Smoke-testing and manual one-off calls LDAssist.Exec in the editor console
Monolith bridge Driving Assist from an MCP client today, on any supported engine version Monolith HTTP server, default http://localhost:9316/mcp
Engine ToolsetRegistry UE 5.8+, using Epic's built-in MCP server Stock ModelContextProtocol plugin, default http://localhost:8000/mcp
Ultimate Engine Co-Pilot Projects already using UECP, a third-party AI copilot with its own chat, MCP server, and ACP agents UECP's Logic Driver extension, maintained by BlueprintsLab

See Transports & Bridges for each transport's call mechanics and gotchas, and Setup & Connecting an Agent to install and wire one.

What it is and isn't

  • Editor-only. Nothing ships in a cooked build, so the plugin does nothing in a packaged game.
  • A thin, generic operation layer, not a vertical toolkit. Verticals are built on top of the primitives, not baked into them.
  • Transport-agnostic. Console, Monolith, ToolsetRegistry, and the Ultimate Engine Co-Pilot bridge are small adapters over one registry, so an operation behaves the same no matter how it was called.
  • Classified for permission gating. Every operation is marked read-only or destructive, so a client can auto-approve the reads and ask before the rest. See Transports & Bridges.

Where to go next

  • Setup & Connecting an Agent: install the plugins, build, choose a transport, and confirm the operations are live.
  • Transports & Bridges: the console, the Monolith bridge, the engine ToolsetRegistry, the Ultimate Engine Co-Pilot bridge, and a contract for rolling your own.
  • What You Can Author: the operation surface, grouped by what it does.
  • Authoring with an AI Agent: conventions to give your agent so its graphs come out clean and compiling.
  • A Dialogue System & the Lighthouse: a reusable dialogue system and a branching conversation on top of it, authored by prompting an agent, and why a prompt should describe the whole system.
  • Advanced Features: camera beats and an animation beat prompted onto that conversation, and the stacked-class pattern behind them.
  • What the Calls Look Like: the ld.* operations on a small machine, with the graph each call sequence produces.
  • Troubleshooting: symptom-first fixes for the common ways setup, a bridge, or an authored graph goes wrong.
  • Graph Generation: the underlying C++ authoring interface, for programmatic authoring without an agent.