That fixed it, thank you!

Hello
I'm having an issue loading a skeleton model into the game because of a NullPointerException:

Caused by: java.lang.NullPointerException: Cannot invoke "com.badlogic.gdx.utils.JsonValue.asFloat()" because "curve" is null
   at com.esotericsoftware.spine.SkeletonJson.readCurve(SkeletonJson.java:1032)
   at com.esotericsoftware.spine.SkeletonJson.readAnimation(SkeletonJson.java:848)
   at com.esotericsoftware.spine.SkeletonJson.readSkeletonData(SkeletonJson.java:347)
   ... 22 more

I'm using the libGDX runtimes version 4.0.18.1, and got the same error on 4.0.18.2-SNAPSHOT.
The skeleton was exported on version 4.0.22 (I just learned about keeping Editor and Runtime versions synchronized while searching for similar issues here).

Assuming the difference in versions is indeed the issue (lesson learned), I have two questions:

1. After reverting the editor from 4.0.22 to 4.0.18, how do I open the .spine file there to export it again? The editor won't open the file due to it being edited in a newer version.
2. Where can I find the 4.0.22 runtimes for the libGDX backend?

Or perhaps that's a completely unrelated issue. I can send the project files if necessary.
Thanks! :grinteeth:

Downloading Spine again and reinstalling it indeed fixed it, thanks!

Hey, I'm using Spine 3.8.76 Essential and tried to open a skeleton my artist uploaded, but I got a warning about it being made in a more recent version (3.8.79 Pro). However I wasn't prompted to update the editor, and I always try to keep it up to date.

When I open the editor Settings, the version to be used is set to "Latest", and the current version is reported as "Spine version: 3.8.79 ESS, launcher: 3.7.81". There are no newer versions available in the drop down menu either.

So I searched the forums here and didn't find much information about it, except for Spine devs requesting the spine.log file. Indeed there are some errors there regarding the update process.

I'm attaching the file to this post, which can hopefully be of any help.

Thanks!

Oh that's extremely useful, thank you Erika!

Hey Spine team, I just saw the 3.8 news and the new features are amazing, so I decided to update my libgdx runtime to take advantage of them, when I read in the changelog "Old projects must be exported with Spine 3.8.20+ to be compatible with the 3.8 Spine runtimes."

This makes perfect sense, the Json and Binary formats have changed, but for someone who has nearly a hundred different Spine models per project, that would take very a long time. I imagine this is also the case for most developers working with Spine that want to update.

Is there a way to auto update these models without having to go through the exhausting task of updating them manually one by one? Any chance an auto updater tool can be released? Or maybe a mass update button in the Spine editor itself?

Thanks.

On my game I have a Spine character that holds a weapon, which is another Spine model entirely. The weapon is attached to the character's hand slot as a SkeletonAttachment. In some cases the character is resized, so I just scale its root bone, and this used to work just fine before version 3.x, but now the SkeletonAttachments ignore the parent's scaling when rendered. I'm using the latest runtime from master.

Looking at the SkeletonRenderer class I notice there are two lines commented out:

// rootBone.setScaleX(1 + bone.getWorldScaleX() - oldScaleX);
// rootBone.setScaleY(1 + bone.getWorldScaleY() - oldScaleY);

Reenabling them fixes the issue completely, so I wonder if there's a reason to disable SkeletonAttachment scaling or if it's just a silly bug.

Should I keep the change and possibly wait for an official commit, or should I scale the attachments manually as I scale my parent skeleton?

Thanks

Yes I completely understand and agree that if aggressive API changes need to be made, the sooner the better.

Thanks for the complete vs end tip, that might solve it all

I just tried the latest version from master but for some reason AnimationStateListener's end method isn't being called [libgdx]

Something weird just happened to my skeleton and I wasn't able to reproduce.

After selecting a specific bone, every other action I did —like renaming a bone— caused it to be scaled by something like 80%. I recorded a video to better explain the issue:

http://take.ms/Fy811
(or if it doesn't work: https://monosnap.com/file/Zkqhv18wQ3GcawSpXUdFJGjmX8dDG2 )

I uploaded a log file as well, although I'm not entirely sure it refers to the same session. I made sure to upload the log before closing the editor while the bug was happening, so it wouldn't be overwritten.

The solution I found for my game was to create two bodies, flipped and not flipped, and enable/disable them as I need.
As for contact events, I keep track of the contacts that are happening and cancel them if they shouldn't be triggered.

Surprisingly, this method had no performance issues at all, and handling the contact possible issue, it was flawless.

I just updated my Spine Editor and Runtimes to the latest version (3.4.02, up to commit 94dcbf4125d52804bb2b0b6952f199b4322f02d0), re-exported all models, and now I'm getting an exception whenever I try to load any model that has indexed names, such as leg_left_02 or segment_1.

Caused by: com.badlogic.gdx.utils.SerializationException: Error reading attachment: leg_left_02, skin: default
   at com.esotericsoftware.spine.SkeletonJson.readSkeletonData(SkeletonJson.java:248)
   ... 23 more
Caused by: java.lang.RuntimeException: Region not found in atlas: leg_left_02 (region attachment: leg_left_02)
   at com.esotericsoftware.spine.attachments.AtlasAttachmentLoader.newRegionAttachment(AtlasAttachmentLoader.java:49)
   at com.esotericsoftware.spine.SkeletonJson.readAttachment(SkeletonJson.java:304)
   at com.esotericsoftware.spine.SkeletonJson.readSkeletonData(SkeletonJson.java:245)
   ... 23 more

In this case, this is how my skeleton.atlas looks like:

skeleton.png
size: 1024,1024
format: RGBA8888
filter: Linear,Linear
repeat: none
body
  rotate: false
  xy: 1, 66
  size: 625, 916
  orig: 625, 916
  offset: 0, 0
  index: -1
leg_front
  rotate: false
  xy: 628, 771
  size: 220, 211
  orig: 220, 211
  offset: 0, 0
  index: 1
leg_front
  rotate: false
  xy: 628, 480
  size: 136, 289
  orig: 136, 289
  offset: 0, 0
  index: 2
leg_front
  rotate: true
  xy: 244, 13
  size: 51, 215
  orig: 51, 215
  offset: 0, 0
  index: 3
leg_left
  rotate: true
  xy: 628, 260
  size: 218, 131
  orig: 218, 131
  offset: 0, 0
  index: 1
leg_left
  rotate: false
  xy: 628, 62
  size: 198, 196
  orig: 198, 196
  offset: 0, 0
  index: 2
leg_left
  rotate: true
  xy: 1, 1
  size: 63, 241
  orig: 63, 241
  offset: 0, 0
  index: 3
leg_right
  rotate: true
  xy: 850, 765
  size: 217, 152
  orig: 217, 152
  offset: 0, 0
  index: 1
leg_right
  rotate: false
  xy: 766, 532
  size: 52, 237
  orig: 52, 237
  offset: 0, 0
  index: 3
leg_right
  rotate: false
  xy: 820, 552
  size: 134, 211
  orig: 134, 211
  offset: 0, 0
  index: 2

Shouldn't Spine look for leg_left, index 2 instead of leg_left_02?

I was just scratching my head having the very same rotation problem, then manually applying the math patch above plus disabling the bone inherit scale fixed the problem.

Hey Nate, I'm from Brazil as well and just reviewed the purchase page translation, nothing wrong there.

"Todas as atualizações futuras serão fornecidas sem custos adicionais." means exactly what you said.