0 votes

How to debug the exported version of the game.

This is when there are no errors in the game in the editor, but the game does not work when exporting

in Engine by (53 points)

1 Answer

+1 vote

It's not possible to debug the same version of the exported game as the one you ship. Or at least much harder, because when you export the game, a release version of the engine is packed with your game data, which is stripped from many checks and debugging information that would slow it down or make it heavier.

If you have a specific problem with your exported game, you can expose the actual problem so it's more clear which kind of failure we'd have to deal with (which OS? Which platform?). It can be a complicated engine bug (release bugs are THE BEST), or it could be a simple script issue like using wrong file paths. For example, it's a common mistake to load files in res:// which works in editor, but have it fail after export because such file can have been stripped by the export (that's the case of PNG files imported as textures).

There is also something more involved you can try: as mentionned, by default a release engine version is packaged. But it's possible to package a debug version instead, as visible in the Export window options. This requires you to build the engine yourself in debug mode. The documentation has a section describing extensively how to get the source code and compile it: https://docs.godotengine.org/en/stable/development/compiling/index.html
Doing this would then allow you to attach a C++ debugger to your running game and see what's going on.
I've never done that myself with an export template but I know it's a possible option.

One last thing I'm thinking, but I'm not sure about:
If you export your game as PCK, you get .pck and an executable file. That executable is actually the engine itself. You could try deleting it, and replacing it with the executable of the editor itself. Then, from a system console, run it with the -d option to run the game with the command line debugger. I have no idea if that works tho.

by (27,902 points)

Thank. But I didn't get it

For example, it's a common mistake to load files in res:// which works in editor, but have it fail after export because such file can have been stripped by the export (that's the case of PNG files imported as textures).

Why the errors are so simple in the description, For example, Failed loading resource: res: //3d/feshfve/fewf.material.
At: core / io / resource_loader.cpp: 278

And what can I know from this? It was impossible to write:
1.there is no resource (if not, then why were there no errors when exporting ???)
2. is the file damaged? (Describe what happened to him)

couldn't you do that?

Ok so from what you are saying, your problem is a material file that doesn't manage to load?

I can imagine two possible reasons:

  • You're on Windows (or Mac OS?), and your file has been recorded using mixed casing. Resources are normally case-sensitive, but these OS have case-insensitive filesystems which caused bugs in the past. For example, maybe the file starts with M, but a scene file or script tries to load it with m, which works in editor because the resource is a file, but won't work after export because the resource is now inside a .pck archive. I've seen someone once have a similar problem after export, with an addon, just because he felt like renaming the addons/ folder into Addons/, which of course should NOT be done.

  • Some sort of corruption occurred. This would need thorough debugging of the scene loader with a C++ debugger to have more insight on what the engine is having trouble with, which unfortunately I can't help much with. If you can reproduce the problem consistently, you could provide the game and its exported version in a detailed bug report on Github, so devs can reproduce and analyse it.

there is no resource (if not, then why were there no errors when exporting ???)

Godot does not run your entire game when exporting, it can't see everything in advance. Although, some things can be checked, to some extent. But it's hard to know if your case can be improved or not until we know the actual cause.

Thank. So all resources must be in lowercase?

Just tried it in lower case - it does not load

What are these 2 mistakes about

ERROR: Failed loading resource: res: //textures/fewfwefg.png.
At: core / io / resourceloader.cpp: 278
ERROR: Can't load dependency: res: //textures/fewfwefg.png.
At: core / io / resource
format_binary.cpp: 655

Thank. So all resources must be in lowercase?

No, they must have a consistent case. Paths must match exactly. You must not have a file with a given combination of uppercase/lowercase letter, and a reference to that file with different letters being lowercase/uppercase. That situation "works" in case-insensitive filesystems, but it doesn't after export.

What are these 2 mistakes about

Same question, same answer as I wrote. Can't tell more from this.

thank thank thank

I was having similar issues exporting (I renamed some resource folders after reading the best practices docs and so the main scene had the wrong paths to other scripts and scene instances). Trying to debug this was difficult because the debugger kept closing very fast after the startup crash. Is there a best practice to see these debugger messages? From this answer, it seems like there's currently not a way to view them inside the godot editor debugger, right? I ended up enabling logging to figure out the issue, but it seemed a bit clunky going back in and opening a new file each test.

Welcome to Godot Engine Q&A, where you can ask questions and receive answers from other members of the community.

Please make sure to read How to use this Q&A? before posting your first questions.
Social login is currently unavailable. If you've previously logged in with a Facebook or GitHub account, use the I forgot my password link in the login box to set a password for your account. If you still can't access your account, send an email to webmaster@godotengine.org with your username.