Comments (14)
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.
from thrive.
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.
from thrive.
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.
from thrive.
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.
from thrive.
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:
from thrive.
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.
from thrive.
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
from thrive.
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.
from thrive.
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.
from thrive.
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.
from thrive.
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
from thrive.
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.
from thrive.
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.
from thrive.
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.
from thrive.
Related Issues (20)
- Create variant of GetEnergyBalanceForSpecies for auto-evo that just has the overall balance
- Add a tutorial for getting the nucleus and binding agents for advancing in the game
- Make AI stop sprinting in conditions where that makes sense
- Behaviour editor has slightly broken layout (in Godot 4) HOT 8
- Some models are missing in Art Gallery
- Art Gallery doesn't disable main menu shader when viewing 3D models HOT 2
- Pressing on extinct species in auto-evo explorer report doesn't show information about this species HOT 5
- Add the miche tree to the editor somewhere for the player to inspect
- Add a toggle button to the evolutionary tree to hide extinct species
- Species initial compound calculation has a bug caused by compound balance being incorrectly calculated for ferroplast
- Fix UpdateInitialCompounds using calculations related to the default patch (and not the ones the species is in)
- We probably need a loading screen for visual object shader precompile step
- Process equation arrow should be aligned lower to not look like it is top aligned HOT 2
- Input system needs a way for more specific inputs to block input from going to more general
- Make ChemicalEquation be able to line wrap if it is too wide
- [Suggestion] Add music selector in auto-evo explore tool HOT 1
- Art Gallery music background is too big when opened in full screen
- Make Thrive native C++ library compile on Windows with Visual Studio
- Increase minimum cell size for engulfing chunks HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from thrive.