FCSW_Ben

Hi devs! I'm trying to drag slot attachments from one skeleton to another. The image region attachments are getting lost in the move.

This seems to happen when those image regions are within skin placeholders. Only the image region for the currently active skin will be moved, and all others are obliterated. If there is no skin selected from the source skeleton, no image regions are moved to the target skeleton at all.

I have close to a hundred of these to migrate. Either I'm doing this completely wrong, or you might have a bug in the editor. What do your elf eyes see?
У вас нет необходимых прав для просмотра вложений в этом сообщении.
We're making complex games almost entirely in Spine! Consider signing up for the closed alpha of our latest Project: https://www.exceptionullgames.com/knockout.html
Аватара пользователя
FCSW_Ben
  • Сообщения: 38

Nate

It's true, only the attachment for the current skin in the dragged from skeleton is moved to the current skin in the dropped on skeleton. To move attachments in other skins, the dropped on skeleton would need skins with the same name (else how would Spine know where to put each attachment?). We could do that, but it could make for some odd behavior.

For example, currently we move from current skin to current skin. If we change to moving all skin attachments to skins of the same name, do we not use the current skin at all for the move? What happens if some skins have the same name and some don't? Do we move attachments to the skins of the same name and lose the others? This could mean the current skin attachment doesn't get moved, but others do, which would be confusing -- I move a slot, and the current attachment is suddenly gone. What if none of the skins have the same name? Do we move none? Do we move only the current skin attachment, as we do now? If so, then sometimes we move attachments to skins of the same name, other times we move the current skin attachment.

Moving items across skeletons is surprisingly more complex than it seems at first. There are dependencies between items and in many cases there's not a great solution. For example, similar problems occur when moving a constraint or a constrained bone across skeletons.

---

Note if you have many attachments, it may make sense to use images in such a way that you can have only a single skin in Spine, then use a different set of images at runtime. For example, give your sword image enough whitespace so any sword image can fit in it (texture packing can strip whitespace, so there is not a performance hit or extra memory usage). Create one skin in Spine with that one image. At runtime, you make a copy of the sword attachment and change the image to any one of thousands of sword images you might have. This works because every sword image is the same size and the sword hilt is in the same place. You can do this with all your attachments, so you only have to rig in Spine one time, the rest is just a matter of using different images.

I see you only have two skins, so this may not apply as much to your project, but it can be helpful for many projects. A lot of people are doing customizable avatars with thousands of items and it doesn't make sense to manually place them all in Spine when that positional information can essentially be baked into the image. It's described in more detail here:
Runtime Skins - Spine Runtimes Guide: Creating attachments
Аватара пользователя
Nate

Nate
  • Сообщения: 9288

FCSW_Ben

That's all very true. And yeah, I guess I'm doing things a little out of spec. :P

It's ultimately a tradeoff of memory we can't afford to make on these devices, and specifying a size constraint on the art pipeline limits creative options down the line. Using the skin solution, even with its own limitations, remains our best tactic.

As far as making this feasible for other users, //IF// you were to consider it in the future, I'd design it to be very strict. It'd be safe to assume the kind of skeleton merging I'm doing would necessitate the target being perfectly set in stone. If I make a typo or addition out of line with that target, Spine yelling at me to straighten up would be welcomed and expected. If a Slot has multiple image regions each to its own skin placeholder, and they match, I would plead with you it's a worthy addition to the editor.

My current workaround was to import the new data twice: Once for the first skin, and again for the second skin, manually moving the region attachments into their proper places in the target skeleton's second skin. It's working pretty well.

Thank you for replying so quickly!
We're making complex games almost entirely in Spine! Consider signing up for the closed alpha of our latest Project: https://www.exceptionullgames.com/knockout.html
Аватара пользователя
FCSW_Ben
  • Сообщения: 38

Nate

You're right it can be a problem if you didn't leave enough whitespace in the images and later want, eg, a bigger sword. In that case the skin in Spine could have the original sword, and a second "large" sword with more whitespace. This adds a little complexity, because now for every sword you need to choose which base sword to copy. This would probably be done with a naming convention, eg a -large suffix. If you leave quite a lot of whitespace when you rig initially, you probably don't encounter this problem. It won't use any additional memory because the whitespace can be stripped from each image.

We have ideas for managing skin attachments and make some manipulation less tedious. We'll keep your use case in mind!
Аватара пользователя
Nate

Nate
  • Сообщения: 9288


Вернуться в Bugs