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

I guess this doesn't work for 5.3 yet as I imported into my project and even the inspector only samples will not even work. Unless I am missing something major in the way this package is to be installed. I should just need to import right? Or is there some other step?

 

Only thing I really need to do for 5.3 is to delete files related to BaseNetworkBehavior class.

 

From some times I have this warning:

Error while parsing: Bad Int64 format with 1E-06; context = <"LightPercent":1E-06,"LightShadowPercent":0.0,"Lig>
UnityEngine.Debug:LogWarning(Object)

Spoiler: Stack trace

Error while parsing: Bad Int64 format with 1E-06; context = <"LightPercent":1E-06,"LightShadowPercent":0.0,"Lig>
UnityEngine.Debug:LogWarning(Object)
FullInspector.FullSerializerSerializer:EmitFailWarning(fsResult) (at Assets/Plugins/FullInspector2/Core/FullSerializer/FullSerializerSerializer.cs:107)
FullInspector.FullSerializerSerializer: Deserialize(MemberInfo, String, ISerializationOperator) (at Assets/Plugins/FullInspector2/Core/FullSerializer/FullSerializerSerializer.cs:90)
FullInspector.Internal.fiISerializedObjectUtility:RestoreState(ISerializedObject) (at Assets/Plugins/FullInspector2/Core/fiISerializedObjectUtility.cs:218)
FullInspector.BaseBehavior`1:RestoreState() (at Assets/Plugins/FullInspector2/Core/BaseBehavior.cs:68)
FullInspector.BaseBehavior`1:OnValidate() (at Assets/Plugins/FullInspector2/Core/BaseBehavior.cs:50)

The strange thing is the LightPercent is defined as float, but FullInspector says that is an Int64.
The warning appears every time I hit play, even if the prefab that has this properties is not instantiated.

 

Hi, @sient

It almost the end of the year, but I haven't see the update or any response from you regarding people's inquiries here in the forum. I understands the RL issues might prevent you from regular update, but the lack of support and answering questions may hurt the confident in your product.

If I may suggest, you might need to think about a big update to keep your future compatibility with Unity. Unity 5.4.0b1 was released yesterday. While it is not needed to support a beta version, but if you have access to Beta, you could prepare your product to be compatible with both 5.3 and 5.4. So people can be assured that atleast your product will be usable for another 6 months.

 

This. I have been using the trial for a few months, and was ready to move on to the full product. I was unable to purchase for some billing reasons that don't need to be mentioned, but now I am kind of glad I didn't because for $65, I expect it to work with Unity updates within a reasonable time frame!

Did Unity make a change that severely breaks the architecture of this? Please let us know so we can set reasonable expectations. I understand that it is possible the update broke this at a fundamental level that will require a major overhaul, but we need to know so our expectations can be reasonably set.

 

Wasn't it always the expectation that over time this component would become obsolete by internal improvements to Unity's built-in Inspector?

 

That could be true only when Unity will support more types to be serialized, like Dictionaries, and will allow to instantiate in the inspector custom classes inheriting Interfaces, etc.
For now I need FullInspector and I really hope that it will be soon supported greatly as it was few months ago.

 

Amen, re Dictionaries, and better serialisation and serialisation to and from file in Unity as standard. . However, I suspect that Sient will return to support this excellent Asset in the New Year...

 

Even with the exposed JSON Serializer in Unity 5.3, the built-in serializer is still very limited.

 

Not severely broken at all. Except for BaseNetworkBehavior which must be deleted or commented out, the rest works fine.

 

Hello everyone, question. I have a class using a dictionary<Enum, Someobject(Not MonoBehavior)>. I can set both the enum and the Object through the inspector, the Object class actually shows up in a drop down. FullInspector doesn't seem to handle newing up those Objects, so they are always null. Is there a way that I could "iterate" through the dictionary and Instantiate what should be there according to the Inspector? Is there some FullInspector magic that I could use for this purpose? Thanks in advance!

 

I often use FI exactly in that way and I have no problems.
I'm not sure but do you have a constructor in your class with arguments? If so you will probably need to add a default constructor with arguments.
EDIT: sorry typo: "without arguments"

 

Interesting, my class does not have a constructor with arguments. But if the class constructor has arguments, where would those be assigned? Especially if the class is being assigned in the inspector.

 

NVM, I tried it again and it's working now. I didn't actually change anything. Think I didn't choose the correct enum before and it wasn't jelling with my assumptions in code. Sorry! Thanks for the help though. The class still doesn't have a constructor with parameters.

 

ping @sient

 

One possible thing that one time tricked me, was that I forgot to set the fields of the classes as public, and in the inspector I was selecting the type of the object I wanted to instantiate, and nothing happened.
The next morning I saw it. Late time work is not good!

 

A small bug (?):

If I have a private serialized field [SerializeField] which in this case is a collection (might be the only case), it is set to null instead of the statically initialized value when Awake() is called...

Code (CSharp):

1. class MyClass : BaseBehavior{
2.  
3.         ICollection<MyType> myObjects = new HashSet<MyType>();
4.  
5.         protected override void Awake(){
6.                 base.Awake();
7.  
8.                 var isNull = myObjects == null; // true
9.        }
10.  
11. }

When I remove the attribute, it works as expected.

This just kinda started happening, so my guess is that it wasn't always an issue... Tried to fully delete all metadata, but issue remained.

Thanks!

 

I think that you shouldn't instantiate the HashSet in the code. Should be done in the inspector.
Make sure that you have the object serialized. Often I have to use the small gear wheel icon on the component and then "Save current state" to don't loose the data I set. I use it before to apply or hit play. Try that to see if that resolves.

 

Hey guys, just wanted to post really quick in case anyone else is running into the same problem.

I was getting constant crashes when recompiling scripts in most of my complex scenes, though not every time -- often it would happen on the second or third time scripts were recompiled in unity. It made working on my project pretty much impossible, I was constantly losing work due to crashes every few minutes.

I've finally found that going to
Window->FullInspector->Developer->RemoveMetadata
whenever a scene is loaded fixes the problem. Something must be screwed up with the new(ish) metadata system. Maybe something in unity 5.3 or 5.2 broke it. Anyway, I was really suffering and about to rebuild my entire project from scratch to see if that would help, so I wanted to let others know.

I hope Sient is ok and will one day return to us!

 

@sient I understand you had a major life event, but you stated that we will see some update at the end of the year. This is near the end of the first month, and we still haven't heard anything more from you since that last post. This is not good for your products or anyone at all.

 

Unity 5.4 does not allow a few property/method to be called during Serialization such as Application.isPlaying, EditorApplication.isCompiling, EditorUtility.SetDirty.

 

@sanpats have you tried Full Inspector with the 5.4 beta? Sounds like it could get ugly. If so, does it break things more than 5.3?

 

5.4beta will emit error messages regarding the uses of properties/methods that I've mentioned above. I have not tested them thoroughly, some only effects performance but some might break something.

 

I've pretty much done with some infrastructure work that'll allow me to be far more efficient with the time I spent on Full Inspector.

You can now download releases at jacobdufault.github.io/fullinspector/access/. I've already uploaded a 2.6.3 build that can be downloaded right now. It should fix any 5.3 related issues.

Once I work through the reported issues (and the 5.4 beta issues - haven't had a chance to download it yet) I'll submit the final 2.6.3 to the asset store. I'll be spending some time each day working through the reported issues.

Sorry about the delays - I don't anticipate this happening again.

 

Thank you for the update. I am downloading 2.6.3 (01-26-2016 at 00:01). This is the correct one, right?

I am torn with the decision to stop using FI because I need solid support from any asset in order to use it in production. But FI is the best of its kind in the asset store. I am glad that it will be fully supported again.

 

I'm very happy to see you again.
Thank you for keeping alive this essential tool! I can't imagine how to work in Unity without it.

 

Hi guys,
do you know of a way to add a custom multi-field search filter based on enums to find easily a "record" inside a dictionary using Full Inspector?
In my very special case I have a dictionary that has a struct as Key, composed by 3 enums. There are more than 50 entries and to search the correct one is very time consuming.
Thanks for any hint you could give me.

 

Create enum fields to receive inputs. Make a method to search the dictionary using those inputs. Expose the method in inspector. You need another field to be a receptacle for the search result.

 

Thanks, so the "receiving" field that will expose the result will be a new dictionary that will contain references to the same instances of the main dictionary, so that I can still edit the values.
I'll give a try. It should work!
Thanks

 

Yes it works very well.
The only issue is that I can't find a way to hide the "+" icon of the result dictionary. Any data added there will be lost.

 

Yep, that build represents the current master. I've been going through the Full Serializer backlog and I'll get to the Full Inspector one soon.

, it's my pleasure.

 

Hi @sient -- welcome back, thanks for the update!

I went ahead and deleted my existing FullInspector2 and FullInspector2_Generated folders and imported the new version. Now I'm getting BaseBehavior and BaseScriptableObjects not found errors everywhere. Looks like because the non-generic wrappers of those classes doesn't existing anymore -- how do I get the new version to regenerate those?

Also -- before installing the new version, I noticed a problem where serialized fields were getting set correctly in the Unity Editor but were null in an Android build -- I guessed this was a FullInspector 5.3 problem (it's the first build I did after upgrading to 5.3). Does that sound like something that this new 2.6.3 FI release will fix?

 

Please see this section in the docs to restore your generated folder. When upgrading, you don't need to delete FullInspector2_Generated.

I'm not familiar with the android issue with 5.3. Is this consistently happening? I haven't had a chance to address any FI issues yet besides fixing 5.3 multi-scene editing warnings and the BaseNetworkBehavior issue. I've currently still going through the Full Serializer backlog.

 

Thanks for the quick reply. Unfortunately the link you gave leads to a blank page. UPDATE: It's working now!

Once I get FI working again, I'll investigate the apparent serialization issue further -- but yes it was happening consistently before I tried to upgrade.

 

Looks like the problem with the Android build is I didn't call base.Awake() when overriding Awake() in a BaseBehaviour subclass that had a serialized interface field. Never had a problem with in the past, but seems to be necessary with the current version of Unity and FI. Does this sound right?

 

FI has always required to call base.Awake() when derive from BaseBehavior and using Awake() within it.

 

It depends. If you're using Full Serializer, the Awake() call shouldn't be necessary. For any other serializer it is required.

 

Hmm, indeed I was never calling base.Awake() before and no problems with Unity 5.1. But with Unity 5.3, I need to call it, otherwise my interface member is not getting set.

 

Hi, you should update the FI Guide on the website about that (not really critical though). I think most people use FS now, so many might not know that base.Awake() call isn't necessary.

 

Unity 5.3 and FI 2.6.3beta works perfectly fine so far. Tested with Unity 5.4.0b4, there are multiple warnings and errors.

All warnings are about the same issue in various scripts, `UnityEditor.EditorGUI.BeginDisabledGroup(bool)' is obsolete: `Use DisabledScope instead' and `UnityEditor.EditorGUI.EndDisabledGroup()' is obsolete: `Use DisabledScope instead'.

All errors are about calling certain properties and methods during Serialization such as 'get_isCompiling is not allowed to be called during serialization, call it from Awake or Start instead.'

 

Ok. I haven't had a chance to start working on 5.4 support yet. I'm going to go through a few more FS issues tomorrow, hopefully those will be completed by Tuesday. I did some refactoring work for the docs page at the end of last week.

Right now, I expect to start address FI issues Wednesday or so, though that might get delayed if FS issues take longer. I'll tackle the 5.4 issues when I'm done with FS issues.

 

There is no rush, for me at least. I still develop using 5.3 as I don't use a beta in production. I just testing 5.4 beta and help reporting issues, so everything can be ready before 5.4 come out of beta.

 

Performance issue in editor (playmode) v2.6.2:

Spoiler: Wall of text

Unity, as we all know, have a very questionable approch to serialization. So for this issue, whenever a gameobject is selected and thus rendered in the inspector, they read values and spam the "OnBeforeSerialize"-callback (even though no changes have been made and there really is no need to "serialize"). Not sure if they ACTUALLY serialize or just invoke that callback for the luls.

The issue:
This will invoke the serialization-process of fullinspector and in the end call fiISerializedObjectUtility.SaveState which in turn does a few heavy operations (InspectedType().GetProperties()). Every frame. This cuts the framerate by more than 2/3.

Question:
Now I haven't looked through it enough so this might be a dumb question, but is this method necessary to run while in play-mode? Is anything even serialized while actually playing?
Without going through the code, I just added the following check in the beginning of the method as a test, thus skipping if in editor and currently is playing, which as expected boosted the framerate back up to the 60-cap. Preferably there could be some higher-level check when unity says "we serialized" where you check the differences and skip if nothing changed (I think you do something like this in fiSerializationManager.DoSerialize, but still execute obj.SaveState in the very end).

Edit:
Okey, I think I might have found something... You have a flag called:

Code (CSharp):

1. fiLateBindings.EditorApplication.isCompilingOrChangingToPlayMode

This in turn calls the following:

Code (CSharp):

1. fiLateBindings._Bindings._EditorApplication_isCompilingOrChangingToPlayMode = () => EditorApplication.isCompiling || EditorApplication.isPlayingOrWillChangePlaymode;

If this is supposed to return as the name suggest, shouldn't the latter "isPlayingOrWillChangePlaymode" be paired with "&& EditorApplication.isPlaying == false" ?

As of know, isCompilingOrChangingToPlayMode returns true when playing in editor thus not skipping the serialization.

Bonus question:
Is there any one specific line where I can breakpoint to know whenever an object did change and has to be serialized (i.e. became "dirty")? Would be good to make sure a class is not inceptionized and keeps looking "dirty" even when nothing changed...

Thanks!

Edit 2:
Just noticed this still is the same. Could you have a look at it @sient?

Thanks!

 

I need serialization while in play mode when I change some settings inside some ScriptableObjects. Of course would be better to do it only when something changes, because now I have to unselect every time the ScriptableObject after the changes to avoid a drop in the frame rate.

 

Thanks for the comprehensive notes. I'm going to take a deeper look at this shortly. For the next couple of days, I'm working on getting some better testing infrastructure for Full Inspector setup. The test tools Unity exports don't seem to handle editor testing. I expect to spend a decent amount of time on FI this weekend, and should be able to make a decision on this change at that point.

I've uploaded a new version of FI to the access page. It mainly includes Full Serializer updates.

 

Just want to note that the issue @Maisey stated above involving isCompiling and such, which is disallowed to use while serializing in Unity 5.4. You may need take that into account as well.

 

@sient Just letting you know that chrome (and I assume others) blocks access to your app on azurewebsites when using https to access the github page (like the link you provided). Changing the client side request to use https will fix it.

 

@sient Sent you a mail some days ago regarding SharedInstances, got no answer. Has it arrived?
And is it possible for you to fix the cycle thing please? It would be very convenient if I could copy list items and then edit them. When it is showing cycle, I am not able to do that anymore. Tried EasyEditor and this is working there without problems. But I like your features, so I think I don't want to give up on your asset.

 

Thanks, taking a look now.

Sorry about that. I'm still working through the backlog. I've replied to your email.

 

Should be fixed now. Thanks for letting me know!