vaibhavgarg

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
vaibhavgarg
  • Beiträge: 1

Mario

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.
Benutzeravatar
Mario

Mario
  • Beiträge: 3242

Ryusui

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?
Ryusui
  • Beiträge: 28

Mario

Jupp!
Benutzeravatar
Mario

Mario
  • Beiträge: 3242

Ryusui

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").
Ryusui
  • Beiträge: 28

Mario

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?
Benutzeravatar
Mario

Mario
  • Beiträge: 3242

Ryusui

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/".
Ryusui
  • Beiträge: 28

midiphony-panda

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 :)
Benutzeravatar
midiphony-panda
  • Beiträge: 20

Mario

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 :/
Benutzeravatar
Mario

Mario
  • Beiträge: 3242

T.Fly()

Mario hat geschrieben: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
T.Fly()
  • Beiträge: 18

Mario

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.
Benutzeravatar
Mario

Mario
  • Beiträge: 3242

meyaoigames

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.
meyaoigames
  • Beiträge: 4

Mario

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

Mario
  • Beiträge: 3242

Mario

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.
Benutzeravatar
Mario

Mario
  • Beiträge: 3242

Nate

Imagine having TWO plugins. Silly Godot! :nyeh:
Benutzeravatar
Nate

Nate
  • Beiträge: 12134

Ryusui

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 @_@;
Ryusui
  • Beiträge: 28

Mario

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 :/
Benutzeravatar
Mario

Mario
  • Beiträge: 3242

Ryusui

Regrettable, but better than nothing.

One way you could go about it is adding it as an export option in the editor - like, an "Export for Godot" option that simply changes the export extension. You could even provide a batch file for converting existing files (which, technically, is something anybody with some command-line expertise could probably do, but still)
Ryusui
  • Beiträge: 28

Mario

I tried to find docs on how to add settings for a plugin but came up with nothing. Do you happen to have a link? Link to sources would also be good enough. Also, it seems the plugin's importer is only queried once for its supported extensions on load, so I wonder if this setup would work.
Benutzeravatar
Mario

Mario
  • Beiträge: 3242

Ryusui

Oop - I was suggesting a tweak for the Spine editor, my bad. I'm afraid I'm not familiar with Godot's inner workings.
Ryusui
  • Beiträge: 28

samlletas

Mario hat geschrieben: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 :/
It's a shame Godot doesn't allow this :/, if there are no other alternatives then I guess introducing a breaking change this early wouldn't be that bad since the runtime released just recently and most people's projects are probably still in early stages.
Benutzeravatar
samlletas
  • Beiträge: 32


Zurück zu Runtimes