Spine - Animation Module (part2)

Monkey Forums/User Modules/Spine - Animation Module (part2)

Skn3(Posted 2013) [#1]
continued from:


Please read the wiki for some instructions.

If anyone would like to contribute to this project then please do, the help would be greatly appreciated.

Enjoy, for free :D


Hey there monkey brains, I have been beavering away at some more monkey developments. This time I have created a module and it has been sponsored by Tony from Playniax/Ignition.

Thanks should go to him as I'm sure this will benefit a lot of monkey games.

So he tasked me to create a monkey module to support the spine runtime. I have nearly finished this, but for now here is a little demo.


Skn3(Posted 2013) [#2]
Sorry for the slowness all, just generally not had time to touch monkey stuff for last 2 weeks... which saddens me!

I would like to support all of the spine features once they are added. I guess once they release it to the public, I could contact Mark and see if its worth my while to try and hack something in the meantime. It would definitely be cool to see freeform deformations working... and potentially a general purpose texture coords rendering approach is something I have needed in monkey before.

re SetSlotColor():
I think at the time of creating the spineentity I was trying not to replicate so much data twice and just have the spine-glue-entity speak to the spine runtime directly. The built in animation process would override slot colors anyway so anything I would add is going to have to update the slot colors every frame. I designed it like this because I didnt want to make changes to the way the underlying spine runtime works.

You could potentially take out my glueentity stuff and use spine as it was originally intended.

re mixing animation:
What kind of thing are you doing? I havn't looked at any animation mixing in spine.

rIKmAN(Posted 2013) [#3]
Hey skn3,

re: SetSlotColor() - yep I realised after I posted that anything you added would be doing what I was doing anyway, just probably cleaner and more efficient :)

re Mixing: I noticed there is a "Mix" Method in SpineAnimation so thought it may be implemented, but could'nt seem to get it to work even though I got it compiling.

The Mix stuff basically allows you to mix 2 animations together, or overlay them as such.

ie. A blink mixed with any other animation, or a walking/running animation on the lower half of a character, mixed with a shooting animation which would affect just the top half so you could ie. Go from walking/running normally to walking/running whilst shooting smoothly and without having to create specific animations for every variation as you could just mix them.

Skn3(Posted 2013) [#4]
When I get a chance I will take a look at mixing and a way to possibly change slot colors. Can't say when but I'll get it done eventually aye ;)

I would be interested to see what your making with spine ?

rIKmAN(Posted 2013) [#5]
Hey skn3,

No problem mate - I really appreciate everything you have done on the module, it really is a great piece of work!
As I've said previously as soon as I'm able I will be sending a donation your way without question.

Information on mixing/combining animations as I mentioned above can be found in the Spine docs here:

Mixing Animations
Combining Animations
Animation State

Unfortunately I can't give any details publicly about my game just yet, except that it is targeted for an Easter 2014 release on iOS to start with, and other formats to follow.

I could maybe send you some information or screens privately if you are really that interested or if it will help with the modules development?
I assume you are cursing and wondering what I am doing to be asking about all these Spine features? :)

On that note - is it possible to add/remove attachments programmatically during runtime using the module?

I know it is mentioned in the Spine docs but I'm not sure if this functionality is in the module, and I'm not at home until Sunday so can't check through the source atm.

Skn3(Posted 2013) [#6]
Cheers for the links info for handy reference.

No unfortunately its not possible to add/delete attachments at runtime with the glue spine entity. There doesnt seem to be much detail on that link either about the process of doing it. Its possible to call "SetAttachment" though on the actual spine skeleton, this might help?

Yeah I would like to see some details via email if you are happy to send? Haha not much cursing ;) Interested to see what its being used for.

Skn3(Posted 2013) [#7]
' - added MixAnimation to gluespineentity see example2 for example of usage

Added update for animation mixing.

So you call

The next call to SetAnimation will remove the mixanimation so you will need to set mix again.

I could quite easily add in teh ability to mix in infinite animations, but probably (for performance) its best to keep it to just two?

rIKmAN(Posted 2013) [#8]
Hey skn3,

First - sorry for the late reply, got back a day later than planned.
Secondly - mixing already, awesome!!!! :)

I've just tried it quickly and it works great :)
I didn't expect an update so quickly so its nullified a few hours work I did creating variations of animations (with/without blinks and that sort of thing) but that's a small price to pay for the ease and flexibility this will bring with a bit of code refactoring - thanks man! :D

I think maybe 3 animations minimum for the mixing, this would allow something like the following example:

(1) Lower body walking (or running etc)
(2) Upper body shooting (or aiming etc)
(3) Ambient animation (ie. blinking etc)

Although if it is quite easy to allow infinite mixing then maybe allow that with a proviso in the notes regarding performance - and leave it upto the coder to decide how many are possible without affecting performance, as this would vary per target I think?

With regards to the attachment adding/deleting at runtime, I have been using SetAttachment in some circumstances, but this only works with attachments that have already been setup inside of Spine itself.

In an example with a character that has 100 possible attachments for a given slot (different clothing, armour or whatever), this means setting up all attachments in Spine and then loading them all into memory when the SpineEntity is loaded.

If these attachments are things that can be selected by the player, or not available until they bought in a shop (so they may in fact never be selected or needed), then it would be much better to be able create/delete the relevant attachments as they were needed in code, which on mobiles would be a huge memory saver - only attachments that were needed would ever be loaded.

I have done a little digging in the Spine docs and it seems that programmatical attachment creation/deletion is related to the AttachmentLoader, which is in the monkey code but is defined as Abstract, so I found myself getting "Cannot create instance of an abstract class." errors when trying to create a new SpineAttachment.

It also seems to require a "skin" parameter, although I'm not sure if this is a necessity or not, or whether you can simply add them to a normal slot on an existing entity.

Here are the docs I found:
AttachmentLoader in Spine Docs

I will get some details of my game over to you but unless you just want a description it may be over the weekend before I can get some screens etc together.

Sorry for the long post, and thanks again for the mixing! :)

rIKmAN(Posted 2013) [#9]
Update: more info...

At runtime, all attachments are in a skin. Attachments in Spine that are not in a skin are placed in a skin named "default".

Most attachment loaders don't use the skin parameter:

The attachment loader is used by SkeletonJson as a way to customize creating attachments. You don't actually need the attachment loader to create a new attachment. Eg, you can copy the code from the link above, though if the attachment loader is convenient, go ahead and use it.

Note that you need to do additional configuration for your attachment beyond what the attachment loader does. See SkeletonJson, just after it does attachment loader NewAttachment. It configures the attachment with data from the JSON. You'll need to do the same.

rIKmAN(Posted 2013) [#10]
Hey skn3,

I'm not sure if you have the Ignition Framework by Playniax, but there seems to be an issue when using it together with the Spine module, specifically the iBitmapFont part of the framework.

If you have it, if you open one of the the iBitmapFont examples (bananas\playniax\ignition\01_simple_modules\08_bitmap_font) and just add
Import spine
at the top of the source and run it, then no fonts are displayed.
Remove the line and the fonts work as expected.

Not sure why, as there are no other commands being used, simply importing the spine module causes it to happen.
Using Monkey v76d, Ignition 1.11 and v17 of the Spine module.

PS. I will email over those details as promised later tonight when I get home :)

rIKmAN(Posted 2013) [#11]
skn3, email sent to the addy on your profile :)

Playniax(Posted 2013) [#12]

The problem is this line in spine.monkey:

#TEXT_FILES += "*.atlas;*.json"

The Ignition font module uses .txt files to load font data and somehow this setting excludes text files so the solution is to add *.txt

#TEXT_FILES += "*.atlas;*.json;*.txt"

You can add this line at the beginning of your code or change it at the spine.monkey file.

.txt is (or was?) a default format for monkey so this could lead to more problems with other 3rd party software. This should be tested more when I have time :)

Soap(Posted 2013) [#13]

>Less than a month after the Kickstarter and just in time for Christmas, meshes are now available in Spine Professional, version 1.7+!

rIKmAN(Posted 2013) [#14]
I emailed aswell, but thanks Playniax, that didn't even cross my mind! :)

Soap, I think this update may well change the exported .json (vertex info etc) and thus not work with this module (yet! :))
I'm only assuming this as I have locked my version at 1.6.42 so have not updated, but I know that version plays nice with the module.

Have you tested v1.7.x with this module?

You can't animate the mesh deformations yet either, but that will be coming soon.

Skn3(Posted 2014) [#15]
The vertex info *should* just be added as another type of attachment so Id imagine the latest spine wont break anything.

I am still waiting for this all to be fleshed out a bit before continuing any dev.

The Christmas break has wiped my memory it seems. Are there any major important fixes/tweaks that need to be added ATM ?

rIKmAN(Posted 2014) [#16]
Completely missed your reply in this thread skn3, apologies!

For me I would like the ability to create/delete/manage attachments in code at runtime, and bounding boxes for collision detection, hitboxes etc
I'm not sure how tied into a "major" update these would be, but those are my 2 "would likes" until a major update :)

PS. Thanks for your feedback re: email, and hope you had a good one mate.

Soap(Posted 2014) [#17]


Spine - FFD and Meshes

rIKmAN(Posted 2014) [#18]
Hey sk3n,

I have noticed that when calling entity.SetAlpha() or entity.SetSlotColor() that it doesn't seem to return the alpha or color to what it was before the call to set the alpha/color on the spine entity.

ie. If I call entity.SetAlpha(0.0), then afterwards, HUD elements disappear as I am guessing that SetAlpha has not been returned to 1.0 from inside the entity.SetAlpha(0.0) call.

Is this behaviour a bug or is it intended that we reset the value manually after the call?

rIKmAN(Posted 2014) [#19]
Is anyone else using this module, or is it literally just me?

ziggy(Posted 2014) [#20]
I'm using it but only the basis of it

rIKmAN(Posted 2014) [#21]
Hey ziggy,

Have you exeprienced the alpha/color problem from above when using SetSlotAlpha()/SetSlotColor() or entity.SetAlpha() at all?

What do you mean by "basis of it"?

I'm really suprised how little this module is being used, Spine (and of course this module) are awesome!

Skn3(Posted 2014) [#22]
Whoops I missed the bug report... looking now...

Skn3(Posted 2014) [#23]
Ok I added an update.
'version 18
' - added RevertColor() and RevertAlpha() to spine entity (cheers rikman)

Does that do what you want?

I wasn't sure what you meant. The setcolor and setalpha commands are on the glue entity itself (so e.g. you are not changing a slot/attachment or something that can be overwritten by spine). So for these commands if you set alpha/color to 0 then they would remain at 0.

Do the Revert methods make sense here or should I rename them?

Skn3(Posted 2014) [#24]
P.S. I will get around to updating the spine module with some new features, but just soooooo very busy these days!

Compared to a year ago (roughly when I did the spine module) things are like a snail vs a cheetah in terms of workload! I had tons of time to pump out lots of module code.

Nobuyuki(Posted 2014) [#25]
I just ran into a really terrible runtime problem attempting to use spine on glfw builds with MinGW. The runtime error is the classic "Memory Access Violation", but the cause is befuddling. See if you can venture a guess as to what the heck is going on. It occurs in gluefiles.monkey, riiiiiight around here:

The problem doesn't occur with the exact same code using MSBuild. I am compiling in debug mode, so -o1 should still be standard-compliant.

Please also note that the input file exists and is valid JSON according to JSONlint! It's not the file! It's gotta be something with how Spine interacts differently with msbuild vs. gcc....

Skn3(Posted 2014) [#26]
Lol wtf, that's a weird one!

Could you provide a test example so I can try it out when I get a spare moment?

Nobuyuki(Posted 2014) [#27]
I'll see what I can do about getting something for you to test. I don't have Spine, myself, so I have to get someone to make a test file that's OK to send that reproduces the bug on my end.

It's possible that because of the garbage coming in from the file stream that this may actually be an issue with the BRL implementation. I hope not, but it is always a possibility. To make sure, though, I'll obviously need your confirmation. Right now I'm using gcc 4.7.2, which is over a year old now and may contain some regressions that could be behind this bug if it's not spine or brl (Edit: 4.7.2 is the latest for MinGW, I just checked). I will look into seeing if a newer version of mingw will fix the issue, but first I want to reproduce the bug in a test example.

Nobuyuki(Posted 2014) [#28]
Here is an example file. https://s3.amazonaws.com/uploads.hipchat.com/11212/127278/JoUCuV0rFiynR8I/spinetest.rar

Nobuyuki(Posted 2014) [#29]
Sorry to bother so soon, but have you been able to test and confirm the bug? Running the example code on a glfw build from minGW should produce a crash.

Nobuyuki(Posted 2014) [#30]
Update: Here is my call stack. I've tested specifically extracting SpineDefaultFileStream to a dummy file and running a few functions on it in an attempt to get it to spit out garbage but wasn't able to do it. It worked as expected there.

In the test code, I altered ReadAll to spit out start, total, and result before the offending line (which is start=total). Start and total report back that their values are -36, which I find improbable. The result string is jibberish, about 19 bytes, although because I copied it from the print buffer it may have been null-terminated. It's probably garbage because it tried to peek in an area of memory that it shouldn't have. The data reads successfully from SpineDefaultFileStream.Load(), however, returning a total of 12155. Somewhere between Load() and ReadAll(), start's position is moved to -36. Perhaps some other piece of memory has overflowed into the integer's position.

I believe I've narrowed it down to the late-binding of your inherited interfaces. This may be a Monkey bug. Will report.
Edit: http://www.monkeycoder.co.nz/Community/posts.php?topic=7958 Reported

Skn3(Posted 2014) [#31]
Hey Nobu,

Appologies for delay getting back to you. I was just going to look into this now but then saw it was potentially out of my control. Could you confirm (from other thread) if this is still an issue?


P.S. I hear rumblings of MojoX in some other threads, I wonder if this would facilitate the mesh support? I wonder how far MojoX is from a release?

Nobuyuki(Posted 2014) [#32]
It's still gonna be an issue for anyone who uses the current stable version of MinGW, I think. The regression seems to affect specifically that version and is a result I think of how your interface code is being translated into C++. It's actually neither the fault of your code or Mark's, but a nasty upstream bug in gcc. Luckily, though, it seems you can upgrade gcc from the commandline without much trouble...

I see references to MojoX in some of the v77f examples, but other than that I don't see many hints of what it includes.

rIKmAN(Posted 2014) [#33]
Sorry for the late response sk3n, been really busy.

I will test the update to see if it fixes the alpha/color issues, but to summarise, it seems as though any call to alpha or color methods do not return the alpha/color to it's original value before the call. This may be intended behaviour, but seems unlikely?

Method OnUpdate()

		If KeyHit(KEY_1)
		If KeyHit(KEY_2)
		Return True
	End Method

        Method OnRender:Int()
		' this will be drawn
		DrawText "Before Text", 480, 50
		' this will  be alpha'd along with the entity unless I put a SetAlpha(1.0) after the entity.Render().
		DrawText "After Text", 480, 600

		Return True
	End Method

If you don't mind sharing, what is it you are doing with Spine to cause the errors?
I ask I have been using Spine quite a lot (can you tell from the thread haha) and have not come across the issues you mention, but would be interested in knowing how you got there for future reference.

I am using the version of MinGW linked to from the Monkey docs.

Nobuyuki(Posted 2014) [#34]
Check the link to the bug report thread I made in a previous post. If loading a spine json doesn't crash then you're fine.

Skn3(Posted 2014) [#35]
Will try and look more into this afternoon, I understand the alpha issue now, so will restore the alpha flag in that call.

monkeyteets(Posted 2014) [#36]
Hey Jon!

Firstly thanks for making this, I just purchased Spine and have been using it, today I noticed there is a bug that has to do with negatively scaled objects. I use the same graphic asset in my atlas in multiple instances (for arms and legs) to save on file size (I use same image asset but just flip horizontally / vertically with -1.0 scale)

It works great in Spine, but in monkey these are very thin.

Okay I removed negative scaling on images and put them on bones and it works better EXCEPT nested bones. For some reason there is problem with nested bones turning it upside down. It shows correctly in the Spine Editor, but not in Monkey

Skn3(Posted 2014) [#37]
Hey there, I plan to attempt some time with monkey modules on Frioday, so will look into this then :)

DeadFall(Posted 2014) [#38]
Hey Skn3, is it possible to just change the skin of one bone object from within monkey? Say I have multiple helmets for a soldier, but I don't want to change the main armor just the helmet. Is that possible?

Soap(Posted 2014) [#39]

rIKmAN(Posted 2014) [#40]
Isn't mesh stuff the thing that might not be possible in Monkey?

Soap(Posted 2014) [#41]
It's certainly possible, just not immediately simple or easy - it would take work beyond what Monkey allows by default yes. With Mojo3D it may be easy.

Nobuyuki(Posted 2014) [#42]
once Monkey supports DrawTriangles for reals, and has some sorta fallback (if possible) on non GL/DX targets, it'll be entirely possible. Right now it might be possible with a quads hack using DrawPoly's undocumented texture mapped option. You'd see seams, though.

Timotron(Posted 2014) [#43]
Sharing a fix for the monkey spine engine for drawing spine files that actively use negative scale in animations to flip bones.

below you will see a modified version of draw from the SpineDefaultAtlasRegion class that I am used when testing the fix

the calling code from inside the method OnRender from the class SpineEntity
	attachment.Region.Draw2(attachment.WorldX, attachment.WorldY, attachment.Rotation, attachment.ScaleX, attachment.ScaleY, attachment.WorldRotation - attachment.Rotation, attachment.WorldScaleX - attachment.ScaleX + 1.0, attachment.WorldScaleY - attachment.ScaleY +1.0, -Int(attachment.Region.GetWidth() / 2.0), -Int(attachment.Region.GetHeight() / 2.0), attachment.Vertices)

Timotron(Posted 2014) [#44]
Another item of note is I have a fix that I made to the SpineAnimation class that allows proper mixing of any number of animations with changing mix percents on the fly. Although I am unsure if I maybe just miss understood the current mix system and I was just redoing what I could already do.

My way of doing it requires an extra skeleton.SetBonesToBindPose() every update and then in the SpineAnimation methods for handling SpineRotateTimeline, SpineTranslateTimeline and SpineScaleTimeline you have set the complete change instead of adding the delta. But you can do cool stuff like have one animation end where you tail it off over .2 seconds while another animation spins up over that same .2 seconds and it is a smooth transition.

Of course, the caveat is that I may have missunderstood the current mix system...


Skn3(Posted 2014) [#45]
Sorry for complete lack of update on all my modules. Just not had the motivation or time recently. With regards to the spine update, it was kind of waiting on Monkey being able to support it natively. I don't really want to go ahead and hack in drawing polygons and whatnot if it requires hacks to mojo (which it would). So unfortunately its on hold.

Soap(Posted 2014) [#46]

IK constraints now available in Spine 1.9.0+!


Soap(Posted 2014) [#47]
Skn3, can you post a bid for doing the necessary hacking? Possibly a few of us who could make use of it can fund doing it. Spine alone is really useful, but having mesh deformation support would really make current project assets look more alive. If a target can't support it, possible to still make the animations work without mesh deformation data being used?

Skn3(Posted 2014) [#48]
Hey Soap,

Give me an email (see signature) and we can discuss potential funded project. Id rather not discuss business rates in a public forum.

The big issue I see with hacking it into monkey is that I would have to duplicate work for the wide set of platforms monkey supports. It makes supporting said hacks incredibly time consuming and its going to be a bit of a mess to maintain a version of the module that works without hacks, and a version that has the hacks... if that was the way forward.

I think realistically I would have to code a separate module for creating/texturing meshes and have that work by itself. Spine could then utilise the functionality...

rIKmAN(Posted 2014) [#49]
Not sure if anything has changed recently, but I just tried out Monkey v79e and am getting an error on a project that works fine in v78c.
I am using the latest version of the module from the svn.

The error is:
MonkeyXPro79e/modules/spine/spineskeleton.monkey<106> : Error : Method SpineSlot.SetToBindPose:Void(Local slotIndex:Int) is private.

but I've checked and there is no "Private" declaration in spineskeleton.monkey.

Anyone else had any issues?

therevills(Posted 2014) [#50]
The error is:

MonkeyXPro79e/modules/spine/spineskeleton.monkey<106> : Error : Method SpineSlot.SetToBindPose:Void(Local slotIndex:Int) is private.

but I've checked and there is no "Private" declaration in spineskeleton.monkey.

Look in spineslot.monkey, line 49:
	Method SetToBindPose:Void(slotIndex:int)

rIKmAN(Posted 2014) [#51]
Ah thanks therevills!

What is the change to Monkey that would make it work on v78c yet crap out on v79e using the exact same version of the module?
It's like v78 ignores the Private declaration...

Skn3(Posted 2014) [#52]
Added a small update for this. Also noticed this recently in another module that used to work but then didn't.
'version 19
' - small fix to remove private method in spineslot.monkey

navyRod(Posted 2014) [#53]
Spine looks pretty cool but kinda bummed out on there model -- the free model to see what you think of it is fully enabled with mesh deforming etc but once you go to purchase it you loose quite a bit of the nice to have features if you just buy the single user $60 version vice the $229 dollar one.

Seems kinda like a bait and switch model -- gotcha hooked but you will have to eat the whole worm if you want to continue ... $ 200 + is pretty pricey

but I guess if ya want it .. they got ya.

Skn3(Posted 2014) [#54]
TBH I think its something they had to do as their kickstarter funds surely can't carry them forever. It is a fairly niche product so maybe they are finding out they can't charge the "indie/1-person" price they were doing so at the start.

mouser(Posted 2014) [#55]

It seems that multipack for the textureatlas is not working.
Whenever there is more than one file (for example: spine_1-1.png and spine 1-2.png) I get the following error:

An higher max width and max height in the texturepacker settings helps here but is no solution for older devices.


Skn3(Posted 2014) [#56]
I will be doing some work on the spine module in a couple of weeks, so will look at this at the same time.

Skn3(Posted 2014) [#57]
Calling all spine module users.

Subsoap has kindly started funding some further developments of the spine module. If you check the repository you can see I have started a new branch. This is a complete re-port of the latest runtime. It includes stuff like bounding boxes, FFD and limited IK support (IK support didn't appear to be fully functional in the official runtime but I got it working for Monkey)

New Branch

Help fund this module
We are looking for your help to fund this development:

If you want to use paypal, use the button below. I'll make sure to manually add paypal contributions to the funding page.

A large chunk of time has been taken to create these new developments and that does not include inevitable bug fixes/improvements in the coming weeks. Currently subsoap has upfronted a portion of the cost and I have taken an equal hit in cost to support the module. We are looking for contributions to help support this module.

I have totally revamped the glue aspects of the module. You can now use the module stand-alone without the SpineEntity stuff ontop. To do so, you will need to Import spine and write some handlers for loading files/atlases/rendering images. You can see examples of these here:

Of course if you want to use my handy SpineEntity then this is still in existence. To use the mojo orientated spine in your projects all you need to do is:
Import spine.spinemojo

From here you can then call:
Function LoadMojoSpineEntity:SpineEntity(skeletonPath:String)

...to load a spine export file. Please see the file below for variations of this function:

I have included a new example7.monkey which lets you modify a pre processor variable to compile various different example files:

each of the available options can be seen in the Select statement below and each one demonstrates a working aspect of the spine runtime.

Lugato(Posted 2014) [#58]
Hi Jon,

I can contribute with £50 but I need a link to paypal :)

Skn3(Posted 2014) [#59]
Hey Luiz,

Much thanks :D I'll make sure to manually add paypal contributions to the funding page.

Skn3(Posted 2014) [#60]
Much thanks to everyone else who has supported so far.

Landon(Posted 2014) [#61]
just sent £10.00

Skn3(Posted 2014) [#62]
Thanks :D could you confirm where you sent it please :) ? I don't see anything in paypal on fundly. Just want to make sure it is working properly...

Skn3(Posted 2014) [#63]
Nevermind I see it.

Odd for some reason the payment has been sent to my non business related paypal account. Did you click the button above or do some other way?

Anyways, much thanks, I will add it to the fundly campaign.

Landon(Posted 2014) [#64]
i dunno i clicked the link that was in the OP

mouser(Posted 2014) [#65]
Maybe a bug? I can't switch the skin.


Monkey Runtime Error : TypeError: dbg_array(...)[dbg_index] is null

Skn3(Posted 2014) [#66]
Looking into it now.. will update when fixed.

Skn3(Posted 2014) [#67]
Ok this is fixed. I have also fixed some other bits with the module:
' - major fix to UpdateCache and UpdateWorldTransform in spine skeleton. Now has fully functional IK
' - updated license in accordance with spines new license
' - small tweak to fix bug when switching from old skin to new skin

mouser(Posted 2014) [#68]
Hi again!

I've found a new problem with events:

Method OnSpineEntityEvent:Void(entity:SpineEntity, event:String, intValue:Int, floatValue:Float, stringValue:String)
        Print "OnSpineEntityEvent"
        Print "event: " + event
        Print "intValue: " + intValue
        Print "floatValue: " + floatValue
        Print "stringValue: " + stringValue

returns no data or only default data

event: cast_the_fishing_rod
intValue: 0
floatValue: 0

Skn3(Posted 2014) [#69]
Not ignoring this, just been fairly busy over the weekend. I will look into this on a lunch break this week.

Thanks for the bug testing btw, it really helps :D

Law(Posted 2014) [#70]
Ok. I think instructions should be updated somewhere. It's a big mess!
I'm not sure I'm even getting the correct version.

This wiki is pretty old: https://github.com/skn3/monkeyspine/wiki/Installation
So, which link do I download?
Or this:
or both!?

Where do I unzip to exactly?

Here you can see I've put it in 'modules\spine" and I got the following error:
Mungo/modules/spine/spineskeleton.monkey<156> : Error : Method SpineSkin.AttachAll:Void(Local skeleton:SpineSkeleton,Local oldSkin:SpineSkin) is private.
(I'm using Mungo) I was trying to build example1. I have the json module too - it came with mungo, actually.
This is with the https://github.com/skn3/monkeyspine version. The other version only has example7 and I can't build that either!

I'd appreciate an update on step by step instructions. Too many links and (i think) old stuff. Confusing to me!

Thanks in advance!,

Skn3(Posted 2014) [#71]
I will look into this week plus hopefully merge a commit. I had two weeks off hence no updates. Stay tuned:)

Skn3(Posted 2014) [#72]
'version 21
' - fixed event data not coming through, cheers mouser
' - added SetIgnoreRootPosition to SpineEntity. By default now spineentity will utilise the root bone position compared to 0,0 in spine editor. Set this to true if spine entity should ignore root bone position and force set to x,y of SpineEntity.

The second item in that update might mean you have to adjust your project. Previously the SpineEntity would assume that the root bone should always be placed at the x,y of the SpineEntity. This meant that all positional animation data for root bone was ignored. Now, the default behavior is to use the root bone position. When you place the root bone at 100,100 in the spine editor, the SpineEntity will be placed at 100,100 offset from the entities x,y.

So make sure you set your root bone to 0,0 in the spine editor. If you want to use the old behavior then call SetIgnoreRootPosition(true) on your SpineEntity .

Skn3(Posted 2014) [#73]
I have merged the development branch into master now, so just download direct from spine module repo.

I have also removed some dead wiki pages and updated some of the information. Please let me know if it helps. Example7 should run out of the box if you have followed the installation procedure.

I am not sure if there are conflicts with Mungo, perhaps we can resolve this together. Let me know how you get on.

Skn3(Posted 2014) [#74]
Another quick commit:
'version 22
' - issue with merging pull request with different line-end-encoding ~r is now stripped out in mojo file reader

Basically a 3rd party pull request changed the line-endings which was breaking the SpineMojoFile implementation.

Soap(Posted 2015) [#75]
Can you check Example7 with building on 82b? For me it is a white screen.

Skn3(Posted 2015) [#76]
Yo I will check soon. Sorry struggling to gather some time, got a hell two weeks up ahead. I will fit this in though, as I suspect it is a very quick fix! Stay tuned!

Soap(Posted 2015) [#77]
Can take a quick look at this soon?

Skn3(Posted 2015) [#78]
Whoops, I will add this to my calendar for tomorrow.

Skn3(Posted 2015) [#79]
Sorry about the delay!

I tried in glfw and things seemed to work fine. In HTML5 not.

I did have a look through the code and found a bug that the atlasScale multiplier on entity was defaulting to 0.0. Which meant the eventual draw operation was drawn at scale 0x0.

'version 23
' - small tweak to set initial atlasScale in spineentity to 1.0 (otherwise images would render with 0x0 scale because multiplied by atlasScale = 0.0)

Let me know if this fixes it for you, tried in latest 83a version.

Soap(Posted 2015) [#80]
Works now! Thank you!

Soap(Posted 2015) [#81]
Could you give some insight into the best way of doing this?


What I want is an easy way to swap out images of slots programmatically, which replace presets in the spine files but are not included in the spine files. Similar to thing rIKmAN was talking about before. It seems like the proper way would be to build a new attachment and then set a slot to that new attachment.




Skn3(Posted 2015) [#82]
Hey Brian,

Looks like some nice tweaks to their UI!

So the best way would be to GetSlot() on the SpineEntity. You should then be able to set the attachment by just doing
slot.Attachment = theNewSpineRegionAttachment '(this sets via property)

You could create the attachment manually and it should work as long as you set all the fields properly.

Soap(Posted 2015) [#83]
How would you do that - creating the attachment manually? I am studying the Monkey Spine code, and it seems the way I am trying to do it is the hard way with maybe more steps than there should be.

The main problem is I want to use spare images as replacement for the attachments. As rIKmAN said before like the situation is there is a character which can equip any number of sword images but do not want all loaded in memory at once.

Skn3(Posted 2015) [#84]
'version 24
' - renamed SpineMojoRendererObject to SpineMojoTextureRenderObject
' - added SpineMojoImageRenderObject
' - added SpineMojoImageAttachment
' - added new example to demonstrate custom attachment
' - added SetSlotAttachment() and SetSlotCustomAttachment() to spine entity

Hey, I have added some functionality to the module. Check out the example to see it working. It is like other commands, you will have to make modifications to the slot each update.

Skn3(Posted 2015) [#85]
Local banana := New SpineMojoImageAttachment("banana_attachment", "monkey://data/banana.png")

Soap(Posted 2015) [#86]
You rock, Jon!! Thank you!

k.o.g.(Posted 2015) [#87]
Does Mesh Manipulation complete not work on html5 target?

Skn3(Posted 2015) [#88]
Hey KOG,

Html5 doesn't have draw poly (textured) so unfortunately not.

If you however wrote a monkey implementation for draw poly it would work without changes to the spine module.

If you were wanting to look into it, you might be able to look at webgl stuff to draw a poly with texture uvs...

k.o.g.(Posted 2015) [#89]

Sorry im not good in that :)
is it possible, that you look into this for me?

i found something like:

Skn3(Posted 2015) [#90]
Hey KOG, slow reply sorry. I don't think it's really possible without getting massively hacky. It would only be webgl possible I think, so that would be the route.

Spine module needs to be without hacks otherwise it becomes a nightmare to maintain. I'd be happy if somone else wanted to contribute?

mouser(Posted 2015) [#91]
I'm unable to render two or more spine-objects using the same skin. Only one of them is displayed.

Class Character
    Method New(skin:String, x:Int = 0, y:Int = 0)
        Super.New("characters", x, y)

oscar = New Character("oscar", 50, 120)
oscar2 = New Character("oscar", 150, 120)

rIKmAN(Posted 2015) [#92]
Been away a while and wow a lot has happened - Monkey2, Pyro etc, madness!

Thanks for the addition of the attachment stuff skin, I think it's exactly what I was after in previous posts :)

Quick question - would Mojo2 allow this module to use all the latest Spine features?

Obviously it would need to be updated, but is the core functionality there in Mojo2 to allow for bounding boxes etc as I know you said Mojo would make things very hacky in terms of updating to be in line with the latest Spine runtimes.

Skn3(Posted 2015) [#93]
Haven't had a chance to investigate mojo2 enough but I'd imagine so. Slightly busy at the moment with wedding planning, but it is on my todo list to take a look. I will have a look next week.

Peeling(Posted 2015) [#94]
EDIT: Nothing to do with Spine per se. Turns out Transcc explodes if you import too many files in the course of compiling your project.

Skn3(Posted 2015) [#95]
Appologies for any delays getting the spine module update for mojo2. I was in the process of getting married and going on my honeymoon :)

Well and truely married now!

'version 25
' - big update to port spine to work with mojo2

OK so I have updated the main branch so that we are running with mojo2.

If you are still using mojo1 you can access the archived branch here:

I wont continue to support this branch, but it is here for those who need it.

So this update I have got things working with mojo2. There are been quite heavy changes, and there are probably more that can be made in the future. For now it seems to be working OK. A few things to remember:
- all draw operations now need a drawlist/canvas
- all color values are now floats instead of 0-255
- html5 mesh deforms now working!

Let me know how you get on!

Peeling(Posted 2015) [#96]
First of all: Congratulations :)

Secondly, an FYI: I think there's a discrepancy between the way Spine transforms ordinary image regions and the way your module transforms them. Whether this affects your new version, I don't know; we're having to stick with the old version.

The relevant bit of code is this:

If snapToPixels
	region.RenderObject.Draw(Int(slotWorldX[index]), Int(slotWorldY[index]), slotWorldRotation[index], slotWorldScaleX[index], slotWorldScaleY[index], Self.atlasScale)
	region.RenderObject.Draw(slotWorldX[index], slotWorldY[index], slotWorldRotation[index], slotWorldScaleX[index], slotWorldScaleY[index], Self.atlasScale)

This code draws images based on the pre-calculated 'slotWorld###' values. Specifically, it uses a position, a rotation, and two scale values.

This means that everything drawn through this code will be a rectangle (strictly 90 degree corners). It will be at the correct angle, but the scale is propagated through from the bone to the region by multiplying bone.scale.x and region.scale.x.

This is how scale is propagated through the skeleton in Spine, but it is not how bone scaling is applied to regions attached to those bones. This is easy to demonstrate: just attach a region to a bone at 90 degrees, then scale up the bone's X-axis. In Spine the region will get bigger along the x-axis of the bone. In Monkey, the region will get bigger along its own x-axis.

If you put the region at 45 degrees instead of 90, you can see that in Spine the rectangle of the region is distorted into a diamond shape, while in Monkey the region remains a rectangle and scales along its own axes.

In our local implementation I've ended up adding 'slot matrices', concatenations of the slot's local matrix and the parent bone matrix, and passing that through to the Mojo matrix when drawing the region.

Peeling(Posted 2015) [#97]
Also, this line at the end of SetAnimation seems to cause a glitch:

dirtyPose = True

This forces the spine code to set the skeleton back to its Setup Pose after the animation has been applied, which means you get one frame of setup pose every time you play an animation.

I've changed it locally so that it only dirties the Pose if the animation is set to null; this seems to fix the glitch.

Skn3(Posted 2015) [#98]
Hey Peeling,

cool fancy sharing your version so I can review and add to official?

Peeling(Posted 2015) [#99]
I absolutely would, except that I've integrated the spine module into our own UI module rather than directly into Mojo (and our version of Mojo has been heavily modified as well), so the fixes aren't suitable for general use.

The glitch fix is dead simple: just don't dirty the pose at the end of SetAnimation.

The transform fix you could do one of two ways: for me it was easier to generate a matrix at the point where the 'slotworld' values were calculated (because all our UI rendering is deferred and done via sortable renderpackets). Since you're drawing directly through Mojo, it might be simpler to use the Mojo pushmatrix/scale/rotate functions to concatenate the bone and region transforms either before calling the region renderer or as parameters to it.

rIKmAN(Posted 2015) [#100]
Does anyone know the latest version of Spine the latest Mojo1 runtimes support?

Soap(Posted 2015) [#101]
I think latest Spine works with archived Mojo1 version.

I don't plan to update to Mojo2 for a while... I hope nothing breaks!

rIKmAN(Posted 2015) [#102]
I think latest Spine works with archived Mojo1 version.

I don't plan to update to Mojo2 for a while... I hope nothing breaks!

Same here!
If you could confirm what version of Spine you are using and what version of the runtime I would really appreciate it!

When I tried a quick update of Monkey and Spine my existing projects gave me errors, but I didn't have time to sit and look at it properly so assumed it was a version/feature mismatch with the runtimes and Spine.

Soap(Posted 2015) [#103]
Spine app is 2.1.27 Pro
Monkey Spine runtime version 18 in one project

It looks like latest is version 24

I've not needed to make new assets in a while, but I'll be working on it again soon so I'll confirm for sure what does work...

rIKmAN(Posted 2015) [#104]
Yeah v24 is the latest one I grabbed from the repo - I'll try 18 as suggested and update Spine on a laptop to 2.1.27 Pro.

Thanks for the info, I won't get time to code now til the end of the week but I will also report back what I find out when I get chance to play.

If skn3 still pops round here - could you confirm the latest version of Spine supported by the last Mojo1 runtimes please mate?

Soap(Posted 2015) [#105]
Did some spine work and can confirm it works. Later I'll test with the last version, as we probably should upgrade to it. If mojo1 version ever needs updating and we have not already updated to mojo2 I can help pay for more work costs to update it.

@skn3 maybe move the mojo1 version to its own git so it can still accept pull requests and so on?

Skn3(Posted 2015) [#106]
Will jump on this next week. Stay tuned :)

I don't get much time to monkey recently but do check back here and try to keep modules updated albeit sometimes slowly...depending on work load.

I'll get a response back in the week.

DeadFall(Posted 2016) [#107]
Any chance to switch from using 3rd party json and instead use the brl.json?

rIKmAN(Posted 2016) [#108]
Got a bit of a weird bug, and was wondering if anyone else had encountered anything similar.

Basically I am programmatically setting attachments during runtime, for example:
' set on
Self.entity.skeleton.SetAttachment("mySlot", "myAttachment")
' set to off
Self.entity.skeleton.SetAttachment("mySlot", "")

I am then trying to check the current active attachment name so i can do something depending on the result:
DebugLog "attachmentName: " + Self.entity.GetSlot("mySlot").Data.AttachmentName

To test I have set a couple of KeyHit() calls to turn on/off the attachment, and it works fine - it appears and disappears as it should.

However the DebugLog always returns "myAttachment" as the name, even when I have set it to an empty string ("") and it is hidden/off visually on screen as it should be.

I checked the Spine site and most other runtimes use "SetAttachment("mySlot", Null)" to do this, but I can't do this as SetAttachment only takes a string as the second parameter, and "" seems to do the trick visually, but the attachment name always returns the original "myAttachment" like it doesn't update or know it should now be empty "".

I am using the mojo1 version of the runtime, and wondering if I am doing something wrong or if it is a bug?

The issue is that I need to set/turn off an attachment based on Y position, and need to know what it currently is to avoid re-setting the attachment every frame if it is already set.

On a lighter note, Spine 3.0.0 is out!

Skn3(Posted 2016) [#109]
Sorry guys for slowwwwwwwwwwwww delay in getting back to you. I am still supporting this module.

I have updated the repo to use brl.json. I didn't even know monkey had gained its own json lib!
'version 26
' - removed dependancy of external json module and switched code to brl.json

I will jump on your bug soon (hopefully tomorrow) Rik. Sorry, I have run out of time today!

rIKmAN(Posted 2016) [#110]
No problem skn3, appreciate it mate, thanks!

Skn3(Posted 2016) [#111]

So the Data structure stores the loaded details so it never changes after loading. You should not really be using the .Data objects anywhere throughout the spine module. If you do, it will always return the name of the attachment, as you are seeing.

You may want to use GetSlot().Attachment. Check to see if it is null, if it is not null then you can check attachment.Name on the SpineAttachment object that was returned.

Does that help?

Function GetSlotAttachmentName:String(slot:SpineSlot)
	If slot.Attachment = Null Return ""
	Return slot.Attachment.Name

DebugLog "attachment = " + GetSlotAttachmentName(entity.GetSlot("mySlot"))

rIKmAN(Posted 2016) [#112]
Hey Skn3,

Ahhh OK that makes sense - and yeah I've not been using any of the .Data structures at all until now, it was one of those one of those where I tried a few different things and Data.AttachmentName seemed logical (to me) that it would return the currently active attachment name, and an empty string if null.

I'll try it when I get home later, but I'm sure you are right and that will work fine.

Thanks mate! :)

Skn3(Posted 2016) [#113]
No problemo! Hope it works!

rIKmAN(Posted 2016) [#114]
I'm just trying to convert an older project to use the new updated (v24?) version of the Spine Mojo1 module to see how much work is involved and whether it is going to be worth porting a larger project, but obviously a lot has been added/changed from the version am currently using (v18 I think)

Is it still possible to use separate images or does the new mojo1 runtime require we use an atlas?

My current project uses
player = New SpineEntity("player/player.json", "", SpineSeperateImageLoader.instance)

...and the image paths used are the paths from within Spine.

I see looking at the new example7.monkey we now need to use:

but this is giving me an error because it can't find "player.atlas", and I can't seem to use the overload methods either as "SpineSeparateImageAtlas" doesn't seem to be available any more?

Sorry for the stupid question but thought I'd ask rather than waste a few hours only to discover we do actually require an atlas now after all (if that is the case)

Also did anyone ever confirm the most recent version of Spine that works with the latest mojo1 runtime?

It's all got a bit confusing to me since the split between mojo1/mojo2 etc - is there a rough guide of what would need to be changed when porting a project from the old module to the new Spine mojo1 module?

Skn3(Posted 2016) [#115]
Do you have an example I can run?

What does player.atlas pertain to?

So the Mojo1 version is no longer supported but it is still archived on the repo. Is there any reason you are not able to use the mojo2 module?

In terms of individual image loader, I am pretty sure I removed this in the latest update as there really isnt a reason not to use an atlas. It would be possible to make new a new atlas loader and plug this into the loading routines. The spine module was designed to make this possible.

If you look in spinemojo.monkey you see I create loader functions which plumb in the global loader objects. Eg
Function LoadMojoSpineEntity:SpineEntity(skeletonPath:String, atlasPath:String, atlasDir:String)
	'allows to specify atlas images dir
	Return New SpineEntity(skeletonPath, atlasPath, atlasDir, spineMojoFileLoader, spineMojoAtlasLoader, spineMojoTextureLoader)

So you can see here this passes of the atlas loader responsibility to the spineMojoAtlasLoader object that is created in the global. If you check the source for SpineMojoAtlasLoader you can see its fairly simple. It returns a SpineAtlas object. We can return our own implementation of SpineAtlas to do whatever we want

So if you were to do something like:
Class SpineSeperateImageAtlasLoader Implements SpineAtlasLoader
	Method Load:SpineAtlas(file:SpineFile, dir:String, textureLoader:SpineTextureLoader)
		Local atlas:= New SpineSeperateImageAtlas
		atlas.Load(file, dir, textureLoader)
		Return atlas

Class SpineSeperateImageAtlas Implements SpineAtlas
	Field imagesDir:String
	Field textureLoader:SpineMojoTextureLoader
	Method Load:Void(file:SpineFile, imagesDir:String, textureLoader:SpineTextureLoader)
		'preload SpineSeperateImageAtlasRegion 's here
		'cache = new SpineSeperateImageAtlas();
	Method Discard:Void()
	Method FindRegion:SpineAtlasRegion(name:String)
		'load/get SpineSeperateImageAtlas
		Return SpineAtlasRegion(regions.ValueForKey(name))

Class SpineSeperateImageAtlasRegion Implements SpineAtlasRegion
	'implement SpineAtlasRegion here

Above code is pseudo code. The basic idea is you would have to make it appear to the spine module that it is using an atlas, but you have just constructed an atlas yourself. You could do this by loading separate images and creating the appropriate interface code to speak to the module.

You can see in SpineMojoAtlasRegion.monkey I implement all of the functionality that an atlas region has to. There is no reason you couldn't hook this up to do whatever you chose.

rIKmAN(Posted 2016) [#116]
Do you have an example I can run?

No the code doesn't run, I get the error I posted above, hence my post lol! :)
or did you mean an example of something else?

What does player.atlas pertain to?

I assume it's because in the above code I am trying to load "player.json" and so it automatically tries to load "player.atlas" for the atlas in the new (old archived) mojo1 module?

During dev I just use single images (or have been) as it's easier to manage (changes to images etc), but you said you have removed the SeparateImageLoader stuff, so now you have confirmed that I guess it makes sense why it no longer works when trying to use the last mojo1 module (v24?).

So the Mojo1 version is no longer supported but it is still archived on the repo. Is there any reason you are not able to use the mojo2 module?

Mainly just that it was written using mojo1 and is a large project that would take time I don't have to convert to use mojo2.
I'd also have to get to grips with mojo2 as I've not used it at all yet - no time again!

It's no problem, I'll just go back to using an old version of the Spine module and the latest supported version of Spine for that module.
v18 works, and I'm not sure when the change occurred to mojo1/mojo2 but I'll see what the latest version I can use is and set up a few different Monkey folders with various module versions installed that I can use as required until I can fully learn and move over to mojo2.

Cheers mate.

Skn3(Posted 2016) [#117]
Yo to the all,

Its been a while since I have posted here. Busy at work is my only excuse!

Anyway I have added an update to the module. It has also been back ported to the archived mojo1 version as well.

'version 27
' - fixed bug in attachment timeline, causing duplicate attachments to render!

This should solve duplicate attachments rendering on the first loop of animation.

mojo2: https://github.com/skn3/monkeyspine
mojo1: https://github.com/skn3/monkeyspine/tree/mojo1_archived

rIKmAN(Posted 2016) [#118]
Skn3 - that's awesome mate, as a mojo1 user thank you so much for backporting the fix! :)

Playniax(Posted 2016) [#119]
Great man!

Soap(Posted 2016) [#120]
Dragon Bones now exports to Spine 3.3 format http://dragonbones.com/en/animation.html

rIKmAN(Posted 2016) [#121]
@Soap: But you still need to own a Spine licence to use the Spine runtimes, so at that point you may as well use Spine as you have a licence.

Soap(Posted 2016) [#122]
Skn3 wrote the Monkey one so it shouldn't apply like the official ones do, but he did include this in the license so.. yeah.. https://github.com/skn3/monkeyspine/blob/master/license.txt I was going to say this would be a good option for people with very little money, but with this license even if Skn3 wrote it it's a no go unless he changes it.

rIKmAN(Posted 2016) [#123]
He wrote a wrapper for the official Spine runtimes, so the actual Spine licence applies as well - ie. need a Spine licence to use them.

Until DragonBones makes it's own runtimes (and they get converted to work with Monkey) it's a no-go for proper releases, although I suppose people learning with personal projects could go this route - just don't release anything.

What version of Spine are you currently using with the Monkey module mate?

Anatol(Posted March) [#124]
Hi! I'm just wondering if the Monkey Spine module supports meshes. A commit message mentions "meshes now animation, but no visual yet" but I'm not sure what that means. I'm considering to purchase Spine, but I'm yet unsure if the essential or professional version. The professional price is a bit steep, but if mesh deformation is supported it may be worth it. Well, the inverse kinematics feature alone would be awesome to have, but I'm a bit on a budget. Thanks. And many thanks also for the work you've put into this already, Skn3!

Soap(Posted March) [#125]
I'm pretty sure it does, but you can test running examples from the runtime with mesh deformations. Check git the old example might have that.

Anatol(Posted March) [#126]
Thanks for the reply. I'm trying hard to make the example work, I was testing the example8 and oldExample, and also a "banana" example from Pyro in bananas/e06_3rdparty/e02_spine/e01_render_to_scene_graph_layer.

It took quite a while to fix a lot of dependencies, i.e. importing everything from spine, glue, (spine) lib, json, fixing import paths from either spine or spine.spinemojo. It finally builds without errors but on HTML5 I only get a blank screen (no runtime error), and Android launches the app but crashes immediately on FATAL EXCEPTION: GLThread 13845.

Has anyone managed to run this? I checked out the latest master. It looks like there went a lot of effort into this, so it'd be nice to get it to work.

Anatol(Posted March) [#127]
Sorry, my bad. You know how you publish the post and in the same moment the penny drops? Well. I should've just checked out the entire monkeyspine into my MonkeyX modules folder, and make sure that the folder is called "spine", not "monkeyspine". The example works out of the box. I don't quite understand the example yet, but at least it's running.

example8 looks more like a spritesheet animation, but oldExample is similar to this one.

Soap(Posted March) [#128]
If you have questions feel free to ask. I worked with Spine a ton a while ago so I can probably answer most general questions. One important tip with animation of meshes is to never animation single verts, and instead animate bones which are weighed on your meshes. Animating single verts is dramatically more resource intense because of the lack of batching.

Anatol(Posted March) [#129]
Thanks Soap. I'm just starting with this. I have no experience with Spine (and still only have the trial version), but I did rigging with bone weights before in Blender and with stop motion animation. I love the idea to work with an armature, once the character is set up properly it's fairly easy to animate. I'll keep playing with this, but no doubt I'll have questions. Thank you!

Anatol(Posted March) [#130]
OK, so MonkeyX definitely supports mesh deformation and IK. I just went through the different demos in the "old example" and set TEST to any of the available modes. Tested on HTML5 and Android. That's quite powerful!

Anatol(Posted March) [#131]
In case anyone else wants to know, I tested if Spine in MonkeyX supports light sources, and it does right out of the box! This is one of the bananas examples with added light source plus normals and specular map on the Spine texture atlas. Even for Spine with mesh deformation, the maps get transformed just the same. It just works. Nice!

rIKmAN(Posted March) [#132]
Good stuff Anatol - fancy posting a small example? :)
I've been meaning to get some use out of SpriteIlluminator which I got in a HumbleBundle a few months ago.

Also what version of Spine are you using?