Persistent Actors

General Info
This method follows what the airstrike manager uses to auto spawn an actor into the game as soon as it's started up. This actor persists and gets recreated through load screens so it is always available and only one instance is ever currently spawned.

What this means for modding is you don't have to override anything to create a persistent actor and you know it will always be available as soon as the game starts. No extra works is required to keep track of duplicates or anything.

This method is also risky however. We are making huge assumptions about how the CIA is spawned and handled. It works, but I don't fully understand how or why. For example, on loading/saving you can see the actor is recreated, however it seems to always load the pertinent information needed if using the persistent save interface. Will it always do this? Who knows? If it one day doesn't work it will be difficult to understand why. It has been used in several mods though and so far no issues have been reported, so use at your own risk. Worst case, you find something to override and create a spawn persistent actor function in there.

How To Create a CIA
1. Create a new Blueprint and set it to inherit from MWCampaignInstancedActor

Now if you start your game your actor will now auto spawn and only one instance will ever exist.

If you want it to save and load variables that are tied to user saves, go to your CIA and add the MWPersistentActorInterface to it. Then make sure to mark any variables you want saved as Save Game. That's it.

Also note with the persistent actor interface, the CIA doesn't load anything until an actual save game is loaded, so it will exist but be in a default state at the title screen.

Using your CIA in other Actors/Widgets
To get your CIA, there are two main ways. The "proper" way is to use the built in GetCIA macro, image below. This can only be used in the event graph so you may have to pass your CIA down into any functions that need it as an input, kind of like the persistent model. The other way is to use a GetAllActors call since it should be safe to assume the actor exists. This way can be used in functions outside of the event graph and doesn't require passing in.

Using CIAs in Co-Op
If you want to have a CIA spawn in co-op for both clients and the host, then you need to set the CampaignInstancedActor object's Spawn Type from "Server" to "Server and Client". Otherwise, it will only ever spawn for the host.

Now, with the "Server and Client" option, if only a host has the mod installed, it will only create the object for the host. If only a client has the mod installed, it will only spawn for the client (good for client side mods). If both users have it installed, the object will spawn using the current user's version. So if the host and client have different mod versions, they will spawn the respective version they have installed.

Events to tie your CIA To
Once you hop into your mod, you will eventually hit a wall of needing to override something. Most likely the logic you've written has to key off of an event in order to know "when" to do whatever it is that you want. I'll list some tricks and non standard events I've found that you can use to prolong overriding anything and make your mod more compatible. You don't need to have a CIA actor to do this, you can create a persistent actor any other way, these just help since your CIA object is created as soon as the game starts so it's difficult to know when certain things occur.

Mission Start
For determining if a mission has been started and everything in the level is already loaded, usually you would override a mission director and use its StartMission event. This event isn't exposed so you can't bind to it externally like mission end. Instead, I found the MWAreaListenerInterface. If you inherit from that and implement the NotifyAreaEntered event like in the image below, you can achieve the same effect. This has been tested and fires after the loading screen goes away. The mission hub true branch can be used for things you want to do as soon as a player gets into the leopard, like notifications.You could also try looking for the loading screen and seeing if it exists, then keying off it going away but I never got that working.

Mission End
Normally, you would wait until a mission has started to get an instance of a mission director. You can use the above start method and bind to the mission end event like in the image below.

Another way is to get the post mission model from the persistent model and tie to the on post mission data updated. This fires on mission ends including abort and fail as well as giving much more information. You're also tied into mission end events for every mission with a single listener set up once. No need for checking if a mission director exists every mission.

UI Screens
This includes most screens, like the options screen, drop preparation, etc. You get the UIScreensComponent and listen for when the screen you're interested in pops into view. Then you manipulate it from the outside, this allows you to make changes without overriding it. Know what you want to do beforehand and see if it's worth the effort of trying to manipulate this way. You have to understand how the widget you're trying to interact with works and if it has any relevant events you can bind to. Also note that you're assuming someone that does override it doesn't drastically change the structure and that you're both not interacting with the same components.There are tons more events in the different persistent models you can look through like time elapsing, changing star systems, reputation increasing, etc.