Nick escribió

you just need to click the [ Install Trial ] button. No need to select device or anything.

Done. Works now, and it's updated. Thanks

Nick escribió

Its good to know anything that can improve the situation. Unfortunately, Spritato is developed based on the UWP (Universal Windows Platform) SDK, which means it is tied to the Microsoft Store. The work to detach it from MS Store could be huge. :tear: I am contacting their staff asking about the update issue and still waiting for their response. I hope this is just something that I did wrong causing the update to fail as this is the first time I made and published an UWP app. I do agree that the experience of using MS Store is not very good.

I see. Well, who knows, maybe MS it's just a necessary early testing step towards better places.

As for the installation process:

• I've right-clicked on Spritato icon in Start menu and clicked "uninstall" (not the standard "add/remove" procedure, but still);
• install on my devices > selected my PC > Install now > Thank you! We’re attempting to install on your selected device(s) > clicked "OK" > nothing happens;

Typed "Spritato" in windows start (like i usually did to find the app), but this time I've found nothing.

Nick escribió

Version 1.0.26 is live with the text color and export dialog issues fixed.

Great news, congrats!

As for updating Spritato: I know this is probably not gonna fall in the "constructive critique" ballpark, but I gotta tell you this: do yourself a favor and dump MS store.

Seriously, I guess even itch.io would be a better place to share your gem with the world. Because:

• Yes, I can confirm that I couldn't update to 1.0.26;
• and no, I couldn't install Spritato anymore after uninstalling it;

Not sure this is due to the "free trial" nature of my version, but the way MS store deals with the whole installing process is "shady", to say the least: no progress bar, no "done installing" prompt, nothing.
You just have to assume that it's done installing the app and search it on your computer, as it doesn't even bother creating a shortcut or something...

Nick escribió

You can open the setting dialog (via menu or just press F3) and turn off "Skip loading layers with [ignore] tag". It is on by default to increase performance.

Awesome, thanks!
And speaking of performance, I forgot to mention: exporting 92 files took this little monster under 0.8 secs... I've never seen anything like that, congrats

Nick escribió

This is the 1st time I saw this happen. I wonder it is related the color theme of the windows OS. Is your windows running in light mode? I am using dark mode all the time so this could be related. Anyway, I am going to fix color in the next version.

Hm, not sure it's related. Both "windows mode" and "default app mode" were set on "Light", tho.

Gonna download the update, thanks for now!

Nate escribió

Ah, that's a bummer. Photoshop is pretty bad in many ways.

Statement of the year: I've been drawing for over 30 years, now (yes, I'm that old ) and I do believe that using Photoshop for drawing purposes (let alone animating) should be considered a crime

As for Spritato. I gave it a try and I thought about sharing some feedback:

1. 1. The software automatically hides folders with the [ignore] tag, so you need to make sure your source file has none before opening it into Spritato;

   2. For the love of me, I couldn't get the "origin setup" feature to work. I can visualize the custom origin on the canvas, but it always exports at 0,0 (default);

   3. GUI makes impossible to edit path once set. So if for whichever reason you need to change it, there's no other way but to restart Spritato;

   

   4. Black font on a Dark theme is... Please don't :tear: (and is there a way to change it, anyway);

That's it for now. As a Clip Studio Paint user, I've always wished upon a working exporting tool (sparing me the "convert to psd>export to spine" chore), so I really root for Spritato!

Erika escribió

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!

Erika escribió

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 escribió

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 escribió

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!

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 escribió

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

ok, thanks

Me: "Don't export images again, just write me a JSON"! 8)
PhotoshopToSpine:

Me: wha :derp:

Nate escribió

Gah, sorry my reading comprehension has failed me. I see you are using a folder tag with a skin tag in it. It's not a bug, it's just the way the script works that the skin folder is at the root. I think your proposal makes sense, so we've made the changes in script v5.2. As always, you can get the latest here: http://esotericsoftware.com/spine-scripts/PhotoshopToSpine.jsx

Sorry for the super late reply to your late reply, Nate :lol:

We basically edited line 281 of the script as follows:

var placeholderName = layer.attachmentName, attachmentName = placeholderName, attachmentPath = layer.attachmentPath;
if (skinName != "default") {
    attachmentName = attachmentName;
    attachmentPath = attachmentPath;
}

So all you need to do is using double tags like this:

and the script will no longer consider any skin folder as the root by default, but will follow a user-defined/tag-based structure.

I will update Script version then, and check what you guys did

Thanks for investigating this, and until next time!

I wanted to create a [folder] skins as main dir and [skin] dryad as subdir.
Script inverted names for whatever reason, and exported [folder] dryad as main dir, and [skin] skins as subdir.
If this is not a bug, i don't know what else is...

EDIT:
Nevermind.
We've managed to edit the script and that bug is gone. Thanks anyway.

As per title,

in order to have a clean and easy to navigate folder structure (I'm kinda obsessed with it, sorry :lol, I've arranged photoshop folders as follows:

however, it so happens that the exported folder structure looks like this:

So basically the script it's sort of inverting the nested structure, as if it was "[folder] dryad" and "[skin] skins".

Not sure this is a known bug or anything like that?

Thanks!

Thanks Nate.

However, there is a problem. Skeleton JSON expects the attachment to be found in:

"{ "name": "wing_lx", "bone": "wing_lx", "attachment": "doll/wings/wing_single_lx" },

while in atlas, the attachment path looks like this:

wings/wing_single_lx
  rotate: true
  xy: 1422, 1286
  size: 354, 758
  orig: 354, 758
  offset: 0, 0
  index: -1

So atlas basically excludes the "doll" folder from the file path.
I suspect it's due to the file structure used during spine import?
I've been using the "Texture Packer" option to export both the skeleton and the outfit for testing.

Thanks

Thanks, Søren.
Yes, that's how I "update" my skeleton, and there probably was a misunderstanding with my coder: sorry about that.

One last question, if you don't mind: what about the Atlas?
Can you imagine exporting an atlas including the main character and +99 outfits? I mean, is there any way to break the atlas into smaller parts? Or is that irrelevant, anyway?

Thanks again!