What's the last thing you folks on the Spine team have produced, besides Spine? Have you made a video game using Spine, since establishing the company? Who plays it, if you did? Who is Spine for?

Observations:
The priorities in product management appear to be either incredibly disorganized, or not considered.
It's a dysfunctional way to produce software, and would be a shame to see this be the reason this tool & company collapses.

Solutions:
Have a clear cut answer to: "who and what is Spine for?"
Listen to specific user feedback. It's tangible (not assumed direction).

I suppose you have some good points there.

We could just list the Unity-specific changes separately a page linked on the Spine-Unity Download page, since that's where we also hoped to centralize the update notes too. It used to live in a forum thread.
And a Twitter account just for spine-unity whenever there are minor but meaningful changes and fixes get pushed to an updated unitypackage.
Major features and changes are still going to have a forum topic.
We could also add a simple text file to the spine-unity folder to keep the editor version match of it.

Still, note that major updates (eg, from 3.5 to 3.6) need to be applied to Spine Editor, the runtime and all exported skeletons at the same time.
That's one reason why we would not tend to go with automatically pushing updates to people, or channels that would make it easy for people to accidentally update one before updating the others. A lot of users have been burned by this before (which led to a lot of extra work needing to be done at a critical time in their development cycles.)

Also note that the runtime isn't an OS, browser or mobile app that has security fixes that people need to get regularly and immediately. You see and control the code, and you could make any changes to it and tell what's wrong when something goes wrong. If something does and there's no fix, you can report it and we can investigate and fix it. If you think there's an essential feature missing, you can post in the forums.

The legal stuff has to do with this: https://unity3d.com/legal/as_provider and Spine runtime distribution requiring that the user have a Spine License (ie, "bought Spine"). The Spine runtimes are source-available but are not under an open source license. I don't know enough about it to explain in precise terms. I'll try to find someone to clarify what's unclear.

You don't seem to have posted often though. Which responses have been insufficient/unhelpful? And what are these common animation industry techniques?

pasquale, it's disconcerting to hear you think we don't listen to users, as we put considerable effort into supporting our users. You've only made 2 posts, one of them this complaint, so I'm not sure why you feel so jaded.

Everyone, we welcome all feedback, however this thread is about staying on top of runtime updates so let's try to stay on topic.

jacobbijani, you make some valid points and we have been working to improve our runtime versioning. Starting with version 3.5, we release editor updates as betas until all runtimes are up to date, then we do a non-beta release. Starting with 3.6, all Spine users will receive a non-beta release email announcement (which they can opt out of). This is the highest level versioning event and probably what most users are interested in. It is equivalent to what you are used to for versioned releases of other assets that you may use and is likely a good time to update your runtime version.

Git master always works with the latest non-beta release. Between non-beta releases we do minor fixes in master. We do this so users do not need to wait for the next big non-beta editor release to get minor runtime fixes. If you aren't having problems, you probably don't need these fixes. These are versioned only by Git commits, though we have recently begun documenting API changes/breakage and behavioral changes in the CHANGELOG.md file in the runtime repository root, categorized by runtime. The idea is that users can look here when updating rather than digging through Git commits to find important changes.

As Pharan mentioned, the Git commit history provides the most granular view of runtime changes. Note that you can view the history for a particular folder if you are interested in changes for only a specific runtime. For example, see the spine-unity commit history. I think push notifications for commits would be too granular/noisy, even for a specific runtime.

I would guess that very few other products provide Git access at all, so you would never even see commits during development, only at each release. While we provide very granular access to the runtime source, it is not necessary to stay updated to the very latest. Updating any software dependency involves risk and is not a task to be taken lightly.

In defense of Esoteric, they have given great feedback to me and others who are actively in the forums. I've always felt this is one of the best supported packages.

Related to your question about that final point:

The Unity2D thread about performance hits and improvements using rigid bodies only happened last week and Pharan already implemented the update using kinematic rigidbodies to improve the performance. (I think it was actually done a couple days ago!)

Pharan is highly dutiful and responsible - he even released an early root motion exploration that several people used that I saw.

pasquale seemed to want to have a general gripe session in a thread he didn't start which is about update announcements. Asking to keep a thread from getting derailed is perfectly reasonable.

jacobbijani wrote

I think you should focus less on how many posts we have, and just on whether or not what we're saying might happen to be true. I've read and searched on the forum since finding Spine. You can surmise a lot about a community without posting yourself.

From our perspective, when multiple new users appear and begin dog piling complaints, we are interested in where those feelings are coming from. It appears that you are complaining that nothing works and that we provide poor support without ever having asked for assistance.

jacobbijani wrote

In a small way, your post is an example of what I'm talking about. Isn't this my thread? Why not just reply to my concerns here? You sort of just glossed over them, and only replied to the update stuff.

You stated you were frustrated and you criticized our support. I thought providing you our usual, good support for the problem you stated would be appropriate. I am sorry that you feel frustrated using Spine. I expect we can improve that if you give us a chance.

jacobbijani wrote

While I can obviously choose not to update my runtime, what's the point of you publishing changes if I don't incorporate them? I've only ever downloaded the latest unitypackage from the website.

If you want versioned updates, you get those when we do big releases like 3.4, 3.5, and soon 3.6. If you want more granular updates or don't want to wait for the next release to get fixes, you can look at the master Git branch. If you want bleeding edge you can look at the X.X-beta Git branch (currently 3.6-beta). There's no reason to get the latest after every Git commit, though you can if you like.

jacobbijani wrote

Our biggest one is with root motion.

I'll let Pharan field this one.

jacobbijani wrote

Another, on the editor side, is with looping. To make an endless loop, we duplicate the first and last keyframe. The editor has an option to control where your loop cycles from. However, when we export for the runtime there's no way to exclude that final duplicate frame.

Why do you want to exclude the last frame? That frame is needed to tween values so they match the first frame when playback is looped. Consider this animation:

frame 0: 10
frame 50: 20
frame 100: 10

If you removed frame 100, the value would tween from 10 to 20, then stay at 20 until playback looped, then it would snap to 10.

jacobbijani wrote

I've found that via "trackEntry.animationEnd" there's a way to control where a loop stops, but it's time-based. It'd be so much easier to just "drop the last frame". Instead, once it's in the runtime, I have to do some magic-number-backed math to figure out where the final frame starts. This is looping, which seems incredibly core. "How are people doing looping? Do they not run into this?"

What exactly is the problem you are trying to solve?

jacobbijani wrote

The last example I have right now is the way BoneFollowers work. They're incompatible with physics-backed GameObjects in Unity. Once something has a Rigidbody2D, you get a performance hit if you move it with it's transform (as the physics engine has to recalculate the scene). I've had to reimplement your BoneFollower script to my own based on Rigidbody2D's MovePosition/MoveRotation. Our characters have colliders, which we track to a bone. "Are we really the only ones doing this? Has no one else noticed the performance hit?"

I expect Pharan has input here, but what you are doing doesn't sound crazy. It sounds like maybe we could provide a RigidbodyBoneFollower script. Users will still need to use the appropriate one based on their scenario. Or, as Xelnath mentioned, an optimization may be already done.

jacobbijani wrote

Thanks for hearing out our feedback. And thanks for dedicating your time into making this thing at all.

Thanks for providing the feedback. We know there is still a lot we can do to improve the runtimes and we are actively working on improving them.

For Root Motion, have you seen this module? https://gist.github.com/pharan/bc0e07647f6c066f432385518ac49149
If you're using Mecanim, there's not much we can do with the limited API they expose.
We can adapt the above code but loops will be a problem, which I think is a major part of root motion so it would be largely unusable.
If we had a callback or could detect loops reliably, problem would be solved.

In what way do you mean "movement code" not involving root motion?
Do you mean other than having a Physics Rigidbody control the Transform? or taking direct control of the GameObject's Transform position yourself? Is there a different paradigm you're after?

For BoneFollower and physics, did you mean BoundingBoxFollowers?
As Xelnath mentioned, there was a recent update where it now automatically adds a new Kinematic Rigidbody2D so it doesn't incur that cost anymore. That's actually mentioned in the upgrade notes.

If you were just using BoneFollowers, note that they are pretty agnostic to what you add to the GameObject they belong to. BoneFollowers can be used for purely graphical things like particle systems and sprites. Even other skeletons.
So if they were custom colliders, you should also add a kinematic Rigidbody2D to each as well to eliminate that physics model rebuild, in which case, moving the transform would be fine albeit it would not have interpolation in the physics update.

Pharan, one problem I've run into with Root Motion and spine has been that the root point snaps or blends back to the zero point and accurately keeping the visual skeleton and the gameplay component in the right spot is challenging and hard to do.

Especially if you're blending animations together.

Just $.05

Good point, Xelnath.
Maybe this needs custom apply code on the AnimationState, like we do with EventTimeline to get the custom threshold.
We'll have to take a look at this over the week.

Xelnath and I did have a bit of a discussion with the Unity Technologies programmer who did the box2D integration.
The Rigidbody2D is a bidirectional integration component between UnityEngine.Transform and an internal box2D body representation.
Moving a Rigidbody2D's transform is fine. It doesn't cause performance issues, but it does apply changes immediately and removes interpolation (in the case where you are moving large distances).
Applying motion using MovePosition/MoveRotation applies the change in the physics update, and is recommended if you want physics faithfulness, crucial if things are moving really quickly.

Thanks for reporting that outdated docs.
I personally would want an API Reference that was just for Unity users so they don't have to look anywhere else, particularly for beginners programmers (plenty of whom are Unity users) who would just be thoroughly confused by the language-agnostic docs we currently have, though I'm not sure how much sense that makes for updates.

Having a sample case would be useful, yes. We'd have to be sure it's general enough to be useful to most people.
If you can share a usable Spine project or exported assets, you can send them to contact@esotericsoftware.com
Watermarked or blacked-out images would probably be fine for our purposes if you're concerned about it leaking.

The "official way" to prepare the Spine rig would come with the correct implementation.
Currently, I can't imagine what limitations it would impose on root bone movement in Spine Editor. I suppose ambiguities would arise if the Transform were scaled, but that's on the Root Motion implementation end.