Spriter/C2 - (9-16-2019 - bug fix)

From the Asset Store
16 Direction Capx
$3 USD
40% off
Rotate & Animation for 16 Direction & Mouse Direction
  • TheRealDannyyy is there anyway you can use the Override Object Animation action to tell each sprite where to be while in ragdoll mode?

  • TheRealDannyyy is there anyway you can use the Override Object Animation action to tell each sprite where to be while in ragdoll mode?

    I guess it would be possible with the use of heavy maths and a lot of events which could easily bloat the memory use.

    Sorry, I get the use of the action in general but I think that would be a little too advanced for me to handle compared to my current method.

    My current way is to create a family with all sprite parts and give them the "chipmunk physics" behavior which has a more advanced pivot joint feature.

    Could you perhaps create a small example so that I could get a better understanding?

    I'd appreciate the effort and thanks for the quick response.

  • "chipmunk physics" behavior?

  • "chipmunk physics" behavior?

    It's a fancy name for a more advanced physics behavior inside C2. (HERE)

    HERE is an old topic of mine about that, it includes a basic unfinished but working example of my method.

    So, I'd like to ask again if you guys would consider adding a feature like that or should I keep on going with my currently old Spriter importing + ragdolling methods?

    It just feels like we've talked more about a workaround than my actual request, which isn't wrong of course.

  • > "chipmunk physics" behavior?

    >

    It's a fancy name for a more advanced physics behavior inside C2. (HERE)

    HERE is an old topic of mine about that, it includes a basic unfinished but working example of my method.

    So, I'd like to ask again if you guys would consider adding a feature like that or should I keep on going with my currently old Spriter importing + ragdolling methods?

    It just feels like we've talked more about a workaround than my actual request, which isn't wrong of course.

    Why do you just divide the objects that you want the physics on into separate parts and scmls to be inserted into C2 and combined them back with behaviors, instead in a singular scml?

    That way, your old methods still work without too much effort.

  • Why do you just divide the objects that you want the physics on into separate parts and scmls to be inserted into C2 and combined them back with behaviors, instead in a singular scml?

    That way, your old methods still work without too much effort.

    I think I don't understand you quite well, you want me to import ~12 different spriter parts and connect them with each other?

    How would the spriter animations still work if I use different scml files anyway?

  • >

    > Why do you just divide the objects that you want the physics on into separate parts and scmls to be inserted into C2 and combined them back with behaviors, instead in a singular scml?

    > That way, your old methods still work without too much effort.

    >

    I think I don't understand you quite well, you want me to import ~12 different spriter parts and connect them with each other?

    How would the spriter animations still work if I use different scml files anyway?

    That's the best way to go with it if you want results quickly and work on other features instead of waiting for something that might take weeks to months to materialize.

    Yes, you have to rebuilt all the animations for each part in new scmls for separate parts. Easier than imagined since you already have all the important details in your original scml. Tedious but doable in several days.

  • That's the best way to go with it if you want results quickly and work on other features instead of waiting for something that might take weeks to months to materialize. Yes, you have to rebuilt all the animations for each part in new scmls for separate parts. Easier than imagined since you already have all the important details in your original scml. Tedious but doable in several days.

    I've never said that I want this feature in a few days, infact it can even take up to a year if it has to.

    So far the workarounds are mostly more difficult or tedious than my actual method, which leads me to believe that there is no "better" way to approach this.

    Anyway, thanks for the idea Sethmaster.

    I really hope that Brashmoney will revolutionize 2D Construct games a little further on this end, I don't see any negative aspect about this TBH.

    It's already a standard feature that comes with the most 3D game engines, so why not make it a standard with 2D engines as well?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • TheRealDannyyy - yeah, it's a bit outside the scope of Spriter to handle physics and and collisions. I think the best alternative would be to create the joints based on the Spriter bone positions. I don't have time to look in depth into chipmunk physics at the moment, but one thing I've considered adding and might be able to add (probably not too soon) is a hierarchical 'for each bone' condition that would loop through the base bones, and then each of their children, etc, and corresponding expressions to give you the 'current child bone'/'current parent bone' type info. Would that be helpful?

  • TheRealDannyyy - yeah, it's a bit outside the scope of Spriter to handle physics and and collisions. I think the best alternative would be to create the joints based on the Spriter bone positions. I don't have time to look in depth into chipmunk physics at the moment, but one thing I've considered adding and might be able to add (probably not too soon) is a hierarchical 'for each bone' condition that would loop through the base bones, and then each of their children, etc, and corresponding expressions to give you the 'current child bone'/'current parent bone' type info. Would that be helpful?

    It's hard to tell right now, it might help but I think I will just keep on going with the current method and unfortunately skip the use of the new spritesheet function.

    However if there are any news about this in the future, I'd appreciate a tag.

  • new version

    11/2/2016

    • Fixed a bug where default pivot points weren't working with the new self-drawing/performance mode
  • Hi lucid, I can't seem to fix my pivot point problem. I just downloaded the newest scml plugin, updated the plugin files in the Construct plugins scml folder, but the sprites of my character are still weirdly rotated.

    I did try again, downloaded the plugin, reinstalled, and saved my Spriter scml/scon files including a new spritesheet png. But this didn't help.

    Running Spriter release 9, the lastest Construct version and the plugin in dates from 11/2 in the Construct folder. Not sure what's happening here

  • robin Sommer - could you send me your zipped Spriter project to ?

  • lucid Sure! I've send you an email with all the files! Thanks again for you time

  • Hi everyone. I am currently using the old spriter plugin and would love to upgrade it to the new plugin version with "performance mode". I haven't done too many characters yet and I could easily delete the old ones and replace them. However, I have a big issue, the main character. A lot of logic has been implemented involving his movement pattern in connection with animation-triggers. is it possible to update the previous scml-object of my main character to the new scml in performance mode? if so, what would be the best way to do this?

    All help is greatly appreciated.

Jump to:
Active Users
There are 2 visitors browsing this topic (0 users and 2 guests)