Okay, bashed all bugs I knew of, ported plugin to Unreal 4.19 and 4.18… (updated 4.20 as well)
I did not create a custom layout for the new tabs, so for the first time you execute the tabs from Toolbar button, “Function Transfer” tab will spawn exactly same size and place of “Property Transfer” tab (behind it);
Just manually drag them tabs to share the same Editor window :]
Note about transferred Macros & Macro calls:
I am unable to replace Macro calls from within Function Graphs.
That means that whenever you copy a Function that contains calls to a Macro, you later have to replace that Macro call to the new one, otherwise Editor will complain about “external linked graphs” (can’t save blueprint, blah blah).
*BP_MyActor *has *MyFunction *and *MyMacro *in it.
Transferred *MyFunction *to BP_MyComponent.
Transferred *MyMacro *to BP_MyComponent.
The call to *MyMacro *within *BP_MyComponent *will still call the Macro from *BP_MyActor *instead of calling the new one in BP_MyComponent.
So, replace *MyMacro *node call with the new *MyMacro *within *BP_MyComponent *and everything be fine. Now BP_MyComponent can be saved and works without issues.
The issue above doesn’t apply to Function node calls, just Macros (as long all the called function nodes do exist on Blueprint you did transfer the function graph calling these nodes).
This has been sorrowfully missing in the editor until now and **greatly **improves fast prototyping (e.g. you start with a couple of variables in your PlayerController or Pawn and before you know it you have dozens of them and a graph full of functions that would be better placed in a component).
Not sure about tutorials, Epic had some on the technical aspects of how to use those, but I imagine you’d be hard pressed to find any that will go into general compartmentalization principles in programming, i.e. when to use them.
Ideally, you would plan your systems in advance and lay out what functionality to place in what classes or components, though admittedly, Blueprint is a great tool to do just that - plan and prototype your game logic and later either refactor and reorganize (e.g. into components) or rewrite in C++ code.
In general, while still learning and especially when working on a project with no clear development path, you will frequently find some elements of your gameplay logic outgrow in complexity what you initially anticipated, at which point moving them into their own components or classes is the best approach, both, in terms of reusability (same code for several types of actors) as well as for clarity (e.g. it is that much easier to manage / debug / modify / extend a “Health System” component in your character, that organizes all variables and functions related to that aspect, than it would be to hunt those down in the base class which at some point would grow into a big pile of …everything).
Blueprint reorganization such as this is now, luckily, much less manual labor - thanks to BrUnO’s plugin here.