The smart SmartObjectComponent tries to pull the claimed/occupying actor by getting a payload of type FSmartObjectActorUserData. Mass however claims the slot via FSmartObjectMassEntityUserData (see FMassSmartObjectHandler::ClaimSmartObject).
Locally we’ve had to diverge the class to expose a “GetInteractorFromPayload” function to retrieve the actor via the mass actor subsystem, but want to highlight this issue for the smart objects component’s compatibility with mass. Would you be open to a PR for having the instigator extraction a virtual function or fixing it in some other way so that the instigator isn’t always null with Mass?
Is there a particular reason you need the instigator set when using it from Mass? How does this handle when a Mass entity claims a Smart Object slot without having an associated actor such as if the representation of the entity is an ISM or even off? ?Or is it something that is more of a quality of life change where the instigator is set if possible?
-James
All good. And that is useful info for us that comments are not clear of when/if something gets populated. Thank you!
Just came up against this issue where the actor isn’t ready. So we’re just going to store the entity id and pull the actor when needed. From an end user stand point it seemed like I should expect it to exist because it’s getting passed in but only does in specific circumstances. We’re undoing our change and just making a static function for pulling the actor from the data instead when needed.
So ignore this request, no code change needed. but a comment on the instigator parameter for when to expect it to be valid would be helpful.