Mario wrote

Look what objects are keyed in your second screenshot. It's the AnimationPlayers beneath the SpineAnimationTracks, not the SpineAnimationTracks.

Yabadabadoooh. I know what the problem is.
When I add an AnimationPlayer for a SpineAnimationTrack, the display in the Animation Editor remains empty:

I have to close the scene and open it again.
I discovered this by accident this morning. After I opened the project, all the entries I wanted were there.

Is this a Godot problem?

Related Discussions
...
deezaster wrote

I have to close the scene and open it again.

Is this a Godot problem?

Not sure, but it is worth noting that Rayxuln's module has a similar problem where certain changes don't appear unless you close and reopen the scene.

Depends on the Godot version. 3.4 has a bunch such issues (unrelated to the module). Imtried to work around some of them. 4.0 is a bit better in that regard, but not quite stable.

@deezaster, I should get to writing docs next week, so I can better illustrate how this is supposed to work.

9 days later

Issue 1 - I am unable to run exported scene in Web browser with spine-godot runtime on Godot 3.4.4-stable (I used ./setup.sh 3.4.4-stable to create custom godot binary), all the spine related cpp files are not found by godot in browsers console.

Issue -2 Not able to build with current godot master branch

Update : silly mistake, forgot to build export template, html5 working fine with 3.4.4. thnks

16 days later

The latest commit fixes building with Godot master. Note that we can't always keep up with their master branch, as it's being quite... "dynamic" in API changes. Godot 4 is also far from ready to be for production. We'll ensure compatibility once Godot 4 RC has been released.

a month later

All right, so now I have to ask: does the beta Godot module work with Spine 4.1 output? Like, do sequences work with it?

Having a little trouble getting it to compile! I've assembled everything as the directions gave (spine_godot in /modules, spine-cpp in /modules/spine_godot), but I keep getting this error:

Animation.cpp
modules\spine_godot\spine-cpp\src\spine\Animation.cpp(30): fatal error C1083: Cannot open include file: 'spine/Animation.h': No such file or directory
scons: *** [modules\spine_godot\spine-cpp\src\spine\Animation.windows.tools.64.obj] Error 2
scons: building terminated because of errors.

Any idea what's going on? I do have the correct spine_godot (the actual source folder, not the containing folder with the examples) and spine-cpp (again, the one containing the "src" and "include" folders, not the containing folder) in the places specified.

EDIT: If it means anything, I'm running

scons platform=windows

in the source folder as I usually do for a build; I know the instructions say something about "setup.bat" but I don't see that file in the build scripts for spine-godot, only "setup.sh".

EDIT #2: Got it compiling. Had to modify the spine_godot SCSub file (remove the # signs from the file paths) and SpineAnimationTrack.cpp (change "godot/editor/editor_node.h" to "editor/editor_node.h").

I redid the build system last week so CI can be used to provide precompiled Godot editor and template binaries. We no longer support cmd.exe to build. Instead you'll. need Git Bash or Msys to build via the bash scripts in spine-godot/build. I'll document it this week.

Glad you figured it out, tho it's weird you had to change the editor_node.h include. What Godot version are you using?

3.4.1, so I'm a little behind. It might have had to do with the fact that my source directory is not "godot/"; it's "godot-3.4.1-spine/".

6 days later

Hello ! 🙂

It's very cool to see you are supporting Godot ! :grinteeth:

Out of curiosity, were there reasons to implement this as a module, instead of via GDNative ?

Thanks for the good work 🙂

GDNative does not have access to many of the editor APIs, like things related to animation player/animation editor, property UI widgets, and so on. I hope that with the new native extensions in 4.0, we can ditch this tight integration. Based on the APIs I see in the header repo, that's unlikely though :/

4 days later
Mario wrote

GDNative does not have access to many of the editor APIs, like things related to animation player/animation editor, property UI widgets, and so on. I hope that with the new native extensions in 4.0, we can ditch this tight integration. Based on the APIs I see in the header repo, that's unlikely though :/

Could suggest the required changes in Godot Proposals: https://github.com/godotengine/godot-proposals/issues

Yeah, that's the plan, and I've already filled a proposal for other minormthings, like PMA support. However, if I was a Godot core dev, I'd be hesitant to open up APIs as that increases the maintenance burden (more so if the asking party is a proprietary software shop like we are). Don't want to step on any feet.

22 days later

It seems using the custom build Godot Spine version clashes with some plugins that also use JSON for data... Keeps saying error parsing JSON at line 0, which doesn't happen if I use the official build of Godot 3.5 (I use a bare new project with only that plugin for tests)

The big one I'm using is Dialogic, which is kinda essensial plugin if you want to have dialogs in the game. Any way to fix this or am I doing something wrong? I've tried doing the reimporting JSON file as keep file (no import), but it's still not working. Any way to not make it a default to import every JSON as Spine skeleton data? (I'd prefer if we could just manually import the spine skeleton data JSON since those files are a lot less than other JSON)

Saw someone with the same issue here: https://github.com/EsotericSoftware/spine-runtimes/issues/2134
Using .skel is not a fix since even without any Spine generated JSON file, using custom build of Godot Spine still auto imports ALL JSON existing in project as Spine skeleton. In the barebone project I test, there are no spine skeleton files present and the Dialogic character json files are still imported as such.

EDIT: For Dialogic only, this should fix the issue: https://github.com/coppolaemilio/dialogic/issues/1094. Still, would be great if by default not all json files are considered Spine skeleton.

Sorry, I didn't get to this yet. I'll try to fix it this week.

Well, this can't really be fixed it seems. A file extension like .json can only ever be handled by a single plugin. If multiple plugins can handle .json, there's a first come, first serve mechanism. E.g. if the spine-godot plugin gets to see the .json file first and decides it's not a Spine .json file, then godot will just say "can't import" and not try another plugin that can also handle the extension.

I'm afraid I have no real solution for this at the moment and am waiting for input from the Godot devs.

Imagine having TWO plugins. Silly Godot! :nyeh:

14 days later

So any word on this? This feels like it might be kind of a dealbreaker for anyone trying to use JSON for anything non-Spine-related @_@;

No word from the core team yet I'm afraid. We'll likely have to use a custom extension for .json files. We already do for imported assets, .spjson, and I guess I'll use that for files to be imported as well. It's not great, as that will break existing projects :/