Referencing OutputType of UFUNCTION by Instance UPARAMETER

Hi, Is there a way to have a UPARAMETER as a refence for the OutputType of a UFUNCTION.
It is possible to reference an input parameter of a function as OutputType of that UFUNCTION by meta DeterminesOutputType=.
I can reference a function in meta of UPARAMETER, but referencing a UPARAMTER in UFUNCTION meta doesn’t seem possible.
I wan’t to do something like:

	TSubclassOf<UObject> Type;

	TArray<UObject*> GetData();

Currently it is compiling with that code but always returning a TArray<UObject*> in Blueprints, no matter what Type I have set … if I set it in an input parameter it works but adding it at every function is overhead that would not be needed.
Is there any way to achieve that, so I don’t need to add a type parameter to every function I want to be able to return a typed output in my helper class.

Kind regards,

I’m not sure I understand what you’re trying to setup, but the short answer is: no. If you want to use “DeterminesOutputType” the actual function needs a TSubclassOf parameter.

Either you have to add the parameter or you have to change your return type to be the type you want instead of UObject. I’d have to know more about this helper class and how you want to use it. It’s possible that you could write custom blueprint nodes (this is different than making a function blueprint callable) but that’s a complicated feature to get into just yet.

Thanks for the answer.
It seems like it needs to be a custom blueprint node.
What I’m looking for is similar to the array handling in blueprint. You set the type once at creation and when you call functions on an instance you don’t need to specify the type again for getting a typed result.
The described way seemed like an intuitive way to achieve that, instead of giving meta the name of the function parameter, giving it the name of the instance field. It was also shown that you can reference your code in meta (like referenceing the setter function in a uproperty). This concludes for me that blueprint knows about whats going on in that instance but can’t set the return type based on it.

Oh I see, something like arrays. That makes sense. I haven’t investigated the internals of how arrays are supported but I know there are all sorts of shenanigans to make that work. You could take a look at KismetArrayLibrary.h, it’s all implemented in the header, but it’s a little obtuse since it can’t actually access any of the data and has to treat it all as blocks of opaque data.