There have been a few detours into tiles that have slowed this project down a bit.  If you aren't up to speed I won't be adding new animations until after the source aseprite gets a release.  The source is, well its pretty elaborate.  Everything is broken up into anatomical layers not just visual layers - it allows you to mix animations in various ways and I've been building this from the outset to require less skill and effort for developers to create flexible assets.  I already have a set of scripts I use to manage a lot of these things, but for a public release it would need documentation and reliability

Below the line is just an explanation of the approaches I've attempted.  But here's the upshot - the goal has moved from scripts to an extension.  I think I've come up with a system for managing costumes and their components which is automated and sensible.  I discovered normal maps are easy to generate with the redundant palette set up I've been using.

With the source and extension released I'll also be outputting several character and color variants for those who aren't using aseprite.  Whether this is released on this project page or I start a new one is an open question.

Finally,  I'd like to try out a funding model that will keep my assets free but still compensate me for my effort an direct my energy towards serving developers.

If you've never heard of a bounty system it's a way to encourage work on open-source projects.  Basically people will be bidding for what I'm working on as I'm working on the rest of the Gumdrop ecosystem.  Like a commission in a way, but the work gets shared with the public when its complete.  I don't know if I've generated enough interest to get that going but it's worth a shot and hopefully the source + extension + character examples will prove the value of the project to a wider audience.

That's the important bits

Everything below here is about the journey so far.  

The  aseprite file has to be used in a particular way to get results.

An element of a costume may have three layers in just one orientation.

The sprite exporter doesn't separate layers + tags into unique animations making it harder to import into an engine.

Managing colors for all the layers was pretty tedious and easy to mix up.

Colors are now arranged in what I'd call a descriptive palette.  Everything is redundant such that you can swap out indexes X through Y and change the blue on the hood but the same blue on the shoes is left in tact.  So palettes are more of a complete color scheme, easy to set up and save, but maintaining that system might be taxing on other users.

First solution was a script that generated a version of each action for each folder resulting in the naming conventions you see now AttackSouth etc.  This required a bit of prep and it was easy to miss a layer or two when going about this.

I've posted multiple images of the layer management system I came up with.  It used empty layers with user data to describe everythign in a costume.  Then you manipulate which set you're using with a dialog box from a script.  This is still great for me but usability for everyone else I'm not sure about.

I then discovered by splitting both layers and tags on the default sprite exporter that I could get the same arrangement as with all the variations of ActionOrientation - so I wrote a script to rearrange the .JSON output.  It saves one step but creates another - a dialog box will ask you to locate the .json you just exported so it can be rewritten.  It's a kludge, but the API isn't very well documented.

The latest addition was an interface to manage clothing elements instead of whole costumes.  This relies on using specific naming conventions so layers are always grouped logically.  It works well - but kind of points out how few costumes have complete animation sets at the moment.

Finally I ran across something on the aseprite discord.  A request for layers to have tags of their own.  That's the solution I was waiting for.  We manage the layers and costumes with hash tags in the layer's user data.  The scripts get integrated into an extension which should manage costume elements and allow them to be saved by having the script add custom hash tags to all the involved layers.  So the main obstacle now is learning how to turn the scripts into a proper aseprite extension.

A lucky side effect of the color scheming is a pretty streamlined process for generating normal maps and I should be able to release them with variants again.