Godot: 3.0.3.stable Linux server version parses command line arguments incorrectly (regression)

[fleskesvor]

Godot version:

3.0.3.stable Linux server

OS/device including version:

Alpine Linux v3.7
Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
No GPU (it's a Docker image for CI/CD)

Issue description:

Running godot --export "Linux/X11" game_name should produce game_name and game_name.pck, instead the build fails with the following output:

ERROR: initialize: AudioDriverManager: all drivers failed, falling back to dummy driver
    At: servers/audio_server.cpp:165.
ERROR: _load: Method/Function Failed, returning: RES()
    At: core/io/resource_loader.cpp:186.
ERROR: start: Condition ' !scene ' is true. returned: false
    At: main/main.cpp:1689.
WARNING: cleanup: ObjectDB Instances still exist!
    At: core/object.cpp:1989.

Running with the verbose flag -v provides additional details:

CORE API HASH: 0
EDITOR API HASH: 0
load resource: res://Linux/X11
ERROR: _load: Method/Function Failed, returning: RES()
    At: core/io/resource_loader.cpp:186.

Looks like it's interpreting the preset as a resource to load. Changing that to godot -v --export="Linux/X11" game_name (note the equals sign =) seems to get me past that, but now it fails on the export name:

load resource: res://game_name
ERROR: _load: Method/Function Failed, returning: RES()

Separating the export name with double dashes (--, with spaces on both sides) makes no difference.

3.0.2.stable Linux server works without a hitch (except for the complaining about missing audio drivers, which doesn't appear to be a problem).

Steps to reproduce:

See above.

Minimal reproduction project:

Could be anything, but I'm attaching a very simple project I've tested on.

rotation.zip

[vnen]

Looks the same as #16949, but you say 3.0.2 is working and that bug report says it's not. There's something weird going on.

[fleskesvor]

It looks similar, but I don't think it's the same, since there's no existing target file in my case, and 3.0.2 has worked predictably for me for several months.

Specifying a filename or wildcard for output both work for me in 3.0.2, eg linux.zip or linux/*, but I haven't tested with an existing file or just the name of a directory.

[akien-mga]

I can't reproduce the issue in the master branch, so it's a regression only in 3.0.3+. I confirm that godot --export "Linux/X11" game_name works fine in 3.0.2 but no longer works in 3.0.3:

$ ~/tmp/godot/stable/Godot_v3.0.2-stable_linux_server.64 --export "Linux/X11" v3-0-2_test
ERROR: initialize: AudioDriverManager: all drivers failed, falling back to dummy driver
   At: servers/audio_server.cpp:153.
$ ls v3-0-2*
v3-0-2_test*  v3-0-2_test.pck
$ ~/tmp/godot/stable/Godot_v3.0.3-stable_linux_server.64 --export "Linux/X11" v3-0-3_test
ERROR: initialize: AudioDriverManager: all drivers failed, falling back to dummy driver
   At: servers/audio_server.cpp:165.
ERROR: _load: Method/Function Failed, returning: RES()
   At: core/io/resource_loader.cpp:186.
ERROR: start: Condition ' !scene ' is true. returned: false
   At: main/main.cpp:1689.
WARNING: cleanup: ObjectDB Instances still exist!
   At: core/object.cpp:1989.
$ ls v3-0-3_test*
ls: cannot access 'v3-0-3_test*': No such file or directory

[akien-mga]

Wasted a couple hours trying to bisect between 3.0.2-stable and 3.0.3-stable building with scons p=server, but it turns out that 3.0.3-stable works fine when self-compiled...

Now trying a build with target=release_debug to see if that's the issue.

[akien-mga]

Now trying a build with target=release_debug to see if that's the issue.

Doesn't seem to be it either.

@hpvb The regression seems to be due to the buildsystem change from Travis to your build machine. Could be LTO too, trying that now locally.

[akien-mga]

Could be LTO too, trying that now locally.

Well no, server doesn't support LTO :)

[fleskesvor]

Thanks for looking into this, @akien-mga. :slightly_smiling_face: Does that mean I should be able to compile the server version and export templates from 3.0.3.stable (and 3.0.4.stable) myself as a workaround? If so, what are the scons command(s) for doing that?

[akien-mga]

You can just compile your own server binary and keep using the official export templates for 3.0.4-stable. To build the server binary, checkout the 3.0.4-stable tag and use scons p=server ("debug" by default) or scons p=server target=release_debug (optimized).

[fleskesvor]

Thanks for the instructions. Should I also add options to include openssl, zlib and libpng? I'm asking because I've experienced issues with libssl in particular on games exported with custom built versions of Godot in the past.

[akien-mga]

Should I also add options to include openssl, zlib and libpng? I'm asking because I've experienced issues with libssl in particular on games exported with custom built versions of Godot in the past.

Those options only matters for the export template. The server binary is for your own use and won't affect the exported binaries at all, so as long as it works for you, you can export any game just fine.

[fleskesvor]

Oh, I see. Thanks again for explaining this. :slightly_smiling_face:

[MazeChaZer]

I ran into the same issue (Godot 3.0.4 server, prebuilt binary, in Docker). To me it looks like the --export command isn't even available. godot --help gives me:

Godot Engine v3.0.4.stable.official.d916135 - https://godotengine.org
(c) 2007-2018 Juan Linietsky, Ariel Manzur.
(c) 2014-2018 Godot Engine contributors.

Usage: godot [options] [path to scene or 'project.godot' file]

General options:
  -h, --help                       Display this help message.
  --version                        Display the version string.
  -v, --verbose                    Use verbose stdout mode.
  --quiet                          Quiet mode, silences stdout messages. Errors are still displayed.

Run options:
  -q, --quit                       Quit after the first iteration.
  -l, --language <locale>          Use a specific locale (<locale> being a two-letter code).
  --path <directory>               Path to a project (<directory> must contain a 'project.godot' file).
  -u, --upwards                    Scan folders upwards for project.godot file.
  --main-pack <file>               Path to a pack (.pck) file to load.
  --render-thread <mode>           Render thread mode ('unsafe', 'safe', 'separate').
  --remote-fs <address>            Remote filesystem (<host/IP>[:<port>] address).
  --remote-fs-password <password>  Password for remote filesystem.
  --audio-driver <driver>          Audio driver ('Dummy').
  --video-driver <driver>          Video driver ('Dummy').

Display options:
  -f, --fullscreen                 Request fullscreen mode.
  -m, --maximized                  Request a maximized window.
  -w, --windowed                   Request windowed mode.
  -t, --always-on-top              Request an always-on-top window.
  --resolution <W>x<H>             Request window resolution.
  --position <X>,<Y>               Request window position.
  --low-dpi                        Force low-DPI mode (macOS and Windows only).
  --no-window                      Disable window creation (Windows only). Useful together with --script.

Debug options:
  -d, --debug                      Debug (local stdout debugger).
  -b, --breakpoints                Breakpoint list as source::line comma-separated pairs, no spaces (use %20 instead).
  --profiling                      Enable profiling in the script debugger.
  --remote-debug <address>         Remote debug (<host/IP>:<port> address).
  --frame-delay <ms>               Simulate high CPU load (delay each frame by <ms> milliseconds).
  --time-scale <scale>             Force time scale (higher values are faster, 1.0 is normal speed).
  --disable-render-loop            Disable render loop so rendering only occurs when called explicitly from script.
  --disable-crash-handler          Disable crash handler when supported by the platform code.
  --fixed-fps <fps>                Force a fixed number of frames per second. This setting disables real-time synchronization.
  --print-fps                      Print the frames per second to the stdout.

Standalone tools:
  -s, --script <script>            Run a script.

The secion “Standalone tools” only offers --script. For my local (non-server, prebuilt) version of Godot 3.04, it says

Standalone tools:
  -s, --script <script>            Run a script.
  --export <target>                Export the project using the given export target.
  --export-debug                   Use together with --export, enables debug mode for the template.
  --doctool <path>                 Dump the engine API reference to the given <path> in XML format, merging if existing files are found.
  --no-docbase                     Disallow dumping the base types (used with --doctool).
  --build-solutions                Build the scripting solutions (e.g. for C# projects).
  --gdnative-generate-json-api     Generate JSON dump of the Godot API for GDNative bindings.
  --test <test>                    Run a unit test ('string', 'containers', 'math', 'render', 'multimesh', 'gui', 'io', 'shaderlang', 'physics', 'oa_hash_map').

The error message was very confusing to me, took me a while to figure this out. Godot should really validate command line flags better instead of just ignoring invalid ones, that would have really helped here.

For completeness, here is the output of godot --export HTML5 index.html --verbose for a very simple Godot project:

ERROR: initialize: AudioDriverManager: all drivers failed, falling back to dummy driver
   At: servers/audio_server.cpp:165.
CORE API HASH: 0
EDITOR API HASH: 0
load resource: res://default_env.tres
load resource: res://HTML5
ERROR: _load: Method/Function Failed, returning: RES()
   At: core/io/resource_loader.cpp:186.
ERROR: start: Condition ' !scene ' is true. returned: false
   At: main/main.cpp:1689.
WARNING: cleanup: ObjectDB Instances still exist!
   At: core/object.cpp:1989.
Leaked Instance: ProceduralSky:1038 - Resource Name:  Path: res://default_env.tres::1
Leaked Instance: World:1035 - Resource Name:  Path: 
Leaked Instance: Environment:1039 - Resource Name:  Path: res://default_env.tres
Leaked Instance: Image:1041 - Resource Name:  Path: 
Leaked Instance: SceneTree:1030
Leaked Instance: BulletPhysicsDirectSpaceState:1036
Leaked Instance: Physics2DDirectSpaceStateSW:1033
Leaked Instance: Viewport:1031 - Node Name: root
Leaked Instance: World2D:1032 - Resource Name:  Path: 
Leaked Instance: ViewportTexture:1034 - Resource Name:  Path: 
ERROR: clear: Resources Still in use at Exit!
   At: core/resource.cpp:418.
Orphan StringName: tree_changed
Orphan StringName: _vp_gui_input1031
Orphan StringName: _vp_input1031
Orphan StringName: World2D
Orphan StringName: BulletPhysicsDirectSpaceState
Orphan StringName: ProceduralSky
Orphan StringName: node_added
Orphan StringName: _vp_unhandled_key_input1031
Orphan StringName: World
Orphan StringName: Viewport
Orphan StringName: node_removed
Orphan StringName: Physics2DDirectSpaceStateSW
Orphan StringName: _vp_unhandled_input1031
Orphan StringName: root
Orphan StringName: Environment
Orphan StringName: SceneTree
Orphan StringName: Image
Orphan StringName: ViewportTexture
StringName: 18 unclaimed string names at exit.
ERROR: cleanup: Condition ' allocs_used > 0 ' is true.
   At: core/dvector.cpp:70.

Godot tries to load res://HTML5, just like in OP.

[akien-mga]

Ah ok, the issue is that @hpvb is building the server binary as tools=no when it should be tools=yes (the default).

[Calinou]

Godot should really validate command line flags better instead of just ignoring invalid ones, that would have really helped here.

As projects may have their own command-line arguments, this cannot be done unless we force project-specific arguments to be passed after -- (which is a common pattern in some applications). This could be done, but it would break compatibility, so it would have to wait for 3.1 or a later release.

[MazeChaZer]

Godot should really validate command line flags better instead of just ignoring invalid ones, that could have really helped here.

As projects may have their own command-line arguments, this cannot be done unless we force project-specific arguments to be passed after -- (which is a common pattern in some applications). This could be done, but it would break compatibility, so it would have to wait for 3.1 or a later release.

Good to know, this was new to me

[fleskesvor]

As projects may have their own command-line arguments, this cannot be done unless we force project-specific arguments to be passed after -- (which is a common pattern in some applications). This could be done, but it would break compatibility, so it would have to wait for 3.1 or a later release.

I maintain a few Godot tool scripts, and I think this would be a welcome improvement, as it would make it easier to validate command-line arguments properly. Currently, my only option is to ignore unrecognized options, which might not be very helpful to users in case of typos, etc.

Ah ok, the issue is that @hpvb is building the server binary as tools=no when it should be tools=yes (the default).

Glad you were able to pin this down. :slightly_smiling_face: Does that mean the official 3.0.3 and 3.0.4 server downloads can be updated, since it doesn't require code changes, and the current versions don't work anyway?

[MazeChaZer]

@fleskesvor I think published releases probably shouldn't be altered, even if they are erroneous.

[MazeChaZer]

I was building a Godot Docker image on GitLab CI this week, that is how I discovered this bug. I finished the image and decided to build the Godot Server binary separately, if any of you guys need it. You can download a properly compiled Godot 3.0.4 Server here (GitLab project). If you need a Docker image with Godot 3.0.4 you can pull mazechazer/godot (from Docker Hub).

[fleskesvor]

@MazeChaZer That's how I discovered it too. I started building my own images with Godot and Butler for use with GitLab CI after I moved my projects from GitHub to GitLab. The images can be found here (3.0.3 hasn't been fixed yet) and an example config here. It might be good to consolidate work on Docker images if this is something that is of general interest though, so I'll see about making a PR on your repo when I've had a chance to test. Is there a reason why you use Debian instead of the more light-weight Alpine?

[MazeChaZer]

@fleskesvor

Is there a reason why you use Debian instead of the more light-weight Alpine?

Nah, not really, I'm just used to Debian. I'm using the debian:stretch-slim image which is only 22MB, but I guess the alpine image with 2-3MB would be even better. I will look into switching to alpine later.

[MazeChaZer]

@fleskesvor I took some time and looked into using Alpine Linux for my docker images. I wanted to use plain Alpine Linux with musl libc. IMO, putting glibc on Alpine Linux kind of defeats the purpose. Anyway, I don't want to offtopic in this issue any further, so I created #20037, we can continue discussing Alpine Linux support there.

[MazeChaZer]

This problem is still present in the latest 3.0.5 binary available at https://downloads.tuxfamily.org/godotengine/3.0.5/Godot_v3.0.5-stable_linux_server.64.zip.
@hpvb could you fix the build config that is used for creating the release binaries? It should have tools=yes (the default value) as @akien-mga noted.

[GammaGames]

Does anyone have instructions to build just the server? I tried using scons platform=server and that didn't seem to work completely

Edit: I'm trying to get 3.0.5, since I already have the export templates for that

[MazeChaZer]

@GammaGames For Godot 3.0.4 this worked for me: scons platform=server target=release_debug

[GammaGames]

That did work, but maybe I'm misunderstanding the purpose of the server. I'll make a question on the Q&A

[hpvb]

So tools=yes would actually be wrong for 'server' which is why I didn't immediately do that. For 3.0.6 the following will happen:

• server will remain as it is now (tools=no) to actually be used as a server process for released games
• a new release will be added called 'headless' which is a platform=server tools=yes build for things like headless exporting etc.

Sorry it took a little bit to gain some consensus.

[MazeChaZer]

@hpvb sounds reasonable, thanks for the information!

[GammaGames]

Is it possible to export a project as a headless binary? I would love to export my server scene into a file that you could run from the command line without opening a window. It would be nice for docker containers, for instance

[fleskesvor]

Is it possible to export a project as a headless binary?

If I understand @hpvb correctly, that's the purpose of the server binary since 3.0.3-stable. You should be able to launch your project either by launching the server binary from the root of your project, or alternatively from a different directory with the --path option.

[GammaGames]

I understand that, it works well. But to run that you need the source code. I'm looking for a way to completely export the project for distribution, but when you run the exported program no window is created, just like when you run a project with the server.

[Calinou]

You should be able to run an exported project in headless mode by placing the exported PCK file in the same directory as the headless server binary. You can also specify its path using --main-pack.

[GammaGames]

That's exactly what I was looking for, thank you! Are the command line arguments documented anywhere? I couldn't find them, aside from the few in the tutorial

[Calinou]

Are the command line arguments documented anywhere? I couldn't find them, aside from the few in the tutorial

You can pass --help to any editor or export template binary :slightly_smiling_face:

[hpvb]

This has been fixed in 3.0.6 with the 'headless' builds.