I am currently using the beta with Tilesets but I want to save a tileset for use on other files. Stupid question but I can’t find how to do it, how do I save a tileset?
1 Like
i think that possibly currenly theres no way, since its a new feature.
what i think you can do is save all tiles in a different file and them when you gonna use it just open it select all create a tileset layer and put them there but thats a way to circunvent the problem.
@dacap thats a needed feature maybe save in a .asets(ASEprite TileSet) or something like that i would say .ast but that extension alredy exists, them you would just need to add a folder sign
crude example i know but that would solve the problem on how to open
to save the tileset it would maybe have e 3 line thing here
Hi there! 
There are plans to link tilesets between different .aseprite files, from the tilemap issue:
- Possibility to link external tilesets
- Persistence (.aseprite information)
- Auto-sync tileset from external file when the original is modified
- UI to select external tilesets
- Special import/external/linked tileset options, e.g. from grids, from frames, from layers, from “Import Sprite Sheet”, etc.
I’m not sure if a new .aseprite-tileset format would be needed or just a way to select and .aseprite file and then any tileset inside the file (or importing the tiles from the canvas, just like in Import Sprite Sheet + other new options that we would like to experiment with).
@Ethan_Buttazzi still not sure how to present the tileset manager, but maybe from Sprite Properties, or just like an option new button in the color bar with the tiles mode as your mockup.
good, also i was working with tiles late night yesterday, i noticed that you can alt+scroll them it just scrolls trougth the palette, what could be done here is when yor in tile mode, putting tiles it would scroll betewwen tiles isnce you cant pick colors anyway
also the ability to rename tilesets would be great
thx for the attention, its good to have a developer that is so involved with the community
It’s good to know that there are plans for fleshing out the tile system! If i might also say, it would be very helpful if we could move the tiles around on the UI without it affecting the actual drawing itself. For example, when I moved one tile on my tile picker it also moved round the tile itself within the canvas. Thanks for the reply tho 
I think a new file type would definitely work, maybe similar to the way we can make custom palettes? Btw, how did you get the dark UI?
I don’t agree about new file type.
First of all extrernal tilesets should have their own palette i.e. just to use external .ase sprite palette. This will be more than enough and generalized. And this way we can use RGB tiles inside Indexed sprite, which is Ok, until Tile map layer converted to just bitmap, where we should get its tiles converted too.
Second of all the frames of .ase file should be used as tiles indices to allow complex multi-layer tiles which flattened when loaded to be used as tiles. And you can hide/show layers in tiles sprite .ase to control what to see in Tile maps. Even tiles of tiles possible this way. But no direct editing of tiles inside where used for Tile map layer, which is preferred in this case. And with “Edit tiles…” to open source sprite of tiles. This should also auto create new frame in source sprite for new tiles of Manual tiling mode effectively inserting drawn content to first suitable visible layer (or creating new layer), and go to existing frame for Auto tiling mode (when modifcation of tile attempted by an artist).
And don’t afraid to use frame numbers as tiles indices. Because animation of tiles should generally use tiles themselves as frames i.e. tiles = frames here (except for NES-like mappers bank switching which is special case of several tilesets used to make tiles animated).
And third of all, information on how to align tiles from external .ase sprite frames i.e. (dx, dy, tile_width, tile_height) could be taken from its Grid (grid_cells_dx, grid_cells_dy, grid_cell_width, grid_cell_height). Even additional information like per-frame/tags user data (working as tile info) and non-rectangular base vectors (by adding support of non-rectangular grids with base vectors first) could be added and used for .ase tiles.
Tiles should be re-loaded and re-flattened when external .ase detected as changed. Also they should be baked into sprite as internal tileset until auto re-bake or explicit re-bake requested by an artist and/or when external .ase is not available.
i dont undestand how that would open?, like in pratice how do we use it simplyfy most of us arent familiar with such intricaces of aseprite
- Just specify for Tile map layer to use external .ase file as tileset
- Draw any content in that .ase file with frames = tiles concept in mind
- This content will automatically be flattened (to get rid of layers) to be used as tiles
- To edit external tiles you will have to edit that .ase file
- But Aseprite will auto-jump to new/old frame of that .ase file by opening that sprite in new tab at specific frame when you try to edit tiles at layer with external tileset
You may ask what if you want to see and edit all external tileset tiles at once — you should create separate working-on-tileset .ase with Tile map layer for this — and just switch between this working-on-tileset sprite (used to order tiles in different shapes) and tileset sprite itself (to edit tiles content).
so like a photoshop smart object? i think thats overcomplex. just saving a tileset in a specific archive type and importing in when creating a tileset layer would be way simpler in pratice and in programming i think
dunno @dacap what do you think which is easier to make
Simpler does not always mean better. Specific format will allow a lot less things to do. No easy Metatiles. No debug overlays. No tags-based debug info. No easy exporting. No easy layered tiles editing (very cool thing!). Extra efforts to code and support a whole new format.
While supporting .ase tilesets will require only a few thing to code: 1) new mode (external .ase tileset), 2) sync re-bake button and notification that sync required, 3) opening .ase tiles when an artist try to edit tile or create new tile. Almost nothing. The same internal tileset, but with function to re-bake tileset from source .ase file when it was changed and when you open sprite with such tileset used.
But surely at the end of the day, if you want to be that complex with it you could use a more complicated program like photoshop? Not sure if I’m alone here, but I’ve always perceived aseprite as a program that’s easy to use rather than being as in depth as industry-standard programs, so I personally prefer the simpler way of making a new file.
i agree, the thing i like in aseprite too, is that even the complex stuff can be easily done with a few examples like plugins, also its the way pyxel edit do it too, and he solenely focused on tiiles
But it’s simple. Draw tiles in separate .ase file. That’s all. Why be afraid of just using external .ase files?
thats clumsy i want to be able to save and open tilesets in the fly.
And you will be able to save and open tilesets in the fly. But why another format? Save to .ase (editor can generate new files), open from .ase (generated or create manually). Why do you need yet another format and extension for it? Also editor can create .ase tileset tileframes automatically and put content there, but only in case of simple one-layer .ase tiles.
This way or another you will have complications — when several your .ase projects using the same external tileset. Because when you modify this tileset (re-save it) it will affect all of your projects, even those that are not open now. And later when you open them you may find them broken. So another good option if you don’t want hard linking should be “Load tileset” instead of “Use external tileset”.
I wasn’t able to read the whole topic (this and Proposal — External tilesets using just .ase files), but about the file format for tilesets: we can easily use .aseprite format to store just tilesets, in the same way we use the .aseprite format to store only a palette (where a dummy a indexed canvas of 16 columns x required rows depending on the number of palette colors is automatically generated).
1 Like
finally a good sumary
1 Like
Good. The question is will you allow to edit these tilesets as regular sprites? WIll you allow to make multi-layer edits of these tiles and then still use them as tileset by flattening all visible layers?
Yes, we’ll allow to use flattened tilesets that are created from multi-layers. In that case the tileset will be “linked as an Import Sprite Sheet command” (or somthing similar). There are some steps:
- We have to improve the Import Sprite Sheet action to support more parameters (e.g. multiple grids? ignore empty cells? find tiles automatically?)
- Once the Import Sprite Sheet command is improved & we support linked .aseprite <-> files in some way (some work in progress), we’ll be able to specify a tileset from external files with Import Sprite Sheet parameters from the tileset dialog (this will enable a kind of metatiles).
As a final goal (maybe too ambitious, but I think it’s something required) would be to do an import/export/bi-directional tiles editing: So not only Import Sprite Sheet should work to import and external tileset, but we could edit pixels in the tileset and those changes should be reflected in the linked/external file (and those changes should be chained on other external tilesets).
A big problem about this: when multiple-layers are used for a tileset that is imported, how do we support editing those pixels? where are sent the changes to pixels? (a new layer? a target layer? should we show all tileset layers in the timeline in some way?)