@BenCreating

Thanks :) I think, that the code will be released in February, so stay tuned :)

@bluecarrot16

Many thanks for your constructive feedback.

"Walk" animation should start on the second frame in the series; the first frame is just the character standing idle. Adding it to the walk cycle makes their legs splay out and looks unnatural.

Oh, yes. I will cut out the first frame and use the idle frame as a seperate animation (would love to use the new idle animation, but there are no compatible spritesheets for clothes, hair, etc. yet)

When you first select an object, the first few animation frames flicker

Are you using firefox? I've noticed the problem too, but only in Firefox. At the moment I can't figure out what the problem is, but I'll investigate and see if I can fix it or build a workaround.

To that end, it takes a few seconds to render the new animation(s) when you add/change a layer. Any optimizations to that would be welcome

Optimization is already in progress :)

"Whip" animation uses the wrong frame size, should be 192x192px

Will be fixed. It's a stupid bug :/

It would be helpful to preview the animation in all directions at once like in the other generator

I have to see how best to do this, as there is little space because of the zoom. But I'm sure I'll find a solution to implement it.

For that matter, I think it would be helpful to see all animations in all directions at once

Did you mean the spritesheets or the animated preview?

I would like to see a preview of the item in the drop-down (I know this would require using something more complicated than an HTML <select> element)

I think that would be great too, but I still have to find a way to implement it in a resource-saving way without loading a preview file for each item individually.

The whole "torso", "torso 2" thing is kind of non-intuitive to me. I understand you probably did it this way so that mutually-exclusive items can be in a single dropdown, but it's not obvious to the user that they should look in "torso" for plate armor but in "torso 2" for jackets. Likewise, I would suggest at least one more torso layer, since you could easily imagine a character with a longsleeve shirt, vest, and jacket. I would also move the armor and vest(s) to "torso 2" and make the jackets and tabard "torso 3." Alternatively, you could label the layers something intuitive like "shirt," "overshirt/armor," "jacket/tabard," etc. 

Same suggestion for "head coverings;" make bandana, hijab, etc. their own layer.

This is already on the todo list. I haven't had time to sort them properly yet. but it will be done :)

Consider breaking some of the items within layers into groups. For example, separate the pirate hats from helmets. Even just using <optgroup> within the same <select> would be helpful as right now it's kind of a jumble, especially for categories like hat or hair with lots of assets.

This is already on the to-do list, too and will be done.

Allow downloading a file without naming it

Yeah, will be implemented.

When an object has multiple "palettes" (e.g. the bicorne athwart admiral cockade hat you mentioned), make a tooltip over each palette

Will be impemented.

Search function for assets (i.e. search box at the very top where I can type "bow" and see it in the appropriate tab of the UI)

I'll have to see how best to do that, but I've put it on the to-do list

Mobile support? (on my iPhone 13, the left and right panels almost entirely cover the preview).

A mobile version is not planned for now. At the moment I also have no idea what the mobile view could look like :)

What method did you use to squash the colors?

That was a mixture of manual and scripted. I have created a python script which writes all used colors into a json file like:

{
   "(0, 0, 0, 0)": [0, 0, 0, 0],
   "(153, 66, 60, 255)": [153, 66, 60, 255],
   "(204, 134, 101, 255)": [204, 134, 101, 255],
   "(228, 164, 124, 255)": [228, 164, 124, 255],
   "(249, 213, 186, 255)": [249, 213, 186, 255],
   "(250, 236, 231, 255)": [250, 236, 231, 255],
   "(39, 25, 32, 255)": [39, 25, 32, 255]
}

Than I've set the colormapping and recolored the spritesheet.

{
   "(0, 0, 0, 0)": [0, 0, 0, 0],
   "(153, 66, 60, 255)": [255, 0, 4, 255],
   "(204, 134, 101, 255)": [255, 0, 3, 255],
   "(228, 164, 124, 255)": [255, 0, 2, 255],
   "(249, 213, 186, 255)": [255, 0, 1, 255],
   "(250, 236, 231, 255)": [255, 0, 0, 255],
   "(39, 25, 32, 255)": [255, 0, 5, 255]
}

What is going on with the colors of the sprites? In the repo you linked https://github.com/vitruvianstudio/spritesheets/blob/main/clothes/torso/longsleeve/male/walk.png everything shows up as a red blob. If I open in GIMP etc. I can see they are slightly different colors of red but I don't exactly understand what's going on. I'm sure this makes your recoloring code more convenient somehow. I humbly would suggest that it will be much more convenient for contributors and users if the sprites in the repo appeared in some default palette, either as indexed or ideally plain RGB PNGs. Much lower friction to adding and editing sprites. I say this as someone who has spent probably more time than anyone adding and modifying sprites in the current generator. 

This results from the method mentioned above, but you can consider it a transitional solution. I only did it this way so that I can better see which colors I have mapped and which I have not. The colors are divided as follows:

[255, 0, 0]

The first part is only a indicator and doesn't have any function.

The second part represents the material. 0 for the first, 1 for the second, etc.

The third part represents the index of the color in the palette. 0 (lightest) to 5 (darkest).

Since it is still a proof-of-concept I left it like this, but it will not stay like this. In the data.json for each item I have already set default colors (still have to check if they are all set well). As soon as the beta version is finished I will color all spritesheets with the defined default colors. That means, if someone wants to contribute new items only has to specify in the data.json which colors were used for the spritesheets (the colors must (currently) come from the color palette of Eliza).

I notice in some sprites, like the "Wizard" hat or the "hood" that there are red spots which don't get recolored when you change palette. I presume this is because these assets had too many colors and you couldn't automatically squash them (or, in the case of the wizard hat, you haven't extracted a separate color palette for the stars), is that right?

Yes, for the "Wizard" hat I forgot to define the material for the stars, so currently there is only one material defined, but the spritesheet itself uses two materials.

The hood is an other problem (also noticed only on Firefox). These spritesheets have very extensive colors with a lot of transparency. Firefox seems to have some problems with transparency. But I will try to fix that.

Did you use a script to transfer the metadata and attribution from Sander's generator? If so, will that process allow you to port updates relatively easily? I ask because I am in the midst of making several such updates ;-)

No, I transfered them manually :/ But I think a script should be possible (with perhaps a little reworking).

I hope I haven't forgotten anything :)

Best regards
napsio