What I am trying to do is to add a grass image object to Tiled which has a number of different frames for animation. So I add all the frames as separate objects into a “collection of images”. Then I pick the first frame in the collection, and choose the Tile Animation Editor. In there I add all the frames and set a wanted frame duration for them all. This works fine, but when I want to add another collection with another name but using the same images so I can set this animation to be slower than the other with a different frame duration setting, these changes reflects onto the other collection too.
I am assuming this has to do with that both collections uses the same images, despite being separated into two different collections.
Is there a way to make this work without duplicating my images and changing their filenames?
Alright so I noticed this only seems to happen if I place any of the images on a tile layer. If I add them to a object layer, they are behaving correctly. I’d prefer to be able to place them on either layer type and have it work though. In this specific case it’s easier to work with a tile layer.
Just tested this, this happens to me too, and it’s not just a performance issue. In my case, the second tileset had the animation faster and the faster animation overrode the slower one. This seems like a bug, perhaps Tiled is using the images as tile identifiers rather than doing it properly like it does for regular tilesets…
Fortunately, there is a workaround, and it’s actually the intended way to do what you’re doing:
Instead of using multiple collections, assign your alternate animation to a tile that was another frame of the original animation. The animation can still start with your intended frame 1, the tile the animation is attached to doesn’t have to be the first frame. This way you’ll also have an easier time telling apart the animations you’re using since they won’t be in identical-looking tilesets, but will be different tiles in a single tileset. There’s no reason to have these duplicate tilesets just for slightly different animations :]
I don’t think it’s fair to mark this one as solved yet, since there is a legitimate bug here - the behaviour you experienced shouldn’t be happening, data from one tileset shouldn’t affect another. If possible, consider changing the category of this post from Question to Bug.
I’ll leave it as solved because technically @eishiya answer solved @srosie’s issue. But yeah, this is also a bit of a bug.
Before adding tilesets to a map, Tiled tries to detect when a “similar” tileset is already part of the map, and if so, it will replace tiles in the stamp with the tiles from this similar tileset. In checking whether two tilesets are similar, Tiled currently only checks the most relevant parameters and does not do a deep comparison of tile animations, terrain definitions and other per-tile properties. So likely the tiles you’ve placed on the map have been silently replaced by those from the tileset that was already part of the map.
This replacement is somewhat historical, it was more relevant when all tilesets were embedded and should probably just be skipped for external tilesets.
@bjorn@eishiya As Thorbjørn mentions, I marked it as solved at it did solve my issue. Not entirely sure how it’s preferred to treat these subjects here in the forums on discourse. I am used to in other forums that one create a new bug ticket/post in the bug section when relevant and leave any other posts where they are. This too because often they want a more detailed bug report post. But it’s good to know that is a possibility here, to re-categorize when appropriate. I’ll keep that in mind for any future posts in the Tiled forum, thanks!
I’m not actually sure how it’s meant to be done here either :'D Making a second bug report post with more details seems like a good idea, but IME most people aren’t willing to do that.
I’ve just committed the following change which should avoid this issue:
Unless you were using embedded tilesets, for those the behavior stays the same for now because avoiding duplicates is more important there, even when there are small differences between embedded tilesets in different maps.
Sorry for bumping this topic, but I believe I have a use case which got broken by this commit:
When loading tile sets into a tile map from a script, as far as I’m aware, the tile set will be considered embedded (even if it’s simply loaded from an external file). If I now have automapping rules referencing this tile set, these two will not be considered the same anymore, and the automapping rules don’t work. Steps to reproduce the use case:
Create automapping rules referencing an external tile set “path/to/my/tileset.tmx”
Define script with a map format that creates a tile map using this tile set:
var myMapFormat = {
name: "my Map format",
extension: "mymap",
read: function(fileName) {
var tilemap = new TileMap();
tilemap.setSize(..., ...); // fill in as appropriate
tilemap.setTileSize(..., ...); // fill in as appropriate
var tileset = tiled.tilesetFormat("tsx").read("path/to/my/tileset.tmx");
tilemap.addTileset(tileset);
return tilemap;
},
}
tiled.registerMapFormat("mymap", myMapFormat)
Load a map using the newly defined format, place some tiles matching the automapping rules.
Try to apply the automapping rules.
This works fine in version <=1.7.1, but stopped working in version >=1.7.2. Commit 5b83b6e seems like the obvious culprit.
I guess the proper solution to this would be to allow explicitly loading external tilesets
without embedding them into the tilemap (something like an ExternalTileset class that behaves like
Tileset but is read-only maybe?)
If you want, I can create an issue on github (feature request or bug, depending
on what you consider this to be.)
@qiuu This is rather a shortcoming in the scripting API. If you load the tileset using tiled.tilesetFormat("tsx").read(...) and add it to the map, then indeed it will be considered an embedded tileset since the source file information is lost.
@eishiya has opened an issue about this on GitHub, which describes the issue and we have discussed a solution in the form of adding a tiled.load for loading such an tileset instead:
