Coldwynn wrote: ↑Mon Oct 31, 2022 1:04 am
I'm sorry, I'm afraid I don't understand what you mean by this. Could you clarify?
This has to do with my, as of now, incomplete understanding of ES3.Load and ES3.LoadInto as applied to saved gameObjects or prefabs.
I understand that with the ES3.Load an instance of the object is created, but when I implement it, I don't see the instance (although a Debug.Log of the vector3 values show that it is "there"). Where is the instance in the Hierarchy? Does it instantiate on the original parent? What if I had Destroy(ed) the parent prior to the load, where does it instantiate then (especially if I have multiple gameObjects on scene)?
Likewise with ES3.LoadInto ... Does this mean that the receiving gameObject acquires all the components (replacing its own original settings) of the gameObject being loaded?
I'm working through several script variations to try and tease out the differences.
Hi there,
ES3.Load will create a new instance if one with the same instance ID doesn't already exist. For example, the following code would load the data into the existing instance:
Code: Select all
var go = new GameObject();
ES3.Save("go", go);
var loadedGo = ES3.Load<GameObject>("go");
Debug.Log(go == loadedGo); // This will output 'true'.
If we were then to exit play mode and re-enter, and run the following code, it would create a new instance as GameObject with the same instance ID will no longer exist in the scene (as it will have been destroyed when we exited playmode):
Code: Select all
var loadedGo = ES3.Load<GameObject>("go"); // This will be a new instance.
Note that if we were to do the following instead of the above code, it would still create a new instance because the GameObject we've created ourselves won't have the same instance ID as the one in the file.
Code: Select all
var go = new GameObject();
var loadedGo = ES3.Load<GameObject>("go");
Debug.Log(go == loadedGo); // This will output 'false'.
The only way to create an instance with that instance ID would be to load the GameObject from the file, which will assign that instance ID to it.
Another thing to note is the strange way that Unity destroys objects. When you call Destroy(go), it only marks that GameObject to be destroyed and doesn't actually get destroyed until the end of the frame. This means the following code wouldn't create a new instance, because you're destroying and loading on the same frame:
Code: Select all
var go = new GameObject();
ES3.Save("go", go);
Destroy(go);
var loadedGo = ES3.Load<GameObject>("go");
Debug.Log(go == loadedGo); // This will output 'true' because 'go' isn't destroyed until the end of the frame.
This is controlled at Unity's end rather than ours.
-----
Where is the instance in the Hierarchy? Does it instantiate on the original parent?
A GameObject's position in the hierarchy (or it's parent) is defined by it's Transform's 'parent' variable, which is saved with the GameObject.
What if I had Destroy(ed) the parent prior to the load, where does it instantiate then (especially if I have multiple gameObjects on scene)?
If the parent doesn't exist, it can't parent the GameObject to anything and will be placed at the top of the hierarchy. This behaviour is defined at Unity's end rather than ours.
Likewise with ES3.LoadInto ... Does this mean that the receiving gameObject acquires all the components (replacing its own original settings) of the gameObject being loaded?
If the Components are supported types then yes (see the Saving and Loading GameObjects guide for more information on which Components will be saved).
Specifically it does the following when loading a Component:
- Check if the GameObject we're loading into already has the Component we're loading.
- If it already has the Component, check if we've loaded any data into this Component yet.
- If it has the Component and it's not yet been loaded into, load the data into this Component.
- Otherwise, add a new Component to the GameObject and load the data into this.
All the best,
Joel