Heyo,
Apparently this is a common problem with modded interactions, but as far as I know, I've only had this problem twice.
The problem is when a save is loaded either from the whole game entirely, or from Main Menu, the interaction is cancelled immediately - as in they don't exit out of it, they just stop and Cleanup() is run. If the game is paused when it's loaded, the sim stays in the animation/position they were in, but as soon as it's unpaused, they stop.
I had this problem with my knitting interaction, but at the time I had multiple interactions derived from an abstract interaction class, where the base class had the Run() method the rest used. I thought the issue was to do with this confusing the game when it was loaded, as maybe some information was different eg starting a new project became continuing one because the interaction had already started. I dunno if that even made sense as as guess, but when I restructured the interactions to have them all individual interactions that triggered the "base" one as the actual knitting one, I didn't have the cancelling issue anymore.

However, now I have an interaction that's just on its own, and it's doing the cancelling thing and I've no idea what's causing it

Any ideas? :p

If memory serves I believe this is due to the interaction definitions not persisting. Do you have a constructor that takes one or more arguments in your definition? If so, you'll need to explicitly add a parameterless constructor as well, so that the game can rebuild it via reflection on game load.

Thanks for the speedy reply!
Unfortunately this interaction def didn't have a constrcutor. I added a paramterless one anyway but it's still doing the same thing :/

The LoadSaveManager itself, seems to be looking for a lot of IScriptProxy and IScriptObject types and restores their tasks. Would it maybe help if you did something like:

public class CLASS : IScriptProxy, IScriptObject, ScriptProxy

Initially I'd assume this isn't necessary, since GameObject itself simply has those derived as well. And, GameObject also does stuff in the background already when the script is attached to the object on Postload. The only requirements that need in order to resume an interaction is:

- If the object is/was in the middle of being routed to (or used to be routed if it's a Vehicle, so bikes primarily IIRC), then it will discontinue the routing.
- You don't in some way after saving trigger the kObjectStateChanged event. This will reset basically the object practically (Well, the posture, the actor using me list and routing) I'd check this with: EventTracker.SendEvent(EventTypeId.kObjectStateChanged, functionHereIfNeededElseUseNull, this);

However, with Actual interactions, also keep in mind that the following could result into weird saving behavior:
- If the interactionPriorityLevel is essentially Zero, autonomously by Npc (Although this includes active sims too), and anything super low-end prio, it won't really bother taking care of it's saving state, existing-wise
- InteractionInstance is indeed the only thing that's persisted but does always check if the interactionObjectPair doesn't equal null. Otherwise it won't "fix up" the interaction on load.
- On PostLoad, the target cannot be null.
- If the object has no InteractionDefinition (Or? and?) tuning file, it will also simply reset things.
- Sometimes Interaction classes we make can be made Abstract, however, you really want to make sure that the class is: Public, private and/or static

Overall regarding animations, all I can really find on it is that it won't persist OneShot Events.

Behind the scenes with Lyralei, adding the ITUN didn't fix it and I can't think of a reason the target would be messing up/getting reset. Also I don't have one shot events for this one...
For now I'm going to leave it and maybe come back to it at another point - perhaps I just need to strip the interaction down and add parts until I find what causes it to reset? :p

Ooh I just figured out what the problem was!
I had an object in Run() which is set at the beginning and is then needed at the end, but I guess it wasn't persisting for some reason.
So instead I stored the variable in the Interaction class, then set the value in Run() (or in ConfigureInteraction, both seem to work) and it no longer cancels!
Though I wonder why other values in Run save - maybe it's because my object didn't have the Persistable attribute?