Editor Extensibility

General Feedback & Requests
1

Dear Epic Games… I hate to be that guy, but I believe we have to talk;
From time to time, circumstances drive me to situations where I must extend the Editor, in a way or another.
Unfortunately, the more I encounter these roadblocks the more these situations are becoming: “-Oh god please no, one of those situations again!”

Putting drama aside, in short: we need someone working on a better streamlined Editor API aimed at extensibility.

I mean, latest event as example… I had to work on this; well, it’s just a simple Blueprint node right?!

1024×652 252 KB

For what I had to achieve, could be a simple task provided we had extensible classes in place.
I had to write over 1.000 lines of code to make this little K2 node work the way I need it to work. This ain’t even funny… C’mon now, that is kinda obscene!
And I’m not done with it yet, because there’s a final caveat that I have to address while “K2_” classes are completely undocumented.
I now see myself wandering around inside engine source code and learning about the Blueprint’s Kismet Compiler Context thingy simply because I don’t know how to make a simple “If Then Else” with pins when return values as UObjects are involved :smiley:
The fact that this ‘single’ spawn node is in fact composed by THREE hidden nodes that are generated in runtime doesn’t help either…

By comparison, I’ve made custom stuff for other engines before; it’s always a necessity…
Let me draw a “graph” to express how I feel the current UE4 workflow for editor extension currently is:

[Complexity]:

Now, we can make some “hacks” and actually use UMG widgets in custom UEditor panels.
But that doesn’t solve everything; we need, again, an API aimed at UEditor extensibility features such as extending K2_ classes easier and faster for example.

Take a look at this: Unity - Manual: Editor Windows
And they classify that as “advanced topic”… Oh boy. I wish doing that same for UE4 was that simple because by far UE4 is my engine of choice, the GameplayFramework is the best out there; but please, add better UEditor API for external developers :frowning: /rant]

2

I agree with the sentiment but… and pardon my blindness… what is custom about that node? Seems like a spawn node with exposed properties… I am probably missing something because I do not spawn stuff in BP that often.

3

Check the name of node. He is using actor pool what can be actually very nice feature.

4

Yes, this is not the normal spawn actor note, Skylonxe got that;
This is a “fake” spawn node I did to “recycle” bullets from a pool of actors I keep in memory. This pool component boosted my average fps from 28fps to 100+ fps when I have 2.000+ bullets on screen, simply because this node allow me to chose when and why I respawn a bullet (it has also an option to run or ignore the construction script of the Blueprint, not displayed in this screenshot).

5

That’s a pretty crazy looking node. :slight_smile:

Not sure what your purpose is with all those pins, but if you want pins for the expose on spawn functionality, look into use of FKismetCompilerUtilities::GenerateAssignmentNodes in the engine. That function essentially does that job for you and can be used on any custom node that creates an object based on a UClass input pin. You’d call it from your ExpandNode override.

6

Once you get grasp of Editor Framework, it’s actually easy to extend and it is well thought out.
The problem here is, that if there are no simple example of bare minimum implementations of various extensions points (like K2Node), it’s hell to figure out what you need to override and what is dependency of what you overrided.
What is sorely lacking is documentation and simple API examples.
I’ve been creating custom graph (like Behavior Tree), and amount of boilerplate code needed to get it working is actually quite big, but doing it from scratch would be even harder. Once I understood what/why it all makes sense, but it took me about 3 days of browsing trough code, and stripping it to get bare working minimum.

I’m not sure about Lumberyard/CryEngine being easier to extend than Unreal (in my experience they are even more tedious).

tl;dr there is **** load of Editor API, but it’s nowhere near documented, so you are blidning browsing random code to hopefully find something that will do what you need (or similiar) as starting point.
Editor API need documentation and samples. Without person who knows engine inside-out it’s hard to get deep into it.

7

That true of some parts. It’s absolutely not true of many other parts - large chunks of the editor code have clearly been written with the assumption that noone will want to extend them from plugin/project code, and as such it’s next to impossible to do so without engine modifications.

8

The only part of the editor code I’ve extended was the graph editor, to create my own blueprint-like editor, and I agree that some more documentation would be splendid. Personally though the part with which I had the most issues was the serialization of my assets, or rather, the traversal of the graph to pack the data into the asset (and the inverse re-creation of the graph). Considering how many graph editors the engine has you’d thing there’d be some sort of standardized functionality for that.

9

Many of the engine’s functions for the Editor echosystem actually have params or functioncalls that aren’t doing anything… Really, this is not a joke; there’s things in there, specially functions with local params that I’ve seen declarations for nothing.
Example: to finish this node I looked into the default Spawn nodes from the engine, and although they all work, they have a lot of useless code thrown in there that does nothing.
I mean, this is also a factor that difficult the learning process. “-how much of this code I see here is actually a requirement?”

This area of the engine needs more love, the gameplay framework is much more polished.