Mega Grant Recipient 2020!
[HR][/HR]
Hello!
I have been using this for a while now and, even though I didn’t have the time to put together extensive learning resources, I believe it’s ready to be shared with you guys
I’ve put together a system which I call “Magic Nodes” (lol) where we can write some C++ functions in-place on any Blueprint Graph and that node will “morph” to match the input and output parameters of the function you wrote within the node itself. Some people might be confused of why we would need this, but instead of trying to advocate the tool I’d rather let your own experience speak for itself; there’s numerous tasks where dragging wires on Blueprint Editor slows down productivity and this tool could be useful to address that, sometimes it’s simply faster to type a few lines of code instead of dealing with wire spaghetti!
With this I also hope, with time, Blueprint developers have a first contact with C++ code and slowly become comfortable moving to Visual Studio workflow later on, if wanted
So, what is this… A few super simple simple examples:
We can type some code, compile (hot-reload), and the node will “morph” its pins to accommodate and execute the function we wrote inside of it.
This can be very handy for developers missing something in-between Blueprints and pure C++ code…
Also it’s very useful to actually “read” right there what exactly that one node is doing.
While coding our functions in this node, we can have some basic auto-complete functionality as well.
However keep in mind that I have no previous experience with any of this, turns out making an auto-complete feature is a beast of a complex task and I’ve implemented only the very basics!
For example, in this screenshot the node detected I am trying to invoke a function from a ACharacter class, so while I was typing it will show me functions and properties members of ACharacter class:
Yes,this will definitely help in moving over to C++, allow learning and replacing incrementally without fear of destroying existing projects.
Just curious, any added bonuses like performance in packaged builds using these nodes over blueprint nodes? or nativization issues or benefits, regardless this is brilliant, cheers.
Hot-reload times are much faster than when you change a whole character class in C++ for example.
This plugin only work on C++ projects, because it generates C++ classes for your nodes.
It self-nativize by default.
The cost of calling one node is the same of calling a C++ function. You can have multiple functions in your node code, they will be all native C++ functions (no VM cost).
There’s only 1 VM cost per node, just like any functions created in pure C++.
You can create and call hundreds of internal functions within your node code and call them, the VM cost ia still going to be just one.
If you call Blueprint Function on the other hand, the VM cost is the function * nodes it contains, each one is a VM cost…
So in this system’s case, your runtime cost is just the same as if you were coding everything from pure C++ in Visual Studio. 1 VM cost per node executed
In fact this plugin generates its own C++ code from the nodes you create, you don’t even need to nativize anything, it’s native code by default!
The generated C++ classes are stored inside your project’s Source/MagicNodes folder (automatically).
Those generated native classes are what is executed in your packaged game, the nodes are just “hosts”.
Fantastic,
hopefully someone at epic sees the value of this and moves a bit of that dev-grant money your way for your ongoing support of the community.
I would be more than happy to help Bruno at repository level to maintain the code, thou I might not have time to add functionality to it besides just maintain new engine releases
Fantastic job as always [USER=“434”]BrUnO XaVIeR[/USER] !
PS: apply this to Unreal Dev Grants if not already!!
Everything should be set now for Marketplace release.
Later on I will setup a GitHub public repo as well, but before that, I want to collect feedback from both users without coding experience and C++ veterans.
For now, I’ve written a little bit about the ins and outs of this system and how it is meant to work for you, here:
The first iteration I was compiling them to a library.
But then I noticed that hot-reloading time was increasing the more nodes I create.
Now what I do is create source files for each node class, hot reload became way faster and will remain the same time always, when I recompile just one node.
Now instead of packing them within a library, I pack their source files inside the Source/MagicNodes/ folder. You will be able to see each generated class within Content Browser’s C++ directory.
The good thing is, if desired, you can remove all Magic Nodes from your Blueprints later and destroy the “Script” asset once the C++ class is generated and compiled. Then you include and use the C++ code directly. So the nodes in this case would be just a testing environment before moving your algorithms to full C++ in Visual Studio environment…
I’ve been doing that. Once a node works the way I want, and I know I will never change it again, I delete the node asset and call the native functions directly from my Character.cpp.
Only nodes that are really self-contained I leave them running as is, when the functionality doesn’t fit any of my native classes.
Oh I think I forgot to mention in the blog post to include “MagicNodeRuntime” module to Build.cs file for that, to make those sources usable by native project classes, otherwise project classes might cause error when calling magic node functions directly.
