Hazard

What exactly is the purpose of SkeletonData.defaultSkin? My guess would have been that defaultSkin is just the skin a Skeleton starts with when created.

Yet that is not how it works in the runtime at the moment. For example in Skeleton.getAttachment the defaultSkin always has precedence over the skin, making it impossible to switch the skin as long as defaultSkin is set.

My suggestion would be to remove the defaultSkin reference from Skeleton.getAttachment entirely and instead set skin=data.defaultskin in the Skeleton constructor. This would also prevent Skeleton.skin from being null when the defaultSkin is used.

Or does defaultSkin have a different purpose that i'm just not seeing at the moment?
Hazard

Kickstarter Backer
  • Messaggi: 7

Nate

In the editor, there are two ways to attach an image. You can just attach them to slots, or you can attach them to skin attachments. If attached to a skin attachment, when exported the attachment goes in the skin. If just attached to a slot, when exported where does it go? If it went in the skin, then it would have to go in all the skins. So instead it gets put in a "default" skin. The idea is that the runtimes check the skin for an attachment (if set), then if not found check the default skin (if set).

Thinking through it all again, this may not have been the best idea for the runtimes. It'd be better to have only one active skin to check. At load time the default skin could be copied and use as a base to load the skin attachments in. The default skin would appear in the skin list as it does now, but wouldn't be stored specially in a field.

What do you guys think?
Avatar utente
Nate

Nate
  • Messaggi: 12126

Hazard

Ah okay, so i was indeed misinterpreting the purpose of defaultSkin. Thanks for the explanation.

But wouldn't it still be better to give the current Skin the precedence over defaultSkin? It seems more practical to me to have defaultSkin as a fallback instead of an override. For example having a guy in underpants as the default skin and then several clothing skins. The clothing skin would be applied wherever SkinAttachments are available for it and other slots (like the face for example) would fall back to the defaultSkin.
Right now, however, Skeleton.getAttachment checks defaultSkin first, thus allowing a skin change only for slots that aren't set in defaultSkin.

I guess i would actually vote for not merging the Skins with defaultSkin during loading. Having a base that applies to all skins can be handy at runtime. I'd just suggest to give the current Skin precedence over the defaultSkin. I'm doing the change in my implementation of the runtime anyway, but my guess is that this behavior is more intuitive for most people.
Hazard

Kickstarter Backer
  • Messaggi: 7

Cuellarjmcg

+1 for this. defaultSkin should just be used as a base, and then other Skins should have precedence over it. I think Hazard gives the perfect example for this.
Cuellarjmcg

Kickstarter Backer
  • Messaggi: 92

Nate

That is how it works. You never said what runtime you use. Please link to the source on github where the skin is checked before the default skin.
Avatar utente
Nate

Nate
  • Messaggi: 12126

Hazard

I'm using a C# runtime derived from the libgdx one. But all current runtimes check defaultSkin first.

Here are the files:
- C++
- libgdx
- Corona

Look for the getAttachment method. All runtimes check defaultSkin first, effectively overriding the attachment provided by the current Skin.
Hazard

Kickstarter Backer
  • Messaggi: 7

Nate

Ah, I see. 8) In the editor there will never be a skin attachment with the same name as an attachment from the default skin, so the order of the checks will only matter if skins are being created programmatically. I don't mind changing the order though.
Avatar utente
Nate

Nate
  • Messaggi: 12126

Hazard

The naming conflict can happen quickly by programatically setting defaultSkin to one of the Skins included in the Skeleton. That's how all the confusion started for me, as suddenly skin switching wasn't possible anymore. The changed order will fix that issue. Thanks, Nate!
Hazard

Kickstarter Backer
  • Messaggi: 7

Nate

Right, though setting the default skin to one of the other skins doesn't make much sense. :)

Added an item:
https://trello.com/card/attachment-look ... c0059d9/57
Avatar utente
Nate

Nate
  • Messaggi: 12126


Torna a Editor