That fixed it, thank you!
RafaSKB

- 11. srp. 2022
- Pridružuje se 28. stu. 2014
- Uređeno
Hello
I'm having an issue loading a skeleton model into the game because of aNullPointerException
: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 on4.0.18.2-SNAPSHOT
.
The skeleton was exported on version4.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:
- 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.
- 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!
- Uređeno
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!
- Uređeno
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.
- Uređeno
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]
- Uređeno
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.
- Uređeno
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.