• Editor

  • defaultSkin has precedence over skin?

    английский

  • Hazard

    • Сообщение #1
    • Это сообщение на английский

    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?

    Related Discussions
    ...

    • Hazard

      • Сообщение #2
      • Изменено
      • Это сообщение на английский

      • Nate

      • Сообщение #3
      • Это сообщение на английский

      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?

      • Hazard

        • Сообщение #4
        • Это сообщение на английский

        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.

        • CCuellarjmcg

          • Сообщение #5
          • Это сообщение на английский

          +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.

          • Nate

          • Сообщение #6
          • Это сообщение на английский

          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.

          • Hazard

            • Сообщение #7
            • Это сообщение на английский

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

            Here are the files:

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

            • Nate

            • Сообщение #8
            • Это сообщение на английский

            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.

            • Hazard

              • Сообщение #9
              • Это сообщение на английский

              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!