Esoteric Software

[tjbrunetto]

Hi Esoteric Team,

I have been using Spine for the better part of 4 years now. I really like your product and it has allowed me to make an amazing game. I have had issues with Spine costing me lots of time since 4.0 was released and the new editor graph was implemented. I often times find myself with moments where at frame 7 I want the rotation of an object to be 45 and then at frame 10 I want the rotation to be 90. Instead of rotating from the direction it was initially rotating at, the object does a complete loop in the opposite direction. This has been annoying me for about 4 months now and I finally decided to post about. This has been costing me time, not a ton of time, but this is a bug that should be squashed soon.

Just my 2 cents.

Tim

[Drako]

Perhaps you will find your answer in this quote:

In Spine < 4, interpolating between two rotation keys will always take the smaller rotation direction.

In Spine > 4, this behaviour was changed with the introduction of the new graph view. Rotations in the positive direction (smaller to larger, i.e. 102 to 236) are always clockwise. Rotations in the negative direction (larger to smaller, e.g. 102 > -123) are always counter clockwise.

This is not a bug, but a feature.

Quote from there - [Editor][Spine web player]: rotation for bones in animations

[Nate]

It would help if you can provide steps to reproduce the behavior that is causing you problems.

Note if you have World axes selected in animate mode, you will only be setting the direction the bone is pointing, you won't have full control over the local rotation direction and can't set local rotation > 360 or < -360 -- choose Local for that. In 4.1 we show a toast message when setting rotation > 360 or < -360 with World axes.

If you are struggling with the new graph, 4.1 has a new version of the old graph. You can check it out in the beta now.

[tjbrunetto]

Hi Nate,

Thanks for the reply. I will be giving the local axis rotational shifts a try and see if that solves my problem. I would be interested in trying out the new version of the old graph. It lacks the power of the new graph but in most cases in regard to my own personal animating abilities, it was faster.

Tim

[stikkanimate]

Just to jump on this instead of opening a new thread Nate, may I ask:

1. Can 4.1 beta JSON exports be expected to work the same as current Spine? If I send an export to our gamedev, would there be anything you can think of that would/could be expected to cause a failure due to 4.1 features?

2. Do you have an estimate for when stable 4.1 might be out roughly or a place where we might see the release date estimate?

[Nate]

1) Not sure what you mean? 4.1 runtimes have some differences to add sequences and other things, but otherwise work very similar to 4.0. 4.0 projects will work the same in 4.1, if that's what you are asking. We haven't made changes to the behavior of existing features.

2) Estimates are never a good idea with software. We would like to finish quality of life improvements and add physics in 4.1. Pushing physics to 4.2 is an option, but that would be a bummer.

To use 4.1 while in beta you likely need the runtimes to be updated. We generally update them quite rapidly, with spine-libgdx being done first and then spine-unity being done soon after. Then usually spine-ts is next, then the rest.

---

@stikkanimate, BTW you once asked about weight transfer from a bone to another bone. You can now do that in 4.1.16-beta, a little explanation here:
https://github.com/EsotericSoftware/spine-editor/issues/301#issuecomment-1025017727

4.1.16-beta allows locking bone weights. You can lock all bones except for 2, then remove or add to one of the unlocked bones to transfer weight from one bone to the other. This covers the desired use case and more.

Note that selected bones are always affected, even if locked. So you can lock all bones, unlock one, then select another and adjust it.

To quickly lock/unlock many bones, press an hold on one of the lock buttons (the colored squares), then drag to other lock buttons.

[stikkanimate]

Thanks Nate, I guess I'll stick with 4.0 for now then.

I'm only asking for a rough estimate because I'm hanging on for 4.1 like a parched man hoping for a drop of water. The 4.1 beta is a full silver jug of glistening clear spring water just out of reach while 4.0 is the wrought iron chain on my leg.

You said soon when you linked the beta so I was hoping that meant within a week or so. If the release is expected to be longer than a month, then I'll begin taking in less animation work so I can keep my mental health. I truly am aggravated every single day I work with 4.0

And thanks for the bone weights consideration, sounds like a great workaround!

[Nate]

Sorry, it's almost certainly more than a month. We'd need to stop development now and roll with what we have for 4.1. That's actually doable because the 4.1 is quite stable (at least as of 4.1.16-beta), but we reeeaally want to get physics finished.

We don't normally recommend this, but it's likely OK to work in 4.1 and then export JSON data as 4.0 so you can open it in 4.0. That has the risk of data loss, but currently when 4.1 writes JSON data for 4.0 it does the following:

• Removes sequences from attachments and animations.

• Moves deform timelines up a level.

• Renames "attachments" timelines section.

• Slot attachment keys need null name if omitted.

Except for removing sequences, the rest are just juggling data around without data loss. Physics will be removed similar to sequences.

[stikkanimate]

ahh okay, that sounds a bit scary going between 4.1 and 4.0 but I'll give it a shot once I'm past this current deadline. Thanks Nate!

Also another minor QoL request (I know I ask a lot, thanks so much for your patience): Can we get a setting slider for how long it takes for a dopesheet selection bar (Click+Drag+Hold) to lock in? Currently the wait time is long enough to feel like a cumbersome feature. For people like me who want a selection box every time I drag, it'd be helpful to be able to customize how long the mouse has to be held before it locks in with the lower limit at 1ms.

[Nate]

No slider, but in 4.1 there's a setting to turn off the delay entirely, and it's off by default.

[spineappletree]

No slider, but in 4.1 there's a setting to turn off the delay entirely, and it's off by default.

Nice!