I can find only “private” over there, why there is no “protected” option? or am I missing something?
If you enable “Show inherited variables” in the view options of the BP editor panel, you can access parent variables.
So if they are not private, they are “protected” by default.
Making it editable (small eye icon) makes the variable public…
So all three visibility planes exist…
You can access variables from other blueprints even if they are not marked as “Editable”. This attribute let’s you edit the variable via the details panel when editing the map itself.
what a idea to protect some variable
if you dont want to change it, just dont change
i dont understand
These attributes are there for the sake of order.
It let’s you know if the author have meant for you to be able to change it.
While working in a team this is even more important.
2 Likes
Look up the basic principles of OOP:
- Information hiding
- Data encapsulation
im not a programmer, so i though when you tallking about “protected” its something constant, without “set”
now i understand.
So, year past after this ^ post and i face some issue, there are no protected variables in blueprint.
In theory… protected is the “editable” and “expose on Spawn” the attribute let’s you edit the variable via the details. At last in old version but is true that is not working.
Not true, Expose on Spawn means you will have pins for those variables when you call spawn actor node. Protected variables are still needed.
My personal preference is to simply use an appropriate naming scheme. Prefix ‘protected’ variables with a ‘_’ character or something like that.
I actually prefer this system over true information hiding because I might have a very good reason to access a private/protected value that the original programmer did not think about.
As long as you know that you are using that value at your own risk, I don’t see a problem.
There are no good reason to access private/protected variables, if you want values you implement “get” interface; if you want change it, you implement “set” interface.
Protected variables are generally bad practice for various reasons. Why should your child class have access to the implementation details of its base class? Rarely they are the best solution, the average blueprinter isn’t able to decide if a protected variable is a nice solution. So I would say it’s legit that’s not even possible.
But generally it’s a pain trying to nicely script OO blueprints due to how blueprints are implemented.
Its not the implementation that is protected, the declaration is.
Why should the child class have access to the base class declaration of a function?
Answer: To override it.
2 Likes
I don’t have any problems implementing nice OOP in Blueprints…
You can do everything a simple OOP language can do; Derive from classes and override functions, declare und implement Interfaces. I don’t see the problem with protected functions and variables here.
And you can 
Blueprint functions can be all 3. Private, protected and public.
Hmmm my main problem are things like reparenting and moving logic in the parent class. I just noticed too many bugs / editor crashes with this. I am also frequently missing some features like abstract classes, direct access to input variables of functions and events and private, editable variables (or being able to override set methods of variables).
show how?
i failed to figure out/explain it to support so i give up
edit::
oh, nvm, functions, not variables, i was thinking about variables.
abstract BPs would be great. I often see myself using an empty class a base. I’m just too lazy to learn C++ and the Framework of UE 
What is the idea behind abstract bp and why you need it?
^
Basic OOP.
Let’s say you have a baseclass for Items in an Inventory for example.
An abstract class is better suited than an interface for this case, because you can directly access the methods/attributes, without checking wether it implements the interface first.
The same goes for any Enemy you can imagine:
Have a base abstract class/BP “Enemy” where you implement the base functions like Damage formulas, but leave the skills the enemies can use empty and implement them only in the concrete classes.