Skip to main content

C++ API

Other plugins and project modules can call the organizer directly instead of going through the editor UI. The entire public surface lives in one header, and it's stable across the 1.x series.

Dependency​

Add UeaboCore to your module's PublicDependencyModuleNames (or PrivateDependencyModuleNames) in your Build.cs file.

#include "IUeaboOrganizer.h"

Getting the module​

IUeaboOrganizer& Organizer = IUeaboOrganizer::Get();

Options​

FUeaboOrganizeOptions Options = FUeaboOrganizeOptions::FromSettings();

FromSettings() builds an options struct from the user's saved Settings, so a plugin-driven organize pass behaves the same way as pressing the shortcut. You can also construct and populate FUeaboOrganizeOptions by hand to override any field.

Organizing​

FUeaboOrganizeResult OrganizeGraph(UEdGraph* Graph, const FUeaboOrganizeOptions& Options);
FUeaboOrganizeResult OrganizeBlueprint(UBlueprint* Blueprint, const FUeaboOrganizeOptions& Options);

OrganizeGraph organizes a single graph; OrganizeBlueprint organizes every graph in a Blueprint plus its members. Both run as a single undoable transaction, exactly like the editor shortcuts.

Result​

FUeaboOrganizeResult reports what happened:

FieldTypeMeaning
bSuccessboolWhether the pass completed.
ErrorFStringPopulated when bSuccess is false.
Before / AfterstructNodes, Crossings, Comments counts, taken before and after the pass.
OrphansRemovedint32Orphan nodes deleted.
RerouteRemovedint32No-op reroutes deleted.
CastsMergedint32Duplicate casts merged.
VariablesRenamedint32Variables renamed for bool-prefix/PascalCase enforcement.
SuggestionsTArray<FString>Human-readable suggestions (extract-function candidates, deep branches).

Stability​

This API is stable in the 1.x series: signatures in IUeaboOrganizer.h won't break across 1.x releases. It stays in that one header so it's easy to track.