Jump to content

sonder

Members
  • Content Count

    19
  • Joined

  • Last visited

  1. That's what I'm doing though, creating keyframes. In fact I don't plan on using tweens at all, just keyframes. (Or if I do use tweens, I'd adjust every frame by hand.) Any time a parent of an IK locked bone is scaled, the IK locked bone is correct until you let go of the mouse button. It then snaps to a seemingly unpredictable angle where the end point's position isn't respected. It's consistent, though, so it must be some simple bug in the math.
  2. IK locking does not interact well with scaling. See these screenshots:
  3. This interface could be a little more usable.
  4. Custom curve dialog's titlebar is "Dialog" Selecting keyframes and trying to change all of their curve types at once still doesn't work as expected. Been waiting for this since B5.
  5. We're still on version 5, but I guess this applies to 5 or 6. We are debating if we should split our main character into several scml files since she needs to have tons of animations that change on each level. The issue with splitting is obvious when you consider that all the images need to be loaded again for each scml wasting VRAM - all the much worse since her body parts are pretty high definition. I could around this by making the engine load each file once, but it would require a bunch of work and could lead to complications down the line with conflicting images. I think that the right thing is to have a single scml file for the character. My partner (mprart) is concerned that Spriter 5 might barf if the scml file gets too complex, so I wanted to find out as much as I could to see if maybe is something that has been worked on in version 6 and maybe I should just update the Spriter support to version 6 instead of wasting time with the workaround. Or if 5 can handle it fine, if no one has had any issues with very complex files in Spriter 5.
  6. sonder

    B6.1 Bug Thread

    We're still on B5, but I've been noticing some issues with timelines and keys belonging to images that have been deleted remaining in the scml file. I was wondering if this has been fixed in B6+?
  7. [strikethru]Thanks Lucid, unfortunately that didn't work.[/strikethru] I know that characterinfo is being used on the "root" bone for sure - a debugging sessions showed that all the other bones have the -1.0 scaley propagated. I think it has to be a problem in the bone transformation stage but I'm not sure if it's a problem with my code or the psuedocode. This is some Forth code. I know it's unlikely, but see if you can make some sense of it. (mini cheatsheet: keywords and symbols are executed from left to right with no exception, ( ) just means a comment, ! means =, @ means "fetch value", and p is short for fixed-point) : unmapFromParent ( struct = spacialinfo ; parentinfo destinfo -- ) locals| dest parent | angle @ scale 2@ p* 0< if 360.0 swap - then parent >angle @ + dest >angle ! scale 2@ parent >scale 2@ 2p* dest >scale 2! ( a @ parent >a @ p* dest >a ! ) parent >px 2@ px 2@ or if px 2@ parent >scale 2@ 2p* parent >angle @ 2rotate 2+ then dest >px 2! pivot 2@ dest >pivot 2! ; I'd show you the bone transform code but it bears pretty much no resemblance to the pseudocode. edit: oh, oops! I was supposed to check the parent scale wasn't I. standby. edit2: OK this is what happened when i fixed that. ScaleY=1: https://www.dropbox.com/s/mmvutqlf1xbwi ... .13.04.png ScaleY=-1: https://www.dropbox.com/s/zjrq9zhuiat06 ... .13.06.png I'm starting to wonder if I'm supposed to be using ScaleY ... shouldn't ScaleX be the one? I only did that because the source animations are "rotated" and I can't even remember what my logic was there. edit3: Success. https://www.dropbox.com/s/3506il73pt613 ... .18.24.png Indeed I was supposed to be using ScaleX all along and your fix seems to have worked.
  8. Yeah, about the conditional parenting I believe that's what the code is doing, but I'll double check that. Strangely I think that vertical flipping (via scalex, so actually horizontal rotated) is working but not horizontal (via scaley). Maybe it could be an issue with unmapfromparent? You've tried flipping in both directions?
  9. So you can see what I'm talking about, here's unflipped https://www.dropbox.com/s/sn3v0rvvsoord ... .43.40.png and flipped (negative y scale ... it would be x but the model is animated "on its side" for reasons I don't really understand but the animator said this was best) https://www.dropbox.com/s/47eibgk81voud ... .43.09.png
  10. I suspect that the code in scmlreference does not support flipping because setting either scale parameter negative in characterinfo only flips each piece individually rather than the entire model. I'm just confirming if this is the case and looking for suggestions or possible workarounds. Or if I'm missing something. Edit: Anyway I don't think we want to flip the images, the shading (side-lit) gets flipped too which looks bad. What we need is a way to flip the bones...
  11. Can someone explain this function to me - what is its purpose and when should it be called?
  12. It would be great if we could put our own custom metadata in scml files manually and have it be preserved by the editor. Basically any "unsupported" xml data should be preserved by Spriter on load and save. This way for example we could put a "defaultspeed" attribute on animations that could be used by the game. Or manually create our own special timeline keys for triggering or manipulating whatever we need without editor support.
  13. We wanted to use a stop motion style of animation for our game and I think the only way to turn off tweening in the editor is to select Instant on keyframes one by one. It should be possible to not only make Instant the default but change the curve type of more than one keyframe at a time.
  14. There are more discrepancies, like when you say "for o in blah blah" in a part and then forget to refer to "o" And in other places I think you return the TimelineKey class when you should be using SpriteTimelineKey or SpatialTimelineKey, not sure. It's been a big heavy going for me unraveling how everything is supposed to work together. It's a pretty good doc though.
×
×
  • Create New...