As a Spine user, I realise GMS1 will not be getting any further updates past the one currently available in the EA, and so with one eye on the future I am obviously looking at GMS2 and have been mulling over whether to purchase it. If I did, I would also be purchasing the "Mobile" exporter for iOS / Android development when available, so it's a decent chunk of change and not something I can afford to purchase and never use, or have it be unsuitable. So, currently I'm quite disappointed with the Spine functionality in GMS - even with the newest update that added Events it's still a pretty slim implementation of the Spine Runtimes and all the functionality it offers. There are about 12-15 skeleton_* commands available to work with and manipulate Spine sprites and animations, which in the overall scheme of things in terms of the Runtimes is pretty slim pickings. So I am wondering if it would be possible for @Mike, @rwkay, @ShaunJS or any of the YYG staff to let me (and other Spine users) know if there are any plans to implement more Spine related functionality in GMS2 going forward? Are there any plans to bring the GMS2 implementation in line with the features already included and offered in the Spine Runtimes? Hopefully there is, but if not could you elaborate why not? I love Spine, and it being supported in GMS1 was one of the reasons I decided to give GMS a go, but compared to other languages and engines the features and functionality for Spine animations is pretty basic. I've even used 3rd party wrappers of the very same Official Runtimes written by individual community members of pretty niche products that offer way more functionality. This isn't a complaint, or an ultimatum or anything of the sort - I'm merely asking so I can plan ahead, and either get my head into GMS2 knowing that new features will be added to the Spine support, or save my money, move on and invest it elsewhere in other tools that will compliment the superior Spine support I already have in other languages and engines. I've read GMS2 is written from the ground up with extensibility in mind, and I know you can't give me a concrete answer - but is it something that you agree needs working on and would be looking to improve going forward, or are you reading this thinking that the current implementation and available commands are more than enough and wondering wtf I am talking about? If you need any examples of the sort of things I'm talking about I'd be happy to provide them if requested (and I'm sure other Spine users might chip in with their own) but this post is already way longer than I anticipated! Thanks for reading, and apologies for a bit of a ramble.