EditDefaultOnly for subobject

Unreal Courses Ask
,
#1

What does EditDefaultOnly for a subobject mean? Does it apply to the pointer value, or does it apply to the subobject itself (properties of the subobject)?

I’ve used VisibleEverywhere and I could still change the properties (mesh) of the subobject, which implies that it’s not the latter.

But if it’s the former, doesn’t that mean the subobject could be removed/deleted via the editor (although, I couldn’t figure out how to do that)? And if so, wouldn’t that mean that the rest of the class cannot assume the subobject exists anymore, and that we should do pointer checks everywhere?

It feels to me that subobject should always be VisibleXXX and BlueprintReadOnly [edit: if/when needed to be exported to the editor and blueprints]

#2

I’m fairly certain you can’t.

I wouldn’t make it BlueprintReadOnly unless you actually need it in blueprint.

#3

So what does EditXXX on a subobject mean?

Why? Is it expensive to enable blueprint access?
And should that be interpreted as “don’t enable blueprint unless you use them”, or as "it’s better to implement ufunction to expose the necessary subobject properties, e.g. GetTurretTransform"?

#4

AFAIK it allows you to change it to be a further derived type. Not sure how useful that is in practice.

In UE4 it also gave you a horrible and confusing UI.

Unreal will generate extra code to make that possible though that’s beside the point. It’s like making a member variable public/protected for no reason. Why would you expose a variable with no reason?

#5

If I don’t do blueprints, then yes, sure.
But if I do do blueprints, then I don’t necessarily know what I will need later. And if I consider it safe to export the variables to the editor for tweaking, why shouldn’t I consider it safe to export to blueprint as well?

And yes, that applies to public/protected as well. I was actually thinking that those variables ought to be protected rather than private for the same reasons.

That said, re-reading my initial post, I think I gave the wrong idea. When I said “should always be […] BlueprintReadOnly”, I really should have added “if/when needed to be exported to the editor and blueprints”. I’ll fix my post to avoid confusing future readers.

#6

YAGNI

Because blueprint is code and the editor isn’t. That’s why the former respects access specifiers but the latter doesn’t.
You’re not going to be able to effect gameplay during runtime just by exposing variables to the property editor e.g. you won’t be able to have “when the ammo is low, flash lights somewhere” just by exposing a variable to the editor.

Blueprint is code and should adhere to good coding practices.

#7

If I write the actor for the marketplace, I cannot know what the developer will do with it. If I write within a team of 100 developers, it is difficult to know. And if it knowable, lacking consistency (some actor exports their subojects, some don’t) can be an issue of its own.

Modifying properties can still affect the gameplay. It has less opportunities to do so than code (no function calls), but it’s still possible (e.g. remove the mesh).
Butt “yes”, it is less opportunities, and modifying some the properties is pretty much mandatory (e.g. to set the mesh and transforms). Which likely why there are different access modifiers for the editor and for blueprints.

“Developer discretion is advised” :slight_smile:

–

Just to be clear, I don’t disagree overall (and indeed, I removed the BP access from my code). I might disagree with the degree.

#8

I would say this is pretty much the same situation with deciding on the access of members in C++. Unless you use the AllowPrivateAccess hack then you will also need to change the access to public or protected in C++.

Perhaps you missed or misunderstood what I meant by “runtime gameplay logic”? My point was that you are eventually going to ship the game without the editor, any modifications through the property editor would have to be before you packaged it and not during gameplay.

#9

Only if using EditXXX. For VisibleXXX, this is more equivalent to a getter-only (or make the member variable a const pointer, which is often problematic for initialization).
But yes, there is no reason to allow blueprints to access a subobject and not allow C++ some form of access as well. I never disputed that.
And in the same vein, a lot of member functions should become UFUNCTION and be virtual and public/protected.

While I didn’t think of it in quite those terms, I don’t think it was different in essence.
Why does changing a property during development as opposed to runtime matter? It’s the effects of the changes that actually matter, and those effects do show at runtime too. The changes themselves are only important in so far as they are the source of those effects.
And even then, changes in one property in the editor (e.g. velocity) can also change other properties at runtime (e.g. location).

I give you that blueprints have more leeway in what they can change, and thus the effects those changes can have. But that doesn’t mean the editor has no opportunities. And in that light, I don’t think the editor is special compared to blueprints. It’s more limited (and harder to avoid because of basic properties such as the mesh and transforms) but I see it more as a matter of degree rather than specialty.

The “principle of least privileges” still means that one should avoid allowing blueprint access while still allowing the editor (since the former is not always required while the latter often is for practical purposes), but I don’t think one should have too much qualm allowing blueprints if they feel the need.

#10

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms