Informations

While there is a lots of classes that can be created for help make your savegame system. Our goal is not to provide all of these because we cannot handle all needed things. DtArchives doesn’t provide project specific classes, it provide things that help you make yours.

Let’s see an exemple that explain what we mean :
We think you’ll need a component that save an actor that is not IElement, that’s simple:
– We create a BP_xComponent inheriting from ActorComponent_DTAe.
– We add IDeepSaver’s interface, GetOwner() as deepObject.
– But now what? Some projects will want to serialize and save at endPlay, some will only want serialize or do nothing because it’s handle by an other class (from an WBP, level… etc).

You’ll make your own classes that match your own project, if you need help we’ll be happy to help but we won’t provide such classes in the base plugin. Maybe later on we’ll provide some of these as downloadable add-ons.

UE4 doesn’t handle multi inheritance, for this reason, you cannot select more than one parent class.
It’s why we used Interfaces, you can sublass any classes and implement yourself IElement, for exemple if you already have a custom class that is not your own and that is your current base class (let’s say AwesomeClass), you can implement IElement in your own baseClass that is subclass of AwesomeClass.

IElement is the only interface that is needed (In reality it’s not “needed” but you’ll prefere use it), all others are optionals, you’ll add them when you need them.

If you are not in this worse case and your base actor class is suclass of AActor, just reparent it to Actor_DTAIComponentOwner (it’s realy helpfull to have a construct event in component), and make a second baseClass that inherite from Actor_DTAe, you’ll parent your classes that often need to be Element root to this one.

Do never reparent all your classes to a third party class, always insert in-between a class from your own even if it his totaly empty. You’ll save time one day…

Currently there is not a lot’s of DTA actors, we will add what you need, it’s easy and fast but at the time we made this tutorial there was :
– Actor
– Pawn
– Character
Each of theme come in two versions :
– DTAIComponentOwner That only fire the Construct event in IComponents.
– DTAe is a DTAIComponentOwner and implement IElement (e for element), it will expose his identifier and elementSetting to instances.

Currently there is only two DTA components classes :
– UActorComponent_DTAe
– USceneComponent_DTAe
These are IComponents (have a construct event) implementing IElement, they need an actor that is DTAIComponentOwner (or DTAe) for work. It will expose his identifier and elementSetting to instances.

UserWidget_DTAe is a widget that implement IElement.
You should know that it his registered befor the construct event, but after the pre-construct event. If you need it to be ready at pre-construct, just add a registerElement node in this event. It will expose his identifier and elementSetting to instances (In Designer mode, selecting the root widget).

You don’t need this if you don’t use “AutoLoadInstances” option (see in B6 InstanceObjects tutorial).

DtArchives provide two GameInstance baseClass :
– UGameInstance_DTA
– UPlatformGameInstance_DTA
Both are the same but inherite from different UE gameInstance baseclasses.

This class will just say to the master that the game is ended, but will do this after all endplay events have been called, the master will handle that and will save instances and instanceObjects at this time, ensuring that your work is completed before saving instances and instanceObjects.

This Won’t work on mobile platforms because no events are fired for endPlay or endGame. See in BP_ArchiveMaster_B5 or B6 if you want to know how to handle this on mobiles.

You can easyly modify your own gameInstance to match DTA, only one overriden function that call a function in the Master for a late endplay event, see “Plugins\DtArchives\Source\DtArchives\Public\DtAImplementation.h”.

For C++ users, please do not use things that are not exposed to blueprint because it is subject to change durring the beta.

Beta roadmap (in this order) :
– Add missing features.
– Clean of bugs
– little optimisation (we won’t work hard here but some easy changes will be done).
– Some functions remake from scratch.
– A better way of using GetObject.
– Async
– Clean of bugs
– All classes documented.
– end of beta.

Once in v1 :
– Pre-compiler options (mainly about identifiers but not only, you’ll be able to build with really little identifiers).
– Real Optimisation (We will work hard here).