[mapeditor] Feature request: Re-importing/re-loading external tilesets

844 views
Skip to first unread message

gregoryg

unread,
Feb 8, 2012, 7:35:32 AM2/8/12
to Tiled Map Editor
Hello,

I was puzzled by the design of the external tilesets, so I am not sure
whether the feature I am asking is valid or I am missing an obvious
solution.

I am developing a large number of separate maps that all reference the
same external tileset. All of them are under heavy development and
therefore new tiles are added/changed on a daily basis. However, every
time the external tileset is changed, none of the maps see the
changes. So, in order to "refresh" the tilesets I have to Add External
Tileset → Import Tileset → remove the old one (thus erasing my whole
map) → re-draw the same map, using the new tileset. As you can see,
this is an extremely inefficient way of doing things, yet I cannot see
any alternative. Ultimately, what I am looking for, is some kind of
"Update Tileset" for any of the external tilesets. Or the option of
not embedding the tileset information within maps (the exact opposite
of what is mentioned in Cocos2d wiki [1], yet cannot be found in the
current version).

I would be very grateful if someone could point out what I am missing
or comment whether this feature would be useful to anyone.

[1]: http://www.cocos2d-iphone.org/wiki/doku.php/prog_guide:tiled_maps#making_sure_a_tileset_is_embedded

Thank you in advance,
Gregory Goltsov

Adrian Tymes

unread,
Feb 8, 2012, 6:22:25 PM2/8/12
to mape...@googlegroups.com
Simple:

1) Create a map. Note which image files it uses for tile sheets.
For best results, keep the TMX and image files all in the same
directory (and save the TMX there the first time you save it, so
it knows it doesn't have to store any path info about the image
files). Close Tiled when you're done.

2) Create new image files, with the same file names,
dimensions, and margin & spacing (if you're using them).

3) Copy these files into that directory, replacing the previous
image files.

4) Reopen Tiled and reopen the TMX. Voila, it's using the new
images!

Note that none of this involved operations within Tiled itself. This
is because of the nature of how these tile sets are updated: you
update the image files, not the TMX file, and Tiled technically only
works on the TMX file.

-Adrian

> --
> Tiled Map Editor mailing list
> mape...@googlegroups.com
> http://groups.google.com/group/mapeditor

Gregory Goltsov

unread,
Feb 26, 2012, 7:19:20 AM2/26/12
to Tiled Map Editor
Thanks for your reply, Adrian. However, I believe you're describing
the Preferences -> General -> "Reload tileset images when they change"
option. My problem can be summarised, I suppose, as why even though
tilesets are referenced from a separate file, they are still a)
contained within the TMX file, b) there is no way to update that
information from the said external TSX?

—Greg
> > [1]:http://www.cocos2d-iphone.org/wiki/doku.php/prog_guide:tiled_maps#mak...

Adrian Tymes

unread,
Feb 26, 2012, 1:57:29 PM2/26/12
to mape...@googlegroups.com
Ah. Yeah, I haven't used TSXes yet.

-Adrian

Gregory Goltsov

unread,
Mar 7, 2012, 7:04:21 PM3/7/12
to Tiled Map Editor
Bump. Surely someone had a similar problem.

—Greg

Thorbjørn Lindeijer

unread,
Mar 8, 2012, 4:26:42 AM3/8/12
to mape...@googlegroups.com
On Thu, Mar 8, 2012 at 01:04, Gregory Goltsov <gre...@goltsov.info> wrote:
> Bump. Surely someone had a similar problem.

I can only say, surely when you change an external .tsx, restarting
Tiled to have this change apply to other maps using that .tsx file
should be enough? At the moment Tiled does not monitor .tsx files so
changes won't apply immediately, but really a restart should be enough
rather than removing/readding the external tileset to a map.

For external tilesets, no information about this tileset is stored
inside the .tmx file apart from a reference to the .tsx file and the
'firstgid' used to determine which global tile ids are from this
tileset.

Best regards,
Bjørn

Pito Salas

unread,
Mar 8, 2012, 9:00:00 AM3/8/12
to mape...@googlegroups.com
Hi Bjorn,

I agree. A simpler possibility that is used in many apps is a 'refresh' command. Would that be trivial to do?

-- Pito

Thorbjørn Lindeijer

unread,
Mar 8, 2012, 9:12:49 AM3/8/12
to mape...@googlegroups.com
On Thu, Mar 8, 2012 at 15:00, Pito Salas <pito...@gmail.com> wrote:
> Hi Bjorn,
>
> I agree. A simpler possibility that is used in many apps is a 'refresh'
> command. Would that be trivial to do?

Not trivial, mainly because an external tileset is loaded only once no
matter how many maps you have open that use it. So to refresh it,
you'd have to either reload the tileset while keeping the Tileset* and
all its Tile* valid, or you'd need to unload all maps, clear out the
cached tilesets and then reload everything again.

I guess the first option would be easier. It is the approach taken by
the reloading of just the image (and it leaves any Tile* that point to
no longer available parts of the image hanging around as empty tiles).
But I'd still not consider it trivial.

The handling of external tilesets is not perfect. Basically they're
documents on their own, but Tiled doesn't handle them as such
currently. Hence making changes to them while they are external is
disabled, you have to temporarily import them to a map so you can
change them, since it's the only way to make the undo stuff work. I'm
not sure how to really solve this problem.

Best regards,
Bjørn

Pito Salas

unread,
Mar 8, 2012, 9:17:11 AM3/8/12
to mape...@googlegroups.com
I certainly don't understand the internals like you do. I was thinking simplistically of the equivalent of save, close, open, in one command. 

-- Pito

Thorbjørn Lindeijer

unread,
Mar 8, 2012, 9:20:57 AM3/8/12
to mape...@googlegroups.com
On Thu, Mar 8, 2012 at 15:17, Pito Salas <pito...@gmail.com> wrote:
> I certainly don't understand the internals like you do. I was thinking
> simplistically of the equivalent of save, close, open, in one command.

Ok, so the point is, that won't work, and it's also probably why
Gregory devised the solution of removing the tileset from the map and
re-adding it. Because simply reloading the map will re-use the same
_still loaded_ external tileset. That's why you currently need to
_restart_ Tiled in order to pick up changes made to external tilesets.

Best regards,
Bjørn

Gregory Goltsov

unread,
Mar 9, 2012, 7:07:20 AM3/9/12
to Tiled Map Editor
Thanks for the replies!

Well, I don't actually use remove and re-add method - it's too
painful; I was just using it to illustrate the possible solution. I
simply edit the raw XML tree (kind of defeating the purpose of using
the editor) when the tileset is updated.

> For external tilesets, no information about this tileset is stored
> inside the .tmx file apart from a reference to the .tsx file and the
> 'firstgid' used to determine which global tile ids are from this
> tileset.

In my case, the .tmx files *do* contain all the 'tile' nodes as well
as the 'firstgid' reference. Could it be an option I selected?

Also, restarting Tiled does nothing in terms of picking up changes
made to the external tilesets (at least in my case).

—Greg

On Mar 8, 2:20 pm, Thorbjørn Lindeijer <thorbj...@lindeijer.nl> wrote:

Gregory Goltsov

unread,
Mar 26, 2012, 5:57:24 AM3/26/12
to Tiled Map Editor
I solved the problem and thought it would be useful to share the
solution in case people land here after googling.

I could've tried to contribute to Tiled and try to implement the
feature myself, but I don't think I would've done a very good job of
it. So instead, I separated the Tiled map from its tileset's
properties (in my game, I'm not directly drawing the map created in
Tiled, but instead the map consists of tokens that represent 3D
models). I created a simple dictionary with keys being the tileset id
and the values being the 3D model names. So when I populate my map
data structure from the tiled map, I simply get the model name based
on the tileset id. This means all that information is in one place, no
duplication and dead simple to change.

This might not be the best solution, but it's simple and was the
fastest and the most robust to implement.

Consider this thread closed and thanks to everyone who replied to my
problem!

—Greg
Reply all
Reply to author
Forward
0 new messages