How to make visual element property fields detach from serializable objects and preserve UI

[nithisha08]

I am creating a property field in the following manner inside of an EditorWindow.

   var serializedComponent = new SerializedObject(component);
   SerializedProperty property = serializedComponent.FindProperty(outerProperty);

   var propertyField = new PropertyField(property);
   propertyField.BindProperty(property);

When i unload the scene, the serialized component loses reference to the original serializable object and the property field stops displaying the original values.

Before unloading:

After unloading:

I want the UI to remain even after the object is destroyed. I don’t want to draw it out manually for complex types using visual elements myself. Can I do this by stopping the property field from listening to serialized property field change events? I looked into cloning visual elements and storing them but that doesn’t seem to be an option.

[Kurt-Dekker]

@nithisha08

When i unload the scene, the serialized component loses reference to the original serializable object and the property field stops displaying the original values.

That probably means you’re editing the thing in the scene, not the thing on disk (eg, prefab, scriptable object or other asset or whatever).

Fix that first, I think your issue will go away.

[nithisha08]

is there a way to do this without having to store my gameobject as a temporary prefab and reload it?

[nithisha08]

Can I get all event handlers and override the one responsible for deleting the UI?

[Kurt-Dekker]

I think you might be looking for ScriptableObjects …

What exactly are you trying to do here?

ScriptableObject usage in RPGs:

ScriptableObjects for an RPG with multiple units in your team

The most important concept about ScriptableObjects (SOs) is that they are custom-shaped blobs of data that you can edit inside the Unity inspector. The serialized values inside a SO map directly to that created asset on disk, the instance of the SO. When your game runs, it needs some data. One way to get that data is to hard-code it in the code. That is bad because when you change it, you need to change code. That’s why we have things like a SO to configure existing unchanging shipped code. W…

Creating lookup tables that can be assigned in the inspector.

This looks like a job tailor made for ScriptableObjects! ScriptableObjects are basically structured blobs of predefined data to help you create content for your game. For instance if I had a ScriptableObject called Weapon, it might have these properties: name detailed name description damage toughness weight what it looks like in the inventory what model it uses in game what animations the player uses to swing it I would create many of these Weapons, each one a file on disk (also called an…

Usage as a shared common data container:

Better Data with Scriptable Objects in Unity! (Tutorial)

[nithisha08]

I just want to display information about the component attached to a gameobject in the scene even after the scene is unloaded. I will not be editing this via the property field. I’m not sure if using scriptable objects is a good idea because i don’t know what fields my component will have before hand - i want a more generic way of storing data associated w the component.

[Ubrano]

It would be beneficial, if you posted more code to the issues you are having. As you already got one clear pointer, you need take care what you are modifying, if you want changes to persist. I.e. an instance vs. the original. With most ‘regular’ serialisation stuff Unity performs flawlessly out of the box, thus your case requires further explanation. What exactly are you trying to achieve?

@nithisha08

display information about the component attached to a gameobject in the scene even after the scene is unloaded

Shouldn’t you try get the information before the scene is unloaded? All dynamic stuff will be gone with the scene unloaded. That’s why you need scriptable objects, so do have a look at them, as advised above, they are suitable to hold information across scenes. Noticeably you should consider scriptable objects can be modified in design time, when you add items to them (e.g. to a list or something, you modify the contents) or if you need additional fields (you modify their structure). Nevertheless, in runtime, you may add contents only temporarily for the duration of the application session. It’s also ambiguous, are you looking to register the name/type of components or are you looking to register the very fields of various component?!? At any rate, you could always resort to writing a custom log of whatever has been going on with the game objects and components of your concern.

Since you are working with serialisation, caution is advised. In our experience you may declare a class serialisable and Unity might even not object, yet custom classes might require custom serialisation.

[spiney199]

@nithisha08

I just want to display information about the component attached to a gameobject in the scene even after the scene is unloaded.

That’s not going to be possible via a serialized object. When you unload the scene, the object is destroyed, and the serialized object is pointing to a fake-null.

You would have to get this data in a non-serialized form before the unload. Otherwise, you might need to change your approach for whatever you’re doing here.

[nithisha08]

Thank you @Kurt-Dekker @Ubrano @spiney199 !

I did end up using scriptable objects. It is a good solution to store persistent data. However, it’s not very good at serializing entire gameobject data because it only serializes the reference to the gameobject. When my property field references a gameobject and the gameobject’s reference is lost when the scene is unloaded, the scriptable object doesn’t work as well anymore. However, it’s perfect for visualizing primitive data without relying on the gameobject. I decided to switch my approach to not display the property field when the gameobject reference is lost like @spiney199 said.