Assigning reusable tileset properties, removing json cruft

Questions
1

I’m playing around with the (excellent) DawnLike set of tile sheets. What I want to do is assign properties to certain tiles so no matter where/when they’re used those property values are always present.

I can do this by adding a bunch of tilesets to a single, empty map, assigning properties to tiles in the tile set, and saving that empty map, which I can make copies of and fill out with actual, non-empty maps.

This should work, but is there a better approach?

Also, the empty map approach described above, when saved as JSON, produces a bunch of property type information that I don’t care about:

         "tilepropertytypes":
            {
             "0":
                {
                 "category":"string",
                 "file":"string"
                },
             "1":
                {
                 "category":"string",
                 "file":"string"
                },

Is there a way to tell Tiled to leave this out? I’m guessing not.

It seems like I can remove this type info by hand and the map file still works in Tiled (!). But maybe I’ll get burned on this later. Anybody know if this is safe (within Tiled, of course)?

Does Tiled have any hook to let me run a post-save command on the newly saved file?

2

Normally, to avoid copying around tile properties into different maps, you’d export the tilesets to external files (.tsx files, or since recently also .json tileset files) and refer to those files from the maps (by using the “Add External Tileset” menu action). The workflow for external tilesets is not great however (you can’t make edits to them while they are “external”, so you need to temporarily “import” them when you want to make changes). Improving this workflow is the biggest change I’m working on for Tiled 1.0.

Tiled did not save this information before version 0.16, so currently the only way to do this would be to use an older version, or to fork Tiled and modify its code to not include this information in the file. I admit the format is a little ugly, but does it really bother you? The information was a lot easier to add to the XML format, but I couldn’t think of a better way in JSON while keeping compatibility.

Removing it will not have any bad side effect as long as the types are all “string”, since that is the default type. When you add numbers, booleans or since recently, colors or files as properties, then removing the type information will turn these properties into strings.

Not at the moment, though it could have once I’ve gotten around to making the tool scriptable. That’s a major project I’d like to work on later this year.

3

Thanks for the quick reply!

I will check out the exported files, sounds like this might be what I wanted but didn’t understand.

I admit the format is a little ugly, but does it really bother you?

There’s a lot of info, it represents a big fraction of the total file size, which would have gotten copied repeatedly into every map in my previous approach. I might decide it isn’t worth worrying about anyway, or maybe external files will make it less intrusive, still finding my way here.

I understand what you’re saying about string being the default type if I do rip out the type annotations.

Thanks for Tiled. I’m enjoying learning it.

4

If I would reorganize the file format from scratch, the properties would probably be stored as JSON objects more like:

{
  ...
  "properties": {
    "foo": {
      "type": "string",
      "value": "bar"
    }
  }
}

But alas, writing things out that way would have broken all existing JSON map readers.

That’s great to hear!