I don’t think you clearly understand the magnitude of the numbers, when talking about the available functions here. But to make a very rough estimate, let’s say blueprints have about 1% of the functions available in a form of a familirzed version of the ones that actually makes up the engine internal codebase. While this can be argued on which functions have any use in blueprints, it still is a very narrow accessibility to the underlying engine.
How many functions you wish to have the blueprints? Where’s the limit? You want something, Joe wants something else, but Edith is more interested in animations so let’s expose everything for everybody, right? So where do we get then? 10 times more functions perhaps? Or the entire codebase? You know the thing is, even a sophisticated intellisense of Visual Studio having a really hard time to dealing with the engine code, because it is very very large, and you can believe me on this.
The problem with nativization it will generate a code that is synthesised on the blueprint logic, and that generally fails to explore the programming principles. It just looks good and works ok in blueprints. But that is far away from what really is required once you set up a complicated operation. Here is an example. You can write a for loop by iterating from the begining to the end, but if you want it to be faster you will instead just iterate on the same values backwards. This way you can exclude one operation on each iteration that is comparing the index. While this sounds a bit trivial, the truth is millions of optimizations like that will make up a well running game. Blueprints have no support for such things, and the best you can have is maybe a reference to a value to avoid it’s being duplicated each time you access to it. You see, this falls far away from what is expected to be in a final product.
A recommendation from my part - which i mentioned in my previous post - is to use blueprints only to execute high level operations. Simple logic nodes that will run the underlying complex operations written in program code. Once you can reduce your logic flow to a few of these exposed functions only, this would not only keep your blueprints clean, but it will run your game incomparably faster.
This is a good idea, and usually is working very well, unless you find yourself in the situation that in code things are very different and you end up reinventing your logic. Fortunately the end result is usually faster than the expected which is what keeps me doing this way But of course many many things is better to be not attempted to be done in blueprints in the first place, because it would fall short very quickly.
Iterations are a good example where the problems start to arise. Even worse once you call functions in iterations.