[MERGED] Custom properties in Properties grid

Started by eri0o, Wed 04/12/2024 02:05:24

Previous topic - Next topic

eri0o





I had this idea of having custom properties available right in the property grid. The custom properties entry still has the same three dots editor, where new properties can be created and all the schema can be adjusted, but it would show the property right there in the property grid instead.

I made a minimal implementation of the idea in a branch in my ags repo.

I only added support for it in room objects. This is mostly to get an idea if this is a good idea or a bad idea. And also to adjust its design, perhaps it should work in some other way - the custom properties in a different page, or somehow they appear at top level, idnk.

Additional details: they are simply strings for now, so they are not aware of the type in the schema. I also made the experiment in ags3, but I guess this should actually be in ags4, where arrays are a thing, but I don't know how this would work with arrays.

Spoiler
references

codes I found searching on google and used as basis for the idea.


Btw, I will probably not invest time in this soon, I should probably get back to documenting 3.6.2 and moving it closer to release. But people usually take a loooong time to give feedback here in the forums anyway.
[close]

Crimson Wizard

This is actually very good. I recall there have been a user request for this, but I cannot remember if we had it in github tracker.

Quote from: eri0o on Wed 04/12/2024 02:05:24I also made the experiment in ags3, but I guess this should actually be in ags4, where arrays are a thing, but I don't know how this would work with arrays.

I did not understand this part, could you elaborate which arrays you are refering to?

ThreeOhFour


eri0o

Uhm, sorry, I think I am mixing the global variables pane with the custom properties pane in my head. :/

Overall the good part here is it is much easier to set values to the properties - they are right there. I was doing some maintenance on my rellax module that uses custom properties when I had the idea. Unfortunately the thought made me forget what I was doing in the rellax code, I will need to progress there some other time.

Snarky

Sweet. It would also be grand if custom properties in AGS4 could use extender attribute APIs instead of needing Get[Text]Property(String key) and Set[Text]Property(String key, [int/String] value). Cf. Ben's latest blog post.

Crimson Wizard

#5
Quote from: Snarky on Wed 04/12/2024 09:31:46Sweet. It would also be grand if custom properties in AGS4 could use extender attribute APIs instead of needing Get[Text]Property(String key) and Set[Text]Property(String key, [int/String] value). Cf. Ben's latest blog post.

That's an interesting idea, I wish someone mentioned this earlier.

Too bad I'm not making games with AGS, if I had, then I'd probably get similar ideas about how to improve workflow.

In theory it's possible for the editor to generate the hidden script which declares and implements extender attributes, or even if just extender get_/set_ functions if extender attributes are not supported. Technically similar to how Global variables script is generated.



Quote from: eri0o on Wed 04/12/2024 02:05:24they are simply strings for now, so they are not aware of the type in the schema

I don't have spare time to look into the implementation details right now. But if you're dynamically creating a property description, it might be possible to also attach a custom TypeConverter to it, which references custom property schema item. They will still be strings behind the scenes (because custom properties are actually strings), but TypeConverter may limit values that you may assign there.

eri0o

#6
Right, the issue is mainly the game owns the properties schema, and not the custom properties, so I don't know yet how connect these things. More an ownership problem. If the custom properties owned their schema I would have an easier time propagating them upwards. Or if the custom property itself had a "Type" property in itself - it only has value and name. I also am again navigating the issue of all this being in AGS.Types... So plugin compatibility and stuff. But this seems alright, since it's just new things. And the code so far is not very much stuff.

About the code generation, that looks doable, I guess it would hide the get/set property calls behind the scenes more for an usability perspective. It would just need to know both the type of the property and if the thing being extended is an instance (room object) or it's an static extension (the room itself).

Also....

Spoiler


Since custom properties allow spaces I am once again fighting the fight for PascalCase auto-coversion....
[close]

Crimson Wizard

Ok, I checked the code now, it's amazingly little amount of code required for this to work. To put it very simply, you implement certain interface and return a dynamically collected arrays of stuff.

Crimson Wizard

#8
Quote from: eri0o on Wed 04/12/2024 10:27:29Right, the issue is mainly the game owns the properties schema, and not the custom properties, so I don't know yet how connect these things. More an ownership problem. If the custom properties owned their schema I would have an easier time propagating them upwards. Or if the custom property itself had a "Type" property in itself - it only has value and name.

First thing that comes to mind is for CustomPropertyDescriptor class to have a static property that links to the Schema, which will be assigned by the editor on init. Similar to how editors and lists of values are assigned to some type converters and property editor attributes.

EDIT: but that's just one idea. Maybe CustomProperties class should have a link to Schema instead. Then it would be able to pass one into created Descriptor, or pass only a Type.

Quote from: eri0o on Wed 04/12/2024 10:27:29Since custom properties allow spaces I am once again fighting the fight for PascalCase auto-coversion....

Removing invalid characters might work. I would advise against auto-changing the letter case though, as that's a matter of a personal code style.

eri0o

Quote from: Crimson Wizard on Wed 04/12/2024 11:14:00
Quote from: eri0o on Wed 04/12/2024 10:27:29Right, the issue is mainly the game owns the properties schema, and not the custom properties, so I don't know yet how connect these things. More an ownership problem. If the custom properties owned their schema I would have an easier time propagating them upwards. Or if the custom property itself had a "Type" property in itself - it only has value and name.

First thing that comes to mind is for CustomPropertyDescriptor class to have a static property that links to the Schema, which will be assigned by the editor on init. Similar to how editors and lists of values are assigned to some type converters and property editor attributes.

That is a really good idea!!! I would never thought about this, that would work, yes.

eri0o

Small question on that approach, does C# use references or does it copy stuff? Like, if the Schema changed, do I need to set the schema again to CustomPropertyDescriptor or it only has a reference, so it is directly pointing to the right thing anyway?

Crimson Wizard

Quote from: eri0o on Wed 04/12/2024 12:44:49Small question on that approach, does C# use references or does it copy stuff? Like, if the Schema changed, do I need to set the schema again to CustomPropertyDescriptor or it only has a reference, so it is directly pointing to the right thing anyway?

IIRC classes are passed by references and structs by copying, but it is also possible to pass structs by reference somehow.
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/struct

Since Schema is a class, then it will be assigned by reference, and reference counted too.

eri0o

#12
Thanks! OK, I think I will be able to put a PR of this for review and it should be like around 200 lines of code.

The only annoying part is I think I need to grep for all CustomProperties property in each thing and add the annotation below to make it work.

Code: c#
 [TypeConverter(typeof(ExpandableObjectConverter))]

Otherwise it doesn't show the thing to make them expandable. I also haven't figured any way to make it load already expanded.

Edit: oh, I think if I put this annotation in the CustomProperties class I don't need to put this everywhere! I wonder if I can do the same for the Editor annotation and remove that from everyone.

eri0o

Made a PR here https://github.com/adventuregamestudio/ags/pull/2604

It's not working yet if the value of the property matches the default value.

eri0o

#14
Built for AGS 3.6.2.x from the CI here

https://cirrus-ci.com/task/5442950715408384

As always if you are testing it please backup or test it with a throwaway project. :)

eri0o

This is merged so it should make into the next 3.6.2.x and 4.0.0.x releases. :)


eri0o

I was doing search for everything and noticed that at some point AGS didn't had the custom properties stuff for setting exposed and someone made a plugin for it

https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/plugin-custom-properties-helper-for-ags/

What I found interesting of this plugin is it had a Reset function that could set the property to its default value - I think, I have not actually downloaded the plugin. Is this something that is actually necessary? I frankly never felt the need but I guess because of how AGS stores them I thought to ask.

Crimson Wizard

I suppose that resetting to defaults may have uses if you have implemented "restart game" in script, or when you have a reusable pool of objects. Without the "reset" function, one has to set each property explicitly to their default values.

SMF spam blocked by CleanTalk