PersistentData

In the VisualElement class, I found things like persistentKey and GetOrCreatePersistentData <T> (), OnPersistentDataReady (), SavePersistentData (), GetFullHierarchPersistenceKey ()
I would like to get a little more information about how this works.
My questions are as follows:
- How does SavePersistentData () understand what needs to be saved?
What kind of things does it save? Does this include ScriptableObject, Serializable, or primitives? Does encapsulation affect (data must be public)? How close is it to the rules for storing objects in MonoBehaviour?
What key is used to save - persistentKey or GetFullHierarchicalPersistenceKey ()?
- How does GetOrCreatePersistentData <T> () understand exactly what we are going to get? Does it depend on the type? From GetHashCode ()?
- Where is the data file stored?

Are there any other methods and fields that I need to know about in order to use it?

 

I found out that GetOrCreatePersistentData returns a value by type. Because of this, I have an even greater misunderstanding of how data is stored. Especially enters the discord in a situation where there are two objects of the same type.
Does it store only 1 object of each type? How does it choose what to store?

Also, I saw that GraphView uses private fields for storage, which are not marked with an attribute, which goes against what is said in the documentation.

 

What is the recomended way to store data about things like Nodes' positions, which are relevant in the editor but not ingame?

 

This is exactly what I'm trying to use it.

I think it makes no sense to keep this data separate from the nodes and you can just enclose it inside UNITY_EDITOR. We can use the internal level of visibility, and then let the editor assembly see this internal. This is the best solution I have found. Otherwise, constant synchronization between the game and editor entities is required, which in my opinion will cause problems in a huge number of cases. Another circumstance is that it still remains important information that needs to be under version control.

So you create two asmdef files for the editor and for the runtime. You link runtime for editor assembly. And create AssemblyInfo.cs in runtime assembly:

Code (CSharp):

1. using System.Runtime.CompilerServices;
2.  
3. [assembly: InternalsVisibleTo("MyModule.Editor")]
4. [assembly: InternalsVisibleTo("MyModule.Editor.dll")]

And use in runtime:

Code (CSharp):

1. #if UNITY_EDITOR
2. [SerializeField]
3. internal int myEditorField;
4. #endif

it is important to understand the difference between the individual information of the editor, which is important only for a specific user (zoom, scroll) and public (node position e t.c.)

 

Do you already have any suggestions on this? I ask about this, because there is also another topic that concerns such data. The fact is that some of them should be able to be used with Undo / Redo. For example, if we are talking about a list of selections, it becomes relevant. We may want to use Undo / Redo for such things. Will the rethinking include addressing this issue, or should such things be done independently?

 

@uDamian are you saying there are no gotchas with having conditional serialized fields anymore? because in older versions, Unity would error when building because different serialization layout between platforms (tried on my own skin multiple times )