Currently i use this code:
const FString command = FString::Printf(TEXT("FunctionName %s"), *SpawnedActor->BlueprintConfig.Texture2D);
FOutputDeviceDebug debug;
BlueprintObjectPointer->CallFunctionByNameWithArguments(*command, debug, this, true);
to call blueprint functions and i use the %s etc… to pass through parameters and it works fine, is there a way for me to pass through UTexture2D? or UObject? like this… %UObject.
I’ve found a solution, i just used this code from rama’s plugin, to pass through the path as a string and load the object within the blueprint.
UObject* UVictoryBPFunctionLibrary::LoadObjectFromAssetPath(TSubclassOf<UObject> ObjectClass,FName Path,bool& IsValid)
{
IsValid = false;
if(Path == NAME_None) return NULL;
//~~~~~~~~~~~~~~~~~~~~~
UObject* LoadedObj = StaticLoadObject( ObjectClass, NULL,*Path.ToString());
IsValid = LoadedObj != nullptr;
return LoadedObj;
}
I might be insane but, I’m not sure if StaticLoadObject actually works outside the editor… have to check though.
TAssetPtr is what you usually use for ASync loading I believe.
StaticLoadObject works anywhere, but object references stored as FStrings don’t get gathered for cooking, leading to missing assets in a cooked build if they are not referenced anywhere else. TAssetPtr does store an (unloaded) asset pointer that correctly gets gathered, hence the better usage.
(I used to point this out whenever people would follow Rama’s tutorials, but since hardly anyone will ever make it to cooking and the issues that might arise… It’s easier to let it slide.)
Would it be ok if i used Texture2D->GetPath() as i currently do now?
Hah yeah, I seem to remember you mentioning it before. Out of curiosity, does FObjectFinder in the constructor still work considering it uses a string reference?
Also, lol @ brutal truth.
It’s not how you obtain a string reference that matters, it’s how you store it. FObjectFinder gives you a hard UObject pointer, which you could then store directly as a UPROPERTY pointer (default subobject, loaded with outer object, gathered by cooker), a TAssetPtr or FStringAssetReference (string, not loaded, gathered by cooker) or a plain string (string, not loaded, not gathered, bad idea).
But that’s besides the scope of the original question:
I’m curious as to why you’re doing this? CallFunctionByNameWithArguments is normally internally used to invoke console functions flagged as Exec through the console. It’s messy, not type safe and once you start dealing with properties that can’t really be used as strings (such as a UTexture2D*), it’s complicated to work with as you’re finding out.
Are you trying to call a function that’s implemented in Blueprint? If so, you would be much better served by defining it natively in C++ and calling it directly. You can do this by making a BlueprintImplementableEvent UFUNCTION:
UCLASS( Blueprintable )
class UMyBlueprintBase : public UObject
{
GENERATED_BODY()
public:
UFUNCTION( BlueprintImplementableEvent )
void DoSomethingWithTexture( UTexture2D* Texture );
};
By declaring a function BlueprintImplementableEvent, you can then implement it in a derived blueprint (it’ll show in the overridable function list) and do whatever you want there. Calling it in C++ is as simple as:
BlueprintObjectPointer->DoSomethingWithTexture( SomeTexture );
Ok so i forgot/was unaware that BlueprintImplementableEvent was a thing, i just created/messed around with a c++ user widget using a BIE and
it worked! so i’m going to convert all my UMG user widgets to c++ ones.
Thank you.
Ah, UMG, that makes sense. Yeah, you have to reparent the widget blueprint to a new class after creating it, but then it works pretty nicely with native code. I actually made my own native base class over UserWidget with some common helper functionality for native interaction.