Sample Request - Aggregate Data Structures on GameObjects

[timeisaparallax]

I've been spinning my wheels trying to wrap my head around how to share data types between different GameObjects and have their attributes show up in the editor. I believe what I'm trying to do is embed complex types inside complex types and have their simple types show up in the Properties Panel.

Is it possible to do this currently with level_editor.xsd or is this a use that isn't currently built in? If it is a sample would be very appreciated. My use case is to create components I can share across different GameObjects without having to add every single property to each new GameObject.

Cheers,
-Bert

[abeckus]

Hi Bert,

We provide sample code in ATF framework that shows how to expose properties of embedded types.
Please download ATF and look at DomPropertyEditor sample.
Try to build and run the sample, it shows properties for a GameObject that have components.
For detail look at the following file:
ATF\Samples\DomPropertyEditor\SchemaLoader.cs
SchemaLoader.cs decorates complex types with property descriptors and associate ui type editor for each property descriptor.
EmbeddedCollectionEditor is UI type editor that is used for editing properties of embedded complex type.

For future updates, I will add an example game object with components.
Until then ATF's DomPropertyEditor is a good starting point.
Let me know if you have any other question.

Alan

[gstaas]

Bert,
There's a discussion of the programming of the DomPropertyEditor ATF sample at https://github.com/SonyWWS/ATF/wiki/DOM-Property-Editor-Programming-Discussion that might be useful to you on the ATF GitHub wiki. It has links to other topics in the ATF Programmer's Guide that might be useful.
Gary

[timeisaparallax]

Thanks guys! I'd caught about 80% of what I needed but that sample should put me over the top. What's the rationale for choosing to use annotations in the .xsd such as scea.dom.editors.attribute versus putting it together in code like the Grid or the DomPropertyEditor sample?

-Bert

[abeckus]

Hi Bert,
Here are few advantages of using code instead of schema annotation for creating property descriptors.

• Easier to create and initialize UITypeEditors and TypeConverters. Can easily call appropriate construct and set properties before assigning UITypeEditor and Converter to PropertyDescriptor. When using schema annotation an editor can be initialized by parsing arguments from annotation and then calling Initialize(string[] parameters). See IAnnotatedParams interface.
• Localization: Easier to localize text in code than in schema.
• Dynamic property descriptors (see GameObjectProperties.cs in LevelEditor).

Using schema annotations was the preferred way in ATF2 framework. The initial push was to allow adding new types without changing the code base. But in practice this idea never fully worked because in most case we ended up having some code to access and utilize the new type.

For all ATF3 based apps we recommend to use code instead of schema annotation for creating property descriptors.
For historical reason, LE still uses schema annotation but I am planning to change that.
Note: Schema annotation still valuable other purposes.

Alan

[timeisaparallax]

Thanks again Alan!

That context with ATF2 versus ATF3 helps a ton. Good to know the direction you're taking things.

-Bert