I would like to share with you some shortcomings of Blueprints in my opinion.
First, why don’t variables have the protected modifier, which would be very useful if we wanted to change variables in the class defaults of child classes, but not allow other classes to access those variables.
Secondly, it would also be nice if they added the ability to return pointers from a function. For example, in order to return some integer value from object, so that you can directly change it, or, for example, return a pointer to an array and work with it already.
Thirdly, I found a very funny bug, or a flaw, but for some reason in such a class hierarchy as:
1
1.1
1.1.1
A protected method created in 1.1 cannot be called in 1.1.1 unless override is made. But a protected method from 1 can be called in both 1.1 and 1.1.1, as well as in 1.1.1.1, etc(I tested it both in the 5th and in the 4th version of Unreal Engine). It would be very good if these features were added to Blueprint and many things would become much easier to implement. Maybe I’m wrong and if you can correct me😅
There are many things Blueprint sucks at compared to c++ and it should be used as a prototyping tool for small things, not to build a complex or final product.
Protected variables are not supported, but protected functions are, through which you can access variables on the base class. Also, if you mark a UPROPERTY as “EditAnywhere”, it will show up on any editor panel even if the UPROPERTY is private or protected in c++. This is an oddity but useful to know that is happens.
You can return references ("&") from functions.
In blueprint, you can then use the “Set By-Ref” / “Set members in” nodes or just modify the type if it is an array or other container.
Noticed this as well some time ago. Notice that if you create the override and then remove the override, you will still be able to call the function… But is this valid? Odd indeed.
Thanks for your reply.
It seems to me that blueprint is a powerful enough tool for both prototyping and creating games, but unfortunately many features have not been delivered☹️. I do not know the whole architecture of the engine, but it seems to me that by adding such features it will become much easier to write many things in Blueprint and not resort to C ++. In a function, you can handle pointers as you said through Set by ref, but to my regret, you cannot return a pointer to a variable. But the 3rd point really put me in a stupor and I already thought that the engine data was damaged or something like that. You just have to redefine the function and use it in the child class
yeaaa, wait until you have multiple blueprint classes inherit from eachother and one suddenly just refuses to execute its methods until they are overriden only to call the base class. It’s a pile of oddities the BP system.
I mean by the time you program a whole game in BP and want to port it to c++ you might require another few weeks or months of work to do that properly. I wrote a list of BP vs c++ comparisons a while back in my documentation:
1. Blueprints have limited access to anything written in c++, this is also true the other way around. 2. Blueprint maintenance can not be done with quick text operations as you are forced to work with nodes and editor panels. 3. A large Blueprints system takes time to convert to c++. 4. c++ file changes are tiny, can easily be compared, logged, merged and restored through version control. With Blueprints this is not the case as they are binary files. 5. Blueprint files can corrupt easily. 6. Large Blueprints, often the case with animation Blueprints save and compile very slowly. 7. Working with structs is easier in c++, as you have more control over its properties and default values. Through meta tags you can also specify property limits for Blueprints like min / max values and modifiability. 8. Blueprints do not show protected properties on the MyBlueprint tab. 9. Blueprints sometimes require a large amount of nodes which would be a oneliner in c++. 10. In Blueprints, distinguishing class members from local variables in the node system can be confusing. I personally store any Blueprint function parameter as local variable, suffixed with underscore to keep my sanity, but this is not required at all when working in c++ with visual studio.
A blueprint is like a prefab – some base class, that comes with additional configuration for which specific assets/effects/tuning parameters to use.
The fact that you can make behavior be part of those tunables, is cool and amazing! Actor base classes expose various events you can bind to and add behavior to, in a flexible way.
But, all in all, Blueprint is configuration not software development. If you derive one Blueprint class from another Blueprint class, chances are that you’re trying to push the system in a direction it’s not really intended to go, especially if the reason for the derivation is to “re-use behavior” rather than, say, “create a standard lamp, then create a wooden lamp” or somesuch.
If you need to reuse code, either stick it in a blueprint function library, or go to C++. Sub-classing from a Blueprint class to another Blueprint class is almost never the right way to solve a use case, long term. And it’s not intended to be! Trying to make it a full-featured programming environment is the wrong thing to do, because we already have C++, which is always going to be using much less machine resources to do the same processing.
Unless you’re talking about an event in a graph this isn’t necessary at all and might as well add to the confusion. The engine already allows you to use function parameters as variables. Example Function Parameters as Variable Nodes posted by anonymous | blueprintUE | PasteBin For Unreal Engine
That feature blew my mind when I discovered it by accident. Previously I was going nuts having to run wires all over the place to connect something to one of the parameters.
Doesn’t Epic discourage the use of blueprint function libraries (not the C++ ones but thoes you can create in the Editor)? Not quite sure where I heard or read that or the exact reasoning behind that. May have something to do with how/when the blueprint function library assets are loaded causing all dependencies to be loaded as well.
I know about this feature and this is exactly the feature I call confusing . You can use function parameters like that as variable nodes but while using the search box to get to these parameters they are easy to confuse with class member properties. For this reason I create new local variables right after the function parameter pins like “InActor_” suffixed with an underscore. Since I only use blueprints for prototyping before I move them to c++, this is somewhat acceptable.
I don’t know about Epic but I usually do. It IS discouraged to use macro libraries as macros are copy pasted everywhere. The thing with function libraries is that when it makes sense to put a function on a class, you should put it on a class instead. Only something absolutely generic like “Math” makes sense to be a library.
*Edit:
A use for blueprint function library if you are not going to use c++:
Implementation of sorting methods.
A use for blueprint macro library:
Method acting on wildcard pins like structs, like when working with datatables.
Huh, I never noticed this! Testing it, I found you can mark it public, find and set up to call the function, then go back and mark it protected and everything compiles and works, but you’re right: for sure a bug.
I use derived BPs everywhere in my projects. I’ve not run into issues with calling derived functions, although most inheritance isn’t very deep before hitting native classes.
Well, I never touch variables of other classes, and it is something that you can already see visually that you are doing it.
On the other hand, if blueprints are fast at something, it’s when it comes to prototyping, and prototyping means doing ugly things.
So I don’t see much reason for it to be enabled by default.
Ah gotcha, thanks for the explanation. It hasn’t really bothered me since I started using those but I guess it would be nice being able to distinguish both at a glance maybe with a different icon or something.
I figured that you can have a c++ protected UPROPERTY marked as BlueprintReadOnly. This way they show up in Blueprint as Public but they are not editable. Not perfect, but usable. Good enough if you just want a bool or datatable row ref.
. You can use function parameters like that as variable nodes but while using the search box to get to these parameters they are easy to confuse with class member properties. For this reason I create new local variables right after the function parameter pins like “InActor_” suffixed with an underscore. Since I only use blueprints for prototyping before I move them to c++, this is somewhat acceptable.