We have some Data Assets created with a BP class inheriting the `UPrimaryDataAsset` class. According to the documentation, Data Assets should be created exclusively with native classes. For BP classes, the use of data-only-BPs is encouraged, but in some cases Data Asset is more convenient.
The `UDataAsset` class is not even `Blueprintable`, so using `UPrimaryDataAsset` is a workaround. Going forward, I would probably opt to creating a `Blueprintable` subclass of `UDataAsset` for such use cases.
However, the important questions is: Are there any possible issues with using BP classes for Data Assets?
One issue we encountered is this one, but resaving BP classes of the offending assets solves
[Attachment Removed]
Hey there, first of all - creating a blueprint of UPrimaryDataAsset is not a wrong thing to do. So subclassing off that is not a workaround that introduces issues. The primary (heh) thing of Primary Data Assets is that the class returns a unique, class-name based Primary Asset ID and Type that scanning for data assets of that type if you choose to use that funtionality.
The main difference between creating a blueprint based on UDataAsset or UPrimaryDataAsset is that blueprints support inheritance, so upon constructing an object of a blueprint class, deciding the default value involves delta serializing from the farthest ancestor to the closest. Similar to what’s depicted in the diagram here in Figure 6. It’s more expensive to load. The first native ancestors and all blueprint ancestors are evaluated at data asset load-time. Meanwhile, if the data asset is directly of the native ancestor, then no default value inheritance needs to be evaluated. The native constructor sets some values (pure C++) and the data asset overwrites some properties (UE modifications, but no propagation).
“According to the documentation, Data Assets should be created exclusively with native classes.”
Can you point out which sentence? The article leans towards recommending data assets of native classes over blueprint ones, but the functionality should work. I believe the documentation recommendations are based on cautioning against mixing BPs and data assets too much: the more BP inheritance, the less lightweight the data asset becomes to load.
[Attachment Removed]
“Assets can be made in the Content Browser using native classes that inherit from UDataAsset. If you want data inheritance or a more complex hierarchy, we recommend creating Data Only Blueprint Classes”
What I understand from this sentence is that you can either:
- have an Asset made using native class that inherits from UDataAsset, or
- have a Data Only Blueprint Classes.
I understood the recommendation in the above sentence as a possible solution to the limitation of using only native classes for UDataAsset assets.
Also, the fact that UDataAsset is not blueprintable, only the UPrimaryDataAsset is.
The only place that hints at support for Assets made with BP class is this: “Blueprint subclasses can be created to add variables and then subclassed again by Data Only Blueprint that sets those variables. With Blueprint subclasses, we recommend using Data Only Blueprints instead of the Data Asset instance to handle data inheritance and update the parent class.”
“The primary (heh) thing of Primary Data Assets is that the class returns a unique, class-name based Primary Asset ID and Type that scanning for data assets of that type if you choose to use that functionality.”
Good to know that subclassing UPrimaryDataAssets won’t cause any issues even if we won’t use it as a primary asset. However, in a larger team, it’s a good practice IMO to clearly communicate intent, and using a Primary Data Assets communicates an intent of making the asset primary for some reason.
[Attachment Removed]
I think your idea of making a blueprintable subclass of UDataAsset should be fine to do! But I’ll find out who wrote that docs page. If they’re available I’ll ask if they would have any concerns/advice.
[Attachment Removed]