Hello,
I was hoping to get some general guidance on the expectations around accessing the internal data for smart objects. For example, when performing a relatively simple task like trying to get the current actor using a smart object slot accessing the data seems like more work than I’d expect and often seems to need engine divergences or very specific setups. I would like to know if I am missing something, or if we should just diverge to expose some of the internals to make it easier.
The “correct” or non diverging path seems to be I should be adding “slotdata/Statedata” to cache the user actor (or entity if using mass) so this can be retrieved when needed by accessing the slot data instead of the “userdata” directly (this is what the gameplay interaction setup seems to do). We could add state tree tasks / modify our definitions to ensure this is always set, but is there a reason for needing this rather than just being able to access the user data for the slot.
Alternatively, we could expose out the user data.
I started down the subclassing USmartObjectSubsystem and hit a couple bumps.
- Needing to diverge USmartObjectSubsystem::ShouldCreateSubsystem to have it check if there is a derived class that wants to exist instead. (so we don’t get our games version and the default)
- FMassSubsystemRequirements::IsGameThreadOnlySubsystem doesn’t work on child classes and needs to be changes so that it doesn’t look up an exact class match. Or USmartObjectSubsystem::Initialize to be changed so it adds both the derived type and the original.
A couple alternative approach to subclassing is exposing either:
- The ExecuteOn functions in USmartObjectSubsystem so they are public (rather than subclassing and using them)
- Slot and Runtime info in FConstSmartObjectSlotView. The state data is exposed already, but not the user data. Any reason for this?
Is there a reason for the slot data being accessible but not the user data? and should we expect to subclass SmartObjectSubsystem?