Handling of change of field or key type

Vote for new features, or make your own requests here.
Post Reply

Handling of change of field or key type

Yes, I would like this feature
2
100%
No, I would not like this feature
0
No votes
 
Total votes: 2

User avatar
Joel
Moodkie Staff
Posts: 4812
Joined: Wed Nov 07, 2012 10:32 pm

Handling of change of field or key type

Post by Joel »

Status

Requested

Complexity

6/10

Description

Some method of handling previously saved field which has since has it's data type changed without creating an ES3Type.

The most effective way of doing this is likely to be using attributes, similar to Unity's FormerlySerializedAsAttribute.

Note that there currently exists a solution to this: to turn off type checking and ensure that you're providing the precise type of the object as the generic parameter when saving and loading (i.e. not using an inherited class as the generic parameter). The following script demonstrates this:

Code: Select all

using UnityEngine;

public class ChangedTypeTest : MonoBehaviour
{
    void Start()
    {
        ES3Settings.defaultSettings.typeChecking = false;

        OriginalClass originalClass = new OriginalClass();
        originalClass.myInt = 456;

        ES3.Save<OriginalClass>("myKey", originalClass);

        RenamedClass renamedClass = ES3.Load<RenamedClass>("myKey");
        Debug.Log(renamedClass.myInt);
    }

    public class OriginalClass
    {
        public int myInt = 123;
    }

    public class RenamedClass
    {
        public int myInt;
    }
}
Joel @ Moodkie Interactive
Purchase Easy Save | Contact | Guides | Docs | Getting started
DeliInteractive
Posts: 9
Joined: Sat Feb 27, 2021 4:03 am

Re: Handling of change of field or key type

Post by DeliInteractive »

Hi Joel!

First: we love love love the tool you've built!

We're looking to release a game into early access which will utilize EasySave 3. Because of the iterative nature of development, we expect save data to occasionally change shape. Supporting a similar feature to [FormerlySerializedAs] for us would be a godsend. This particular data shape change problem consistently borked our players' saves when we changed things in our old game We Need To Go Deeper (which didn't use EasySave). I saw this resulted from another forum thread here, but I'm not quite savvy enough of a C# programmer to know how to make a custom solution like the other user.
User avatar
Joel
Moodkie Staff
Posts: 4812
Joined: Wed Nov 07, 2012 10:32 pm

Re: Handling of change of field or key type

Post by Joel »

Hi there,

If you haven't created an ES3Type for your data and you're letting it automatically serialise it, an alternative until we get enough votes on this would be to disable type checking (this is described in the first post of this thread).

If you're using ES3Types you would simply need to edit the ES3Type you've created so that it uses your new class name.

All the best,
Joel
Joel @ Moodkie Interactive
Purchase Easy Save | Contact | Guides | Docs | Getting started
DeliInteractive
Posts: 9
Joined: Sat Feb 27, 2021 4:03 am

Re: Handling of change of field or key type

Post by DeliInteractive »

Joel wrote: Wed Jun 29, 2022 8:50 am If you're using ES3Types you would simply need to edit the ES3Type you've created so that it uses your new class name.
Absolutely, and we are using ES3UserTypes. They're super duper slick. I've also noticed that if I serialize a list of base class type by value, it can deserialize correctly into its child class objects -- that kinda blew me away! No doubt EasySave is much more capable in the face of evolving save files. It would just be cool to have more guard rails for dummies like me who may not realize something is going to slip through the cracks before it busts a player's save. Honestly any other already-existing features or good practices that you know of could likely go a long way. I'm just too new to the field to even know the right questions to ask.

Anyway, hopefully some other folks chime in looking for a similar feature. If not, we'll try to build up an internal practice that minimizes the damage our agile development is prone to cause. Heheheheh!
Post Reply