Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build Profile "Detect from Project" Causes Error: Mainloop type doesn't exist: SceneTree #103884

Open
popcar2 opened this issue Mar 10, 2025 · 3 comments

Comments

@popcar2
Copy link

popcar2 commented Mar 10, 2025

Tested versions

  • Reproducible in Godot 4.4.stable

System information

Godot v4.4.stable - Windows 11 (build 22631) - Multi-window, 1 monitor - OpenGL 3 (Compatibility) - NVIDIA GeForce RTX 4060 Laptop GPU (NVIDIA; 32.0.15.6636) - AMD Ryzen 7 7735HS with Radeon Graphics (16 threads)

Issue description

Using "Detect from project" in the engine compilation configuration editor causes the build to crash on launch. I detected from project, saved the .build file, then compiled Windows release templates using it. Exporting the MRP with that build makes it crash on launch with this error: "Mainloop type doesn't exist: Scenetree"

Clipboard - March 9, 2025

This issue doesn't happen when I reset to the default settings then tick off the same nodes/resources manually. Looking at the autogenerated .build file, we can clearly see the issue: it includes "MainLoop" in the list of disabled classes which Godot apparently needs to run. Removing it from the file fixes things... Sort of.

This should probably be its own separate issue, but it's worth noting in this same MRP, the autodetect feature fails to include other things the game needs to run. The game crashes on launch due to not having StyleBoxFlat: ERROR: Class 'StyleBoxFlat' or its base class cannot be instantiated. After removing StyleBox from the list of disabled classes, it now causes an error that it can't find KinematicCollision2D, which should definitely be included when 2D physics bodies exist in the project.

This thing is too overzealous in what it removes. I'm tired of fighting the build editor for one day 😪.

build_files.zip

Steps to reproduce

Open up MRP, go to Project>Tools>Engine Compilation Configuration Editor

Click on "Detect from project", then save as a new .build file

Try compiling a release template and use it to export the MRP. The build created will fail to launch with the error mentioned above.

Minimal reproduction project (MRP)

godot-size-test_2.zip

@bruvzg
Copy link
Member

bruvzg commented Mar 10, 2025

Seems like Detect from project only checking resource files on disk to get list of used classes, so it won't detect default theme, scene root and internally used classes.

Not sure why this feature exists at all, disabling classes do nothing except skipping class registration in the ClassDB, it seems to be completely useless.

@popcar2
Copy link
Author

popcar2 commented Mar 10, 2025

Not sure why this feature exists at all, disabling classes do nothing except skipping class registration in the ClassDB, it seems to be completely useless.

I thought so too, but after some testing it turns out that it can help greatly reduce build sizes. After following the optimizing for size guide in the docs, my MRP was 29.8MB when exported for Windows. Using the build config editor and disabling everything else that isn't used, my MRP goes down to 21.0MB exported. That's pretty huge.

There's also PR #103719 which would automatically detect and set build options for you. When that gets merged it'll be a life-saver for people trying to minify their binary size. Definitely a feature worth the investment imo.

@akien-mga
Copy link
Member

akien-mga commented Mar 11, 2025

Seems like Detect from project only checking resource files on disk to get list of used classes, so it won't detect default theme, scene root and internally used classes.

Yeah we should probably hardcode some base dependencies if they can't be detected reliably. CC @YeldhamDev

Not sure why this feature exists at all, disabling classes do nothing except skipping class registration in the ClassDB, it seems to be completely useless.

It actually works, because the linker then sees this code as unused and removes it at link time. (At least in some cases - I wouldn't guarantee it's 100% reliable, especially for more complex classes which might somehow still be referenced in other parts of the engine even if disabled in ClassDB.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants