The same class loads as a different class.

[KBTIT]

For example, in UnitManeger.cs we have units as follows

Code: Select all

public Unit unit = null;

On the other hand, Room.cs references a unit that belongs to

Code: Select all

public class Room {
	[HideInInspector][ES3Serializable]
	public Unit joinUnit;
}

Save and load as follows

Code: Select all

void Save(){
        Unit unit = new Unit();
	room.joinUnit = unit;
	
        ES3.Save("unit", unit, file_name);
        ES3.Save("room", room, file_name);
}

void Load(){
	unit = ES3.Load("unit");
	room = ES3.Load("room");
	
	Debug.Log(room.joinUnit, unit));
	Debug.Log(ReferenceEquals(room.joinUnit, unit));
    	Debug.Log(Equals(room.joinUnit, unit));
}

After loading, the unit and the unit in the room are compared, but none of them will be false.
For example, if I set the name of string to unit, the name of the unit and the name of the unit in the room match.

Therefore, the save and load appears to be somewhat normal...
However, because the clusters do not match, the unit cannot find the room it belonged to.

How can I fix this problem?

[Joel]

Hi there,

Please could you send me a script which I can drop into a new scene in a new project which replicates your issue along with instructions so I can see what is happening.

Also if your issue is that it creates a new instance when loading rather than referring to the original, this is normal as fields of non-UnityEngine.Object types will be saved by value. In this case you would need to give each of your instances a unique ID and then save this instead of saving the class itself, and save a list of all of your instances which you can cross-reference with these IDs.

All the best,
Joel

[Joel]

Thanks for sending that over. This part of my previous message is indeed relevant to you:

if your issue is that it creates a new instance when loading rather than referring to the original, this is normal as fields of non-UnityEngine.Object types will be saved by value. In this case you would need to give each of your instances a unique ID and then save this instead of saving the class itself, and save a list of all of your instances which you can cross-reference with these IDs.

There is an example of this here:
https://moodkie.com/forum/viewtopic.php?t=2396

All the best,
Joel

[KBTIT]

Uh, sorry, I looked at the Example but could not understand how this works.
I mean, in my case, what do you want to dictate?

[Joel]

The issue is that your jointUnit field will be saved by value, not by reference, because it's not a UnityEngine.Object type. This means that when loading the jointUnit field, it will always create a new instance of that Unit and not a reference to it (because it's not possible to save a non-UnityEngine.Object type by reference).

Instead of saving the Unit itself, you would need to save some unique ID which allows you to determine what Unit jointUnit refers to. The example I provided shows a way of doing this. When a Unit is created, it's added to a Dictionary and assigned a unique ID. Now instead of saving the jointUnit itself, you would get it's ID from the Dictionary and save this. Then when loading, you get the Unit with the loaded ID from the Dictionary and assign it to your jointUnit field.

If your Unit's are created at runtime it's also necessary to save/load the Dictionary before saving/loading anything which references one of your Units.

Also note that if each of your Units have a unique name, you could use this as the unique ID.

All the best,
Joel

[KBTIT]

Hmmm, I think I may have understood, but I am confused.

I mean, not the easy-to-handle list type as follows,

Code: Select all

static public List<Unit> units = new List<Unit>();

Do we need to use a meaningless Dictionary type to store the class, such as

Code: Select all

static public Dictionary<string , Unit> units = new Dictionary<string, Unit>();

[Joel]

Hi there,

You can use a List or a Dictionary. With a List you would need to iterate through the list and find the unit with the given ID, whereas with a Dictionary it's a single line of code to do so, but whichever you prefer.

All the best,
Joel