Asset Store Limitation

I.... wuuuuuuaaaaaat???

I can understand that one must support prefab overrides... But SerializedProperty? Why is that a requirement?

A while ago, I started rewriting the whole inspector because of a long list of limitation that I hated in it. A long, long, long list. The first being that I don't want to rewrite a custom editor every time I write a new script, and I still want control on how everything is displayed. The first thing I dumped was the SerializedProperty, for a lot of reason.

It allowed me to do a lot of thing that would be otherwise impossible, such as prefabs override apply/revert per field or copy pasting structure like a Vector3 per field (Copy/Paste position!). Or simply to have a moving separator between the labels and the fields. Or about a hundred other features.

I was considering packaging it and selling it, but now looking at that limitation, I see I would be rejected? Why?

 

Bump... Or is this the wrong forum to ask about that?

 

I moved it to Assets and Asset Store, since it's concerning the Asset Store directly.

--Eric

 

I was wondering about that forum...

 

Bump?

 

Damn this forum moves fast... Forth page... Should I just give up?

 

Please do not bump topics every few hours.

 

Getting the whole functionality right yourself without using SerializedProperty is almost impossible, there are simply too many edge cases you may not find now, but your customers usually will. For customers it is essential that undo/redo as well as the whole prefab functionality just works. That's why it makes a lot of sense that those are required for editor extension.
The way I am trying to think is usually, how can I create an editor interface using SerializedProperty. Sure, it is a restriction, but at the same time it makes your life a lot easier.

 

I can understand that it makes it easier for a lot of people. However, it's just like I said, SerializedProperty/SerializedObject doesn't support the features I want.

Just the idea that the "type" returned by a SerializedProperty is an enum is very limiting. (http://docs.unity3d.com/Documentation/ScriptReference/SerializedPropertyType.html) Some of Unity's base type aren't listed in it.

But I guess the most annoying thing of all, is that SerializeObject can only be created from UnityEngine.Object.

I know it's not an easy job, but it's far from an impossible job.

So I'm asking, why this arbitrary limitation? What if someone comes up with something better? It would be refused because it's not using Unity's stuff?

 

It is so unlikely that someone comes up with something better, that you can almost forget about that special case and that's likely the cause why they didn't mention it. I am more than aware of the limitations that come with SerializedObject/SerializedProperty, that's why I understand your concerns. But keep in mind that if you are using SerializeObject, you end up spending a lot less time to maintain your code. If you do something else, it is likely that you need to use tricks in order to get it working and that automatically means that your code is much more likely to break with future Unity versions.

 

That's the point... I'm not using "tricks", but what most property grid use; reflection, which is dependent on the .NET framework, not Unity. My dependencies on Unity itself is very slim. Basically, I derive from Editor... and that's pretty much it.

My goal was simple... To never write an Editor ever again.

• Unlimited number of depth, any object or sub-object - even reference - can be expanded and inspected
• Expand and browse ANY type, even Unity's
• Inspect Fields, Property or even Methods
• Support Sub-component creation, polymorphic fields
• Movable separator between label and editor, no wasted space
• Right Click labels for contextual menu
• Contextual menu is extensible per field type
• Copy / Paste fields, whole objects or structure
• Apply / Revert prefab change per field
• Sortable List with buttons
• Move list item up, top, down, bottom, or clear list from contextual menu
• Any item in a list can be expanded and inspected
• Attributes on list are propagated to their children when they are base types. (Int, float, string)
• FieldEditor, unlike PropertyDrawer, fully supports Layouting (GUILayout, EditorGUILayout)
• Unlimited number of attribute per member
• Group items into fold-able groups
• Inspector can be drawn outside the Inspector panel, on any EditorWindow
• Inspector can inspect object not deriving from UnityEngine.Object
• Hide/Show items per scope (Ex.: Basic, Advanced, Debug)

Added attributes;

• AllowSceneObject: The object picker list scene object too
• Bypass: Any Unity's type become expandable recursively
• CreateDerived: A field sport a + sign which allow you to create a type deriving from that field's type. Popup let you choose which type.
• Descriptor: Can change name, tooltip or even color of a field, fixed or at runtime.
• DisplayAsParent: Any nested object are display as being part of their parent's fields.
• Expandable: Makes any class or fields have a > sign that allow you to browse it's internal values.
• FieldEditor: Forces a field to uses a specific editor
• Help: Display an help box. Help box data can be modified at runtime.
• Inspect: Flag what you want the inspector to display. Field, properties, methods. Can be hidden at runtime.
• MaskedEnum: Turn an enum into a bitfields.
• ReadOnly: Make a field not-editable, and it's child. Property without setter are readonly by default, but do not propagate downward.
• RestrictProperty: Turn any field into a drop down list of choices.
• Size: Forces a list to be of a specific size, cannot add or remove element.
• Space: Add a specific space after the current field.
• TextField: Change how a text field is display; text field, text area, password, tag, file picker, folder picker

And I'm probably forgetting some feature.

http://i.imgur.com/sqoI3bF.png
http://i.imgur.com/Ax3gMAL.png

The idea is, while you can still define how a specific field is displayed and edited, you never need to write an Editor ever again. You can fully control that directly from your class definition.

We are using this for numerous projects in a game studio. It's not perfect yet, but it's rather stable.

 

I see. You have a pretty good argument why you are not using SerializedObject. You may just submit your package to the asset store or you can contact them if you are still unsure. Anyways, you seem to have a valid exception for the rule. Just be prepared that you may need to make your point clear.

 

I agree that SerializedObject / SerializedProperty is very limited, too. I rolled my own serialized things for my upcomming Inspector2 extension, too. So anyone at Unity reading this ? please answer right here ! Is it valid or not to use our own serialized thing in stead of Unity's SerializedObject / SerializedProperty ?

 

Since I never got an answer, I decided to roll out my asset anyway and hope for the best. Supporting undo, prefab override, multiselection and so on was a pain, but it was worth it. ( http://forum.unity3d.com/threads/244169-Advanced-Inspector-A-different-approach-to-the-Inspector )

Just noticed Thien that you do a beta run before releasing... Maybe I should consider doing something similar, considering the number of features and the apparent endless combination possible.

( http://i.imgur.com/NkdlXol.png - Hierarchy panel with a favorite section. )

 

I dont think it is a requirement for everything, only for the items that need to be saved right etc

Also i think using serilized objects in the script itself will not create any problems for hidden variables that communicate with the custom editor/inspector

I use a mix of serized hidden properties in the script and the ones i need bolded for prefab overrides i enable with serilized objects and so far everything works fine

 

Well, since my package was accepted, this settles is.

 

EDIT: Wrong thread.