Full Inspector: Inspector and serialization for structs, dicts, generics, interfaces

The issue is with both forge-unity and the full inspector samples, using unity 4.3.1f1, though I just found out that they must be placed in the Assets folder, not a subfolder of it. That fixed the error, I'm just surprised that the location matters.

Also, you might want to update your first post in this thread. There are two links to the trial but they seem to be pointing to different versions.

By the way, I hope you will also bring Forge to the asset store along with a more detailed guide. I haven't had a chance to experiment with it yet, but it sounds very promising!

Thanks for your help.

 

What is forge-unity ?

 

Ah, thanks. I've corrected the links.

That's strange that you're getting errors when the assets are not in the top level directory. I'm able to put them wherever I want. There shouldn't be any code in Full Inspector that depends on the location of files (one of the samples references a ScriptableObject, but Unity should be taking care of the paths for that).

Happy to help. Let me know if you have any other questions.

 

An entity-component-system implementation that is engine agnostic. It includes Unity bindings.

forge is the entity system (features)
forge-unity are the Unity bindings

However, I'm focusing on Full Inspector at the moment and have shifted my game development strategy such that forge is no longer directly useful to me, but I'm happy to help with any bugs/issues.

 

Forge looks interesting. Wondering what development strategy you have shifted to. Have you found another approach for structuring games?

 

I wanted to do a more rapid fire approach, ie, game jams, where I really wanted to be able to use the built-in systems of Unity (which you cannot do with forge) such as physics.

 

Update 2.1 has been accepted and is now live in the asset store! Make sure to update! If you're using the trial, then you can just redownload for the latest version.

Thanks

 

Hey sient,

I just downloaded your product and I get this error:

Assets/FullInspector2/Serializers/JsonNet/Converters/ColorConverter.cs(1,7): error CS0246: The type or namespace name `Newtonsoft' could not be found. Are you missing a using directive or an assembly reference?

 

This is one attractive looking library you have there. Want!

I hate to be that guy. But is there a way to get all that goodness without deriving from BaseBehavior?

 

Hey kharder,

Have you extracted the documentation zip into the Assets folder? If so, please move it out of the assets folder -- Unity will mistakenly try to compile these files.

If not, can you verify that you have Assets/FullInspector2/Serializers/JsonNet/DLLs/Newtonsoft.Json.dll and would you also mind trying to import Full Inspector into an empty project?

Thanks

 

Unfortunately, Full Inspector needs some base type. However, because full source is provided, you can modify BaseBehavior so that it points to the type you need to derive from. There is a section in the guide here that explains how to do this.

Let me know if that works.

 

Thanks for the respond, sient. The problem was another asset from the AssetStore Sorry

 

Sure. Let me know if the conflict can be fixed on my end; if it isn't too disruptive, I'd be happy to incorporate the change into the next update so that others don't have to deal with the issue.

Thanks.

 

Thanks for the new update.

Testing out EasySave 2. Unzipped easysave2-experimental and getting this error:

Assets/FullInspector2/Serializers/easysave2-experimental/easysave2-experimental/EasySave2Serializer.cs(16,34): error CS0115: `FullInspector.EasySave2Serializer.Serialize(UnityEngine.Object)' is marked as an override but no suitable method found to override

Edit: The samples-assetstore is missing all monoBehaviour references. I tried using the zipped file you sent for the previous version but it's giving errors. Can you send an updated version.

 

Getting back to serializing part of the project I'm currently working on. Just downloaded the new update and giving a spin.

I'm trying to do the following to test the serializing/deserializing features of json.Net.

1. Play samples-jsonnet scene
2. click Simple Types, change some values that are serializable.
3. Window > FullInspector > SaveAll
4. change some values that were previous changed in step 2.
5. Window > FullInspector > Restore All

Nothing seems to happen. The values were not restored.

Is there documentation to show how to Save/Load data during a game play?

I also checked the examples games but honestly, I don't exactly know what is supposed to be happening in these game examples. I just don't get what each one is supposed to be demonstrating. Can you explain a bit what's going on. Perhaps a video would be ideal to explain how to use various features of FullInspector. In particular, How to save data during game play, quit the scene. Fire up the scene again and load in the saved data that was previously saved.

Cheers.

 

Sorry about that. The BaseSerializer API changed slightly; I'll update the EasySave2 serializer in the next release (if you need it now, I can send you a custom build).

Strange that the asset store sample is missing all references; it must not be uploading. I'll manually verify that it actually uploads on 2.2. But for now, here are the asset store samples for 2.2. View attachment $FullInspector21 AssetStore Samples.zip

 

SaveAll / RestoreAll ensure that every object in the scene has its most recent state serialized (this allows for some custom workflow handling -- in 99% of cases it isn't necessary to use these).

I have a new API coming in 2.2 that makes it easy to serialize and deserialize an object to disk that doesn't have any UnityEngine.Object references. If it does have UnityEngine.Object reference, then you'll have to serialize to a ScriptableObject (instead of just a plain .txt file or similar). There is a new sample that demonstrates how to do this, and I'm going to add a relevant section to the documentation.

The example games are pretty rudimentary and just demonstrate different ways that interfaces and the like can simplify a game's internal architecture.

Thanks

 

My main use case for Full Inspector is to:

1. Save Load game states
2. Save/Load procedurally generated GO during game play.
3. Save/Load game states to disk and/or server.
4. Save/Load procedurally generated GO to disk and/or server.

It would be so Awesome if you make the examples that covers these basic use cases.

I would love to have a preview copy of 2.2 when you are ready.

 

I've been doing some investigation with disk based serialization, and unfortunately, the results don't look too promising. Before I released Full Inspector, I spent quite a bit of time trying to figure out a clean way to serialize GameObjects and, in general, MonoBehaviour references. The only solution that I found that worked well was to just let Unity handle the serialization of UnityEngine.Object references, and then pull the serialization/deserialization data from that.

For disk based serialization, we still need Unity to handle UnityEngine.Object references, but I haven't found a way to do this. Perhaps you have another idea, but ScriptableObjects seemed like the proper solution here, however, changes made to them will not persist throughout gameplay. If I ever do end up implementing a full scene save system, it will likely be in a separate (likely free) asset that just depends on Full Inspector.

For 2.2, what I plan on doing is including a nice API for serialization of any type that does not contain UnityEngine.Object references to and from disk. Here's what it currently looks like, but I'll likely simplify the API.

Code (csharp):

1.  
2. using FullInspector;
3.  
4. public class MyBehavior : BaseBehavior {
5.   // The object we serialize to/from disk
6.   public struct SerializedStruct {
7.       public bool BoolValue;
8.       public int IntValue;
9.   }
10.  
11.   // Value editable in the Inspector
12.   public SerializedStruct Value;
13.  
14.   public void DeserializeFromPath(string path) {
15.     var serializer = new JsonNetSerializer();
16.     string content = File.ReadAllText(path);
17.  
18.     // Deserialize from the json state
19.     Value = (SerializedStruct)serializer.Deserialize(typeof(SerializedStruct), content, new NotSupportedSerializationOperator());
20.   }
21.  
22.   public void SerializeToPath(string path) {
23.     var serializer = new JsonNetSerializer();
24.  
25.     // Serialize the current state
26.     string content = serializer.Serialize(typeof(SerializedStruct), behavior.Value, new NotSupportedSerializationOperator());
27.    
28.     File.WriteAllText(path, content);
29.   }
30. }
31.  

Thanks.

 

"For disk based serialization, we still need Unity to handle UnityEngine.Object references, but I haven't found a way to do this. Perhaps you have another idea, but ScriptableObjects seemed like the proper solution here, however, changes made to them will not persist throughout gameplay. If I ever do end up implementing a full scene save system, it will likely be in a separate (likely free) asset that just depends on Full Inspector."


Unity Serializer open source project has managed to serialize the entire scene, only problem is it uses too much linq and is not working well on IOS. Perhaps if you check out his code it might give some ideas of how he's managed to do it. http://whydoidoit.com/

 

@sient: Thanks for your last response to me - I have another question please if you don't mind:

If I change a property value at edit time (int, string, etc) - the value persists when I enter playmode. I want to know when do these properties/values save? When do you tell your base behaviour to save itself? i.e. when does serialization happen? Is it just manual? (via SaveAll) - Do you do it from your editor? (via a change block) - can it be automated somehow? - I couldn't think of how one would automate it - Obviously, deserialization is suitably placed in Awake, I was thinking one could maybe serialize in OnDestroy? - it does make sense when Unity is reloading... but not when you actually destroy the object yourself :s - I wish unity would expose callbacks for (de)serialization.

Thanks.

 

Before I wrote the serialization code, I actually investigated this project. He requires that you add a special "identifier" component to the GameObject which I was never able to get working well. Additionally, I'm not sure that a completely automated approach to serialization is the way to go -- his code is quite simply, complex.

 

If you're just playing a regular game, then you don't need to serialize the behavior on destroy, as that data is going to be lost regardless, so the serialization will be unused.

If you're using the editor, the serialization is automated (assuming that you're only editing the object that you're inspecting, otherwise, you need to manually restore/save the edited object). As you inferred, this is done via a change block in the editor.

If you're saving during gameplay, and you're persisting objects and the like via something like Unity Serializer, then you can call FullInspectorSaveManager.SaveAll() to prepare every BaseBehavior to go through the Unity serialization process.

It would be fantastic to have proper serialization callbacks, but the current system works well and I expect it to be stable throughout updates.

Thanks. Let me know if you have any other questions.

 

That makes sense. But, how do you handle the values being changed from code? - not via the editor (let it be in edit-time or run-time) In other words, if I change a value via code, when does the behaviour save itself?

Thanks.

 

If you change a value in code that you are not inspecting with the inspector while in the editor, then you do have to save it yourself (or set FullInspectorSettings.ForceSaveAllAssetsOnRecompilation to true). However, this is pretty simple and is just a simple behavior.SaveState() call.

If you can think of a way to automate this, I would be happy to do so. ForceSaveAllAssetsOnRecompilation does automate it, albeit at a iteration performance cost that I don't believe is worthwhile in the default case.

Thanks

 

The reason I asked, was because no matter how hard I tried to squeeze my brain to think of a way that you could have not called SaveState manually, I couldn't - calling Save manually makes sense. But I thought you had some magic going on somewhere However, why not make the "ForceSaveOnRecompilation" thing happen on a per-behaviour basis? - in other words, each behaviour will have a ForceSaveOnRecompilation flag - that way I have a little bit more freedom - I could leave the behaviours that I don't need to modify via code with the flag unset, and set for the ones I maybe care about...

 

Ah, good idea. I'll look into it and possibly include a more refined recompilation save system in 2.3.

 

Also, if you don't mind - what tool you used to write your documentation? (your html docs)

 

I use sphinx with plugins sphinxcontrib.fulltoc and sphinxcontrib.inlinesyntaxhighlight.

 

The 2.2 update has been submitted to Unity for review. It should (hopefully) be available early next week.

2.2 includes support for easy serialization to files (for types without UnityEngine.Object references), adds the "Open Script" button that is shown by default on Unity inspectors, adds support for ICollection<T> types, and allows for custom ordering of properties in the inspector (via a new Order attribute). It also includes a number of important bug fixes.

Here is the more detailed changelog:

If you would like this update now, please feel free to send me an email. The trial now also points to v2.2.

 

Hi,

I got this asset yesterday and I like having proper inspector support.

On one of my behaviours I put a public dictionary called TestDict just to check out the dictionary support. I was pleased with how the inspector behaved but didnt need a dictionary on this particular script so deleted it from the script. Now every time the script is compiled i get the error:

Unable to find serialized property with name=TestDict on type PositionGuidedMissileController
UnityEngine.Debug:LogWarning(Object)
FullInspector.SerializationHelpers:RestoreState(ISerializedObject) (at Assets/FullInspector2/Core/SerializationHelpers.cs:209)
FullInspector.BaseBehavior`1:RestoreState() (at Assets/FullInspector2/Core/BaseBehavior.cs:51)
FullInspector.FullInspectorCommonSerializedObjectEditor:EnsureRestored(ISerializedObject) (at Assets/FullInspector2/Core/Editor/FullInspectorCommonSerializedObjectEditor.cs:86)
FullInspector.FullInspectorCommonSerializedObjectEditor:OnSceneGUI() (at Assets/FullInspector2/Core/Editor/FullInspectorCommonSerializedObjectEditor.cs:110)
UnityEditor.DockArea:OnGUI()

If this is going to happen every time I remove a previously serialised element from a script it is going to get annoying. Is there anything I can do to stop/prevent these errors?

Edit: It seems that after restarting Unity the warning has ceased so it may just be a temporary issue.

Cheers

EvilNoodle

 

So the warning is an attempt to prevent data loss and warn you about it (because you renamed or removed a variable or did some similar event). If this is an annoying behavior to a number of people, I can turn it off by default in 2.3 (likely behind a settings flag).

If you want to get rid of the warning permanently, then you can double click it and simply delete the Debug.LogWarning statement (but *keep* the continue statement right after it).

I'm assuming that you got the warning multiple times, but after each warning you did not interact with the inspector. If this is the case, then the serialized state was not getting updated, hence, the warning would persist. At some point in the Unity restart cycle the behavior got serialized. This behavior is correct.

Let me know if there is anything else I can do.

Thanks.

 

Update 2.2 is now live in the asset store.

I've also managed to include a new setting, FullInspectorSettings.EmitWarnings, which enables or disables if Full Inspector emits warnings (such as missing serialization data). It defaults to false.

For convenience, here is the changelog:

Please make sure to update! Let me know if you have any questions.

Thanks.

 

Can you explain how to test the write to disk example.

I see a bool and int.

What are we supposed to do in order to get it to save to disk?

 

Here's the relevant section of the guide. Let me know if you still have questions.

Thanks.

 

Thanks for the documentation link.

The thing that was not clear for me is the Context Menu.

There are a number of choices:

1. Serialize to Console
2. Save Current State
3. Restore Saved State
4. Serialize to Path
5. Deserialize from Path

I can see in the Disk Serialization Behavior code that the last 2 are being used for path serialization.

Perhaps I'm wrong but I did not see in the docs how the other choices work in this case.


Another thing that I'm not clear on is how this Serialize to Path differ from what EasySave2 is offering. Actually, EasySave2 can serialize many more kinds of objects to file. I'm also under the impression that JsonDotNet can also serialize meshes and binary so many types can be saved.

 

Another question:

Unity cannot serialize Dictionary or Struct in the editor or during run-time. Using Full Inspector, without the saving to path feature, will Unity be able to serialize a these structures during run-time ?

 

Choices 1, 4, and 5 are specific to Disk Serialization Behavior, whereas Full Inspector automatically adds choices 2 and 3. These are not in the docs because they don't apply in general; they are only there for the sample.

1: This serializes the current state and prints the result to the Unity console
4: This serializes the current state and saves it to the given file path
5: This deserializes the current state from the given file path

The serialize to path is designed to make it easy to use the same serialization customizations that Full Inspector includes, so that you don't have to go through all of the work of manually preparing, ie, Json.NET for serialization so that it can, ie, properly serialize Vector3.

 

I'm not entirely sure what you mean. If you're implying that you can make changes to the component in play mode and have them persist through edit mode, then unfortunately the answer is no, as Full Inspector is just using Unity's serialization mechanisms which do not support this behavior.

If you're looking to just serialize a general dictionary to a file, then yes, Full Inspector supports this during run-time.

 

"The serialize to path is designed to make it easy to use the same serialization customizations that Full Inspector includes, so that you don't have to go through all of the work of manually preparing, ie, Json.NET for serialization so that it can, ie, properly serialize Vector3."

Does this mean that anything that Json.NET can serialize then FI will be able to save to file?

 

Correct (excluding UnityEngine.Object types). Same with protobuf-net and BinaryFormatter.

 

1. "UnityEngine.Object types", can you give an example of some of these types?

2. For EasySave2, what would be the advantages in using Full Inspector, or rather, how should EasySave2 be used with Full Inspector.

 

Sure. MonoBehaviour, ScriptableObject, Mesh, LightProbes, etc.

You could do something like

Code (csharp):

1.  
2. string serializedState = SerializationHelpers.SerializeToContent<SerializedStruct, JsonNetSerializer>(Value);
3. ES2.Save(serializedState, "customKey");
4.  

and just use EasySave2's string serialization support.

Thanks.

 

I'm trying to serialize to file as much as possible and it looks like ES2 will be able to do this more than any of the other serializers due to Full Inspector's UnityEngine.object constraint.

ES2 can serialize textures, meshes and audio whereas FI cannot. For example, if I send a mesh, texture or audio to ES2 for serializing. Should I just use ES2 or can I through FI using the code above.

 

Nested-good-lord-prefabs. Is it possible with new serialization system? I know that JSON.Net allows you to populate properties easily and to handle serialization process on every level. So, I'm interested do you consider to implement that kind of feature?

 

You could go through Full Inspector, but it'll require a custom implementation of ISerializationOperator.

Let's say the ISerializationOperator is called ES2SerializationOperator. Then you could write functions

Code (csharp):

1.  
2. public static class SerializationHelpersES2 {
3.         public static T DeserializeFromContent<T, TSerializer>(string content)
4.             where TSerializer : BaseSerializer {
5.  
6.             var serializer = ObjectCache.GetInstance<TSerializer>();
7.             var oper = ObjectCache.GetInstance<ES2SerializationOperator>();
8.  
9.             return (T)serializer.Deserialize(typeof(T), content, oper);
10.         }
11.  
12.         public static string SerializeToContent<T, TSerializer>(T value)
13.             where TSerializer : BaseSerializer {
14.  
15.             var serializer = ObjectCache.GetInstance<TSerializer>();
16.             var oper = ObjectCache.GetInstance<ES2SerializationOperator>();
17.  
18.             return serializer.Serialize(typeof(T), value, oper);
19.         }
20. }
21.  

which are used in the same way as the SerializationHelpers methods. Then, your SerializeToContent and DeserializeFromContent functions can handle any UnityEngine.Object type that ES2 can handle.

However, what I would recommend for the SerializeToContent and DeserializeFromContent methods is to have a data format for saved-game serialization that is completely separate from your behavior serialization format. This save file format is then used to restore your game state, and it shouldn't need to reference any UnityEngine.Object types.

 

The serialization system works on a per-behavior level. Full Inspector doesn't touch anything beyond that (one major reason is for portability across Unity product cycle updates, so that your serialized data will still be completely valid when, ie, 4.4 comes out).

If you're just referring to prefabs that contain multiple nested game objects, then this works as expected.

However, if you're referring to prefabs which have child prefabs (modified externally), then Full Inspector does not support this as Unity itself does not. If a new asset comes out that supports nested prefabs, then I would imagine that Full Inspector would be pretty easily adaptable. If it isn't, then I'd be happy to create a few extension points that make it so. The prefab support code in Full Inspector is pretty minimal compared to the serialization and editor support.

Thanks. Let me know if you have any other questions.

 

Would you consider a request to expand the ES2 examples to demonstrate how to best utilize ES2 with Full Inspector.
ATM, ES2 examples are very minimal. ES2 has many users and like myself, these users might be interested in FI if they could better see the benefits via more examples.

Edit: Json.NET seems to support Mesh, Textures and Bson data. Is there a way to support these additional types also.


Cheers.

 

I don't use ES2 myself, so it's hard to write examples because I don't own the asset. However, I'm happy to answer any questions or offer implementation advice.

The way that I would use ES2 with Full Inspector is pretty simple. Continue using ES2 as you do now, and if you have a complex data type that you want to save then convert it to/from a string using Full Inspector. Then use ES2 to save/restore that string.

Please see the Mesh/Texture and the BSON issues for tracking.

Let me know if there is anything else I can do. Thanks.

 

This approach makes sense.

One thing that I am running into with this approach is a way to handle the situation where the Complex Data Type also contain objects that FI doesn't support. It quickly becomes quite a trick to keep all of this in mind when serializing. How to manage this kind of situation.