Proposal — External tilesets using just .ase files

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.

How to work with external tilesets:

  1. Just specify for Tile map layer to use external .ase file as tileset
  2. Draw any content in that .ase file with frames = tiles concept in mind
  3. This content will automatically be flattened (to get rid of layers) to be used as tiles
  4. To edit external tiles you will have to edit that .ase file
  5. 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).

Also you don’t need Library of tiles/patterns this way. Because you can use .ase files both for tilesets and for tiles patterns. As for wang tiles support it can be added with using frames/tags info as tiles info to categorize tiles. This also proposes Scripted Smart Tile Brushes feature.

this feature does make sense to add ngl

1 Like

i see you moved this to a new thread good, you see, the way you do we cannot make and save on the fly, we are opbligated to create a whole another archive and settle the specific way you’re saying and them we can save, thats too much work, also using frames would be even more confusing and useless too cause you want if thats how you wanna do you want an atlas of tiles just too complex for everybody

saving in a different tile type like pyxel edit and opening when creating another tileset layer is much simpler you can say simple doest mean good, but complex doest mean better either.

It is simple. Why do you think it’s not simple? Just use external .ase file. That’s all. You can save anytime. You’ll have to create another sprite with Tilemap anyway to handle usage of external tileset in either format.

I’ll repeat — in EITHER format.

I just wrote about how to do it in details. So what to be afraid of? Do you afraid of when somebody describe details of simple things? What is the difference between saving to .ase and saving to .asetiles (example extension). What is the difference between opening .ase and opening .asetiiles? The only difference is that you cannot edit .ase tiles directly, but have to ask editor to open another tab for it and edit there. But editor will open it automatically in this case, so what to worry about? For internal edits you have internal tilesets.

I think we can have both. External .asetiles tilesets (just internal tilesets saved to external file) and external .ase tilesets (edited manually). The first is editable during work with Tilemap layer, the second is editable by auto-opening new tab and have more power of combining layers, including sub-tilemaps for metatiles. Everybody is happy.

At least there should be way to export .ase into .asetiles format. But it will only slow down the workflow.

The biggest danger if developers will make external .ase files for tilemaps, but will allow to reference only to internal tilesets there. Now this will be really useless.

i read it all, and i still cannot understand what are the benefits of making tiles in frames then saving and loading into a tileset layer?, what are the benefits for your average aseprite user?.
It feels overcomplicated. my idea for saving tilesets would be similar on how you save palettes.
Save currently tileset as external file: this way it would take the tiles alredy in the current “tile palette” and save it jus as it is, and when you gonna use it again you could just create a tileset layer you would be able to open said file and i t will load
why use a .aseprite file when you can just create another extension to store data?
@dacap whats your opnion on the topic, also sorry for calling you a third time alredy you probaly have other things to attend.

What is the real difference between .ase file and hypotetical .asetiles file? Why do you think that .ase file cannot work as “palette” file?

You can save tileset to .ase file (generated with single layer). You can load tileset from .ase file (single layer or flatten-baked if many layers). You can refer to external .ase tileset for editor to automatically re-load/re-bake its tiles when this external file changed.

You can even edit tiles of external .ase tileset without opening it if it has single layer only.

And when your refer to external .ase tileset and you try to modify its tiles, and it has more than one layer the editor will open new tab for you to handle this situation (multiple layers tileset).

what im suggesting is basically deal with tileset as we deal wih palettes, you open a saved archive and if do modifications you can save it yet again or not it cant be that difficult, both work on indexes

I’m afraid of another solution @dacap and @Gasparoken may conclude to use. With internal tilesets already there they may decide to add ability to “Refer to specific named tileset in another .ase file”. Which may seem good at first glance, because then you can have multiple tilesets and their corresponding Tilemap layers in single .ase file and refer to them from any other .ase files.

But it will come for a cost. Because those internal tilesets are artiicial things now. You cannot use full sprite editing workflow to create them, with layers and sub-tilemaps. Which means you will have to seek another clumsy solutions for those useful features, like special make-a-tileset-from-sprite scripts (in case those tilesets are accessible from scripts at all).

Also they may decide to add internal tilesets referencing lists (and even with exact tiles used) to notify user what projects will suffer / need tiles remapping when tiles change. Which will be useful until you try to copy tilesets file and edit separately, then copy back. Then this feature may fail. It can be somewhat repaired by scanning surrounding .ase files, but it will be clumsy too.

you dont need to do “make-a-tileset-from-sprite” because anything put there is alredy treated as a new tile if you just select 2 or 3 option, anything pasted into the tilemap layer becomes a tile

Not for multi-layer tilesets. Not for sub-tilemaps tilesets.

so you are suggesting that we use a .ase frames to make tiles just to be able to make multi-layer tiles and sub-tilesmaps? thats not even in yet if it will ever be, and then be able to save that way??
the fact that we would need to work in frames is alredy bad enough.
just try to boil down wharever you want is hard to undestand with all text make a summary of it for gods sake

Read carefully. With simple tilesets you won’t need to work in frames. Only for complex ones. And it will cost nothing, because it will use already existing functionality of layers and Tilemap layers. Again, read carefully.

There is nothing to “fight for simplicity”. It will be as simple as you can imagine.

i read it 10 times and i CANT FOR THE LOVE OF GOD undestand why you need this and how the hell the external .ase file works or should be made

You just save your tileset to .ase file. It will be GENERATED for you. Then you can open it if you want and make it complex. Or you may NOT open it and edit your tilemaps as usual. Is that clear enough?

so photoshop smart object basically?, but why would the average aseprite user need this way?

“Using external tileset” is smart thing either way. Only if you “Load tileset” it will be simple. I think you don’t realize the difference between those two options. First option will keep tileset synced between projects at all times. The second is just making internal copy for your specific project.

Don’t think about Aseprite as a toy. It is professional tool, just with user-friendly interface hiding all that complexity from you and making you happier this way. And it should have as much power as it could if it could be implemented relatively easily.

People already asked about meta-tiles and about layered tiles workflow. So this will be useful and could be quickly implemented with bake-tiles-from-frames approach, using full power of existing sprite editing with layers-and-frames workflow. Developers already told they want to add “smart” (as you call it) feature of external tilesets, so why not to add it this way?

so again, photshop smart object, yes or no?

ok i have i proposal, why we just dont bake a the flattening in the export tilese?

This is an option too. To add “Export tileset” with variants (from sprite sheet, from frames-and-layers, etc.). Or at least allow to create make-a-tileset-from-frames script (as I already mentioned).

The only question is why we need another file format? It will cost a price to support it.

i mean .ase is alredy treated in a different way by photoshop as a swatch file, creating another one is good for organization too