Experiences with Spine?
by Eero Karvonen · in Torque 2D Beginner · 05/20/2014 (9:49 am) · 36 replies
Hi,
I searched the forums and couldn't find any more than one Spine-related topic...
So, what kind of experiences have you had with Spine assets in T2D so far?
Does the T2D runtime already include all the pro features that are presented with green lights on on Spine's website? For instance, mesh-deformation capability?
In other words: is now the right time to go and buy the pro license?
Is the T2D 3.0 Spine Toy the only TS-bindings documentation on it at the moment?
I searched the forums and couldn't find any more than one Spine-related topic...
So, what kind of experiences have you had with Spine assets in T2D so far?
Does the T2D runtime already include all the pro features that are presented with green lights on on Spine's website? For instance, mesh-deformation capability?
In other words: is now the right time to go and buy the pro license?
Is the T2D 3.0 Spine Toy the only TS-bindings documentation on it at the moment?
#2
Does the licensing of Spine Runtimes imply that the community has to wait for Esoteric software to solely update the runtime for the official release?
My main concern is that I need to have movement animations and simultaneously be able to point the gun and head to any direction. Can this be easily done in your branch, Simon?
Or what about this: Using two skeletons for a character - one for the torso and one for the pelvis/legs. Then the torso could be animated for shooting at all the needed directions.
05/23/2014 (6:21 am)
In which file can I find SkeletonObject_Scriptbindings?Does the licensing of Spine Runtimes imply that the community has to wait for Esoteric software to solely update the runtime for the official release?
My main concern is that I need to have movement animations and simultaneously be able to point the gun and head to any direction. Can this be easily done in your branch, Simon?
Or what about this: Using two skeletons for a character - one for the torso and one for the pelvis/legs. Then the torso could be animated for shooting at all the needed directions.
#3
-
Spine and T2D are 100% separate entities. Esoteric Software is not actively working on updating the runtimes for T2D (as far as I know). As such, it falls back to the community to handle these changes.
-
To answer your question, the bone overrides in my branch prevent the specified bone from being animated by the ongoing animation. Override the head bone's rotation and the gun/arm bone's rotation and then set their angle to point at the target.
The two-skeletons option should work but that's exactly what Spine is meant to be used for; play a standard animation + a partial animation for the torso.
As mentioned previously, though, my branch comes with no support; pull it if you want but you are mostly on your own from there.
There are two reasons for this
1. The functions that I've added are not clean or even efficient. They serve my own purposes and are only made public so that others might use them as a starting point for their own projects if they want. Heck, I don't even remember how to use half the functions in there! :)
2. If you want to use Spine in a project, in 99% of the cases you will have to code a custom solution. My branch is simply a dump of my work code, not a solution to all Spine-related issues.
05/23/2014 (6:42 am)
You can find the Script functions and methods for Skeleton Objects in T2D/engine/source/2d/SkeletonObject_ScriptBinding.h-
Spine and T2D are 100% separate entities. Esoteric Software is not actively working on updating the runtimes for T2D (as far as I know). As such, it falls back to the community to handle these changes.
-
To answer your question, the bone overrides in my branch prevent the specified bone from being animated by the ongoing animation. Override the head bone's rotation and the gun/arm bone's rotation and then set their angle to point at the target.
The two-skeletons option should work but that's exactly what Spine is meant to be used for; play a standard animation + a partial animation for the torso.
As mentioned previously, though, my branch comes with no support; pull it if you want but you are mostly on your own from there.
There are two reasons for this
1. The functions that I've added are not clean or even efficient. They serve my own purposes and are only made public so that others might use them as a starting point for their own projects if they want. Heck, I don't even remember how to use half the functions in there! :)
2. If you want to use Spine in a project, in 99% of the cases you will have to code a custom solution. My branch is simply a dump of my work code, not a solution to all Spine-related issues.
#4
I examined the sources and now I'm basically familiar with the current capabilities related to this in the engine - and in your version of course, obscure or not. :)
Let's say, if you wanted to superimpose the Skeleton Objects on existing scene objects (without affecting the existing physics - only visual enhancement), in which direction would you go? Is there a way to disable ALL the physics for the skeleton and just glue it with a joint?
Setting the skeleton static and updating it's position on every update seems out of the question because the objects don't absolutely sync.
05/23/2014 (3:03 pm)
Ok, thank you for the clarifications!I examined the sources and now I'm basically familiar with the current capabilities related to this in the engine - and in your version of course, obscure or not. :)
Let's say, if you wanted to superimpose the Skeleton Objects on existing scene objects (without affecting the existing physics - only visual enhancement), in which direction would you go? Is there a way to disable ALL the physics for the skeleton and just glue it with a joint?
Setting the skeleton static and updating it's position on every update seems out of the question because the objects don't absolutely sync.
#5
You should try to set the Skeletonobject's bodytype to "kinematic"; this makes it react only to forces that you apply directly to it (setLinearVelocity, ApplyImpulse, etc.). I think that joints will respect this as well (not 100% sure!)
05/23/2014 (8:46 pm)
A Weldjoint or DistanceJoint with a distance of 0 would offer a pretty static way to glue the skeleton to the underlying object.You should try to set the Skeletonobject's bodytype to "kinematic"; this makes it react only to forces that you apply directly to it (setLinearVelocity, ApplyImpulse, etc.). I think that joints will respect this as well (not 100% sure!)
#6
Setting default density or gravity to zero for the skeleton will not help the situation, and setting the body type to kinematic disables the movement for the "combo object" altogether. Or should I copy all the velocity from the main object to the skeleton even though they are jointed together? That would sound like something that might yield very unexpected results.
If I don't combine the objects, but set the skeleton as a kinematic object on another layer and use moveTo(), the result is as laggy as setting the position directly.
I find it difficult to believe that such a rudimentary feature is missing from the physics engine - mounting just for the sake of visuals. Of course, because SkeletonObject is a kind of scene object, that cannot be achieved.
So far, no solution.
05/24/2014 (4:15 am)
The joints you described give a pretty stable connection, the only drawback, however, being that the skeleton affects the physics as a "burden" for the actual character.Setting default density or gravity to zero for the skeleton will not help the situation, and setting the body type to kinematic disables the movement for the "combo object" altogether. Or should I copy all the velocity from the main object to the skeleton even though they are jointed together? That would sound like something that might yield very unexpected results.
If I don't combine the objects, but set the skeleton as a kinematic object on another layer and use moveTo(), the result is as laggy as setting the position directly.
I find it difficult to believe that such a rudimentary feature is missing from the physics engine - mounting just for the sake of visuals. Of course, because SkeletonObject is a kind of scene object, that cannot be achieved.
So far, no solution.
#7
What would be nice is a way to create SceneObjects (and descendants) that have no physics presence in the scene. A way to just turn off physics entirely and manage movement directly or by a method similar to TGB's mounting.
05/24/2014 (10:31 am)
I'd like to point out that the physics system is Box2D and is not technically part of the engine - T2D uses it, but neither GarageGames nor anyone on the steering committee made it. Becoming familiar with their documentation will help you to better understand what can be done with physics in T2D.What would be nice is a way to create SceneObjects (and descendants) that have no physics presence in the scene. A way to just turn off physics entirely and manage movement directly or by a method similar to TGB's mounting.
#8
Why are the contributors always adding lots of half working features rather then concentrating on strengthening individual stuff. Surely it should be Quality > Quantity? I've seen numerous threads and whatnot of what people are working on or have done, and I think imagine the good that could've been done if they put that work on strengthening existing features.
I wish I were a good enough C++ coder to contribute because I would, so I know I have no room to complain here especially as this is all voluntary -which I'm much grateful for- but this engine just seems more and more unfriendly unless you're already a well experienced programmer and can go directly into the engine and tinker with it. I know it's a C++ engine and nobody said it was for beginners, but nobody said it wasn't. I feel comfortable enough to work with TorqueScript but it seems I'm screwed unless I can work in confidence inside the engine itself? So is this an engine someone can achieve much with TorqueScript or should I come back when I'm fluent in C++?
Sorry to bomb your thread, OP.
I don't mean any of this offensively, just frustrated.
05/25/2014 (6:28 am)
This is what is frustrating about this engine. You see a release post for 3.0 and think how awesome it is to now have Android and Spine support, then when you dig deeper it's always half working stuff (at best).Why are the contributors always adding lots of half working features rather then concentrating on strengthening individual stuff. Surely it should be Quality > Quantity? I've seen numerous threads and whatnot of what people are working on or have done, and I think imagine the good that could've been done if they put that work on strengthening existing features.
I wish I were a good enough C++ coder to contribute because I would, so I know I have no room to complain here especially as this is all voluntary -which I'm much grateful for- but this engine just seems more and more unfriendly unless you're already a well experienced programmer and can go directly into the engine and tinker with it. I know it's a C++ engine and nobody said it was for beginners, but nobody said it wasn't. I feel comfortable enough to work with TorqueScript but it seems I'm screwed unless I can work in confidence inside the engine itself? So is this an engine someone can achieve much with TorqueScript or should I come back when I'm fluent in C++?
Sorry to bomb your thread, OP.
I don't mean any of this offensively, just frustrated.
#9
As for "is C++ necessary?" it all depends on your point of view.
In most cases, Torquescript is really all you need. C++ allows you to extend the engine based on your specific needs or easily fix bugs and add new features.
Of course, if you don't have access to the C++ code, how do you know what functions do what and how to use them? Thankfully, the Steering committee has made extreme efforts to provide the complete engine documentation here.
Aside from that, almost all questions can be answered by the wiki. I still consult its wisdom on a daily basis.
If you are trying to make a game, you usually sit down and list what features you need; then proceed with assembling the scripts and assets to make your game.
As an example, the Spine implementation I've linked to was made for my specific needs; Overriding a bone or a Skin is not part of the Spine runtimes, in any engine. It's 100% C++ Torque with the TorqueScript Console methods to make it useable.
I sat down, listed what features I needed and coded them from scratch.
The way I see it, I have three options :
1. I spend weeks implementing all the current features of Spine, rewriting parts of the engine to accommodate these and testing everything on my own, polishing it and releasing it for free to the community.
2. I share whatever I've made, hoping that someone might take my work and use it as a starting point for a more complete implementation.
3. Avoid sharing anything at all, keep to myself and never help people on the forums.
I choose option 2 because I believe in this community.
So, where are you stumped when trying to make your game? Write a new blog post about it, ask questions on the forums, visit the irc channel, etc.
05/25/2014 (8:20 am)
@John : I agree with you, it's quite frustrating sometimes.As for "is C++ necessary?" it all depends on your point of view.
Quote:I feel comfortable enough to work with TorqueScript but it seems I'm screwed unless I can work in confidence inside the engine itself?
In most cases, Torquescript is really all you need. C++ allows you to extend the engine based on your specific needs or easily fix bugs and add new features.
Of course, if you don't have access to the C++ code, how do you know what functions do what and how to use them? Thankfully, the Steering committee has made extreme efforts to provide the complete engine documentation here.
Aside from that, almost all questions can be answered by the wiki. I still consult its wisdom on a daily basis.
If you are trying to make a game, you usually sit down and list what features you need; then proceed with assembling the scripts and assets to make your game.
As an example, the Spine implementation I've linked to was made for my specific needs; Overriding a bone or a Skin is not part of the Spine runtimes, in any engine. It's 100% C++ Torque with the TorqueScript Console methods to make it useable.
I sat down, listed what features I needed and coded them from scratch.
The way I see it, I have three options :
1. I spend weeks implementing all the current features of Spine, rewriting parts of the engine to accommodate these and testing everything on my own, polishing it and releasing it for free to the community.
2. I share whatever I've made, hoping that someone might take my work and use it as a starting point for a more complete implementation.
3. Avoid sharing anything at all, keep to myself and never help people on the forums.
I choose option 2 because I believe in this community.
So, where are you stumped when trying to make your game? Write a new blog post about it, ask questions on the forums, visit the irc channel, etc.
#10
Maybe it's best if I list what I hope to have from it. Also note very likely we'll only need the Essential version of Spine.
We're hoping to using it for a 2D platformer game, the SkeletonObjects will largely be used for NPCs and the Player character. Think Limbo: https://www.youtube.com/watch?v=a6vRXBOzGzU
Idk if that is using Skeletal animation but assuming it is, could I achieve the same functionality through Spine and TorqueScript as it is? I think what I need will be like what Eero wants; being able to move characters and have animating arms for different actions and whatnot. I.e. a player walks to a button and presses it.
05/26/2014 (7:54 am)
Hi Simon, thanks for the reply. Some good notes there. I guess I'm just a little heated because I told the artist Spine was good to go; seeing it advertised as now implemented in the engine, on the Spine website and a very convincing SpineToy. Now I need to figure out exactly how limited it is? For instance, when they go into Spine and make something, export it to the correct file for T2D what kind of surprises are there going to be in-game?Maybe it's best if I list what I hope to have from it. Also note very likely we'll only need the Essential version of Spine.
We're hoping to using it for a 2D platformer game, the SkeletonObjects will largely be used for NPCs and the Player character. Think Limbo: https://www.youtube.com/watch?v=a6vRXBOzGzU
Idk if that is using Skeletal animation but assuming it is, could I achieve the same functionality through Spine and TorqueScript as it is? I think what I need will be like what Eero wants; being able to move characters and have animating arms for different actions and whatnot. I.e. a player walks to a button and presses it.
#11
@John: Your question was answered by Simon: "You can find the Script functions and methods for Skeleton Objects in T2D/engine/source/2d/SkeletonObject_ScriptBinding.h"
github.com/GarageGames/Torque2D/blob/development/engine/source/2d/sceneobject/Sk...
github.com/GarageGames/Torque2D/blob/development/modules/SpineToy/1/main.cs
I haven't tried the spine features, so if they're bugged ya'll will be the first to find out.
05/26/2014 (8:36 am)
@Eero: Did you try setting the skeleton as a sensor and disabling its gravity?@John: Your question was answered by Simon: "You can find the Script functions and methods for Skeleton Objects in T2D/engine/source/2d/SkeletonObject_ScriptBinding.h"
github.com/GarageGames/Torque2D/blob/development/engine/source/2d/sceneobject/Sk...
github.com/GarageGames/Torque2D/blob/development/modules/SpineToy/1/main.cs
I haven't tried the spine features, so if they're bugged ya'll will be the first to find out.
#12
Short answer : no. Not even with my branch.
T2D 3.0 Spine implementation is really best used as a replacement for Sprite-based animations and not much more at the moment.
Long answer :
- Limbo has ragdoll physics. While this would be achievable with T2D, it would require some C++ modifications. And that's not just T2D-based; any engine would need to be modified to do this. In more recent Spine versions, you can specify collision shapes for each limb of the skeleton but that hasn't been implemented in T2D 3.0 or in my version.
- The setMix function in stock T2D 3.0 allows you to specify how to smoothly transition from one animation to another but it does not allow for multiple animations at the same time..
In my branch, I've added this functionality so if you have a basic walking animation and another animation which animates just the arms, you'd call setAnimation for the walk animation and setPartialAnimation for the arms animation. This would solve your button pressing issue.
05/26/2014 (3:10 pm)
@John : Limbo was also the first thing I though of when seeing Spine. Quote:...could I achieve the same functionality through Spine and TorqueScript as it is?
Short answer : no. Not even with my branch.
T2D 3.0 Spine implementation is really best used as a replacement for Sprite-based animations and not much more at the moment.
Long answer :
- Limbo has ragdoll physics. While this would be achievable with T2D, it would require some C++ modifications. And that's not just T2D-based; any engine would need to be modified to do this. In more recent Spine versions, you can specify collision shapes for each limb of the skeleton but that hasn't been implemented in T2D 3.0 or in my version.
- The setMix function in stock T2D 3.0 allows you to specify how to smoothly transition from one animation to another but it does not allow for multiple animations at the same time..
In my branch, I've added this functionality so if you have a basic walking animation and another animation which animates just the arms, you'd call setAnimation for the walk animation and setPartialAnimation for the arms animation. This would solve your button pressing issue.
#13
@John: I have made the mistake of not mapping all the resources I would need before starting my game project, and now I'm struggling with the result. What currently keeps me from going onto Unity, are the countless hours spent learning T2D framework and the potential I have noticed in the community pushing the package forward in its capabilities... However, I might still change my mind. :D I think we're in the same boat regarding C++ - subjects to waiting for engine features instead of implementing them ourselves.
05/27/2014 (6:45 am)
@practicing01: I tried setting for the skeleton object one collision shape and set it as a sensor. I also set the gravity scale and density to zero. Still affects the player physics a whole lot.@John: I have made the mistake of not mapping all the resources I would need before starting my game project, and now I'm struggling with the result. What currently keeps me from going onto Unity, are the countless hours spent learning T2D framework and the potential I have noticed in the community pushing the package forward in its capabilities... However, I might still change my mind. :D I think we're in the same boat regarding C++ - subjects to waiting for engine features instead of implementing them ourselves.
#14
05/27/2014 (7:10 am)
@Eero : Use the engine which you feel would most likely fulfill your current needs, don't feel bad about letting T2D go. You'd be surprised at what tricks you can pull off with the knowledge you've learned from this experience :).
#15
kekeke I have a mount() function in my fork that ignores physics (it's a copy/paste of the camera mount() github.com/practicing01/Torque2D/blob/development/engine/source/2d/sceneobject/S... ). It's not perfect however.. So I have to agree that a fully rigid mount is needed for the engine.
You can also achieve a rigid mount with composite sprites but I'm sure problems will pop there too (also you can't add a skeleton to a composite sprite can you? I haven't looked at that code).
The engine right now forces users to use box2d if their game is built with TS only. I'm not familiar with the c++ either but perhaps there can exist a set of functions for movement that could play nice with box2d.
On Unity, if you have the money, go for it. The goal of game development is to make games, not game engines. I haven't switched engines because I'm good at finding solutions to my problems when they drive me bonkers enough :P
05/27/2014 (8:20 am)
kekeke I have a mount() function in my fork that ignores physics (it's a copy/paste of the camera mount() github.com/practicing01/Torque2D/blob/development/engine/source/2d/sceneobject/S... ). It's not perfect however.. So I have to agree that a fully rigid mount is needed for the engine.
You can also achieve a rigid mount with composite sprites but I'm sure problems will pop there too (also you can't add a skeleton to a composite sprite can you? I haven't looked at that code).
The engine right now forces users to use box2d if their game is built with TS only. I'm not familiar with the c++ either but perhaps there can exist a set of functions for movement that could play nice with box2d.
On Unity, if you have the money, go for it. The goal of game development is to make games, not game engines. I haven't switched engines because I'm good at finding solutions to my problems when they drive me bonkers enough :P
#16
Plain and simply, all I simply want Spine for is it's gorgeous smooth animation abilities, and by this I mean I could use Sprite / Raster based code interchangeably with how Spine is done (obviously with some changes). So I don't want any special techniques, I'll code my players to behave how they would just like a raster sheet, except I want to use Spine animations for that more nicer look but _that's_ it.
For instance I'll have a physics box (i.e. a SceneObject) to be the player and apply forces to it to move it and whatnot, then just play / attach a Spine animation over it and be able to switch to jump animations or action animations. The animations will have no special ability other then to be parented / playing to the physics box. I think it sounds simple hopefully, I just want someone to confirm I'll be able to. I don't expect to need the Pro features, it's just basic player / prop usage I want.
05/27/2014 (10:56 am)
@Simon my bad, when I referenced Limbo I meant purely the animating itself, I don't mean at all the ragdoll / or physics capabilities I knew that wouldn't be in there :)Plain and simply, all I simply want Spine for is it's gorgeous smooth animation abilities, and by this I mean I could use Sprite / Raster based code interchangeably with how Spine is done (obviously with some changes). So I don't want any special techniques, I'll code my players to behave how they would just like a raster sheet, except I want to use Spine animations for that more nicer look but _that's_ it.
For instance I'll have a physics box (i.e. a SceneObject) to be the player and apply forces to it to move it and whatnot, then just play / attach a Spine animation over it and be able to switch to jump animations or action animations. The animations will have no special ability other then to be parented / playing to the physics box. I think it sounds simple hopefully, I just want someone to confirm I'll be able to. I don't expect to need the Pro features, it's just basic player / prop usage I want.
#17
Simon, you made a good point there! However, I think I'm still going to stay aboard for some time. All in all, it's only some minor features that will be implemented sooner or later. And I could easily develop other aspects of my project meanwhile. I got the impression from what Nathan Sweet replied on Trello that he is currently working to get the T2D Spine runtime to support all the editor features.
@John, if I understand you correctly, I think you can do exactly that with the current Spine support in T2D: play a single Spine animation for the scene object at a time. Simon pointed out this location T2D/engine/source/2d/sceneobject/SkeletonObject_ScriptBinding.h for the complete list of the console methods available.
05/28/2014 (2:13 pm)
@practicing01: Your mount() looks quite nice! Does it also update nicely if you abruptly teleport the character?Simon, you made a good point there! However, I think I'm still going to stay aboard for some time. All in all, it's only some minor features that will be implemented sooner or later. And I could easily develop other aspects of my project meanwhile. I got the impression from what Nathan Sweet replied on Trello that he is currently working to get the T2D Spine runtime to support all the editor features.
@John, if I understand you correctly, I think you can do exactly that with the current Spine support in T2D: play a single Spine animation for the scene object at a time. Simon pointed out this location T2D/engine/source/2d/sceneobject/SkeletonObject_ScriptBinding.h for the complete list of the console methods available.
#18
@John : What you describe can be done in stock T2D MIT 3.0.
A quick distinction, though. When you add a SkeletonObject to the scene, this new object is derived from a SceneObject. As such, you can add a collision shape (or many collision shapes) directly to it, without the need for a separate Physics box.
The wiki is your friend!
05/28/2014 (2:57 pm)
@Eero : Nice to hear you're staying!@John : What you describe can be done in stock T2D MIT 3.0.
A quick distinction, though. When you add a SkeletonObject to the scene, this new object is derived from a SceneObject. As such, you can add a collision shape (or many collision shapes) directly to it, without the need for a separate Physics box.
MySkeleton.createPolygonBoxCollisionShape(%width, %height, %centerx, %centery, %angle);
The wiki is your friend!
#19
If I start with the jump animation in the creation method of the object, the same crash happens, whereas the "walk" animation works fine to start with or changed run-time.
05/29/2014 (3:08 am)
I copied the spineboy from the official Spine Toy to my project to work as a placeholder for my character, and now that I set everything the way it is setup in the toy, it crashes every time I try to switch to the "jump" animation:%this.setAnimationName("jump", false);I don't have a clue why this crash happens since the log doesn't report any details about the problem (not even when trace(true)). (I'm using OS X 10.8.)If I start with the jump animation in the creation method of the object, the same crash happens, whereas the "walk" animation works fine to start with or changed run-time.
#20
05/29/2014 (3:20 am)
This is the crash report. Does it give any hints?Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.garagegames.Torque2D 0x0010188a spAnimationState_setAnimation + 101 1 com.garagegames.Torque2D 0x0010181d spAnimationState_setAnimationByName + 57 2 com.garagegames.Torque2D 0x00118b80 SkeletonObject::generateComposition() + 212 3 com.garagegames.Torque2D 0x0011888c SkeletonObject::setAnimationName(char const*, bool) + 92 4 com.garagegames.Torque2D 0x0011751d cSkeletonObjectsetAnimationNamecaster(SimObject*, int, char const**) + 59 5 com.garagegames.Torque2D 0x0013a4af CodeBlock::exec(unsigned int, char const*, Namespace*, unsigned int, char const**, bool, char const*, int) + 13277 6 com.garagegames.Torque2D 0x0012ebe0 Namespace::Entry::execute(int, char const**, ExprEvalState*) + 200 7 com.garagegames.Torque2D 0x0013e7de Con::execute(SimObject*, int, char const**, bool) + 298 8 com.garagegames.Torque2D 0x0013e8c5 Con::executef(SimObject*, int, ...) + 128 9 com.garagegames.Torque2D 0x001e4c79 SceneObject::postIntegrate(float, float, DebugStats*) + 73 10 com.garagegames.Torque2D 0x0021fe63 Scene::processTick() + 1065 11 com.garagegames.Torque2D 0x0021fee2 non-virtual thunk to Scene::processTick() + 22 12 com.garagegames.Torque2D 0x00100198 Tickable::advanceTime(unsigned int) + 222 13 com.garagegames.Torque2D 0x00149123 DefaultGame::processTimeEvent(TimeEvent*) + 207 14 com.garagegames.Torque2D 0x0014af9e GameInterface::processEvents() + 102 15 com.garagegames.Torque2D 0x00148f2a DefaultGame::mainLoop() + 74 16 com.garagegames.Torque2D 0x002832fa -[osxPlatState mainTorqueLoop:] + 34 17 com.apple.Foundation 0x94ed0974 __NSFireTimer + 117 18 com.apple.CoreFoundation 0x92775406 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22 19 com.apple.CoreFoundation 0x92774da5 __CFRunLoopDoTimer + 709 20 com.apple.CoreFoundation 0x92759bb2 __CFRunLoopRun + 1842 21 com.apple.CoreFoundation 0x9275901a CFRunLoopRunSpecific + 378 22 com.apple.CoreFoundation 0x92758e8b CFRunLoopRunInMode + 123 23 com.apple.HIToolbox 0x98985f5a RunCurrentEventLoopInMode + 242 24 com.apple.HIToolbox 0x98985cc9 ReceiveNextEventCommon + 374 25 com.apple.HIToolbox 0x98985b44 BlockUntilNextEventMatchingListInMode + 88 26 com.apple.AppKit 0x96b2293a _DPSNextEvent + 724 27 com.apple.AppKit 0x96b2216c -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 119 28 com.apple.AppKit 0x96b185cc -[NSApplication run] + 855 29 com.apple.AppKit 0x96abb5f6 NSApplicationMain + 1053 30 com.garagegames.Torque2D 0x000c5a75 start + 53
Associate Simon Love
The 3.0 branch doesn't have access to event listeners and is limited to one animation at a time to be applied to a skeleton. It does not support mesh animations as this would require lots of source code modification to T2D.
I've made changes on my own version to allow for partial animations, overrides to bones, skins and slots and many other nifty little tricks such as event listeners (animation events, animation start, end, etc.).
Bear in mind though that my version is a work in progress and is 100% unsupported, even by me. It doesn't support mesh animations either. Look at SkeletonObject_Scriptbindings for all updated functions.
You can grab my version from here if you are interested.