Moving blueprint functions/variables to C++ (feature request)

Reimplementing blueprint functions in C++ is a bit of a pain. I usually change the function name (i.e. “FunctionX” to “FunctionX_OLD”), implement “FunctionX” in C++, and then change every use of the old one to use the new one.

The process is critical when going from prototype to optimized but it also becomes a factor when C++ code ends up needing to access an existing blueprint-defined function. It’s also worth noting that since 4.18, I have gotten corrupted packages after performing this process. No one can pin it down but it’s real so I always back up before doing this kind of conversion. It manifests as a mismatch in the look-up tables that the engine uses to map RPC functions.

It would be nice if there was an easier way to do it. And I think automating the process would be straight-forward for someone who knows that aspect of the engine intimately.

It might be pretty easy to use nativization: convert the function to native code, change all the references, and delete the blueprint function. Let us finegle the generated code into something better for people to work with. It’d be easier than it is now.

Automatically moving variables to C++ would be even easier. Can’t tell you how many times I’ve had to move a variable into C++.

Cheers,

If you nativize a blueprint and peek its underlying generated C++ source code, it is unreadable (I think you have already seen it). So I doubt that there is a way to further make it readable by human by manual editing it.
It is more productive IMO, to just convert manually the BP to C++. Many spaghetti BP nodes can be converted into a few lines of C++ code, so it quite easy. And also, if you are not sure about the corresponding C++ BP node, you can always right click on it and select Go to Code Definition (but not all node has this though… lol)

But that is where his issue is. Have to deal with it myself too.
The method which gives you the less headache but takes more time is to treat BP implementation like a pure prototype and instead of porting it to c++, treat it as a ground up implementation in c++ (with a knowledge that was acquired in building BP prototype).
The gradual transition, can work to some degree if your code mainly lives inside of components. The other trick is to define most of your variables (especially structs) in a c++ scaffolding class and treat it as an abstract that doesn’t implement anything yet. When you feel you are done with BP prototype you can inherit a c++ class from your abstract where c++ implementation will go until you feel safe to ditch BP implementation and just merge c++ child into previously abstract class. It’s messy but feels easier for a large classes where you can debug c++ implementation in parallel to existing BPs.
No idea how automation could help with that. Perhaps we need an easier way to move variables and classes around. There are still issue with re-parenting BPs and changing interfaces.

“Sadly” I agree with above post. Putting variables in C++ from beginning makes entire conversion a lot easier. And later still I usually refactor entire logic manually.

Although… we could use little help to start a process. Like a way to to create a new parent class for blueprint and automatically reparent it. The same functionality could be used to repair blueprints which parents don’t exist anymore.
And moving variables of generic type automatically to this parent class without loosing values on instances. That would be awesome.

But I even if Epic already thinking about such tools we would have to wait until they finish basic improvement for blueprints itself, finish up nativization and hot reload… :wink:

​​​​​​​I don’t except that moving logic would be ever available, but that’s the smallest issue for me.

Using UEditor’s API it’s possible to programmatically get all “FunctionX_OLD” input and output pins then connect them to the new node created from C++.

It’s simple to access blueprint functions and property that doesn’t exist in C++ parent class, there’s FindField() and FindFunction() methods on UObjects.
You can use them in C++ base class while you still have functions and variables that don’t exist in C++ yet.
​​​​

This sounds awesome. Thank you for sharing this. Should help with solving some headache.

But it should be based on reflection if I remember correctly so it’s not that performance friendly.

It’s just a way to keep the project compiling and running while there’s variables and functions you didn’t have the time to convert to C++ yet.

Thanks! I will have to look into that. If I survive this coding push… The conversion process isn’t that bad. Just thought I’d throw it out there.

I understand, but it’s very tempting to leave it “as is” or even to excessively use this feature in other places that’s why I had to warn about this “convenience over performance trap”.

And I support the idea of better BP-to-CPP conversion process. It’s just not that realistic to happen soon, unfortunately, unless someone will dig into it share - epic is currently too busy with fortnite and other stuff.

I’m also trying to migrate from BP to C++, but since I went really far in BP and got fairly deep parent-child B hierarchies, with tons of blueprints code, it’s not an easy matter to migrate. Take this as an example… maybe some has a solution for it. I am trying to re-parent a blueprint from it’s original blueprint parent to my new C++ class.

If I keep the variables and function name and type and interfaces identical, seems to work fine… just not with point type properties… so anything like a SkeletalMeshComponent or StaticMeshComponent property is problematic. I see the components if I drag the CPP directly into the world, and VisibleAnywhere/BlueprintReadWrite works correctly… but I look at the child BP, none of these properties show any details in the details window, and if I drag the child BP into the world, the components are read only.