Guaranteed official support doesn't help if Photoshop is lacking a feature you need. Try asking Adobe for a specific feature or even a bug fix and see how long it takes. The benefit of our small team is that we are much more agile and responsive.

Even if we were open to a source license, I don't think you really want to be working on the editor. The runtime source is open, which can facilitate development of many needs.

For the specific feature you mentioned, changing the texture used by a mesh so the mesh structure and FFD continues to be used, you could do this via the runtimes. Briefly, setup your mesh in Spine with a single texture. At runtime, get the MeshAttachment and adjust the UVs to point to a different region and optionally change the texture it uses. Lacking editor support to key this switch this makes it more difficult to key in animations. Events could be used to key the texture switches, though this would still lack visualization in the editor..

Adobe certainly has a lot of manpower, but they won't fix your bugs and release an update the same day it was reported or even write down your feature requests.

The main reason we don't license the source is the risk it puts on our business. This is separate from my opinion that getting involved with setting up and forking a complex tool is not usually necessary.

It depends on your use case as to how much of a hack it is. The various textures need to be very similar to be applied to the same mesh, so all that is involved is a visual check for replacement textures. It's not uncommon to have a tool for previewing skeleton configurations and associating/editing game data. This could allow artists to preview their mesh texture swapping, hot reload images, etc. The skeleton viewer tool is nearly what you'd want for this and it's only ₁₅₀ LOC (without UI).

There is a similar situation which is common, where an app has hundreds or thousands of images per slot. It doesn't make sense to do the work of attaching them all in Spine just to preview that the art is correct. It's much more efficient to setup only a single image per slot, like a template, then programmatically replace the attachments with the actual images needed. In this case you'd also want a tool artists can use for previewing.

Best of luck figuring out how you will be building you game! If you have any more questions or concerns about how Spine might work for you, feel free to ask them here.

nozomiyume, you are a pain the ass. It is wrong to criticize the way you want to take your intellectual property.. is not your problem. Also you dont have obligation to buy the software.. seriously... go somewhere else

newbacknew, you are free to disagree with others but please keep it civil.

I actually thought he was just fine. Disagreeing with an assessment is nothing at all like being a pain in the ass. The entire discourse between Nate and homeboy went smoothly enough to me.

I would like to pitch in. Not that the previous support was bad at all, but from our view (myself and the boss man here) spine 3.0 has been a massive pain in the ass in terms of the 'official support'. It isn't just the massive down time that is the issue, although it was/is (things seem to be picking up on the forum), the problem, for us at least, was the lack of patches. Spine 3.0 has caused a lot of (critical) bug fixes to be locked behind a v3.0 wall. And because the update has taken/is taking so long this is highly frustrating.

In my opinion bug fixes should have been done on another branch of the repo, so they could be released without having to wait for 3.0. It is annoying to work with the editor which currently has many frustrating bugs (now fixed in 3.0), but what's worse is we are coming to the end of a project, and wont be updating to spine 3.0 to get the bug fixes. (unless of course there is an 'use old ik and scale' tick box, so projects work exactly the same)

I hope the support returns to its previous glory.

BinaryCats, I agree not having a proper branch was a mistake. It was a minor update that grew organically. We thought we could reach v3 in a timely manner, then got stuck in a quagmire. Wait until you see the IK solution that works with nonuniform scale!

The v3 changlog has grown a bit, most notably is support for multiple font sizes (much easier to use on high DPI displays) and the ability to type characters in various languages: Latin/Cyrillic/Greek, Chinese, Japanese, and Korean. The fonts are too large to come as an update, so they need to be included in the launcher. Since v3 requires a launcher update, we decided it should go into v3 rather than force another launcher update shortly after v3. In other news, development on v3 continues every day. All that remains is fixing up minor issues with the tools and other aspects that the scale changes introduced. Most of these are simple, though some are a bit tricky.

v2 projects will still work in v3. To avoid having to do some minor fix ups, avoid using 1) flip, 2) non-uniform scale, and 3) avoid disabling scale or rotation inheritance.

@Nate, Spine V3 is going to work with the actual Unity Runtime? or is going to need another new runtime?
I want to know this because I bought the Assets Gunman and Hitman from your store.. this assets are compatible with Spine V3 if I want to create new animations..?

Thanks

Spine-Unity is made up of actual Spine-Unity and Spine-C#.
v3 needs a new Spine-C# but Spine-Unity will stay mostly unchanged.
v3 is mostly changes in how transform information travels through the bone hierarchy, which is defined in Spine-C#. Spine-Unity's core is mostly asset management and rendering and won't noticeably change.

Spine-Unity's utility classes, where it interacts with bones, will likely break though in cases where scale is not (1,1) or was negative or where flipping was used.
Because of this, the extra tools Mitch made may need to be fixed but he did say it would be easier supporting v3 than it was supporting v2.

Can't comment on Gunman and Hitman compatibility 'cause I don't know.
But if you want to make new animations, they'll work fine in all cases where you didn't change the scale to anything except 1,1 and you didn't use single-bone IK (which was broken).
It's really the utility scripts that need updating.

Hi Pharan..
In any case will be an update on Hitman and Gunman asset if that asset need for the Spine-Unity Runtime, right? they will remain outdated?

I remember Mitch said he'd update them.

awesome.. thanks for the info Pharan

Sorry! another question..
There will be some way to keep using Spine v2 with the current Sine-C# & Spine-Unity after the V3 release.
I say that to keep safe projects without much change

I'm not sure what Nate is planning with backwards stuff. Pretty sure there won't be any newer versions of v2.

But currently, the Spine editor retains all previously installed/downloaded versions you can switch to so as long as you don't delete those, you can continue to use them. You can access it in the settings menu (F12)

(This feature was included in case a new version is unexpectedly crashy in your setup. And I guess so you don't get bitten by version changes and don't have to keep updating at an inopportune time.)

So yeah. I'm pretty sure this feature isn't going away and you can continue using an older version of Spine to keep working on your current project.

Pharan ha scritto

I remember Mitch said he'd update them.

Yea, those'll definitely get updated, along with a new Equipman asset getting released sooner or later... (Probably coinciding with V3 at this rate).