Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for custom types in properties #2199

Open
redxdev opened this issue Sep 26, 2019 · 3 comments
Open

Support for custom types in properties #2199

redxdev opened this issue Sep 26, 2019 · 3 comments
Labels
feature It's a feature, not a bug.

Comments

@redxdev
Copy link

redxdev commented Sep 26, 2019

One of the problems I've personally run into with the property editor (and object types, by extension) is that the available types for each property (string, int, float, bool, etc) don't always cover all the different types of things I'd like to store into properties. There are plenty of existing issues about adding more types (arrays, object references, etc) but inevitably there will always be one more type to represent in properties (for example: vector or matrix values)

In my projects I tend to have a very generic tiled-to-custom-map-format parser that doesn't know exactly what type each property is supposed to be, so I end up writing a parser for the "string" type that supports putting vectors or other types into string properties (so something like (0, 1) would parse out to a vector). The problem with this is that I also have to support normal string properties, so that involves also writing out a way to escape parenthesis (for example) just in case I need to start an actual string with a (.

I'm proposing adding support for "custom" types that map to any existing type of property but have a different type name. In my mind this would work by having the type attribute on properties be set to the usual string/int/float/etc that Tiled supports and have an additional attribute named customType set to whatever the user specified. This would massively simplify writing custom property types without having to wait for their support in Tiled itself.

Here's an example of how that might look in XML:

<object ...>
  <properties>
    <property name="MyVector2" type="string" customType="vector2" value="3,5" />
  </properties>
</object>

Tiled would need to support specifying the customType value somehow (+ support in the object types editor), but this would allow external parsers to be given a hint as to how to parse properties that don't fit into Tiled's normal types.

@bjorn bjorn added the feature It's a feature, not a bug. label Oct 17, 2019
@bjorn
Copy link
Member

bjorn commented Oct 17, 2019

Yeah, I totally agree this can be useful as well, in addition to supporting custom compound types (#489), arrays (#1493) and enums (#1211). All these things (apart from arrays, possibly) have in common that we need a place where new property types can be defined. It would be nice if we can add this as part of the support for projects (#1665), which is planned to be the main feature for Tiled 1.4.

@bjorn
Copy link
Member

bjorn commented May 12, 2020

Due to the addition of a number of other features and the changes having taken longer than estimated, I'm going to take this out of the roadmap for 1.4. I'd prefer to release Tiled 1.4 soon and will aim to have this in Tiled 1.5 instead.

Edit: As part of the addition of projects, the "object types file" reference moved from the global preferences to a project-specific option at least (change 532e943).

@bjorn bjorn added this to the Tiled 1.5 milestone May 13, 2020
@bjorn bjorn modified the milestones: Tiled 1.5, Tiled 1.6 Sep 29, 2020
@bjorn
Copy link
Member

bjorn commented Dec 23, 2021

I've just merged some major work towards this feature as part of #3215, which for now only adds support for custom classes (extending the support for custom enums added in #2941), but can be extended to also support defining custom types based on existing types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature It's a feature, not a bug.
Projects
None yet
Development

No branches or pull requests

2 participants