Keep an image collection tileset synced with a folder

[patchuby]

Now that tiled supports rearranging tile order in a tileset, it would be nice to have the ability to keep a tileset in sync with a folder.
So the user would select a folder when creating a tileset, and the tile order would be based on the alphabetical order of the folder and whenever an image is added to the folder it is automatically added to the tileset.

Possible issue : What happens when an image is removed, with a tile used in a map : does it delete the tile "silently" or is there a prompt/warning to replace the tile with another tile on the tileset.

[bjorn]

Possible issue : What happens when an image is removed, with a tile used in a map : does it delete the tile "silently" or is there a prompt/warning to replace the tile with another tile on the tileset.

We can't automatically delete tiles, mostly because a tile can have associated data like collision shape, animation or terrain info. So when an image can't be found, there should probably just be a message (like there is already) telling the user a referenced file could not be found, and the user can remove the tile manually. Of course, we could add a quick "remove all tiles with broken image reference" kind of action.

Another tricky case might be when the user renames an image. Then a new tile would be added, but the user may want to keep the associated data and actually would just want to change the image file reference of the affected tile. I don't have a good solution for this in case of external renames, but we could provide a rename action within Tiled that handles this case (though first of all images files would have to be displayed in the Project view, which I think would be nice as well).

[drschwabe]

Just armchair quarterbacking here but one thing you might consider is that Git is a very good file diff'ing algo built in and it detects renames (which you can inspect retroactively; ie- on Tiled bootup or on a timer while the app is running; you can also parse this data via raw CLI or something like SimpleGit js module if you wanted more programmatic API).

Many users may already have their image collection in a git repo (presumably apart of a bigger project). Possibly you could thus have a 'graceful upgrade' for these users such that if they have their image collection in git you could use git as your source of truth as to when a rename happens and simply update based on that.

Maybe this could also integrate with Tiled Projects ie- in your Projects UI you give the user the option to specify a git repo; and this then is the basis for unlocking the git-enabled features like rename detection.

[bjorn]

Hmm, I think it could be preferable to detect renames directly. It could for example be done by storing a hash of each image and using that to match up new images to existing but missing images. The downside is of course the extra hash to store for each tile in the tileset, but we'd only store that for these automatically synced tilesets (though, storing hashes of tile images could also help with automatically detecting and adjusting to re-arranged image-based tilesets).

[eishiya]

(though, storing hashes of tile images could also help with automatically detecting and adjusting to re-arranged image-based tilesets).

You have to be more careful with this for image-based tilesets than Image Collections. It's common for tilesheets to contain many tiles that look identical. Most commonly this is just due to empty space in the tileset, but sometimes it's also due to tiles being repeated for other reasons. Sometimes these tiles hold different properties or belong to different terrains. Tileset rearrangements like this often involve entire blocks of tiles being moved, so Tiled could use surrounding unique tiles as "tiebreakers" when dealing with repeated tiles.

I'm hoping that Tile Atlases and the tools to edit them will make it easy enough to move groups of tile definitions that automatic matching won't be necessary for minor tweaks.

In any case, I hope this would be optional even for Image Collections. And if the hashes are to be stored in the tileset files, then it's even more important for it to be optional (and not just for exports). I would rather deal with renames and the resulting "missing" tile images manually, because it is an infrequent scenario for me, and usually happens for a reason - if I rename a file, there's a good chance I don't want it to be the same tile any more, and that a different tile might take its place under that name.

Edit: Also, does it make sense to store the hashes for the tile in Image Collections? Multiple tiles may use the same image, with different or the same subrects. It seems like it would make more sense to store a <filename, hash> dictionary, since there are fewer files than there are tiles.

Edit 2: I wonder if it's even necessary to store the hashes in the tileset, especially if they're per-file rather than per-tile. Why not (optionally) store imageFile:hash pairs in the Project instead?
I also think it would be acceptable, though not as good, to not store the hashes at all, and only have Tiled do this syncing while it's running. Tiled "fixing" changes made while it wasn't running would be going above and beyond :]