Easy Multi Save Documentation
Easy Multi Save Documentation
Easy Multi Save Documentation
Plugin Versions
1.07 (UE4.22 - UE4.23)
1.06 (UE4.19 - UE4.23)
Example Project Version
1.1
Table of Contents
Chapter 1. Introduction 3
1.1. General Concepts 3
1.2. Installation 3
1.3. Example Project 3
1.4. Quick Start 4
Chapter 2. Reference 5
2.1. File System 5
2.2. Native Function Overview 6
2.3. Saving and Loading 9
2.4. Plugin Settings 11
Appendix 26
Support 26
Credits 26
Plugin Version History 27
Chapter 1. Introduction
1.1. General Concepts
Easy Multi Save is a lightweight all-in-one saving/loading system, that does the major
work for you. The goal is to make it as easy to use as possible, even if you have no
experience other than the UE4 basics. The system supports all kinds of games and apps
for all platforms. EMS is all about streamlined saving of complex data.
Save/Load:
● Data to an infinite amount of save game slots.
● Persistent data such as game progress.
● Player/Client including Controller, Pawn and State.
● Level and Sub-Level Blueprints.
● Actors placed in the level or spawned at runtime.
● Actor components for all Actors.
● Blueprint Structs that can be recursive.
● A separate player profile, for storing settings etc.
The system has a clear and consistent structure, in-line with the core idea of UE4.
"Work smarter, not harder."
1.2. Installation
The installation works as with every other UE4 Plugin. After downloading, look up the
Easy Multi Save Plugin in L
ibrary ➔ Vault . Then click on I nstall in Engine .
Now you are ready to use EMS.
1.3. Example Project
The Example Project shows most examples from here in action.
NOTE: The Example Project is currently only available for Engine Versions 4.20 and up.
Download here
It only features a minimal amount of content, so you should be able to copy and paste
things into your own projects. The EMS_HelperFunctions library also features a few
useful methods for you to use.
1.4. Quick Start
If you just want to get the bare-bones functionality working before reading about the
details, you can do so.
➤ Add the EMS Actor Save Interface to your Pawn Class.
➤ Add the EMS Actor Save Interface to one of your Actor Blueprints or a Level Blueprint.
➤ Call the Save and Load Game Actor nodes by simply binding them to input keys.
Like in the image below. Make sure to check Level and Player Actors on both nodes.
This is the most simple way of saving and loading Actors, you are now free to expand
upon this and add variables to your classes that you want saved etc.
Make sure all variables you want to save have the Save Game flag checked!
In the coming chapters you find an in-depth overview of what EMS can do.
Chapter 2. Reference
2.1. File System
Easy Multi Save uses a multi file saving structure, where all files for a savegame are put
into a single folder with the name of the save game. This also supports easy sharing of
save games between players and you are able to just upload the files you need to
services like Steam Cloud.
/SaveGames/SaveGameName/
The folder holds all the data for a single save game / save slot.
/SaveGameName/SaveGameName_Slot.sav
Holds information on the save slot, like level name, list of players and timestamp.
Slot info is always saved automatically when calling one of the save functions.
/SaveGameName/SaveGameName_Persistent.sav
This is the persistent save file that exists between levels.
/SaveGameName/SaveGameName_Level.sav
This file holds all placed and runtime spawned level actors with the save interface.
/SaveGameName/SaveGameName_Player.sav
This file contains all the information on the player controller and pawn.
A client in multiplayer should only save this file.
/SaveGameName/SaveGameName.png
This is the thumbnail created for the save game from a 2D rendertarget source.
/SaveGames/LocalProfile.sav
This file can hold information on the local player, for example if you have settings that
you don't want to put into ini files, like mouse sensitivity.
2.2. Native Function Overview
Less complexity, more power. EMS does not need many functions to operate.
Here you will get a nice overview of each function and what it does.
Make sure to check out the EMS_FunctionOverview Blueprint in the Example Project.
Save Game Actors
This is the main function for saving Player and Level Actors.
Data
Here you check what data you want saved. Level and/or Player.
Load Game Actors
This is the main function for loading Player and Level Actors.
Data
Here you check what data you want loaded. Level and/or Player.
Full Reload
If false, load only Actors that have not been loaded.
Set to true if you want to reload all saved Actor Data.
Useful for reloading game data without reloading the actual level.
You still need to reset the level state for unsaved Actors as you see fit.
Save Persistent Object
Here you can save the persistent object save file, which should be used to store data
that you want to persist between levels and access globally in a convenient way.
Return Value
If the saving was successful.
Get Persistent Object
With this, you can get the persistent object save file, wherever you want.
No need to extra call a loading function.
Return Value
The persistent save object, from which you can easily cast to your custom
persistent save class and directly access the data.
Get All Save Slots
With this, you can get all the save games that you have saved. Aka. Slots, which are
saved automatically with game data or persistent data.
Return Value
The array of all available save game slots, sorted by time of saving.
Set Current Save Slot
Here you can set the name of the current save game slot. All save/load functions will
then use this slot name, this ensures consistency. If you don’t set the current slot, the
Default Save Slot Name w ill be used from the P
lugin Settings .
Save Game Name
The current slot will be set to this name.
Get Current Save Slot
With this, you can get data from the current save game slot.
Save Game Name
Returns the name of the current save slot. Simply a shortcut for convenience.
Return Value
The slot info save object, from which you can easily cast to your custom class. In
most cases, you should be fine with the default slot info.
Delete Save Slot
This function deletes a save game folder and all of its files.
Save Game Name
The slot/folder to be deleted.
Save Local Profile
Here you can save the local profile save file. This can be used to store data such as
player settings, which are separate from the save slots.
R
eturn Value
If the saving was successful.
Get Local Profile
With this, you can get the local profile save game object and access the data globally in a
convenient way.
Return Value
The local profile save game object, from which you can easily cast to your custom
class.
Export Save Thumbnail
Export a save game thumbnail image from a rendertarget source.
This function is expensive and usually causes a small hitch.
Texture Render Target
The render target source from which the thumbnail is generated.
Save Game Name
The name of the save game slot, for which the thumbnail should be exported.
Usually this should be the current slot, but there may be cases, when you want to
export for a different one.
Import Save Thumbnail
Import a previously exported thumbnail image.
NOTE: This function is currently only available for Engine Versions 4.20 and up.
Save Game Name
The name of the save game slot, from which the image should be imported.
Return Value
The thumbnail image, imported as Texture2D.
2.3. Saving and Loading
Transforms
Transforms are automatically saved/loaded for moveable Actors.
For Components, the relative Transform is used.
The Pawn automatically saves/loads location and rotation.
The Controller automatically saves/loads the view rotation.
Variables
All variables are treated the same, you just check the S ave Game flag.
Blueprint Structures
These are treated like all other variables, you just check Save Game and that’s it.
No matter how complex the struct is, EMS takes automatically care of it.
So you can have an array inside an array inside an array etc. for every Actor.
Dynamic Object References
Saving dynamic object references is not supported. For example, you spawn a bunch of
Actors and store them inside an array in your level Blueprint. This can get really messy
as it would require to relink objects etc. You would basically save the Actors directly by
adding the interface and then access them when the level blueprint is loaded, or you
would need to respawn them from data inside the array.
Static Object References
Variables referencing Meshes, Materials or AnimTrees can be saved, as long as it
contains a direct reference to an asset. For example, you have an Actor and you want to
set it’s Static Mesh Component to a new Mesh.
Alternatively, you can also just use a string with the object path and find it with the asset
registry. This is a bit more flexible in some cases.
Logging
The Output Log will give you a good overview of what EMS currently does.
Type "LogEasy" in the log filters, to see only messages from EMS.
Actor Dependent Objects
Saving actor dependent objects such as AnimBlueprints, UI Widgets and Blackboards
directly is not supported, this can break compatibility with other Plugins or even default
UE4 features. You can just save variables directly inside the Actors.
Actor Name Dependence
Since UE4 does not have a GUID for Actors, EMS uses Actor names as unique identifier.
This means, if you rename an Actor, you also need to resave it. If you make an update
for your game where you have an Actor renamed, old save game files will not be able to
load that Actor.
Game Instance
Saving the Game Instance is currently not supported. Usually it is just used to pass
variables from one level to another and not for saved data. There may be support for
Game Instance saving in a future update. Using the P ersistent Save is alot easier and
more flexible in most cases. You can also use the Persistent Game Mode feature.
See P lugin Settings .
2.4. Plugin Settings
First, it's important to know that you don't need to change any settings to get going.
But it's good to know what they do. To change settings go to:
Project Settings ➔ Plugins ➔ Easy Multi Save
General Settings
Default Save Slot Name
If you don't specify a current slot name, or if you just want to use a single save game
without slots, this will be the name of your save game.
Persistent Save Game Class
The Blueprint you want to use as your custom persistent class, where you store data
that should be accessible between levels. You can simply cast to your custom class, to
access the data. See P ersistent Data.
Slot Info Save Game Class
If you want to use custom data for your Save Slots, this defines your custom Blueprint
class for it. Usually you are fine with the default Save Slot class. See C
ustom Slot info.
Profile Save Game Class
The Blueprint you want to use as your custom local profile class. This is where you
should store data like settings etc. See L ocal Profile.
Persistence
Persistent Player
If this is checked, the Player Controller, Pawn and Player State, can be saved and loaded
independent of the level. See The Player section.
Persistent Game Mode
If this is checked, the Game Mode and Game State, can be saved and loaded
independent of the level.
Save and Load
Multi-Thread Saving
If enabled, saving happens not on the game-thread, this is useful if you have many
Actors with complex data, so you won’t get any frame drops. This is potentially not as
safe as using the game-thread and is to be used with more caution.
Load Method
The method to use for loading Level Actors. See L oad Methods .
Chapter 3. Basic Use
3.1. Save Slots
If you only want to use a single save game, you don’t need the save slot system at all.
You just set the Default Save Slot Name in the Plugin Settings and you’re good to go.
A save slot is simply a folder which holds all the save game information and files.
EMS supports single slot, static slots and an infinite number of dynamic slots.
For quick saves, auto saves and manual saves. The four functions described in the
overview, will make it very easy to set up any kind of behaviour in your Blueprints.
If you don’t want to save/load anything at all, like when starting a new game, you can
just call Set Current Save Slot and set the name to something like NULL or NONE.
And then set a proper name again when saving. If the name is not set, it will use the
Default Save Slot Name from the P lugin Settings.
More advanced topics about save slots can be found in the C ustom Slot Info and
Additional Data sections.
3.2. Save Interface
Every Actor you want to save, needs the E MS Actor Save Interface added to it.
The Interface calls some useful functions and events.
ActorPreSave
Called before saving the Actor, here you can safely set all kinds of variables and make
sure they have the exact value you want at the time of saving.
ActorSaved
Called after saving the Actor and its components has finished.
ActorLoaded
This event is called after loading the Actor and its components has finished.
From here on, its safe to access all the loaded data of the Actor.
ComponentsToSave
Here you can add an array of Components that you want to save.
This function has no effect for the level blueprint, since it cannot have components.
See A
ctor Components .
3.3. Level Actors
Saving and loading level actors is really easy with EMS. You can save placed as well as
runtime spawned Actors and mix them up, even if they have the same base class.
You can save almost every Actor you want by just adding the EMS Actor Save Interface .
From physics Actors, to AI characters, to doors and campfires. There are no real limits.
Of course you can just add the interface to Level Blueprints and Sub-Level Blueprints as
well and save/load all their data. They just work like every other Actor.
You can save Game Mode and Game State as persistent Actors, so they can be loaded
independent of the level. See Plugin Settings .
Saving the Game Instance is not supported. You can just use the P ersistent Object .
Procedural Levels
For a procedural generated level, you would save the Actors directly and then load the
level from the saved file, instead of generating it. You can also combine this with level
streaming and saving/loading sub-levels. If your level has thousands of Actors, you
should definitely use one of the advanced L oad Methods .
3.4. The Player
Players are handled differently than level Actors by EMS.
The Player Controller, Pawn and Player State are saved to a seperate file.
This allows for saving and loading the player in a multiplayer game.
For example, in a survival game, when the player builds a shelter, it will be part of the
level. But the actual parts may have been stored in the player inventory.
Load Game Actors for the player can be safely called after you have possessed your
Pawn. You can also possess the Pawn and then call Load Game Actors for Level and
Pawn at once, while still having a loading screen around. In the end, it's really up to your
project. EMS does not mess with Pawn possession or anything else.
In multiplayer, you have to load server and client data separately. See M ultiplayer .
Inventory
Inventory is always a special case. EMS does not provide a rigid path to save inventory,
but using the available tools will make it very easy.
To save complex inventory, it’s a good idea to save the data inside your Pawn and then
call events on the individual inventory Actors once the data has been loaded.
This means, you don’t save the actual inventory Actors as you save level Actors.
This is where the Blueprint struct saving(aka. Structception) comes into play.
Use a complex Blueprint struct to store all inventory data inside your Pawn and then
spawn the inventory on load and re-apply the data, done. 😺
Persistent Player
The persistent player option can be very useful if you don't use level streaming and
want to easily keep player health and ammo counts for weapons etc. saved over the
course of several levels, without storing the data in the persistent save file.
In this case, the transforms of the Pawn and Controller are not saved at all, you will
need to set them manually in your Blueprints, so you can keep track of the proper
position for each level. You would just save/load a custom struct array with transforms
and level names in the Pawn or Controller Blueprint.
3.5. Actor Components
Scene and Actor Components
Components are added to an array, as part of the E
MS Actor Save Interface.
This also gives you a nice overview of the components that are saved and loaded.
Otherwise it works exactly as saving Actors.
Components don't need the interface, as they are part of the Actor.
You can access component variables with the interface events and/or call functions on
the Component to use the variables .
Child Actors
These Components can also be saved as part of the Actor without the interface.
If the class of the child Actor has the interface, it will not get saved as a Component.
3.6. Persistent Data
The persistent save object can be useful if you easily want to save persistent data and
access it globally in a convenient way. This can be compared with a standard UE4 save
game object. It’s a lot easier with EMS, since it works globally by just using the
Save Persistent Object and Get Persistent Object functions.
You need to create a child Blueprint of E MSPersistentSaveGame and then set this in the
plugin settings to the Persistent Save Class. This way you can easily cast to your custom
Blueprint, i recommend making a function in a library so you only need one node.
In addition to the persistent save game, persistent player and persistent game mode,
you also can save every Actor between levels in Version 1.07 and up . To do this, you just
need to add the “EMS_Persistent” Tag to the Actors tag array. If the Actor with the Tag is
placed inside the level, it will respawn automatically in other levels when the savegame
is loaded.
3.7. Local Profile
The local profile can be useful if you want to save something like player settings, which
you do not want to save inside ini files, or if you have a Blueprint only project that does
not use the GameUserSettings system.
You can simply use the Save Local Profile and Get Local Profile nodes everywhere in
your Blueprints. Similar to the Persistent save functions. The difference is, data in this
file is not bound to a save game slot.
Similar to the persistent save game, you will need to create a child Blueprint of
EMSProfileSaveGame and then cast to it.
3.8. Thumbnails
Easy Multi Save luckily also support saving thumbnail images as *.png for save slots.
This is done by saving the captured image of a 2D render target source. It can be really
useful for a save game UI. The Example Project shows how this can be done. In the
EMS_HelperFunctions library, you find a Blueprint function named Save Thumbnail
Image, which shows how to set up the render target capture.
Make sure the Render Target Texture has the R TF RGBA8 f ormat.
Please note that converting and saving the *.png image is expensive and usually causes
a small frame drop.
Chapter 4. Advanced Use
4.1. Level Streaming
EMS fully supports saving and loading Actors for streamed Sub-Levels.
To save data from a Sub-Level, it must be loaded and visible.
To load data from Sub-Levels, you just need to call the Load Game function again after
the Sub-Level has been loaded and is visible.
Dynamically spawned Actors are always part of the persistent level.
You also want to keep F
ull Reload u
nchecked, otherwise it would load all Actors again
and not just the new ones from the Sub-Level.
4.2. Multiplayer
Saving in multiplayer games is a very complex topic, there are many pitfalls and
considerations.
You will have to save the player seperately for client and server.
This can look something like this:
Client
A client can save the replicated data of it's owned Actors. Controller, Pawn and Player
State. You will have to pass all saved variables(including transforms) through a
replicated function call, so the server knows about it.
The automatic saving/loading of transforms has no effect on a client.
In practice, it looks something like this:
Listen Server
The Listen Server can save/load its own Player as well as the Level.
Dedicated Server
Saving and loading data on a dedicated server is supported in Plugin Version 1.07.
The saving and loading works as it would on a ListenServer.
4.3. Load Methods
Having huge amounts of Actors in your level can be potentially expensive to load.
For this case, EMS supports different methods to load level Actors.
The Player always uses the default method.
You can change the load methods in the Plugin Settings .
Default
The default method simply loads all Actors in the game thread at once.
This is useful for small amounts of Actors and is likely sufficient for most projects.
Deferred
Deferred loading is a method for loading many Actors at once.
It distributes the loading across several frames. The system batches up a small amount
of Actors, loads them at once and then repeats this as many ticks as it needs to load all
actors. This is useful if you have a medium amount of Actors that contain alot of
complex data, like structs.
Multi-Thread
This method will perform the major update and comparsion operations on a
background thread, this is useful for very large amounts of Actors, that don’t use super
complex data.
4.4. Custom Slot Info
Using a custom Save Slot Info is easy aswell. You need to create a child Blueprint of
EMSInfoSaveGame and then cast to it from GetCurrentSaveSlot t o access the data.
Since the Slot Info is always saved automatically, you need to make sure that you set the
variables before one of the main save functions like Save Game Actors or
Save Persistent Object.
4.5. Additional Data
Sometimes you want to save additional data as part of a Save Game Slot.
For example, a Render Target as *.png from a panorama photo mode in your game.
The only thing you need, is to set up the correct paths to the Save Slot.
In this example, a Render Target is exported to the Current Save Slot and saved in the
appropriate folder.
4.6. Versioning
Different projects may have different requirements for versioning.
This is why EMS does not have pre-build versioning.
Do you want to check against engine or game version ?
Do you want to hide the save slot or show a message that the save game cannot be
loaded ? Or maybe you don't want the player to be able to start the game at all.
You can easily set up versioning with EMS. If you want, you can do it per save-file as well.
As with all sub-systems for EMS, flexibility is the key.
In this example, we check against the Engine version of UE4.
In your C ustom Slot Info, create a new string variable called EngineVersion.
Set this variable before saving the game.
Check against it as you see fit. Here we just prevent loading the game, when the engine
version does not fit. In this case, saving again would still allow for override. But you can
prevent that by not starting the game or not allowing the player to save again.
4.7. Project Based Plugin
In some cases, for example when building for Android arm64-v8a , you will have to
package Easy Multi Save alongside the project to make it work on the device.
You have to copy the plugin from the Engine to the Project Dir.
Create a P
lugins folder inside your Project directory. \...\MyProject\Plugins
Go to the Folder where UE4 is installed and pick the version your project is using.
For 4.22 this is \ ...\Epic Games\UE_4.22\Engine\Plugins\Marketplace
Copy the EasyMultiSave folder to the newly created Plugins folder inside your project
directory.
Now open the Epic Launcher and uninstall the Easy Multi Save plugin, so you only get
the one from the project. Please note that you have to install EMS again from the
launcher, if you want to use it with other projects.
Appendix
Support
If you have questions, comments, bug-reports, feature requests or want to show a
project that uses EMS, feel free to contact me any time.
It would also be very nice, if you could rate EMS on the UE4 Marketplace. Thanks!
Email Support
HegiDev@gmail.com
Twitter Support
Michael Hegemann (@HegiDev)
Support Thread
Thread at the Unreal Engine 4 Forum
Credits
Easy Multi Save © 2019 by Michael Hegemann .
Special Thanks
Rune de Groot
Jaden Evanger
Rama
JimW
Orfeas Eleftheriou
Muit
Matt Stafford
Matthias Hölzl
Sukrit Sarankawin
Herr Edgy
Plugin Version History
Version 1.07
● Actors now properly save default values of variables
● Added support to save any Actor between levels with the "EMS_Persistent" tag
● Added support for saving on Dedicated Servers
● Added support to save C++ Structs in Blueprint
Version 1.06
● Fixed a small bug where the correct persistent save is not loaded when using
multiple save game slots
Version 1.05
● Fixed an issue where the Playerstate is not loaded
Version 1.04
● Fixed save issue with non-player-controlled pawns
Version 1.03
● Fixed error related to EMSData.h when trying to package project
Version 1.02
● Support for UE 4.19 and UE 4.21
● Binary Support for iOS and Mac
Version 1.0
● Initial Build