Erika escreveu

1. this happens generally when one has more than one attachment in the same slot, I am unsure if this is your case though.

Yes, that's case. But still, other slots having multiple attachments managed to display the correct one;

2. Are you choosing "ignore" existing attachments when importing? because it may be the case. Also what version of Spine are you using?

Nope. I mentioned using "replace", and the version is 4.0.18 PRO.

Will send files at contact@esotericsoftware.com.

Thanks

Hello Erika,

as for the first problem, yes, it's related to some slots (including hair_front).
the others are:
-yb
-hair_side_top
-pupil_l
-iris_l
-mouth
-facepaint
-hair_side_bottom
-hair_main_back

As for skins: why would i want to use skins instead of folders, when it's just those slots being problematic? eyelash_r and eyelash_l slots work just fine, despite featuring multiple attachments.

As for the "keys deletion" I'm gonna send you a spine file with a key for the "eyelash_pain_l" attachment setting it as visible on frame 0 of the "tripping" animation. The key will be deleted as soon as you import the PTS .json file via "import into existing skeleton/replace" and select the chibi.json.

Thanks

EDIT:

figured out the "hidden attachments" issue: pretty sure it's a flaw in the script.
We're not Java experts, but it seems like the script checks for visible layers from the top of the folder list and, for some reason, it validates as visibile/not visible only the layer at the bottom of the list.

So the attachment you want Spine to display as default should be sorted as follows:

While if you place it anywhere else but at the bottom, then said attachment it's not gonna be set as default:

Erika escreveu

As for what attachment is visible, I could reproduce what you are experiencing. So as a workaround one can simply place the layer they want to be active at the bottom of the list for now. I've opened an issue here to see if this may be fixed:
https://github.com/EsotericSoftware/spine-editor/issues/600

Yes, we have figured as much (check the EDIT of my previous post ).

Erika escreveu

As you have greatly different hairstyles in the same slot that seem to be meant for skins, skins seem the logical option, and there's the very convenient [skin] tag that creates both a folder and skin with skin placeholders and everything necessary automatically. Of course you are free to also create them manually in Spine, but this would simply be less time-consuming.
Skins - Spine User Guide
If you intend to use this skeleton for different characters, I highly suggest you look at how skins can help you simplify this. If you are just goign to animate a change from one hairstyle to another, then I agree skins are not needed, but you'll need to duplicate animations if you want to have a walk animation with a hairstyle, and then another, you'll be forced to duplicate the walk and key the other attachments, which would be not needed with skins.

Yes, the animations should suit procedurally generated characters, hence the hairstyles were initially planned as random as well. So yeah, I think arranging presets for them (aka skins) it's a way better solution than creating as many copies of the same animation for as many hairstyles we plan to have.
OT question (but not really OT): what do you think about eyes? Since their structure is rather complex, wouldn't be better to arrange different expressions into skins or events? As of now we're handling stuff like blinking via code, but I wonder what's the most consistent way to arrange them in Spine.

Erika escreveu

As you are choosing to replace the data already present in your skeleton with the new one you are importing, you are choosing to delete this information. This will also delete any mesh information you may have created to replace the art with the information in the json. As that json only contains the information generated by the Photoshop to Spine script, the keys get deleted.

Still doesn't explain why only certain keys got deleted. I'm importing the very same Json (not a "new one") and I guess the information it contains should affect all of the keys, not just some?

At any rate, thanks for your help!

Erika escreveu

I'm unsure what you mean by "all the keys", but in theory, the keys that get replaced may be the ones that mark an attachment as active or inactive, and direct deformation of a mesh attachment.

I mean this:
https://streamable.com/5m208u
psd was wrapped with the "layer at the bottom" workaround in mind (and nothing was changed in the meantime).

Thanks for all your help, anyway!