I’ve created 2 blueprint objects MyThing and MyHolder in the content browser and inside MyHolder I’ve created a variable VarThing which takes a MyThing object as value:
How do I instance MyThing in the content browser so that I can see and set it as the default value for VarThing?
Note: This is purely for learning purpose and is not an XY problem
The stuff in the content browser are object templates - they do not exist as objects. When something is added to the scene (or spawned) - a template is used to create an instance.
Look up defining UPROPERTY variables in your class, specifically TObjectPtr and TSoftObjectPtr
I think maybe PrimaryAssetID’s work, but you have to set the AssetManager up.
Unfortunately this is not something that you can do purely in blueprint.
If you defined UMyHolder in C++, you could do this using Instanced Objects and selecting a type of UMyThing would do what you want to accomplish.
so what should I use to get the desired effect? because ultimately I want to create an asset (not enums) for labeling stuff and storing some other data in that asset (which an enum can’t do)
I looked into soft and weak pointers and from what I can tell I can reference a class instead of an instance if I use Soft Class Reference type in VarThing which doesn’t seem ideal since I’d have to make a new class everytime I make a new MyThing.
I have no idea what you mean by PrimaryAssetID and AssetManager setup
However I did looked into Data Assets and these do look promising and would work if I made MyThing blueprint inherit from Primary Data Asset and then created instances of it as such:
are there any limitations I might face while doing this? other than not having custom icons? lol
I’m open to a c++ solution, could you please elaborate on what you mean by
using Instanced Objects and selecting a type of
UMyThing
Sure it’s just a couple of markups:
First is your UMyThing:
UCLASS( EditInlineNew )
class UMyThing : public UObject
...
Then in your MyHolder class:
UPROPERTY( Edit***, Instanced )
UMyThing* VarName;
UPROPERTY( Edit***, Instanced )
TArray< UMyThing* > CollectionName;
In the editor for a UMyThing asset in the Editor, you’ll get a dropdown for the members with the Instanced markup. That dropdown will list every class that derives from UMyThing (you can exclude classes a few ways, but the most useful one is using Abstract in the UCLASS). When you select a type from that dropdown, it will create an instance of that type and add a small section that is all the properties of the selected type (similar to how structures are shown). If UMyThing were blueprintable, you’d be able to make blueprint types and they would also show up in the drop down. But because of the markup required, the base class used for instanced properties and the properties themselves need to be defined in C++ even if the instanced type picked in the Editor is a blueprint one.
You can also now do something similar with TInstancedStructs. It’s a little easier because it doesn’t need any markup. You just make a new USTRUCT, make a bunch of USTRUCTs that derive from it and then declare properties with TInstancedStruct< FBaseType > as the variable type. But the usual structure limitations come into play.
Lastly it’s worth mentioning that this can be very powerful for configuring things, but is best for things that are meant to be unique across instances. Benbyy’s suggestion of creating assets and referencing them is also a strong solution when multiple objects really want to share details.
For example, our game had abilities (no big surprise) which would be your UMyHolder. It had an array of instanced objects for the effects that it would cause (because those effects were meant to be configured uniquely on each ability). But if the effect where applying a status effect, instanced of it having another instanced object, it had a reference to another data asset. Because every ability that applies Stun should apply the same Stun.
So instanced objects aren’t meant to replace or be better advice, just another tool in the toolbox.