Pak Protector Posted November 29, 2023 Report Posted November 29, 2023 (edited) I've been working for the past 3 or so weeks on getting a new SpriteKit implementation of Spriter working. I found that the old repo's floating around were partial at best, and didn't really seem to work. At this point I've got it working very nicely, except for one thing that I've found in one of the test Spriter projects I have access to. What I'm seeing is that in this one project, the 3rd frame has a single extra bone added. It does nothing and has no children. Spriter loads it fine and it doesn't affect anything within Spriter. This image shows the diffs between the original file (on the right) and a version of the file without the extra bone. In my framework though, the problem I have is that on the one frame that contains the extra bone, every bone after that is renumbered. My understanding was that the bone-ids would not change. So my objects, that get created for the first frame have references off to their parent bones, and because this is all happening within SpriteKit, the objects are real children of the bones, creating a true hierarchy like that seen in Spriter itself. When the frame with the extra bone is reached, that extra bone takes on the ID of one of the other bones and as a result, the bone that originally had that ID ends up with the bone properties of the new mystery bone. And then, every other bone gets the wrong properties because they too have essentially been renumbered. I thought that perhaps I could instead use the timelineID to identify the bones as these remain consistent, but there is no obvious way for an object to identify it's bone via a timelineID. Am I overthinking this? Edited November 29, 2023 by Pak Protector Added an image to illustrate the issue. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.