We have encounter an issue in the Chooser when we setup output object column for soft reference object ptr (an optional montage object). It is working correctly when the montage is loaded. But before it just returns always null - not soft ptr nor soft path. The behavior is even little bit worse because when I put a breakpoint to the file where (I guess) the output is resolved and filled, the asset is loaded and from that point everything seems to be ok (the editor must be restarted).
I believe that it could be a problem in method
FOutputObjectColumn::SetOutputs
where the type data in the row is
FSoftAssetChooser
and ChooseObject(FChooserEvaluationContext& Context) is called. There is a second overload of this method that can return soft object ptr, but this one is called elsewhere in the different scenario.
My suspicion is that soft reference is resolved (loaded?) in FSoftAssetChooser::ChooseObject() even it looks like the right class for soft references.
Is this something what is intended or can we can find some workaround? Maybe a different type of the column that will return just soft pointer and won’t try to resolve the asset?
We’re missing support for this at the moment. For returning animation sequences and montages in choosers, which can be returned as soft asset references, we expect the user to handle loading the asset. That said, in this case, where the object output could be anything and resolution occurs in code, we’re working to improve it in the future.
I don’t have an exact workaround, but would you try:
In FOutputObjectColumn::SetOutputs, it should call the version of ChooseObject that outputs a soft object ptr. Then, FChooserParameterObjectBase will need a SetValue function that takes a SoftObjectPtr, and a FObjectContextProperty::SetValue implementation that can set a soft object pointer output variable without ever loading the asset. If the property is bound to an actual Object pointer variable We’d recommend just making it set null if the asset isn’t loaded, possibly with a log, because that’s the case where it’s user error because they haven’t loaded it in advance, or used a soft object ptr so that they can load it later.
That looks good, and if it’s working for you, then that makes sense to us as well. Thanks for sharing, and if you would like, feel free to PR that change, and I’ll get it integrated.
Thanks a lot, Dustin. I tried something but not sure if it is correct as I don’t know how I can resolve the type of the output on SetOutputs level (if the output is a soft ptr).
What I did:
[Image Removed]In this case I call the second version of ChooseObject method with soft ptr and then a new version of SetValue which returns true if the target is a soft else false - in that case it fallbacks to the original code. It seems to be working better regarding the original issue.