HTML5 Export: html file looks for files by different names from what exporter gives them

[CarlFink]

Godot version: 3.1.1.stable.official

OS/device including version: Intel NUCi5 running Debian GNU/Linux Testing (Buster).

Issue description: Downloaded the sample file Godot3_dodge-1.3.zip from here on GitHub. Unpacked it and imported it. Downloaded the export templates from within the Godot editor. Selected the HTML5 template and exported, then copied the resulting files to /var/www/html/creep and changed the permissions. I am running Apache 2.4.28-2 here on my system.

When I try to open the game from a browser I'm told, "Failed loading file 'dodge_3.wasm': Not Found". That's correct, it is not found, because Export actually named the file "dodge_3.0.wasm". That extra ".0" is not helping and I have no idea why there is a discrepancy.

I am attaching the whole Creeps file, since it's small. Thanks.

Steps to reproduce: As above.

1. Install the stable Godot
2. Download and import the "Dodge the Creeps" example project
3. Download the export templates
4. Export as HTML5

Minimal reproduction project:

Creeps_hate_html5.zip

[CarlFink]

More info: I tried exporting for a Linux target, and got what I suspect is the same error. Console output quoted below: OpenGL ES 3.0 Renderer: Mesa DRI Intel(R) HD Graphics (Coffeelake 3x8 GT3) SCRIPT ERROR: GDScript::load_byte_code: Parse Error: Unexpected token: Identifier:sextends At: res://Player.gdc:1. ERROR: load_byte_code: Method/Function Failed, returning: ERR_PARSE_ERROR At: modules/gdscript/gdscript.cpp:785. ERROR: load: Condition ' err != OK ' is true. returned: RES() At: modules/gdscript/gdscript.cpp:2168. ERROR: _load: Failed loading resource: res://Player.gdc At: core/io/resource_loader.cpp:285. ERROR: poll: res://Player.tscn:3 - Parse Error: [ext_resource] referenced nonexistent resource at: res://Player.gd At: scene/resources/resource_format_text.cpp:440. ERROR: load: Condition ' err != OK ' is true. returned: RES() At: core/io/resource_loader.cpp:208. ERROR: _load: Failed loading resource: res://Player.tscn At: core/io/resource_loader.cpp:285. ERROR: poll: res://Main.tscn:5 - Parse Error: [ext_resource] referenced nonexistent resource at: res://Player.tscn At: scene/resources/resource_format_text.cpp:440. ERROR: load: Condition ' err != OK ' is true. returned: RES() At: core/io/resource_loader.cpp:208. ERROR: _load: Failed loading resource: res://Main.tscn At: core/io/resource_loader.cpp:285. ERROR: start: Failed loading scene: res://Main.tscn At: main/main.cpp:1739. WARNING: cleanup: ObjectDB Instances still exist! At: core/object.cpp:2095. ERROR: clear: Resources Still in use at Exit! At: core/resource.cpp:425. I tried exporting to Windows, and got what looks like the same thing:

Does the Export function just hate periods?

[KoBeWi]

This is a duplicate of #28103 (except the Windows part)

[CarlFink]

So, looking at the bug @KoBeWi linked to, I saw that both happened under Linux. I fired up my Windows VM to try there, figuring to see if that was the problem. Except the 64-bit Windows executable fails to start up. The unavoidable Windows console that opens when I execute it (?) has these errors:

ERROR: _display_error_with_code: CanvasShaderGLES2: Vertex shader compilation failed:

0:1(13): error: syntax error, unexpected $end ERROR: get_current_version: Method/Function Failed, returning: null ERROR: bind: Condition ' !version ' is true. returned: false ERROR: _display_error_with_code: SceneShaderGLES2: Vertex shader compilation failed: 0:1(13): error: syntax error, unexpected $end ERROR: get_current_version: Method/Function Failed, returning: null ERROR: bind: Condition ' !version ' is true. returned: false ERROR: _display_error_with_code: SceneShaderGLES2: Vertex shader compilation failed: 0:1(13): error: syntax error, unexpected $end ERROR: get_current_version: Method/Function Failed, returning: null ERROR: bind: Condition ' !version ' is true. returned: false ERROR: _display_error_with_code: SceneShaderGLES2: Vertex shader compilation failed: 0:1(13): error: syntax error, unexpected $end ERROR: get_current_version: Method/Function Failed, returning: null ERROR: bind: Condition ' !version ' is true. returned: false ERROR: _display_error_with_code: SceneShaderGLES2: Vertex shader compilation failed: 0:1(13): error: syntax error, unexpected $end ERROR: get_current_version: Method/Function Failed, returning: null ERROR: bind: Condition ' !version ' is true. returned: false ERROR: _display_error_with_code: SceneShaderGLES2: Vertex shader compilation failed: 0:1(13): error: syntax error, unexpected $end ERROR: get_current_version: Method/Function Failed, returning: null ERROR: bind: Condition ' !version ' is true. returned: false ERROR: _display_error_with_code: CanvasShaderGLES2: Vertex shader compilation failed: 0:1(13): error: syntax error, unexpected $end ERROR: get_current_version: Method/Function Failed, returning: __null ERROR: bind: Condition ' !version ' is true. returned: false ERROR: _get_uniform: Condition ' !version ' is true. returned: -1

I speculate based on some of those errors that Godot Engine doesn't like running in a VirtualBox VM, in particular because it doesn't like the VB video driver? I also tried the 32-bit version with the same result.

This is rather frustrating, since I do not currently own a native Windows or Mac box. Now I'm wondering about running the Windows version of Godot under Wine to do a successful export ....

[Zireael07]

VirtualBox drivers do not support OpenGL versions required IIRC, or the support is incomplete.

[CarlFink]

VirtualBox drivers do not support OpenGL versions required IIRC, or the support is incomplete.

Thanks, that was my guess.

[CarlFink]

Wow, I'm being verbose in the last 24 hours, but this might be useful: if I change the project to GLES2 (it came from the download as GLES3), export works.

OK, the game breaks (game-end code is never triggered by a collision, so it runs forever), but it exports without the above error.

I hope that's useful to the devs.

[lawnjelly]

Does the Export function just hate periods?

Presumably you can test this out by changing the filename. But yes, in general it's usually dodgy territory to try and use periods in a filename that is also using them as a separator for the extension, as there may well be code that searches from the left for the first period instead of from the right.

Consider also I have a feeling some of the exporters may use multiple extensions (e.g. blah.png2342343.etc.stex) so searching from the left may not be a bug, but the most sensible behaviour. If periods in the filename is a problem ideally the exporter would put an error message box or something warning the user of this.

Edit Tried this I downloaded the dodge the creeps 1.3 from https://github.com/kidscancode/Godot3_dodge/releases. I got the same missing dodge_3.wasm, when the file was called dodge_3.0.wasm. Editing the html filename on export so there were no periods seemed to solve this.

When I had a look at the .js file,

    Engine.load = function(newBasePath) {

        if (newBasePath !== undefined) basePath = getBasePath(newBasePath);
        if (engineLoadPromise === null) {
            if (typeof WebAssembly !== 'object')
                return Promise.reject(new Error("Browser doesn't support WebAssembly"));
            // TODO cache/retrieve module to/from idb
            engineLoadPromise = loadPromise(basePath + '.' + (wasmFilenameExtensionOverride || 'wasm')).then(function(xhr) {
                return xhr.response;
            });

Maybe the getBasePath is getting confused by the period. Needs a javascript guy to have a look, but personally I would tend towards just not allowing . in the filename, because anything in the chain could get confused by it.

[KoBeWi]

I tested a Windows export on Windows and it works no matter how many periods I put in the name. So this might only affect Linux or exporting from Linux.

HTML5 is broken on Windows too, but that's #28103 as mentioned

[KoBeWi]

Can anyone still reproduce this bug in Godot 3.2.3 or any later release?

[akien-mga]

Tested 3.2.3 on Linux, works fine. The issue was likely fixed in 3.2, like #28103.