Dear Community,
After delving deep into the engine code, and learning a lot about the special K2 nodes that require special classes and special code, I’ve learned how to use wild cards!
I will explain what I’ve learned below!
I’ve compacted the 14 nodes of my Config BP Suite into just 2 !
My 2 nodes support 7 different variable types!
Pull Request Link
https://github.com/EpicGames/UnrealEngine/pull/1083
(You need to be logged into your UE4 Github account to view this link)
**Video of The Pull Request**
Check out this video!
The single pin in my 2 nodes can become 7 different variable types!
https://www.youtube.com/watch?v=xwGMNNJFaz8
If you'd like to see these 2 Wild nodes added to the engine you can post at the link above!
What Is This About?
I’ve observed and received a lot of feedback from the Community that support for config files in BP would be greatly appreciated.
I originally made 14 nodes and submitted this pull request to Epic. https://github.com/EpicGames/UnrealEngine/pull/604
Epic asked me to turn the 14 nodes into 2 wild card nodes that would support the 7 different file types.
I had no idea how to do this.
I spent all last night researching how to do this by reverse engineering one of Epic’s only single-value wild card nodes.
My biggest hurdle was that most wild card nodes were array based, and had special support for not needing to be a K2 node.
Well now I present to you my very first K2 custom class BP node, that has wild card support for 7 different file types!
See the video for full details!
**Pics**
How Wild Card Nodes Work
I thought I’d offer a brief explanation of what I’ve learned so far about how wild card nodes work!
Inside of K2 nodes there is this section like this:
void UK2Node_GetGameConfigVar::ExpandNode(class FKismetCompilerContext& CompilerContext, UEdGraph* SourceGraph)
{
Super::ExpandNode(CompilerContext, SourceGraph);
Within this function, the BP node can be converted into other “invisible” nodes that exist only within the Blueprint Graph Intermediate.
These are nodes you never see!
But you can programatically generate these other nodes and connect their pins using the ExpandNode function!
So basically you are making nodes and connecting pins for invisible nodes with C++ code !
**Why Create Nodes Within Nodes?**
Why would you want to do this?
Well for one thing, wild cards of course! (another reason is SpawnActor which actually internally made of BeginSpawn and FinishSpawn hidden nodes)
Now what you see as the generic BP node is actually going to "morph" behind the scenes based on the type it determines you have given it, as you see in my video above.
When the BP graph is compiled, this generic node transforms invisibly into the correct type.
This means that the correct BP node with the correct typed inputs/outputs has to exist somewhere.
ConfigBPLibrary
In my engine integration I created ConfigBPLibrary to house these nodes, which are hidden from the context menu via
UFUNCTION(meta = (BlueprintInternalUseOnly = "true"),
My K2 nodes,
UK2Node_GetGameConfigVar
UK2Node_SetGameConfigVar
Each call the 7 different kinds of Get/Set nodes that I put in the ConfigBPLibrary, and choose which one to “morph” into at ExpandNode time.
To be clear though, the wild card node actually deletes itself and is not part of the final blueprint graph from the runtime engine’s perspective!
This is actually important for packaging the game!
My K2 nodes, like the others, have a lot of Editor dependencies, and the game would not package very happily depending on UnrealEd and KismetCompiler, etc etc.
So the ConfigBPLibrary is a runtime library, whereas the K2 node are Editor-side.
This means that my K2 Editor-only nodes quietly delete themselves and replace themselves with the appropriate Runtime-friendly type-specific nodes!
**The Most Technical Part**
The most technical part of this process is in ExpandNode where you must carefully "wire" the nodes that you create together!
Here's a small code sample (legal reasons)
```
//!
// Move the input pins to the function
CompilerContext.MovePinLinksToIntermediate(*FindPin(FGetConfigNodeName::GetSectionPinName()), *CallFunction->FindPin(TEXT("SectionName"))); //See video to see this in action!
CompilerContext.MovePinLinksToIntermediate(*FindPin(FGetConfigNodeName::GetVarNamePinName()), *CallFunction->FindPin(TEXT("VariableName"))); //See video to see this in action!
//!
//~~~
//! Connect the return pin of the visible node to the return pin of the internal function return value!
CompilerContext.MovePinLinksToIntermediate(*FindPin(FGetConfigNodeName::GetResultPinName()), *CallFunction->GetReturnValuePin());
```
**Notice how I have to wire the newly created BP node together myself!**
I must be very careful to wire the return node of the WildCard node (that deletes itself) to the newly created node, so that the return wire that you choose to connect is maintained!
So basically in my code on Github you can see that I am replacing the Wild Card node with a type-specific node from the ConfigBPLibrary, based on what type of wire you plugged into my Get/Set Config Wild Card node!
Again I reverse engineered this from various K2 nodes within the Epic code base, so I do not take credit for this great idea, **but I sure did have fun figuring out how Epic does wild card BP nodes!**
Conclusion
And that’s how Wild Card Nodes work!
All my code is on Github
https://github.com/EpicGames/UnrealEngine/pull/1083
Rama
