Unreal “Magic Nodes” (Programming)



I’ve put together a system which I call “Magic Nodes” 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 we wrote within the node itself. Reasons behind why I built this is, in part, because 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.




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 an auto-complete panel will popup, showing me functions and properties members of ACharacter class:






Here a quick intro of how these nodes are setup and how to make them work correctly for you…
Because this is “real C++” (encapsulated into a safer environment), but still C++, these nodes require your Unreal Project to be a C++ project in order to execute.
Magic Nodes rely on Unreal’s Hot-reload feature to be useful. The basic workflow:


  1. Just like regular C++, you have a Header field (H) and a CPP field (CPP) where you can declare and define you node’s functions, respectively. Alternatively there’s also a Type field (T) where you can declare any additional types such as enums, structs or classes that your node will use at runtime to execute the code you create.
  2. Before compiling your changes, you have to save your node, that will update the “root source”, the source which stores your code and shares it with all the instances of your node. You can place on Blueprints multiple instances of your node, the source code to execute will be the same for all of the instances executed.
    “Ctrl+S” works as a shortcut for this save button.
  3. Once you’re happy with your code, you need to compile the node, this first button from the Node toolbar. This will run a pre-compilation system that will examine your code… If everything seems correct the this pre-compiler will do all the work necessary to generate (or update) a native C++ class which is what is going to be executed at runtime once your game is packaged. That means that this node is just a “shell” holding the entry point of where and when your C++ code will execute within your Blueprint Graph. The node itself is purely visual and in reality doesn’t do anything besides display to you what it is going to execute.
    If the pre-compiler is happy with what it sees in your code you should hear a “success” beep sound confirming that it indeed generated the native node correctly.
  4. If the pre-compiler is happy with your code, next step is to tell Unreal Engine to incorporate the node runtime into the Blueprint’s Graph execution flow. We do that by hitting the Hot-reload button from the main editor’s toolbar.
    This step is where the actual C++ compiler kicks in and catch any deeper defective code you might be trying to compile; If you can’t get past this stage, it’s a good idea to ask C++ veterans on Unreal’s forums, usually they can point out what exactly is wrong with your code.
  5. Once Hot-reload compilation is complete, this is where the “magic” part comes in… Click the refresh button and the node, now properly compiled to binary library, shall update its input and output pins to reflect the entry function in your code (“FSelf::Execute” function). Once pins are generated and/or updated, you can proceed to link your target variables to it and/or set default values of your pins.




Let’s create a node which takes a reference to our Character Blueprint, subscribes a native (node’s internal) function to Character’s “Jump” event and then tells the Character actor instance in game world to jump… This example characterizes as a “Persistent Node”, it keeps running like an Async Function such as Delay Nodes.
Of course, you could simply call the the “Jump” node instead and be done with it, but the point here is to exemplify how you can do that same action from Native C++ with magic nodes instead of calling one new Blueprint Virtual Machine‘s function for every single node you need to call (VM function calls in the end have heavy performance implications, they are orders of magnitude slower than native code and many developers end up converting good portions of their code to C++ because of that). The fact that we can add hundreds of functions to a Magic Node’s source and a call to that node is going to be just ONE call from the Virtual Machine, that’s a performance boost to be considered while at same time we don’t have to deal much with complex plugin modules setup (lot’s of boilerplate code) just to run our functions is also a workflow improvement, there’s much less support code to write on Magic Nodes…

So, make sure that you have Magic Node plugin installed and properly activated:



First we will need to create our “source”. We can do this from File -> Project -> “New Magic Node Class…“; That will create a new Magic Node pack in your content browser:



Once the source is created and named, let’s forget about it for now. Let’s go to our Character Blueprint and add a new Magic Node to its Graph:



We now have a “shell” to execute our node. By default it is empty, if you try to compile the Character Blueprint you’ll see Unreal’s Blueprint Compiler to complain about it:



So, that source pack we have created before, we need to tell our shell to use that source we have created, for that we use the asset picker right below that error message on the node, it will bind this shell node to our source so we can start coding our functions in it:



Now we have our source and the node shall become editable. If we try to compile our Character Blueprint once again, you might notice that it now recognizes our Magic Node as valid, however it will now complain it can’t allocate the entry point “Execute” function even though we can see it is there in our source. The reason why it is that way is because the runtime C++ only cares about compiled binaries, it doesn’t care or interact with any components of the Blueprint’s Virtual Machine:



We don’t have to care about that right now, let’s proceed and create our node’s code.
To make it work, we’re going to directly use two member classes of Unreal’s Game Framework, Character class and Input Component class. To use them, we have to include the path to their respective header files; if you’re not sure where those headers are located you can type their types in your script ( ACharacter, UInputComponent ) then Ctrl+LMB them: The Magic Node will launch your browser and search Unreal’s API website for your looking for those classes pages. If the page exists, you should be redirected to these pages, at the bottom of the pages you can find the paths to their headers, here:


Click the “+” sign of # Includes row to include their paths:



Done that, we now need to type some code to achieve our goal.
Let’s add this functionality to our H section and CPP section of the node
(don’t worry about the “Character” pin already visible here, that is only there because I have already compiled this node).
Code to the left goes within the Header (H), right one goes within the CPP section:



Epic Games team added the same “Subscribe()” function to Unreal Engine on 4.24 and above. To avoid problems then we have to use now “Enroll()” macro inside of Execute function, instead of the “Subscribe()” you see above.


Done that, let’s now save and pre-compile our node, from the node’s toolbar:


Then tell Unreal to compile the binary version of our node.
Clicking the Hot-reload button:



Once Hot-reload compilation is complete, let’s head back to our node’s toolbar and click the “Refresh” button:



Done that, we shall now see that your Magic Node now displays an input pin called “Character”. Let’s attach to it a variable of our Character’s self Blueprint:



If you did everything correctly, now compile the Character Blueprint (Blueprint toolbar, not Hot-Reload) and then your Character Blueprint should now be happy and understand what have just made; When playing in editor, if you press the space key the character will jump (make sure you have input settings setup on project settings panel):



And that’s it, a quick example of how to run native C++ code on Blueprint Graphs without leaving the Blueprint Editor to work on external applications such as Visual Studio!
If you leave the game running for a while though, the code will stop working…
That will happen because Unreal will run a Garbage Collection operation and our Magic Node running will be destroyed. It’s simple to avoid that, because our node is latent (Persistent Node), we don’t want it to be garbage collected, so we just have to change the declaration and definition body of our “Execute” to output a self-reference, like this:


Then we save the script, pre-compile again, Hot-reload again and now after Refresh our node has an output pin. We promote the output to a variable (here named “Controller Script“) and make the Character Blueprint hold a reference to it, so while our Character Blueprint exists the Magic Node will never be garbage collected:


When we are done with it and want the node to be destroyed, all we have to do is set the variable “Controller Script” to null pointer. The next time Garbage Collector runs it will collect the remains of our node and destroy it as expected!


But what if we don’t need a persistent node?
In this case it’s way simpler. We can write the whole functionality within the entry point “Execute” function. Doing so will NOT generate any garbage and the Magic Node will be a “Fire & Forget” type of node, it will be destroyed right after execution flow (white wires) leaves the Magic Node, just like any regular Blueprint nodes!
Like this example node shown previously:


So, I’m running out of time for now, this should illustrate how the general workflow is meant to be when you create Magic Nodes. If you have doubts and questions, feel free to ask in the Unreal Engine’s public forums (link below).


When you want your C++ classes to reference and use Magic Node classes from the Source/MagicNodes/  directoy, besides including a node’s respective class header, make sure you add the “MagicNodeRuntime” module dependency to your project as well:



-We don’t make mistakes, just happy little accidents!”  — Bob Ross
Happy coding!



You can find more about this tool and contribute feedback on Unreal Engine’s forums here: https://forums.unrealengine.com

This is a simple Editor Plugin for Unreal Engine.

It helps to batch transfer Blueprint Properties (variables) between any number of Blueprints selected on Asset Browser.



It’s very simple to use:

  • Pick a ‘Source’ Blueprint.
  • Pick Target(s) from Asset Browser.
  • Pick which variables to copy.
  • Click ‘Apply’ and save.

Property Picker supports keyboard modifiers:

  • Alt + Click: Pick variable under cursor right away.
  • Ctrl + Click: Unselect selected variable.
  • Shift + Click: Multi-selection.

Property Transfer Tool for Unreal (Programming)


  • This Plugin implements for you accurate data types to represent Decimals and Money values compatible with the Unreal Engine environment.
  • All Currency types introduced are IEEE 754 compliant, C++ Classes to represent accurate world currencies defined by ISO 4217.
  • The FDecimal type can store up to 10^24 (29 signed digits): 99.999.999.999.999.999.999.999.999.999;
  • The FDecimal type can be used on both C++ and Blueprint objects and actors.
  • Replication and Serialization are handled by converting from Decimal to a subset of TCHAR* packs to maintain absolute precision.
  • The FDecimal type introduced is optionally compatible with the FSafe Structs from the SCUE4 Anti-Cheat system: https://www.unrealengine.com/marketplace/scue4-anti-cheat-solution
  • Implementation is based on Intel RDFP Math Library: Copyright(C) 2011, Intel Corporation. All rights reserved.

Why not use Float or Double to store in-game currency?

  • Because floats and doubles cannot accurately represent the ‘Base 10’ multiples used for money representation. The problem with floats is that the majority of money-like numbers don’t have exact representation as integer times power of two. Representing money as a double or float will probably look good at first as the software rounds off the tiny errors, but as you perform more additions, subtractions, multiplications, divisions on inexact numbers, you’ll lose more and more precision as the errors add up. This makes floats and doubles inadequate for dealing with money values, where perfect accuracy for multiples of Base 10 is required. While using Int32 or Int64 you are limited by size and cannot accurately represent real-world monetary numbers. The FDecimal have large precision of 128 Bits to guarantee your players will not lose any in-game currency during regular transactions. This is invaluable for games where the player must be able to store large amounts of money, such as RPG tiles.

Why Intel’s Decimal Floating-Point Math Library?

  • Decimal floating-point operations were a necessity from the beginnings of the modern age of computing. However, the lack of a good standard for decimal computations has led to the existence of numerous proprietary software packages for decimal or decimal-like computation, most based on fixed-point decimal types, and each with its own characteristics and capabilities. A turning point for decimal computation is the revision of the IEEE Standard 754-2008 for Binary Floating-Point Arithmetic as an important addition to it is the definition of decimal floating-point arithmetic. The primary motivation was that decimal arithmetic makes numerical calculations more human-friendly. Results will be as people expect them, identical to what would be obtained using pencil and paper. Decimal arithmetic also provides a robust, reliable framework for financial applications that are often subject to legal requirements concerning rounding and precision of the results in the areas of banking, telephone billing, tax calculation, currency conversion, insurance, or accounting in general. The binary floating-point arithmetic that computers use does not always satisfy the existing accuracy requirements. For example, (7.00 / 10000.0) * 10000.0 calculated in single precision is 6.9999997504, and not 7.00. Similar examples can be found for double precision, or any other binary floating-point format. The underlying cause is that most decimal fractions, such as 0.1, cannot be represented exactly in binary floating-point format. The IEEE 754 standard proposal attempts to resolve such issues by defining all the rules for decimal floating-point arithmetic in a way that can be adopted and implemented on all computing systems in software, hardware, or a combination of the two. Intel’s implementation will run on any platform based on Linux™, Windows™, HP-UX™, Solaris™, or OSX™.

The Library is available at GitHub:

UE4 Decimals (Programming)

UE4: Finite State Machine (Programming)

I’ve developed a new  UE4 Plugin. Simple, yet powerful, Finite State Machine system which allows you to manipulate Actor States through Animation Graph’s State Machines, Behavior Tree Tasks, Blueprint Graphs, or C++ Native Code.
Finite State Machines allows for more logic encapsulation and cleaner code architecture in general, drawing systems design and debugging easier on the long run.


Some Features:

* Blueprintable Finite State Machine System.
* Blueprint Actor Component Based.
* Event-Based Tasks/Actions can be Broadcasted.
* Supports Enumerators as State ID.
* Supports Runtime State-Machine Creation/Deletion.
* Supports Runtime State-Machine Event Bindings.
* State Machines can Tick and Track Update Time.
* FSM Properties can be Replicated.
* Get/Set States from C++, Blueprints, Animation Graphs, Behavior Trees.


How to use:

* First, get the Plugin (not published yet :p) for your compatible Unreal Engine 4 version and install it. After successful installation, you’ll be able to use the FSM Component and its link interfaces. Add to your Actor a FSM Component and you’re good to go.


The  Component:

* Launch UEditor and pick an Actor which you want to use FSM with;
From the default Details panel, click ‘Add Component’ drop-down and from the ‘Custom’ group select ‘Finite State Machine’ component; Give it a name.


Blueprint Graph Usage:

* From your Blueprint’s Graph, Component tab, select the State Machine and then you can see in Details panel under the ‘Events’ group there’s now three items: ‘On Begin’, ‘On Update’ and ‘On Exit’.

Clicking one of those Events, then you can attach Blueprint Functions to execute bound to each of them and query for current State ID or Name. The buttons adds a custom Event attached the the FSM Component, since State IDs are unsigned bytes, you can create Blueprint Enumerators and compare against IDs for good code readability.

* Blueprints that have the FSM Component attached also have access to all its Get/Set/Remove State functions as well. You can Add/Remove States any time, in running game, not just in Editor.


Animation Graph Usage:

* If you wish so, you can make a FSM Component reflect a State Machine inside an Animation Blueprint. This however applies only to Skeletal Characters.
Animation Graph’s State Machine Editor is great to setup a FSM and keep a complete visual reference of how your FSM behaves. To do so, you create an Animation Blueprint as usual for your Skeletal Asset, but instead of choosing AnimInstance as Parent Class, pick ‘StateMachineABP’.

* That way your Character can set FSM States based on its Animation States while you react to State changes from your Character Blueprint easily. Once you have your new Animation Blueprint set, in ‘Class Defaults’ you can dictate which FSM Component syncs to Graph and which Animation’s State Machine you want to link.

* Once ‘Override FSM’ in Details panel is enabled, the FSM Component attached to your Character Blueprint will automatically replicate and follow the States from Animation Graph every time it changes. This requires you to use in Character Blueprint the Animation Blueprint Class you have your State-Machines, of course; But you can create multiple State-Machines inside Animation Blueprints for a variety of purposes so this doesn’t affect workflow for the actual Animation States, simply create a dull Machine for FSM Graphs without any code affecting the skeletal entity.


Behavior Trees Usage:

* You can also manipulate FSM States within an AI Controller’s Behavior Tree Board. Using the custom Task nodes: ‘Add State’, ‘Set State’, ‘Check State’, and ‘Remove State’, you can easily make your AI dictate FSM Component’s States based on AI decisions. This is also an awesome way to easily make your AI react to changes within an Animation Blueprint’s State or react to changes within a Character Blueprint’s Events.


Native Code Usage:

* So you are more of a C++ guy?! No problem, setting up a complex FSM within a C++ Class is as simple as creating sub-objects. An additional power you have from Native Code is you can bind Functions to FSM States, directly.

You can bind a new Function to States during runtime, or unbind Functions from it while the game is running as well. You can also easily manipulate States by State Name, State IDs or even directly compare against Enumerator types, with very simple lines of code, such as:

[At 1.3+: StateMachine->SetActive(true,false); is required to activate FSM]


C++ Character Class example, using the API from UFSM 1.6.0+ :



Final Note:

* With a little bit of imagination, this little tool provides unlimited possibilities! Thanks to the awesome environment provided by Epic Games and their Unreal Engine 4.
If you’re used to work with State Machines, such as Unity PlayMaker, you’ll quickly adapt to the workflow proposed by this Plugin; You can really encapsulate all code logic into Finite State rules. If you never tried FSMs before to build game logic, it will set you free of infinite spaghetti piles of code on the long run, give it a try!