woohoo! i was watching it be solved in realtime. building with github actions is typically a cleaner solution for me
Skeir

- il y a 11 jours
- Inscrit 14 oct. 2023
i accidentally built Godot 4.4 from the latest commit on the master branch from the Godot repo (woops) however it did successfully build. i also tried to run the spine Github Action again, and got the same errors and results for only windows builds.
here's my vanilla Godot scons build logs:
godot-windows-build-log.txt141kB(i tbh just copied that from the console, i have no idea where else to get the logs as no file was generated)
- Modifié
Github action builds failing on Windows editor and template
i have been attempting to build the spine runtimes for the godot editor and templates for the past few months, ever since godot 4.3 came out. i have tried deleting my old fork and making a new one from the official spine github. it builds everything fine on godot 4.2 and previous versions, but only the windows build seems to be broken on godot 4.3 builds. i have done EVERYTHING i can to try building locally, but i just can't. i heavily prefer having my exported projects encrypted with a PCK key, and this so far has been the best way for me to do it.
steps:
- make a fork from the official spine-runtimes github
- in spine-godot-v4.yml in the /workflows directory, add this line at the bottom of the env: section
SCRIPT_AES256_ENCRYPTION_KEY: ${{ secrets.PCK_KEY }}
- in your repository settings, go to Secrets and Variables, then Actions and create a new repository secret called PCK_KEY. you can test with a real 256-bit AES key if you want, or just some random value
- once the changes are committed and pushed, wait for github actions to complete
- check if windows builds for godot 4.3 were succesful
Runtime information
i'm currently using the latest spine runtime version 4.2
(if images aren't working)
4.3 windows editor log:
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\mutex(37): error C3861: '_Mtx_init_in_situ': identifier not found
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\mutex(536): error C3861: '_Cnd_init_in_situ': identifier not found
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\condition_variable(56): error C3861: '_Cnd_init_in_situ': identifier not found
scons: *** [thirdparty\thorvg\src\loaders\svg\tvgSvgLoader.windows.editor.x86_64.obj] Error 2
scons: building terminated because of errors.
[Time elapsed: 00:07:56.21]
Error: Process completed with exit code 2.4.3 template log:
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\mutex(37): error C3861: '_Mtx_init_in_situ': identifier not found
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\mutex(536): error C3861: '_Cnd_init_in_situ': identifier not found
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\condition_variable(56): error C3861: '_Cnd_init_in_situ': identifier not found
scons: *** [thirdparty\thorvg\src\loaders\svg\tvgSvgLoader.windows.template_release.x86_64.obj] Error 2
scons: building terminated because of errors.
[Time elapsed: 00:06:48.48]
Error: Process completed with exit code 2.Mario if I want to compile with a PCK encryption key on Godot, do I have to build the export templates locally? i assume i would because the Godot docs warn "This will not work if you use official, precompiled export templates. It is absolutely required to compile your own export templates to use PCK encryption."
Harald
Yeah I was linearly changing the scale, I can see how that makes it less convincing now. I'm glad you confirmed I can programatically change the Z spacing after the halfway point. I was worried I couldn't since in Unity it only allows me to change the Z spacing to a negative value in the inspector.Mario
Oh I see the confusion sorry. I'm doing a Paper Mario styled game, and I'm trying to do a gradual rotation instead of an instant flip towards the left or right direction. I've compared side by side with my unity project using the ScaleX for a pseudo rotation effect, and on Godot using the actual plane's Y rotation for the effect. I notice when using actual rotation the effect feels more appealing compared to gradually changing the ScaleX from 1 to -1.It is a small visual difference, but for my game I was planning on having an attack that uses a sprite spin effect, and when I tried that on Unity I wasn't liking the results when using ScaleX. I could continue using SubViewports for the rest of my game, but I read I believe from you that it would have a big performance hit if more than 10 sprites were on screen.
the thing that fixed the nuget problems for me was opening visual studio (not vscode) and clearing nuget cache in settings. i don't have a nuget package manager, but i'm sure it has the same thing. after that try launching your project then editting the c# script
Mario
Is there any way I could make my sprite rotate in 3D space or appear to rotate in 3D space without using ScaleX?The only thing I can think of right now is inverting the z-offset when the character is 90° through the rotation (aka pretty much invisible to the camera). If the z-offset works how I think it does, then inverting it from a value like 0.01 to -0.01 would make it so when the entire sprite is flipped it'd appear facing the other direction but the draw order would be the normal order you expect.
(also unrelated thank you the NuGet package update fixed my C# issues)
Before 3D is supported for Spine on Godot I have a small request. I saw someone make a temporary solution for 3D. And I realized I actually enjoy how this feels and looks for my game.
I'm one of the many Unity refugees, and had some issues with 3D Spine skeletons back on Unity. On Unity I was required to add some Z-Depth, but if I wanted to rotate my character in a 3D space I'd have to instead rotate it in 2D space using ScaleX. Using the temporary solution I can rotate the Sprite in 3D space, which felt better both visually and for the 2.5D effect. Having it on a completely flat plane also seemed to improve how it looks when lit and shaded.
Could you add support for being able to render 3D sprites on a plane similar to how it's done in that GitHub issue?