In the above example, chargeAbilityBlueprint is a pointer to an actual object, but chargeCast is NULL. Trying to get a UAbility type by replacing UBlueprint with UAbility also results in a null object.
Pretty sure you need to get rid of the Blueprint’ in the path aswell, or at least it’s not needed, I don’t have anything like it in any of my code and it works fine.
A picture of me inspecting the reference object at runtime, after it has been loaded. The type appears to be blueprint, which I suppose is correct, but it’s a blueprint with UAbility as a parent type…
Interestingly, the object can cast into a Blueprint without throwing an error. The parent class is absolutely Ability, as shown in this screen from within the editor:
I’m fairly sure that Blueprints boil down to UClasses don’t they, not instances of a given type? That might be why it’s failing. If not, then Zeblote’s code should work but you should probably provide an outer or it’ll just get garbage-collected unless it’s strongly referenced anywhere.
To be honest it’s bad practice to use String Asset References in code (or any kind of hard reference to content for that matter) anyway. Use TSubclassOf or TAssetPtr instead and get or load the object from there.
Also if this asset is used during gameplay, you probably don’t want to be loading it during game time either - so use TSubclassOf and set the class in the editor:
UPROPERTY(EditAnywhere, Category = "My Classes")
TSubclassOf<UAbility> AbilityBlueprint;
A UBlueprint object contains the information for the Blueprint, it isn’t the final compiled class. You want Blueprint->GeneratedClass for that.
So, using the OP’s original code:
FStringAssetReference chargeReference = "Blueprint'/Game/Content/Abilities/Charge/ChargeAbility.ChargeAbility'";
StaticLoadObject(UObject::StaticClass(), nullptr, *chargeReference.ToString());
UObject* chargeReferenceObj = chargeReference.ResolveObject();
UBlueprint* chargeAbilityBlueprint = Cast<UBlueprint>(chargeReferenceObj);
UAbility* chargeCast = Cast<UAbility>(chargeAbilityBlueprint->GeneratedClass); // GeneratedClass should be valid as Blueprints get compiled at start up, but you can toss an if check if you want to be super safe.
Apologies for the late response. Strangely, that also doesn’t work. In the example provided, chargeCast is a NULL object. The generated class is not, so the cast must be failing. We can see that the chargeAbilityBlueprint is, at this point, is derived from ability:
Any other thoughts? This particular issue is driving me crazy