Request to Add Support for Enumeration Properties

[lazybotter]

One really good option to add to the "Add Property" dialogue would be the ability to add multiple string values that would display as a "Select" or "Dropdown Menu".

So for an example:

I could create an object that has a Type of "Box".
The "Box" could then have a "BoxType" property. "Solid Box, Mystery Box, Danger Box".
Then when creating the object on the map we can just select what "BoxType" we would like the "Box" to be.
This would be great for custom game engines etc when creating the maps.

Thanks! Carl ;-)

[bjorn]

Definitely. The main challenge here is that such enumeration properties would need to be based on enumeration types, which would have to be defined before you can define a property of that type. So this means a new section in objecttypes.xml for complex type definitions (I could also imagine supporting types that have sub-properties here later) and then coding some way in which these types get used by the property browser.

Starting with just enumeration properties would be a good idea, I just want to be prepared a little for sub-properties later.

[lazybotter]

Any movement on this? :-)

[lazybotter]

Anyone started on this yet?

[bjorn]

I haven't gotten around to this yet. If it is any comfort, for Tiled 0.17 I did get around to several other property enhancements, like adding "file" and "color" types and supporting multi-line values for "string" properties.

This feature is definitely still on the list of things to improve about the custom properties system.

[jeremyherbert]

Has any work been done on the UI of this? ie how would one define the enum types? Would you have a separate editor window, much like the object types editor, but one that is used just for defining enums? Or something in the same window? Are enums defined as a simple integer->string mapping like in C, or something else?

I'd be interested in giving this a go, but I am not sure which is the best way to proceed. I'd of course like to try and have the code merged eventually.

[bjorn]

@jeremyherbert No work has been done on this. Indeed it would be good to mock up the UI before starting to code this. Thanks for your interest to work on this and to try getting it merged!

Are enums defined as a simple integer->string mapping like in C, or something else?

I imagine the enum will be defined only as the list of options (strings), and these strings will be used when saving/loading. A downside of that is that you can't easily rename one of the enum options, but it does mean you can add/remove them without causing many issues (and without requiring the user to be careful with value assignment in this case).

Would you have a separate editor window, much like the object types editor, but one that is used just for defining enums? Or something in the same window?

I'm hope we don't need too many separate windows and am thinking of something like this to start with:

When you'd click the button to add a new property type, then a new window would pop up where you could define what the new property type would be (eventually, it could be more than just enum, and it could even base on existing types like 'int' and just add a min/max value - not sure yet at which level that makes most sense). In case of an enum, you'd have a list of strings there with +/- buttons and Ok/Cancel buttons.

As a bonus it would be cool if you could drag-n-drop from Property Types into Properties to add a new property of that type. :-)

[jeremyherbert]

Do you think it would be ok to put it in the object properties window when these types can also apply to tiles? The feature I'm personally looking for is the ability to attach enums to tiles, rather than objects.

[bjorn]

Do you think it would be ok to put it in the object properties window when these types can also apply to tiles? The feature I'm personally looking for is the ability to attach enums to tiles, rather than objects.

Yes, that's alright. Actually, there is another issue open for defining custom properties for other data types (#1410) which means this dialog will probably be further extended to support that as well.

[MikaelMollberg]

This would be great to have!

[Tanz0rz]

I want to give a big +1 for this feature! It would really come in handy for my project right now.

[JoeCreates]

Another +1 from me.

[tolgakaranlik]

What kind of Patreon or GitHub Sponsors support can I make to speed up the development of this feature?

How long would it take to have this feature done if I pay for the right Patreonship?

If it would take long, can I contribute to the development with coding this feature for Tiled?

Thanks

[bjorn]

@tolgakaranlik Thank you for your interest in sponsoring this feature! On both Patreon and GitHub, there is a $200/month sponsorship level at which you can determine what I should work on for an entire day. Even when a day may not be enough to implement this feature, I will make sure it will get done.

Alternatively, if you have the time and ability to develop this feature yourself, then this is a great option as well. I give reviewing pull requests generally a high priority and I can help with polishing it up if needed.

Regardless, any level of support would be really appreciated!

[tolgakaranlik]

Sorry I have seen your reply late. I am going to do both, I'll donate $200 bucks for your development and I will also implement some features by myself. If all goes like I planned, I will be donating that amount on 23rd of Feb and as soon as I make the donation, we can argue about which portion you will do and which portion that I will do. Feel free to contact me at tolgakaranlik@gmail.com after you get your payment

[bjorn]

@tolgakaranlik That's great to hear, I'm looking forward to working together! When you're ready I'm also open for a video call over Discord, Skype or Jitsi Meet.

[svipal]

Is this still open / bounty relevant ?

[bjorn]

@svipal This issue is still relevant and indeed there is a bounty on it. It's something I planned to work on for the release after Tiled 1.5. Is it something you're interested in working on?

[svipal]

Yep I am ! Has there been any work done on the subproperties ?
Also - Were you thinking about only having them available from object types's properties as in your mockup ?

[bjorn]

@svipal I'm not attached to putting them in that dialog, it could be preferable to have a dedicated dialog for defining new property types.

Also, currently the object types are saved in a separate objecttypes.xml file. I left it as such because I wanted to get basic project support released with Tiled 1.4 without making the project mandatory, but it might make more sense to merge this into the project file, which makes things easier for the user (one less file to manage). However, changing that is not necessarily part of adding support for enums, so you could also choose to write those out to the objecttypes.xml file for now.

[svipal]

I'm thinking having a separate dialog for property types might help if we eventually want to add subproperties to other stuff than objects. I'm gonna just be saving it in the project file for now.
This might take some time by the way.

[svipal]

Ah, but I disregarded a few things.
Do you eventually want to make using projects mandatory to access custom objects or subproperties ?
Because if not it might get a bit messy when exporting an objecttypes.xml that relies on subprops defined in a project file.

[bjorn]

Yes, I think it would be good to make projects mandatory in Tiled 1.6, since it would enable a number of simplifications (also regarding asset selection in various places).

[bjorn]

After a few weeks of focusing on this change (and thanks to @svipal for getting it started!), it is finally done! (though further work is still expected on this change before the release)

The UI for defining enums currently looks as follows:

When adding a property in the Properties view, any defined enums can now be chosen in the property type combo box:

And their value will display as a combo box in the Properties view:

Currently, enum property values are stored as follows, but this is still subject to change:

 <properties>
  <property name="door" propertytype="State" value="Locked"/>
  <property name="enemyType" propertytype="EnemyType" value="Neutral"/>
 </properties>

I'm considering whether we should use int values (potentially optionally) and whether to use the type ID instead of (or in addition to) its name. This would help handling cases where the type or its values are renamed.

The enums are currently stored as part of the project. For consistency I'd also like to move the object type definitions into the project, but currently they're still in their own file.

For testing out this feature, you can get the builds at https://github.com/mapeditor/tiled/actions/runs/983140218 (when logged in to GitHub). Any feedback is welcome!

[eishiya]

I finally gave enums a quick look. The UX is intuitive to use and I didn't run into any problems.

I'm considering whether we should use int values (potentially optionally) and whether to use the type ID instead of (or in addition to) its name. This would help handling cases where the type or its values are renamed.

I'd really like this as an option. Most (but not all) of the enums I'd use correspond to enums in my game code, and it would be simpler to have them as numbers instead of strings. For this kind of use, not only would the values need to be numbers, but the user would need to be able to control the numbers, as they might not always be simple sequences starting at 0 or 1.

If they're numbers, perhaps it could also be possible to have bitfield-style values, where a property can have several values (value1 | value2 | ...). This would have to be some sort of checkbox in the enum definition though, so that Tiled can know to restrict the numerical values to powers of 2, so that the original values can be deduced from the sum.

All of this should just be an option. For many other scenarios, string values are very convenient, and it would be annoying to have to go through some definitions list (which may need to be exported from Tiled) to get them.

For consistency I'd also like to move the object type definitions into the project, but currently they're still in their own file.

Would it still be possible to export the definitions? A separate file is simpler to parse when you want to make sure in-engine defaults match the default values in Tiled. The same ability would be nice for enums, too... FWIW I check my defaults by hand, so this is just a theoretical scenario. I don't know if anyone uses the definitions files this way.

Are/will enum definitions (and object type definitions) be exposed via the scripting API? Some of my enums are fairly large and I'd prefer to write a script that lets me populate an enum by copypasting my enum definitions from my game code rather than doing it by hand via the GUI. If not, I can always write something that'll modify the project file.

[bjorn]

I'd really like this as an option. Most (but not all) of the enums I'd use correspond to enums in my game code, and it would be simpler to have them as numbers instead of strings. For this kind of use, not only would the values need to be numbers, but the user would need to be able to control the numbers, as they might not always be simple sequences starting at 0 or 1.

The option to save enum values as numbers was added now, alongside the support for defining custom classes (#3215). However, defining custom numbers for each enum value is not supported yet.

If they're numbers, perhaps it could also be possible to have bitfield-style values, where a property can have several values (value1 | value2 | ...).

Support for treating enum values as flags was also added as part of the addition of custom classes.

Would it still be possible to export the definitions?

Yes. Of course we have discussed this topic further in #3123. Support for exporting/importing property types still needs to be added as well.

Are/will enum definitions (and object type definitions) be exposed via the scripting API? Some of my enums are fairly large and I'd prefer to write a script that lets me populate an enum by copypasting my enum definitions from my game code rather than doing it by hand via the GUI. If not, I can always write something that'll modify the project file.

First of all I need to make their values accessible and creatable through the scripting API. Allowing them to be also defined through scripting is something I'd like to explore as well though.

[solerante]

are enum properties exposed to the api?