UEdGraph classes (Engine module) - safe to use for data architecture at runtime?

[Herr_Edgy]

Hello,

I’m thinking of basing my data architecture for my editor- and runtime-plugin on the UEdGraph and UEdGraphNode classes.
Those classes are in the Engine module, which is a core runtime module, so they should be safe to use in regards to packaging.

However, they ARE classes related to editors, and basically most occurences I found in the source code use the #if WITH_EDITOR preprocessor directives, so something tells me that there is a reason that UEdGraph fields do not get shipped.

Why is that? I just tested with an empty project and just by added a UEdGraph and UEdGraphSchema object to an actor it packages fine, so that suggests I can use them in my runtime data architecture. However, since the source code heavily implies NOT to do that, I wonder if the dependency on editor modules only becomes apparent later on or something?.That is of course, if I want to build an editor like the SoundCue editor or BehaviorTree editor.

[BrUnO_XaVIeR]

If you try to package a game using graph classes, it’s possible your classes to be corrupted depending on what you’re doing and the packaged game won’t run at all.

I never tried it, but doing that would be like stepping on eggs.
I would just make my own runtime graphs instead, just to make sure there’s 100% no surprises.

[Herr_Edgy]

@BrUnO_XaVIeR

If you try to package a game using graph classes, it’s possible your classes to be corrupted depending on what you’re doing and the packaged game won’t run at all.

I never tried it, but doing that would be like stepping on eggs.
I would just make my own runtime graphs instead, just to make sure there’s 100% no surprises.

Where does this come from? I mean, it does sound weird that Graph classes just get corrupted even if they are part of a runtime module.
I’ll see what I can do about it, thanks.