No "protected" attribute to blueprint variables?

Tell me what is the difference between your “abstract class” and general bp class to inherite from with the checkmark “abstract” = true (make you unable to use it in, only childs).
I understand the need in pure virtual functions/pure abstract class, to ensure in compile time you override the interfaces with unique implementation, but what you asking its just common parent with interface.

Where exactly can you say that an BP is abstract?:confused:
Edit: found it.

An abstract class is kind of both. Because you can implement functions directly and leave some function abstract.

The thing is that when using an interface, subclasses are not guaranteed to have methods implemented or even declared.

Yeah. Thats another pair of shoes.
Setting up an OOP inspired class hierachy is rather smooth, but refcatoring blueprint classes is a huge irritation in the rectal passage.
As you said, moving declrataions/implementations to the parent class breaks things for sure.
Thats where the BP system definitely need some love.

An abstract method in a class (its the method/function that is abstract, not the BP class), basically just “promises”/“requires” subclasses to have this method implemented with a common name/paramtere signature.

Say, I have a class, called “vehicle”. I add an abstract method called “Beep”.
In the subclasses “Truck”, “Bicycle” and “Car” I would override the Beep function. The implementation in the car class beeps like a car horn. The implementation in “Bicycle” rings like a bike bell and the implementation in the truck class operates the compressor and honks the horn.

Of course, i could have declared the functions in each class directly with no abstract ancestor.
The upshot of the abstract class is now that when I give the implementation job to three different developers, all implement the beep function.
Otherwise, the guy implementing the truck class calls the function “Honk”, the bicycle guy calls his function “RringRring” and the car guy “Meep”.
So, it helps with keeping names consistent across inherited class siblings.

And being “protected”, children can override, but the function is still hidden from the outside.

Well, I found this topic because have the same problem. It looks like is difficult to maintain a OOP in blueprints.

So, looking the replys I don’t see how implement protected variables. I am going to make a public and follow a convention to make it a fake protected( I only will not call getters and setters in other blueprint).

This can be easy because it is a “personal only one programmer” project .

I don’t know why protected variables is a bad practice like someone wrote here…