Is there a best practice for adding UI extensions to the editor within the primary game module, or is it mandatory to make a new module? I guess you could use a bunch of #ifdef WITH_EDITOR inside your primary module’s declaration and implementation, but is this the expected method for implementing it?
There’s a real lack of information regarding extending the editor, whether just simple extra menu buttons or going the whole way up to custom Graph Editors.
I am not sure about a “best practice”, because of the lack of information, as you have stated.
It really resolves down to the practicality of the matter, in that Plugins, are pretty much the only way you can go. For myself, I have put off writing a Editor plugin at this point, because of a desire, to be able to write a generic slate module, that can pull in a flat text file, and construct windows, etc based off of that. Hence i’m looking at keeping the editor functionality that I desire, to be encapsulated in it’s own module.
With that said, I still have the #if WITH_EDITOR scattered in some code for the plugin i’m getting ready to release. It’s not a big deal to me at all really.
So “best practice”, I really doubt there is one, it’s more a “roll your own”.
.
Editor it self runs on UE4 they are not seperate, all editor APIs are accessible from any point, ofcorse when games get package those APIs are unavailable
Modules are equile and can do the same things regardless where they are engine source, game project or plugin they will work the same, only difference is distribution, so it’s ok to do editor module in game project if you make game specific thing, but if you want to make something that works in every project, plugin is the thing.
In game project insted of .uplugin you add modules to .uproject file, structure is the same as in uplugin
With editor code, best practice is to have editor code in sperate module and mark it as "Type": "Editor", but if you really can’t seperate the code you use WITH_EDITOR, or mix of two, generly editor only class should be in sperate module.
As for how to start first you need to learn about Slate, editor UI framework… which also powers UMG and its avable in client to make game ui:
Slate User Interface Programming Framework for Unreal Engine | Unreal Engine 5.1 Documentation
A new, community-hosted Unreal Engine Wiki - Announcements - Epic Developer Community Forums
Also watch this, it a nice start point:
check up plugin templates as they show simple examples. Other then that look up engine source code, plugins source code to see how things you see in editor look like in code.... sadly thats only way to learn editor devlopmentThankyou for the response.
As for learning Slate, and so on, I’ve done a fair bit of work with it in the past, with creating Widgets, but that’s a far cry from creating a full custom Editor for a new asset type, for example.
There’s actually a fair bit of documentation on creating custom details panels, just wish there was similar information for utilizing SGraphEditor/FStaticMeshEditor, or even the real basics of FExtensibilityManager.
The training stream you linked looks really useful so I’ll take a look at that and see if it deals with what I’m looking for.
Look up sound cue and sound class editor source code, is one of simplest graph editors.
https://github.com/EpicGames/UnrealEngine/tree/release/Engine/Source/Editor/SoundClassEditor
https://github.com/EpicGames/UnrealEngine/tree/release/Engine/Source/Editor/SoundCueEditor
Importent note is that graph is like text code, just a discription… blueprint 
using that graph you compose a data which will be used to compose data used in gameplay, for example sound cue use only one graphnode class to hold sound cue node data and when you save it spawn sound cue nodes objects and change them together
You probably also interested in creating assets type, you start with making AssetToolAction class which descibe the asset and actions you can do. Engine holds all assetstoolaction classes in one module but you can place it on any module:
As those classes are not UObject you need to manualy register them on module load for make edito to support asset:
But thats only to support asset in content browser, make import or create new asset you need to make UFactory class… but i gonna leave that as homework for you… it not that hard to figure if you look on other UFactory classes
Quite helpful - thankyou.
That, put together with the video you linked earlier, should fill in the basics. I’ve done my fair share of digging through the code for tips on how to implement things in the past, but at times it is difficult to ascertain the bare minimum implementation required.
I was originally asking about if the acceptability of using editor code in the gameplay module, because I’m co-authoring a book, and doing so would keep the sample code simple. I’ll be moving forward with an editor module instead, though, it seems a more robust long-term way to do things.