[Request/Bug] BP - Blueprint scope variables again

I would like to request a padlock on these variables for private non editable. I know there is the Editable option under the details but as far as I can tell that doesnt have any affect to the defaults, private does seem to hide if its set before the first compile so I do think there might be a bug there.

duplicate.jpg

Hi Daniel,

You said that you believe that there is a bug with the private setting not working before the first compile? I would like to repro this and see if it is a problem, could you give me the exact details to what your result is and what you would expect the behavior to be?

Thanks,

Alexander

Okay cool, Ive checked it and it does seem to be a bug. My understanding of making a variable private means its not accessible from sub-objects or subclasses.

  1. Create a new blueprint from Actor.
  2. Create a blueprint scope variable.
  3. Tick editable on the blueprint scope variable in the details panel.
  4. Tick private on the blueprint scope variable in the details panel.
  5. Compile.
  6. Place an instance of this blueprint.

The Variable now shows up in the defaults which is fine, since the editable variable is only exposed to instances if its checked.

If however private is ticked in the details panel it still shows up in instances if editable is ticked.

Just to expand alittle bit, I was just looking for an optimization for variables that are only required to cache data temporarily within the blueprint and do not need to be accessed at all from outside of it. I do not require the default value or for it to be editable in any way, infact I would like to ensure that by listing as (in UScript terms) Protected.

Hi Daniel,

Private and Editable attributes are uncorrelated.

Current rules of access:

  1. A variable added in a blueprint Parent is always editable in Defaults of the blueprint.
  2. Let blueprint Child be based on Parent. The variable is editable by default in Defaults of Child.
  3. If the variable is marked as Private it cannot be modified in Defaults of Child and it cannot be modified by the script in Child blueprint.
  4. The variable can be modified per object’s instance (both for Parent and Child) if it is marked as Editable.

About Protected access specifier - we are thinking about such feature.

Cheers

Well I have found the local variables recently so I might be able to use those to return variables to the eventgraph so the variables wont be openly blueprint scope.

I am curious if theres overhead associated with having defaults and defaults of children as well as having private variables that are editable on alot of instances. I think the protected keyword would allow optimizations in respect to how those variables are initialized and how memory is handled. The difference might be negligible but I just thought I would let you know.

When you don’t define a default value, a variable uses ‘default’ default value (it just must to be defined). So there is definitely no impact on the final game performance.

Ahh okay sounds similar to UScript then, thats good to know. I just dont want to bog things down too much because Im actually attempting to do as much as I can in blueprint.