Hi there,

I've duplicated a skeleton to compare how it looks, side by side, with different skin constraints applied... and the second skeleton doesn't include those constraints in the skins.

Steps followed
1.- Open project
2.- Select Male_Side skeleton
3.- Click Duplicate

Expected behavior
Skins constraints are included inside the skins containing them in the original skeleton:

Actual behavior
The same skins don't contain the constraints:

Nevertheless, the constraints "think" they're in those skins:

The same behavior occurs when importing the skeleton from the project file.

I've never noticed this specific case before, but I think it must have something to do with another issue I couldn't reproduce at the time, and I told you guys to forget about until I could...:

Skin constraints/bones not enabled after skin change

This is not exactly the same, but it's very similar in the sense that constraints are not actually in the skins reporting their membership.

I'd be willing to sent you my project by email, if you need.

Also, the log file doesn't tell anything other than the common "Automatic backup complete" lines.

Thank you.

Done, and thanks!

Nate wrote

Thanks for the project files. There were a number of problems in Spine with duplicating a skeleton:
1) Skin constraints were not duplicated correctly.
2) The applied skins in the duplicate skeleton were in the wrong order.
3) Linked meshes sometimes appeared in the wrong skin in the duplicate (yikes!).

Yeah, "something" was clearly wrong.

My project, as you could see, makes heavy use of skin contraints, and problems started to appear long ago. I couldn't put my finger on what they were, and that's why I only could offer you a repro method for this dupe issue.

But if I'm to be honest, I'm not sure the description of what you guys have covered in those three points will address all of the glitches I've seen, lol. I speak about skin constraints being listed in other skins, but not really "present", when duplicating skins in the same skeleton.

Maybe it's fixed, as a secondary effect of solving the other ones. I'll need to see it. :p

Nate wrote

We've fixed all of these in 4.0.09-beta. Please note we don't plan to do more 3.8 releases.

Wait, what? :o

Nate wrote

Have you tried v4 yet? I know you have brought up a number of issues and we keep saying it's all better in v4, so it would be great to hear how it goes for you.

Yeah well... but that's the thing: v4 is in beta stage, and 3.8.99, apart from these hiccups is very stable and my project is huge. I can't take that risk.

My "business" model is through monthly subscription on SubscribeStar (crowdfunding) and I can't afford getting stuck for days if I find myself in a technical impasse.

But regardless of my personal case I don't think that decision of declaring the current production version 3.8 as defunct and unsupported is a wise move. You're basically forcing everyone commiting to an untested platorm without any overlap with the current stable version.

Yes, I had several issues related to memory in recent versions, but you fixed them in 3.8.9x and that was great, but also kind of taken for granted. Sorry if I sound like an entitled bitch lol, but I mean, version overlapping is standard practice.

Unity, for example, has its LTS (Long Term Support) program:
"These updates will only cover usability fixes aimed at improving the stability of the product to enable users to ship their projects."

In short, they're adding new features to Unity 2020, along with new bugs, but making sure 2019 remains stable and supported until people feels confident about 2020 and its brand new shiny features.

But if you don't support 3.8, then you're basically leaving us no options other than getting stuck in time or doing a leap of faith.

Anyway, I'll stop the ranting about this. I just hope you give a second consideration to that decision.

Nate wrote

Your project is quite large and using clipping attachments can be very expensive. Are you testing that performance at runtime remains acceptable as you continue to add to your project? I highly suggest doing this periodically to identify any potential performance problems as early as possible.

I added that clipping with some fears, as an experiment. I'll probably remove it if I see a 5 year old computer can't handle the game. Thank you for the heads up.

Nate wrote

Another concern is that many of your attachments have warning symbols. For meshes this means that the mesh has weights from bones which may not be active. For example, that could happen if the bones are in a skin, but not in the same skin as the mesh. It could also happen if the bones are in a skin but the mesh is not in any skin.

Yes, this is intended. It's meant to avoid a ridiculous number of skin combinations and make management of these models a possible task for a human brain. :p

To illustrate it, in the female model you can see there are...:

1.- BreastsType (4 skins): contain transform and path constraints related to the "shape" of the breasts.

2.- CupSize (5 per type = 20 skins): contain transform constraints to make them smaller or bigger (it's not enough just scaling).

3.- Breasts (4 breast types * 9 skintones * 3-4 tan effect = approx. 120+ skins): contains the images proper, with no constraints.

And that's not all, I also have numerous clothes, like shirts and bras that use the same meshes as the Breasts (duplicated, as they can't be linked yet). BUT could be affected by additional separate skins constraints to make the breasts more firm (because it's a bra, you know). I have many dozens of those as well...

Now imagine I needed to create a single skin, with all relevant bones and skin constraints for every possible combination... hell no. :shake:

So, as soon as I realized I could separate the image attachments from the constraints, I threw myself into it and thanked you guys for making it possible, even if you didn't designed the thing for this use case, lol. In fact, my game wouldn't be possible if I couldn't apply skin constraints "additively".

ALSO, with all the problems I was having (and I still have) when duplicating skins with constraints in them, of course I wanted to stay as clear as possible from needing to manage hundreds of skins that might have, or maybe not, the constraints Spine said they had.

Nate wrote

The ramification of the warning symbols is that some or all of the vertex transforms cannot be computed for the mesh when the bones it is weighted to are not active. When that happens the affected vertices will appear at 0,0 in world coordinates.

When in Spine, if you have unchecked Hide viewport skin bones then all the skin bones are active, even if their skin is not. This allows the vertices that would otherwise be placed at 0,0 to be placed correctly. You should not rely on this though, because at runtime only the bones that are active will be available, just like when Hide viewport skin bones is checked. You will see your mesh either not appear at all because all the vertices are at 0,0 or some of the mesh will be OK and the rest will be stretched to 0,0.

I don't use that option in Spine. I wasn't even aware it did that, so I'll be sure to avoid it even with more reason now, lol.

I'm aware of the stretching when not all elements are active, yes. It's to be expected and logical, and I'm careful about it because I'm using that system I've described above.

Nate wrote

I highly suggest fixing all the warning icons in your project before adding more attachments. It may be a lot of work, but your skeleton won't work correctly at runtime unless you do it. It is much easier to fix the warnings as they appear when making changes to the project rather than letting it get up to hundreds of warnings that need fixing.

Acually... it works, lol.

One of your colleages already saw my project and said the same about the warnings, but seriously it works well with additive skinning and it's a blast to have this kind of customization in an adult game.

Maybe I'm exploiting Spine capabilities far more than you thought as the normal use cases, but... I'm not a normal person. :rofl:

Look what you've done, now I look like a pretentious little bitch, haha!

Anyway, just reconsider the support for 3.8, please? I'm sure I'm not alone in this sentiment.

And thank you for your reply and your troubleshooting work.

Nate wrote

Continuing development on non-beta versions is very time consuming, even when only doing bug fixes.

Nate wrote

Unity is a multi-billion dollar company. We, unfortunately, are not.

Nate wrote

There are pros and cons to that, eg we listen to every individual customer, we have quick turnarounds on fixes, you get responses from the owner of the company on a Saturday afternoon, etc.

Yes, I actually agree with you but... I just needed to try. :lol:

But yeah, "comparisons are odious", you know.

To be honest, I'd be more than happy to jump on a subscription model with you guys. Those $300 I paid four years ago are waaaay amortized in terms of business utility and customer support. And I don't even understand how you are still alive as a company by now.

The thing is, you've made an amazing piece of software, and it has become the bread and butter for a lot of video game animators out there. But at the same time, there's a finite number of us in the World.

I don't have a clue of how many licenses you've sold, but there will be a day you could be a victim of your own success, when new users still buy the software because it's great, but not in enough numbers to justify, as you've appropriately pointed out, the owner of the company, along with his few staff, giving detailed responses in the forum.

I don't think a $100 yearly sub would be a deal-breaker for people that makes a living thanks to Spine, and it might make a huge difference for you guys.

Nate wrote

Abelius wrote

Now imagine I needed to create a single skin, with all relevant bones and skin constraints for every possible combination... hell no.

You would never do such a thing. Instead you would compose a skin from multiple other skins, which is equivalent to pinning skins in the Skins view:
Runtime Skins - Spine Runtimes Guide: Grouping attachments

One approach to simplifying a project like yours is to make each unique setup in Spine only once, then at runtime change the images as needed. Eg if you have blonde and brunette hair that use the same meshes, you only need to rig one of them, then at runtime you can swap the images to get the other. This way if you have 20 variations that are image changes, you have only the minimum needed in your skeleton's rigging, though you do need to manage changing the images at runtime.

This is interesting but it says "A skin can be created programmatically, then populated with the attachments from other skins". It says attachments, not images. And this...:

newSkin.addSkin(skeletonData.findSkin("pants/green");

...is exactly what I'm doing right now. This is part of my PlayMaker skin action:

What I've understood by your suggestion is that there is a way to create an attachmente at runtime and give it an image path? And then add that attachment to a new skin? I mean, creating a skin based on attachments that don't even exist in the skeleton hierarchy?

If that's the case I'd be interested in knowing how, yes. That way I could get rid of all "images only" skins like the hair, multiple skintones, etc.

Nate wrote

It can still work if you always make those things active by showing other skins, but it can be error prone because it's easy to forget to do so.

Don't underestimate my OCD powers, mortal. :mmm:

Nate wrote

In such a large project I think it's worthwhile to try to minimize the amount of rigging you do, as described above and here:
Runtime Skins - Spine Runtimes Guide: Creating attachments

Ah, now it is actually talking about "creating" an attachment. You actually meant about this up there, right?

The only problem is that it's only a paragraph with no definite instructions. I've tried to find it in the runtime docs, with no success. Could you point me in the right direction, please?

Nevertheless, there's one thing I like about using premade skins, which is that they represent an abstraction layer to avoid issues in Unity, if I need to change the names of the attachments or images.

Even though I'm also the "coder" for my game, I still like to have animation and logic as separate as possible, if that makes any sense.

Nate wrote

If you really want to help, then just make more than $500k USD/year and license Spine Enterprise yearly!

What a big problem to have, yes. :smirk:

Also, thanks for the follow up instructions. Now I wonder if that would be compatible with asset encryption...

This is turning offtopic already, but you may be excited to know that after some serious nagging, a plugin from the Asset Store is now capable of protecting exported files from Spine to Unity.

There's only some compile errors remaining, and for that the author of the plugin told me he'd contact you guys soon.

But it's working for me already and it's awesome. Asset rippers will cry, I'm sure. :p

Yes, I know what you mean. Look at Red Dead Redemption 2 on PC.

Anyways, I'm excited because I can finally close the door of my house when I leave. Just that makes a real difference.

Before this, ANYONE could dump all assets in a couple minutes with zero effort. Anyone.

Now it's only someone with skills and determination. Two qualities the typical lazy "creator" with the cheap excuses of "I like your game so much that I want to make a spin-off" or "you're not fast enough, so step aside", severely lack of.

So yeah, I'm happy, lol.