This was brought up during the coding workshop. It's not really a bug, but rather a difference in workflow. Spine will have it's own integrated texture packer, the same one we have been using internally while working on Spine and it works with folder names. We already have some communication going with Andreas and I'm sure we can work something out to rectify the inconsistency.

If you drag the parent folder into TPP, it creates a smart folder reference and then the subfolder names are included atlas.

Alternatively, you can rename textures so you never get duplicate names. (For example, instead of having goblin/head.png and goblingirl/head.png, you have goblin/goblin_head.png and goblingirl/goblingirl_head.png.) Then you just look for the filename without path in your app.

I've tried both, and I prefer the first method, but smart folders can cause some other problems that you have to work around. If Andreas adds an feature to optionally include path names in the atlas, that would be ideal.

You can also copy and paste TextureAtlasAttachmentLoader and strip the path off the attachment name before looking it up in the atlas.

TexturePacker(Pro) supports folders if you add complete folders instead of individual images.
It just removes the top folder.

@YaW - just add your "images" folder from the screenshot above.
The paths should be available now.

Paths are removed if individual sprites are used.

hey @andreasloew I Have Been using TexturePacker(Pro) for a while (Paid License) and I was the one who brought up this issue during the coding work shop... just a question for you.. The Linux version of TexturePacker.. I noticed the version # on it are older than the windows mac platform.. whats happening with that am I missing awesome features?

I'm going to look to night to see if i can get Andreasloew suggestion to work this evening

andreasloew you make great software.. I am anticipating the built in texture packer for Spine but still plan to use your product for ALL my static Sprites / Generic animation Thanks for making great Texture/Physics software at a great price!

andreasloew escribió

Well... linux... I really wanted to support it but since not even 2% of the users are linux users...
I plan to release an 3.x.x versions if I find the time - but I don't call it a fully supported platform.

Thanks for the quick response! I feel that as of right now it might not be a big slice of the market share..this boils down to the fact that without proper support you will never see that percentage increase.. in fact you will probably see it decrease as users might find alternatives. It's the nature of cross platform support beast.

I do however have suggestions..
*You could opensource your Linux port if the 2% Loss revenue from that platform isn't big hit to the old wallet.. this would allow community patches and improvements (and possible forks)

*You can migrate to use a different GUI implementation that would support compiling across multiple platforms... Such as QT.. Or Java using the lovely Scene2D..

*Make your paid version for Linux a CLI only and open source the GUI.

These are all just suggestions because as a Linux user it's depressing to hear how small the Linux market shares are.. it won't attract attention when allot of the times commercial software versions and features are lacking in comparison to the other operating system versions. Just my 2cents Thanks andreasloew!

Just my two cents on the linux "issue". I think with Valve making steam available on linux it will quickly become more interesting for everybody. We've already seen nvidia giving far better support for linux after this happened. It will take time, but linux will certainly become more interesting in the future.