I'm using the layers to png script to order to save images as well as get the json file to allow me to import data for faster setup. Unfortunately, I've run into a snag. My current project is quite complex, and I'm adding subfolders within /images in order to group a single skin's assets. Then I can use the texture packer to export and get a single atlas per skin rather than having one skin's assets spread across multiple atlases. To maximize setup time, I'm using the json from just one skin for setup, and I'll create the rest of the skins from that. The script plays very poorly with this setup. I can change the output directory to the correct subfolder, but then when I import the data the Image folder's path within the Hierarchy is set to the subfolder. When I fix the path to the root folder so other skin images will also be accessible, all of the image paths for the original skin are broken and I have to manually change them all back to the appropriate subfolder.

Is there another way I could be doing this, or is this level of automation not possible?

In my case each skin represents an individual character, and we're trying to keep it so that each skin is totally contained within a single atlas for processing reasons. When an individual character is generated, only one atlas need be loaded for that character. Based on this other thread (Organize atlases by skin automatically) and further exploration on my own, the only way to accomplish this is to use the texture packer and subfolders. Each subfolder corresponds to a skin.

I want to be able to import data so that for the first skin within a project file I can have all the image attachments arranged automatically for me. The first skin is done. Then when I create a skin for a different character I can easily update the original images. I wasn't aware of the find and replace feature, but that will make this step even easier.

The problem is that the Images directory will be set to whatever folder the JSON points to, in this case a subfolder (i.e. /images/character-01). I need to have access to all the subfolders, but when I update the directory path to the root folder (/images) the image paths break and I have to update them and point them back to the correct subfolder (/images/character-01). I could create a dummy skin that exists solely for the initial setup and is contained within the root folder rather than a subfolder, but I still have to go through and update every image so this doesn't strike me as any more efficient.

Basically what I'd like is for the script to recognize that I'm pointing to a subfolder, and therefore I don't want the entire image directory to also point there instead of the root. Does that make more sense?

Before fixing the Images directory path

After fixing the Images directory path

Indeed, fixing the Images directory path causes quite a few other problems.

After importing and setting up the first skin I duplicate it. If an attachment is a mesh, I make sure the mesh is linked between the skin and change the image path to swap in the new skin's image. If an attachment is just a regular image, I can change the image path or drop the new image onto the canvas, copy and paste the old images coordinates, and move the new image into the correct slot.

Again, my problem is not with making subsequent skins. I already understand what you're saying about image paths. My problem is that there seems to be no way for me to import data properly if I'm using subfolders. Either I make a dummy skin by importing JSON that corresponds to images in the root of the images folder and then change all of its image paths to correspond to a subfolder, thus ensuring that I never have to change the path for the images directory; or I import JSON that corresponds to the subfolder I want to make my first skin out of, which first forces me to change the path for the images directory so it points to the root and not a subfolder (so all subfolders are accessible for future skins) and then to change the the image paths for every attachment in the first skin (so they're pointing to that skin's associated subfolder instead of the root). Either way there's extra work that wouldn't be there if I wasn't trying to work with multiple subfolders.