Questions about import/export plugin

[samhocevar]

Hi, I have written an import/export plugin for the PICO-8 fantasy console cartridge format, which happens to work pretty well so far, and I have a few questions and remarks.

• first, it was pretty easy to implement, the API is well designed and the provided Python examples were helpful, thanks!
• unfortunately I had to write it in Python because the JS API is missing a loadFromImage equivalent for custom tilesets; what are the chances that such a function is going to be available soon?
• are there plans to implement a mechanism that lets a script update only parts of a tileset, instead of reloading the whole image? for instance, update just one sprite
• in order not to break the cartridge (e.g. the code or music sections), the plugin stores the whole file as a map property: m.setProperty('data', base64.b64encode(cart)) so that the saved cartridge can be byte-per-byte equivalent to the loaded one; is there a way to hide this property so that the user cannot inadvertently delete or corrupt it? in Python at least there is no way to subclass tiled.Tiled.Map.

[bjorn]

• first, it was pretty easy to implement, the API is well designed and the provided Python examples were helpful, thanks!

That's great to hear! The Python plugin was mostly contributed by @stt so I've just highlighted him as well. :-)

• unfortunately I had to write it in Python because the JS API is missing a loadFromImage equivalent for custom tilesets; what are the chances that such a function is going to be available soon?

I'll try to include a solution to this in Tiled 1.4.

• are there plans to implement a mechanism that lets a script update only parts of a tileset, instead of reloading the whole image? for instance, update just one sprite

Can you describe your scenario in a bit more detail? There is Tile::setImage, which could be exposed. A tile's image is right now either cut from the tileset image or loaded from a particular file, but I guess there is little against allowing to set the tile image directly from an extension.

• in order not to break the cartridge (e.g. the code or music sections), the plugin stores the whole file as a map property: m.setProperty('data', base64.b64encode(cart)) so that the saved cartridge can be byte-per-byte equivalent to the loaded one; is there a way to hide this property so that the user cannot inadvertently delete or corrupt it? in Python at least there is no way to subclass tiled.Tiled.Map.

Hmm, why are you storing the whole file there? Since this file is already on disk, wouldn't it suffice to read in the file before writing to it? Though of course, that won't work when you save under a different file name. I guess supporting hidden properties would be a pretty good solution.

Btw, really nice to see PICO-8 files supported by Tiled!

[bjorn]

I've added a link back here in the https://github.com/mapeditor/tiled-extensions README.

[samhocevar]

Can you describe your scenario in a bit more detail? There is Tile::setImage, which could be exposed. A tile's image is right now either cut from the tileset image or loaded from a particular file, but I guess there is little against allowing to set the tile image directly from an extension.

I would need that for two features:

• first, there is this weird PICO-8 specificity that part of the memory is shared between the map and the tileset, so modifying some sections of the map is supposed to also modify the tileset. Right now this is only partially supported by my plugin by doing a save/reload cycle.
• second, I wanted to abuse the layer system to allow changing the palette at design time: I’d like a tileset with only 33 tiles that represent the PICO-8 palette + transparency, and a layer in the map with only 16 cells, and the user would be able to compose the current palette using that (implementing Option to restrict layer to a single tileset #153 would be nice, by the way!). Modifying that special layer would update the global tileset in real time.

Hmm, why are you storing the whole file there? Since this file is already on disk, wouldn't it suffice to read in the file before writing to it? Though of course, that won't work when you save under a different file name. I guess supporting hidden properties would be a pretty good solution.

Yes, reloading the file from disk would break “Save as…”. Also it feels a bit risky in general, I can imagine a lot of scenarios where the original file disappears, or is modified by source control, or may get corrupt… I think it’s safer if Tiled knows exactly how to recreate the file.