Some buttons are not working on self-built version

[arenekosreal]

Some buttons are not working on self-built version

[arenekosreal]

OK, finally I managed to export a working game by running

godot-mono --headless --build-solutions --quit
godot-mono --headless --import

before do actual exporting.

I will close this issue now because I managed to solve this problem, but I think you may consider adding a note at setup_instructions to help people who have to face same situation.

[arenekosreal]

Yes, this is the problem. If I export the game directly without imported into editor, those buttons are not working. Let me see if I can find out any solution for this.

[hhyyrylainen]

There should be command line Godot flags to run the editor until it has imported all assets and then exit (though I remember there being github issues about that getting stuck and needing a fallback max iterations count variable to exit properly, though that bug may be fixed in Godot 4.3).

Edit: and that import process should work in headless mode as well.

[hhyyrylainen]

Edit: I should have maybe said so at the start but I've seen this issue with some buttons not working in the past: and in the past it has usually been because the game files have been automatically broken by Godot (it disconnects random signals in the main menu from buttons and messes up the theme file partially) when opened in the Godot Editor. Usually I think export errors lead to all buttons not working (which I've also seen when I've had issues with exporting with mismatching template files or a C# code build failure).

I think this is likely the error that gives some indication as to what is going wrong:

ERROR: Unable to open file: res://.godot/imported/default.png-0ecb64421bbeb83f3647ba16f0738ab3.ctex.
   at: _load_data (scene/resources/compressed_texture.cpp:41)
ERROR: Failed loading resource: res://.godot/imported/default.png-0ecb64421bbeb83f3647ba16f0738ab3.ctex. Make sure resources have been imported by opening the project in the editor at least once.
   at: _load (core/io/resource_loader.cpp:274)
ERROR: Failed loading resource: res://assets/textures/gui/cursors/default.png. Make sure resources have been imported by opening the project in the editor at least once.
   at: _load (core/io/resource_loader.cpp:274)

Also this seems suspicious:

ERROR: Failed to create an autoload, script 'res://src/engine/Invoke.cs' does not inherit from 'Node'.
   at: _create_autoload (editor/editor_autoload_settings.cpp:423)
ERROR: Failed to create an autoload, script 'res://src/engine/StartupActions.cs' does not inherit from 'Node'.
   at: _create_autoload (editor/editor_autoload_settings.cpp:423)

Which is maybe an indication that the C# source code was not built. I think Godot should build it automatically when exporting, but a manual dotnet build may fix that.

If I understood you correctly, you are trying to like setup a script to build Thrive from scratch? The usual solution to the above problem is to just open Thrive in Godot Editor and let it sit for a while to import all of the assets. Though that is not suitable for a scripted use-case. Or alternative if you did open the game files in Godot Editor once, the problem might be the editor automatically breaking stuff that needs to be git reset away (I'd link you our wiki page here, but our servers are down currently due to hosting provider technical issues). After the initial import the editor should most of the time not break any of the game files automatically, but it is good to check that first whenever some buttons don't work at all in the game.

Our CI builds run in a container (there's a script to create the container in the Thrive repo), and then run the following after cloning the code:

      - run:
          name: Build with warnings
          command: dotnet run --project Scripts -- check compile
      - run:
          name: Download native libraries
          command: dotnet run --project Scripts -- native Fetch
      - run:
          name: Create builds
          command: dotnet run --project Scripts -- package --dehydrated
      - run:
          name: Upload devbuilds
          command: dotnet run --project Scripts -- upload

Which is probably not that helpful, as really the only step you'd need to replicate the build is: dotnet run --project Scripts -- package Linux --compress false I added a few flags I think you'd need in your use case.

Our packaging script does a few extra stuff like including info on which commit the game is built from, which is then shown in the options menu, which I think are missing from your script.

Edit 2: I read the full build log and one more thing stuck out to be:

ERROR: Cannot connect to 'pressed': the provided callable is not valid: MarginContainer(PlayButton.cs)::OnButtonPressed
   at: connect (core/object/object.cpp:1323)

I don't recall seeing that error much, so that might be very related to the issue at hand. Could it be that the code is not compiled beforehand and that is all of the issue? Because that would explain why that error is printed: the callback is not valid because the C# code is not loaded due to not being compiled.

[arenekosreal]

I don't think so. You can see line 3763 of build.log to find that godot calls dotnet publish to build C# part. According to microsoft's documentation, dotnet publish will build the project automatically if needed. After C# part is built, godot will do savepack stage, at when those connection failure happens.

As I have explained before, calling cmake and godot manualy instead using Scripts project directly is because that I don't want my custom CXXFLAGS being modified by cmake. Actually I am just trying to do package work for my linux distribution, so I have to make build workflow match the distribution's requirements, such as using -O2 instead -O3 in CXXFLAGS.

Edit: I tried your advice and unfortunately it failed, there is no change in built game.

Edit2: As for errors like ERROR: Unable to open file: res://.godot/imported/default.png-0ecb64421bbeb83f3647ba16f0738ab3.ctex, I don't think it is a big problem, because the file will be generated by godot after reimport completed:

[hhyyrylainen]

I meant that the code may not be built when the editor starts. And when the editor starts that is when it prepares to load C# as scripts attached to Nodes. It might work like you describe but then Godot would explicitly need to try to reload the editor's script instances after the publish step, which it might not do (because the C# version of the engine has so many extra bugs, I wouldn't be surprised if this was one of those).

Edit2: As for errors like ERROR: Unable to open file: res://.godot/imported/default.png-0ecb64421bbeb83f3647ba16f0738ab3.ctex, I don't think it is a big problem, because the file will be generated by godot after reimport completed:

I realized after commenting that, this is likely the case as you get those errors anyway when doing a fresh export, so the errors are not serious. Unless you are deleting the source files each time before building, I'd still check that git status doesn't report any changes on your local Thrive copy.

[arenekosreal]

In fact, exporting game is the first time I start godot in the project. The whole build workflow is run in a systemd-nspawn environment and should finish without interactive operation. So I cannot import in godot editor manually and run export job. I have also tried running dotnet build -c ExportRelease before calling godot, but there is no change to the game.

It seems that no modified file is listed in git, the dist folder is my custom export directory so it is not included in .gitignore

[hhyyrylainen]

I was about to test doing a build in a container based on the steps you tried, but then I remembered that our website outage (which hopefully won't last too much longer) affects the LFS assets (which are currently unavailable so no new clones can be made).

For reference this is the podman image specification for the environment I would have tried: https://github.com/Revolutionary-Games/Thrive/blob/master/podman/ci/Dockerfile

So yeah due to that unrelated website problem I cannot test and verify if your build should work with a correctly setup environment or if the build steps themselves need tweaking.

[hhyyrylainen]

Okay so our online stuff started working and I did some testing in a container, and I noticed that the builds I made also had the same issue. Even when using the export script. So there is something pretty weird going on I can't figure out.

I plan on updating Thrive to use Godot 4.3 this week. I expect I'll need to investigate this further at least then to make sure builds can be made by our CI system correctly that don't have this bug.

[hhyyrylainen]

When upgrading to Godot 4.3 I just saw this same issue on my computer. I did a new dotnet build and then ran our export script again (though if I remember right I did open the Godot editor and run Thrive through it once at this point to confirm that the back button worked when the game wasn't exported, which it did), this time when exported the back button worked. So maybe that was unrelated or it was truly a case where the code just needs to be built an extra time to ensure all works fine in the exported version.

Also I again verified that builds using that specific Dockerfile (though updated to Godot 4.3) also create exported builds that have all working buttons.

[arenekosreal]

Unfortunately exporting game with godot 4.3 still not work. I have even tried calling dotnet build -c ExportRelease before exporting. But I could not launch editor and then try exporting because each command is invoked in a headless environment. So I guess it may because that godot editor did some trick to fix this problem. I am going to try to export game with godot editor to see if there is any change.

Just for reference, here are log files when building with makepkg:
thrive-0.7.0-3-x86_64-prepare.log
thrive-0.7.0-3-x86_64-build.log
thrive-0.7.0-3-x86_64-check.log
thrive-0.7.0-3-x86_64-package.log

[hhyyrylainen]

Still it is weird that our CI setup manages to make working builds, though maybe it is different because it uses the dehydrated build system I wrote where it takes the .pck file and removes usually not changing files out. The builds are then put back together on the client computer where the separately tracked files are put back into the .pck file. But this process shouldn't result in any different .pck file than before. So I'm not sure if that could explain the difference.

A just completed fresh build log is here: https://dev.revolutionarygamesstudio.com/ci/1/build/11390/jobs/1 inspecting it, it looks like it is totally missing the Cannot connect to log lines. That export log has all kinds of errors but that's the one that the CI build doesn't have but your log does have. So maybe that is really the real reason? It's also missing any errors about ERROR: Failed to create an autoload, script 'res://src/engine/Invoke.cs' is not compiling.

Could that have something to do with the runtime environment or something not supporting running the C# code? Or maybe the default Godot editor settings doesn't use dotnet for general building meaning the source build fails only for internal editor usage? I see quite a few potential causes of the symptom of the editor being unable to see that the button signal connections are valid.

[arenekosreal]

Good news, I tried exporting latest commit 27ae9a8dfb10d4d7831d98963330187dedfff77c after imported in godot editor, then this problem disappeared, even build with --headless flag. Then I will try to export same commit directly after cloned repository without imported into godot editor to check if my guess is correct.

[hhyyrylainen]

I'll keep that in mind if we add like official instructions for building Thrive inside a podman container. For now the supported way to build Thrive is with our custom build script, which is already explained in the setup instructions file.