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

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.

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

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.

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.

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 🙂

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.

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.

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).

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

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.