[Open Source] VFW (135): Drawers. Save System and full exposure

Wait what's 'parameters'? - if you have access to the parameters, you could just return the names immediately: parameters.Select(x => x.name).ToArray(); or get the length/count and create a string[] like in the above code. The only way I found to access the parameters was via that GetParameter(int index) - which is why I had to create an array and assign the names. Found it really weird, and inconvenient that there is no parameters array...

 

Haha, yeah I was on minimalistic auto pilot there I'll post the updated functions in a sec Thank god unity accepts conditional compilations...

 

So In AnimVarAttributeDrawer FetchVariables works now :

Code (CSharp):

1.         private void FetchVariables()
2.         {
3.  
4. #if UNITY_5
5.             variables = Animator.parameters.Select(x => x.name).ToArray();
6. #else
7.             variables = EditorHelper.GetAnimatorVariableNames(Animator);
8. #endif
9.             if (variables.IsEmpty())
10.                 variables = new[] { "N/A" };
11.             else
12.             {
13.                 if (!attribute.AutoMatch.IsNullOrEmpty())
14.                 {
15.                     string match = niceName.Remove(niceName.IndexOf(attribute.AutoMatch));
16.                     match = Regex.Replace(match, @"\s+", "");
17.                     if (variables.ContainsValue(match))
18.                         memberValue = match;
19.                 }
20.                 current = variables.IndexOfZeroIfNotFound(memberValue);
21.             }
22.         }

In GUIHelper HelpBox :

Code (CSharp):

1.         public static GUIStyle HelpBox
2.         {
3.             get
4.             {
5. #if UNITY_5
6.                 return EditorStyles.helpBox ;
7. # endif
8.                 return RTHelper.LazyValue(() => helpBox, value => helpBox = value, () =>
9.                     typeof(EditorStyles)
10.                         .GetProperty("helpBox", BF.Static | BF.NonPublic)
11.                         .GetValue(null, null) as GUIStyle
12.                 );
13.  
14.             }
15.         }

All in all Unity has done some good work simplifying Editor stuff.

GUIStyles still don't really work in the inspector but I think I'll tackle that tomorrow. It's probably complicated and all that keeps me up at the moment are buckets of coffee
Btw. do you want constructive criticism/ code review? I understand if you don't, it's WIP afterall.

 

I think you might want to change that to:

Code (csharp):

1.  
2. #if UNITY_5
3.             variables = Animator.parameters.Select(x => x.name).ToArray();
4. #else
5.             variables = EditorHelper.GetAnimatorVariableNames(Animator);
6. #endif
7.  

What do you mean with "GUIStyles still don't really work in the inspector"?

And sure, hit me with it if you think it's beneficial

 

Well, expanding a GUIStyle in the inspector shows only the message : "Object doesn't have any visible members". It does however have a couple of public properties like
public GUIStyleState normal { get; set; }
that I was under the impression your plugin would handle. But I'm not even through your tutorials yet so it's probably just me .

I really like your code. It's very clean and structured, you guide new users by using proper access modifiers, something I personally ignore all too often. However, from what I have seen so far there are not enough comments. If your aim is to make this a standard package every Unity user can use and extend upon, then some method and or class descriptions may perhaps help new users navigate and understand it more easily.
Another thing is naming conventions.

{AnimVarAttributeDrawer}

Code (CSharp):

1.         private Animator animator;
2.         private Animator Animator
3.         {...}

That one got me confused big times . Renaming animator to either _animator or m_animator would be much cleaner and consistent with how most people do it here. For me personally _ or m_ is an indication not to set that particular field directly while "animator" looks all too public. Then you could also rename Animator to animator to avoid the overlap with the typename. As it is right now I was running in circles trying to find static methods that don't exist

I haven't looked much into your code yet so that's all I've noticed so far. I'll post again if I find more. Being a natural microoptimizer (my excuse for bad practices) I probably won't notice everything, but each time I analyze some one else's code I also introspect on how I would and should write my own code, so if you disagree with anything I said, please don't hesitate to tell me so I can become a better programmer myself

 

The properties in GUIStyle are not auto-properties. So they won't come out visible going through my serialization logic. I determine whether or not something is visible if 1- it was serializable 2- annotated with [Show]. Properties with side effects are not serialized (with obvious reasons. for ex you might have a property that accesses that Unity API, and that's not allowed to run in the serialization thread, only the main so when you set/get the property value, you'll have problems) - To add support to GUIStyles (didn't think people still use them now that there's the new UI...) you have to write a custom drawer for it, a ObjectDrawer<GUIStyle> - or, if you could somehow inject the [Show] attribute on the properties and use the patched dll, that would work too

Problem with comments is that they're not compiled, which means if they had a mistake it will go by. If something's not documented that means I'm not sure if it will stay that way or change in the near future. If it does change and I forget to update the comment (which could easily happen), I will have unsynced comments, and that will do nothing than confuse people if I forget to update them. To me, having uncommented code is better than having code with wrong/unsynced or confusing commenting, because at least you could still reason about it and figure it out on your own without confusion. I try to write self-documented code as best as I can. I tend to think of the examples and all the attributes in the fw are a form of documentation, since you could just look at them and (hopefully) easily figure out how to write your own drawers etc. Better documentation will come eventually, doxygen or something, Idk. [Edit] another reason I'm not so stressed out about comments, is the user-base. I'm close to a 100 active users (maybe less? more?...) the bigger, the more important documenting becomes.

Why would that naming confuse you? - Naming convention has always been a thing for me I couldn't settle on. I sometimes follow different conventions in different areas of the code (editor vs runtime) which might not be good but I like to experiment with different styles and hopefully land on something consistent. Keep in mind the code for this has been under development for almost a year now... so you could imagine a lot of changes could happen. Different codes are written in different time frames, through time you learn new techniques, adopt different mindsets etc. All of that will in turn affect the way you do, think about and write things. Once you learn a new/better way to do things, you can't just go and change your previous codes to adapt to this new way, cause it might not be even doable, or could even break things. That particular example you pointed out, I wouldn't say there's anything serious about it, but if I were to write it now, I would go with _animator for the field, and animator for the property (you will see this pattern a lot in different areas where lazy programming is used). - I'm currently settling on _fieldName for private fields, propertyName for private properties, and FieldName/PropertyName for public fields/properties. So if you see a different naming style, you know that it was written in a different time. - But again naming conventions eventually go back to personal preference, I once looked at a code in CodeProject, I literally couldn't stand reading it - I guess confidence play a role in being consistent. You might watch a Jon Blow compiler programming video and decide screw pascal-cased C# style highlevel writing, I want to go snake-cased hardcore C-style sys architect lowlevel codes babeh!

I don't know for how long you've been a user for this framework, but it's shaping up. Over time I'm simplifying things, deleting files, getting rid of redundancies and reducing dependencies. That way I can focus on what's essential. That would help in figuring out what parts needs documenting the most. If there's a particular part that's not clear to you, please let me know.

Hope some of that made sense

 

Does this require the Pro version of Unity in order to run?

Asking, because the BSO object in the ExampleAssets folder isn't rendering any drawers and they delete themselves when I try to expand them.

I am probably missing some fundamental setup step here.

 

Nop, it doesn't.

There's no such steps. If the BSO example isn't working, there's something outright wrong. What version of Unity and VFW are you using?

I can't seem to trigger that behaviour here. Can you elaborate when and how that happens? - so you just expand the properties group and you don't see anything? drawers 'delete themselves'? ...

 

v1.2.9 installed, everything work perfectly so far.
I only have to find out that BetterEditor has been replaced by BetterBehaviourEditor, and I think it the same for other classes.

Why don't you use the obsolete attribute?

 

That's not the case. BetterBehaviourEditor was always there. But there was a redundant layer of abstraction. There was a BaseEditor and BetterEditor. There was no need for those two. Only one would work. I could have called BaseEditor BetterEditor but I wanted to be consistent with my other stuff (BaseDrawer, BaseGUI etc)

 

Ok, no issue and I should have looked into the code before implementing
Thanks again for the good work.

 

Guys, if anybody's having random trouble with data persistency and you're using 4.6.2, there seems to be a bug in Unity's serialization http://forum.unity3d.com/threads/4-6-2-newtonsoft-deserialization-problem.295474/

I've been told by a user that he had issues where some of his data (List<List<Class>>) isn't getting serialized. Downgrading to 4.6.1 and the problem seems no longer there.

 

Vex(e),

I am using 4.6.1f1, I imported the .unitypackage linked in the first post into a Unity 2d project I have running currently. After doing so, when I open an example project, the example objects don't render their properties. Would it be better if I got on Skype and showed you?

"alexanderyoshi"

 

Yep, I'm still using the legacy GUI. I'm working on a learning platform that will enable anyone to just download Unity and my package and create awesome quizzes/tests. You will create them in 2D at first, but once I finish the most important bits and pieces I will work on generic 3D RPG level generation that incorporates these different tests into a real game.
To make it accessible for everyone setup needs to be minimalistic : Just add a type of question, add answer(s) in the inspector, then share it with the world. Legacy GUI minimizes the scenegraph to just the gameObjects with Questions on them, while the new GUI would add all kinds of buttons, labels, checkboxes and whatnot to the scene which would have to be cleaned up and pooled on play resulting in bloated scenes.
This is also why your plugin looks so interesting to me. Having more control over the inspector can only help newbies who've never used Unity before get right in and create their own quizzes/tests.

So much to do and so little time I'm having a couple of isssues atm :

Is there a version of [Paragraph] or some other Attribute that works like [TextArea(min,max)] ?
MinimalisticView adds an inlined "Source" GameObject at the end of the inspector GUI. Is that intended? Can it be turned off?
Is it possible to hide the "Script" category part in the inspector?

Other notes :
For what it's worth, Unity 5 doesn't require transform caching anymore. I read that on the Unity blog some time ago but I can't find the reference. But it can't hurt much to cache it twice so there's no need to change anything specific for v5 users I suppose ^^

 

Just checking this out, and I noticed a bug in BetterBehaviour.cs:

Code (csharp):

1.  
2. public Vector3 back
3.         {
4.             get { return -up; }
5.             set { up = -value; }
6.         }

That's "down", not "back". This one should be renamed "down" and a new one should be made for "back" that is -forward.

 

Also, I'm using Unity5 (though I don't think it's causing any particular problems) and lots of the objects in the sample scenes throw errors and have broken inspectors when I click on them. For example in the "Attributes" scene, all of these are broken: Constraints, Sequences, Path, Draggable, AnimatorVariable, Readonly, and SceneTransition. I believe they're all throwing this error:


NullReferenceException: Object reference not set to an instance of an object
Vexe.Editor.Helpers.GUIHelper.<get_HelpBox>m__AE () (at Assets/Plugins/Editor/Vexe/Others/GUIHelper.cs:325)
Vexe.Runtime.Helpers.RTHelper.LazyValue[GUIStyle] (System.Func`1 getCurrent, Vexe.Runtime.Helpers.Predicate isNull, System.Action`1 setValue, System.Func`1 getInstance)
Vexe.Runtime.Helpers.RTHelper.LazyValue[GUIStyle] (System.Func`1 getCurrent, System.Action`1 setValue, System.Func`1 getInstance)
Vexe.Editor.Helpers.GUIHelper.get_HelpBox () (at Assets/Plugins/Editor/Vexe/Others/GUIHelper.cs:322)


I think it's related to the [Comment] attribute?

 

Did you use the updated methods here :

In AnimVarAttributeDrawer :

?

I'm using b20 and it works.

 

Ah, making those changes did fix it. Thanks. Next time I should read the whole thread...

 

One more nitpick, which is more a personal preference but might be important if you do want this to be accepted as a shared standard in other plugins: I don't like the idea of adding all the Transform properties to BetterBehaviour, and I especially don't like the idea of re-implementing things that Unity deprecated like "active". They got rid of that and separated it into "activeSelf" and "activeInHierarchy" for a reason, to make people understand there's a difference, not to just force us to type a few more letters out of spite.

I think BetterBehaviour should just contain whatever is necessary to make the inspector features function correctly, and not include a lot of redundant wrappers for things, because if a developer uses those wrappers makes it very hard to switch between MonoBehaviour and BetterBehaviour, and it hides changes to Transform that Unity might make in the future. It also clutters up Intellisense with a bunch of properties that are only relevant if you're messing with the transform, and if I wanted to do that, I would type "transform". The Transform class should contain all things related to the Transform, while the Behaviour class should only contain things related to being a Behaviour. If someone wants to create a subclass of either MonoBehaviour or BetterBehaviour that wraps all the properties of Transform, they can do that themselves pretty easily; it should at best be an option, and not part of the base package.

 

@Xelnath maybe you can shoot me a screencapture? (OBS is pretty good)

@makeshiftwings Thanks for your input and spotting that mistake. I'll try to release a patch tomorrow addressing it and some Unity 5 things like the helpBox and AnimVar errors mentioned above. And you're right. Thinking about it, there could be like a CachedBehaviour or something that have those wrappers. Thing is, those were added a long time ago, before I even thought of sharing this. I wanted quick and easy access to some of the things I use the most. So I added them (same thing for 'active') Never thought about removing them because there were always things of higher importance I wanted to address first, such as struct inspection and multi editing. But I'm with you on that. Addressed in next version. I'll make them obsolete and remove them after a couple of versions.

@kiriri About TextArea, currently no. But it should be simple to implement. I'll see if I can add it to the next release. As for the 'inlined source' I've never heard of that. Could you attach a picture? For the header, you could currently do that only from editor code (ShowHeader boolean in BaseEditor) but not in a configurable way from your behaviour. Will see what I can do about it.

 

Another weird thing: In the example scene, all the fields of the different BetterBehaviors are shown in alphabetical order rather than the order they're actually defined in the class. This doesn't seem to happen with my own new classes, only the ones in the sample project.

 

I've mentioned that before. Since I support exposing fields, properties and methods. Having members show up in the order they're declared in is very tricky https://groups.google.com/forum/#!topic/mono-cecil/ZElCqo0mU0Y (if you know of a simpler way than what was suggested, please let me know) - Members are sorted like this: FieldsThenPropertiesThenMethods, thenby data type name (so bools come before ints), thenby member name (so a comes before b) - You could use [DisplayOrder(#)] to explicitly define the member order. (Added to faq )

 

Ah ok. To me, the best compromise would be to do FieldsThenPropertiesThenMethods and that's it, otherwise leave the order as the Reflection calls give it, which is usually the same order they're declared. I usually organize my code something like that anyway. But I see now where that happens so I can change it myself.

 

Actually, I noticed for me it was doing Properties, then Fields. I think it's because the float precision is too low that it fails to actually see the difference between float.MaxValue - 1 and float.MaxValue - 2 in the "GetVisibleMembers" section. I changed it to just use 1000f, 2000f, and 3000f and then it ordered them correctly. I think maybe that part should do OrderBy(DisplayOrderAttribute).ThenBy(FieldsThenPropsThenMethods).ThenBy(etc....) so you could just use non-close-to-max numbers for the FieldsThenProps part.

 

For some reason I didn't think that doing just FieldsThenPropertiesThenMethods would keep properties sorted by their order of declaration. But it seems it does. Thanks for pointing that out. Definitely much better.



(not that anyone would organize code like that, but just to show that the actual physical location of the field/property doesn't matter, what matters is the declaration order. For ex you declared f1, p1, f2, m1, p2 you get f1, f2, p1, p2, m1 in the inspector)

 

This is what happens as I click on each header in BSO.



... I just realized you meant a video clip. Apologies. Will make it tonight when I get home.

 

@Xelnath there's an error at the bottom in the console. Could you give me the full stack trace?

 

Code (csharp):

1.  
2. NullReferenceException: Object reference not set to an instance of an object
3. Vexe.Editor.Drawers.MethodDrawer.Header () (at Assets/Plugins/Editor/Vexe/Drawers/API/Core/MethodDrawer.cs:107)
4. Vexe.Editor.Drawers.MethodDrawer.OnGUI () (at Assets/Plugins/Editor/Vexe/Drawers/API/Core/MethodDrawer.cs:83)
5. Vexe.Editor.GUIs.BaseGUI.Member (System.Reflection.MemberInfo info, System.Object rawTarget, UnityEngine.Object unityTarget, System.String key, Boolean ignoreComposition) (at Assets/Plugins/Editor/Vexe/GUIs/BaseGUI/Controls/Members.cs:25)
6. Vexe.Editor.Internal.MembersCategory.Draw (UnityEngine.Object target) (at Assets/Plugins/Editor/Vexe/Editors/Internal/MembersCategory.cs:161)
7. Vexe.Editor.Editors.BaseEditor.OnGUI () (at Assets/Plugins/Editor/Vexe/Editors/BaseEditor.cs:357)
8. Vexe.Editor.GUIs.RabbitGUI.OnGUI (System.Action guiCode, Vector2 padding) (at Assets/Plugins/Editor/Vexe/GUIs/RabbitGUI/RabbitGUI.cs:125)
9. Vexe.Editor.Editors.BaseEditor.OnInspectorGUI () (at Assets/Plugins/Editor/Vexe/Editors/BaseEditor.cs:120)
10. UnityEditor.InspectorWindow.DrawEditor (UnityEditor.Editor editor, Int32 editorIndex, Boolean forceDirty, System.Boolean& showImportedObjectBarNext, UnityEngine.Rect& importedObjectBarRect, Boolean eyeDropperDirty) (at C:/BuildAgent/work/d63dfc6385190b60/Editor/Mono/Inspector/InspectorWindow.cs:1093)
11. UnityEditor.DockArea:OnGUI()
12.  
13. -----
14. VerificationException: Error verifying Fasterflect.Caching.Cache`2:Insert (TKey,TValue,Fasterflect.Caching.CacheStrategy): Could not merge stack at depth 0, types not compatible: TValue ([boxed] Complex) X System.WeakReference (Complex) at 0x0018
15. Fasterflect.Emitter.BaseEmitter.GetDelegate () (at c:/Users/vexe/Desktop/MyExtensionsAndHelpers/Solution/Fasterflect/Emitter/BaseEmitter.cs:53)
16. Fasterflect.MethodInfoExtensions.DelegateForCallMethod (System.Reflection.MethodInfo methodInfo) (at c:/Users/vexe/Desktop/MyExtensionsAndHelpers/Solution/Fasterflect/Extensions/Core/MethodInfoExtensions.cs:62)
17. Vexe.Editor.Drawers.MethodDrawer.Initialize (System.Reflection.MethodInfo method, System.Object rawTarget, UnityEngine.Object unityTarget, System.String id, Vexe.Editor.GUIs.BaseGUI gui) (at Assets/Plugins/Editor/Vexe/Drawers/API/Core/MethodDrawer.cs:46)
18. Vexe.Editor.GUIs.BaseGUI.Member (System.Reflection.MemberInfo info, System.Object rawTarget, UnityEngine.Object unityTarget, System.String key, Boolean ignoreComposition) (at Assets/Plugins/Editor/Vexe/GUIs/BaseGUI/Controls/Members.cs:24)
19. Vexe.Editor.Internal.MembersCategory.Draw (UnityEngine.Object target) (at Assets/Plugins/Editor/Vexe/Editors/Internal/MembersCategory.cs:161)
20. Vexe.Editor.Editors.BaseEditor.OnGUI () (at Assets/Plugins/Editor/Vexe/Editors/BaseEditor.cs:357)
21. Vexe.Editor.GUIs.RabbitGUI.OnGUI (System.Action guiCode, Vector2 padding) (at Assets/Plugins/Editor/Vexe/GUIs/RabbitGUI/RabbitGUI.cs:125)
22. Vexe.Editor.Editors.BaseEditor.OnInspectorGUI () (at Assets/Plugins/Editor/Vexe/Editors/BaseEditor.cs:120)
23. UnityEditor.InspectorWindow.DrawEditor (UnityEditor.Editor editor, Int32 editorIndex, Boolean forceDirty, System.Boolean& showImportedObjectBarNext, UnityEngine.Rect& importedObjectBarRect, Boolean eyeDropperDirty) (at C:/BuildAgent/work/d63dfc6385190b60/Editor/Mono/Inspector/InspectorWindow.cs:1093)
24. UnityEditor.DockArea:OnGUI()
25.  
26. -----
27.  
28. VerificationException: Error verifying Fasterflect.Caching.Cache`2:Insert (TKey,TValue,Fasterflect.Caching.CacheStrategy): Could not merge stack at depth 0, types not compatible: TValue ([boxed] Complex) X System.WeakReference (Complex) at 0x0018
29. Fasterflect.Emitter.BaseEmitter.GetDelegate () (at c:/Users/vexe/Desktop/MyExtensionsAndHelpers/Solution/Fasterflect/Emitter/BaseEmitter.cs:53)
30. Fasterflect.ConstructorExtensions.DelegateForCreateInstance (System.Type type, Flags bindingFlags, System.Type[] parameterTypes) (at c:/Users/vexe/Desktop/MyExtensionsAndHelpers/Solution/Fasterflect/Extensions/Core/ConstructorExtensions.cs:103)
31. Fasterflect.ConstructorExtensions.DelegateForCreateInstance (System.Type type, System.Type[] parameterTypes) (at c:/Users/vexe/Desktop/MyExtensionsAndHelpers/Solution/Fasterflect/Extensions/Core/ConstructorExtensions.cs:92)
32. Fasterflect.TypeExtensions.Instance[BaseDrawer] (System.Type type, System.Object[] args) (at c:/Users/vexe/Desktop/MyExtensionsAndHelpers/Solution/Fasterflect/Extensions/Core/TypeExtensions.cs:45)
33. Vexe.Editor.Drawers.BaseDrawer.Create (System.Type drawerType) (at Assets/Plugins/Editor/Vexe/Drawers/API/Base/BaseDrawer.cs:83)
34. Vexe.Editor.MemberDrawersHandler.GetDrawerForType (System.Type objectType, System.Type[] typeCache, System.Type baseDrawerType) (at Assets/Plugins/Editor/Vexe/Drawers/API/MemberDrawersHandler.cs:205)
35. Vexe.Editor.MemberDrawersHandler.GetObjectDrawer (System.Type objectType) (at Assets/Plugins/Editor/Vexe/Drawers/API/MemberDrawersHandler.cs:141)
36. Vexe.Editor.MemberDrawersHandler.GetMemberDrawer (Vexe.Editor.EditorMember member, System.Attribute[] attributes, Vexe.Editor.GUIs.BaseGUI gui) (at Assets/Plugins/Editor/Vexe/Drawers/API/MemberDrawersHandler.cs:102)
37. Vexe.Editor.GUIs.BaseGUI.Member (Vexe.Editor.EditorMember member, System.Attribute[] attributes, Boolean ignoreComposition) (at Assets/Plugins/Editor/Vexe/GUIs/BaseGUI/Controls/Members.cs:50)
38. Vexe.Editor.GUIs.BaseGUI.Member (Vexe.Editor.EditorMember member, Boolean ignoreComposition) (at Assets/Plugins/Editor/Vexe/GUIs/BaseGUI/Controls/Members.cs:44)
39. Vexe.Editor.GUIs.BaseGUI.Member (System.Reflection.MemberInfo info, System.Object rawTarget, UnityEngine.Object unityTarget, System.String key, Boolean ignoreComposition) (at Assets/Plugins/Editor/Vexe/GUIs/BaseGUI/Controls/Members.cs:33)
40. Vexe.Editor.Internal.MembersCategory.Draw (UnityEngine.Object target) (at Assets/Plugins/Editor/Vexe/Editors/Internal/MembersCategory.cs:161)
41. Vexe.Editor.Editors.BaseEditor.OnGUI () (at Assets/Plugins/Editor/Vexe/Editors/BaseEditor.cs:357)
42. Vexe.Editor.GUIs.RabbitGUI.OnGUI (System.Action guiCode, Vector2 padding) (at Assets/Plugins/Editor/Vexe/GUIs/RabbitGUI/RabbitGUI.cs:125)
43. Vexe.Editor.Editors.BaseEditor.OnInspectorGUI () (at Assets/Plugins/Editor/Vexe/Editors/BaseEditor.cs:120)
44. UnityEditor.InspectorWindow.DrawEditor (UnityEditor.Editor editor, Int32 editorIndex, Boolean forceDirty, System.Boolean& showImportedObjectBarNext, UnityEngine.Rect& importedObjectBarRect, Boolean eyeDropperDirty) (at C:/BuildAgent/work/d63dfc6385190b60/Editor/Mono/Inspector/InspectorWindow.cs:1093)
45. UnityEditor.DockArea:OnGUI()
46.  
47.  

 

Well, the first error is the result of the previous ones which I've never seen, and I believe you're the first to ever come across! - Fasterflect will hopefully be removed in the next couple of versions if I could write a simple fast reflection alternative my own.

Questions: Did you make any modifications to anything? or this just happens right out of the box? - Does this only happen in BSOExample?

And, could you wrap the errors in code tags? ['Code'] errors [/'Code'] (no single quotes)

 

I did nothing besides import the project and its example files into my Unity2d project.

However, I did import them into a project with objects I had already created for the little experiment I'm doing. It is worth noting, that when I opened a brand new unity 3d project and imported your VFW files, there were no errors.

It also happens in all of the scenes that I opened within that project.

 

And what happens now if you move the files you had in first project to the new one?

 

Seems to work in a brand new Unity3d project with copy and paste of the assets folder.

Trying again with a brand new Unity2d project.

[Edit]: Also works there.

Not sure what's in my existing project that causes these issues.

Found it! Switching the Build settings to "Web Player" instantly causes the issue to reappear.

 

Hey vexe!

So I wanted to test out this set on aUnity 4.3.X PS Vita Project. Made a clean one and imported the package and got this error:

I also wanted to know if I can achieve the following with this package:

So I have a class like this (or similar)

Code (CSharp):

1. public class Quest
2. {
3.     public string questName;
4. }
5.  

And a MonoBehaviour where I have a List of this class and add to it like this:

Code (CSharp):

1. public class QuestGiver : MonoBehaviour
2. {
3.     public List<Quest> quests = new List<Quest>();
4.  
5.     // Use this for initialization
6.     void Start()
7.     {
8.         quests.Add(new Quest { questName = "Save the World" });
9.         quests.Add(new Quest { questName = "Plant a Tree" });
10.     }
11.  
12. }

Without the package I can't see the List in the Inspector. What I would like to have is not only the possibility to see the List but also to see the fields/properties of each element in the list.

Like this:

Is this possible?

 

ISerializationCallbackReceiver was introduced back in 4.5 . Is updating no option for you?
Lists do work in the editor but adding/removing elements in the inspector will not create new Quest objects for you. So you will have to handle that manually eg in the update loop with a null check for each element in your quests list. Or you might just want to use Quest structs here if performance is not all that much of an issue.

 

We develop for the PS Vita and there we have to stick with Unity 4.3, I'm afraid, so updating is no option at all, I'm afraid :/

 

Hey there @BTStone. Yep, unfortunately that serialization callback is key to my serialization :| - Is there something specific to 4.3 that your platform requires?

Just released a patch covering those Unity 5 errors. Also fixed the script header so changing it now will change the script! - And, BasicView with no splitters is now the default view. If you want categories annotate with FullView.

Hopefully in the next release I will create some sort of config asset to configure default views, displays and a bunch of other things. Also try to be independent of Fasterflect, less dependencies make my day. And maybe improve the serializer's allocation. As it currently allocates like crazy when serializing large dictionaries...

 

No, the plattform doesn't require anything, it's Unity. We literally can't update Unity to a higher version. When developing for consoles you get a special Unity Build and have to stick to it and the updates you get. And for now this is Unity 4.3, we have to wait till the Unity 5 Console version come out and that could take months :/

 

That sucks! - You should be able to see the list in Unity's default inspector if you mark your quest class with [System.Serializable]

 

Yeah, but not the fields/properties of the class :/

 

You mean you can't see the quests' names? In my Unity this works:

Code (csharp):

1.  
2. public class Test : MonoBehaviour
3. {
4.    [Serializable]
5.    public class Quest
6.    {
7.      public string name;
8.    }
9.  
10.    public List<Quest> quests;
11. }
12.  

Must be a Unity 4.3 thing again then. However I do remember that this is supported even in versions older than 4.5

 

Ah, true, that does work. But not with properties, right?

 

Nop. The way the default Unity editor works is via SerializedProperties which only work with fields.

 

I see, alright, well then we'll use this one with our next project in Unity 5

 

Any idea why "web player" builds break when using your Editor-only changes? (Or is there something about Web Player apps that doesn't support Vexe)?

I'm planning on a PC release, but the web deploy is nice for showing off incremental changes. I'm a unity noob so please forgive me if this is an obvious issue.

 

For what it's worth, Web is working in v5. Can't say anything about 4 because my connection is too slow to download it again... Are you sure it's this plugin that's breaking it? Can you build if you remove it again?

 

I can always build - the issue is that the drawers stop working if I switch my build from PC to Web.

 

hello vexe, thanks for this amazing plugin
i would like to report a bug

if a script with serialized interfaces is recompiled by unity then some references is lost in current scene. Reloading current scene without saving restores all lost references

i am using unity 4.6.2 and VFW 1.2.9p1

 

@Xelnath I'm not sure. But it's something related to Fasterflect. I'm planning to get rid of it in 1.3 so maybe it will resolve the issue.

@ToBeGlad I mentioned in an early post (#162) that there's a bug in Unity's 4.6.2 serialization. Can you roll back to 4.6.1 and see if the issue is still there? (or try their p1 patch, they might have resolved it I'm not sure)

 

That is great work man! Since it is open source already, is there a reason this is not on Github or something similar? It would probably be easier to manage bugs/issues etc. or even let people help you

 

It's currently a private repo on bitbucket. Will eventually make it public just need to sort some things out