 |
Attention | Topic was automatically imported from the old Question2Answer platform. |
 |
Asked By | LemonadeFlashbang |
I’m working on trying to get online multiplayer set up for a game of mine, and as part of that wanted to export the game file so I could more easily have multiple copies of it open at once (and test across different computers).
However, my game is crashing when exported as an executable!
Here’s a shot of the debugger when I run in editor to show there aren’t any game breaking issues.
Now when I compile the files I get:
The game seems to be failing to find some scenes and script files. However, I can open up the .pck file and find those scenes inside of it! Adding them explicitly to the resources tab in the editor’s export settings doesn’t seem to change anything.
This is happening for about 3-4 scene files, basically everything that’s loaded at game start- including my main scene.
Here’s the editor’s export menu:
I added the “.” to make sure I was importing ALL files since others have had issues with exporting and dynamic loading- but I don’t think that’s the issue due to the presence of these files/scenes in the .pck
I’m using the Creature 2D Runtimes so I don’t have a lot of flexibility when it comes to changing versions. None of the broken scenes reference the CreatureGodot class that it packages, and I’ve also tested against custom runtimes so I can confirm that’s not really the issue.
Has anyone seen something like this before? I’ve encountered a similar issue in this question but it’s been inactive for about a year.
Double-check that all paths in scripts use the correct casing, as the virtual PCK filesystem is case-sensitive unlike Windows’: Project organization — Godot Engine (latest) documentation in English
Calinou | 2021-01-26 13:22
I checked for that- you can see in the example above that “res://UI/Deck/Card.tscn” is in the same case in the .pck despite not being found by the game.
However I think I’ve found a clue- although I’m not sure how to resolve it. I believe the error is the "Cannot load byte code from file ‘res://UI/Deck/Card.gdc’
The card fails to load, then I believe the “Dealer” object which deals card is failing to load as a result. The Dealer object exists on the board, so the Board scene is then crashing next.
The Board is preloaded by the Game Manager autoload, so of course the whole game is then crashing on startup.The “Game Runner” default scene crashes because it references this board, which doesn’t exist.
Here’s the script file from our first error. It’s throwing a parse error because it can’t find the _ready() function.
This happens here. There’s a “self._ready()” call if the object is unitialized before I pass in the different Card parameters, because I’ve found that when I create the card scene and tell it to initialize it can sometimes initialize before it’s ready. When that happens, the onready variables aren’t loaded and are treated as nulls, causing a crash.
This isn’t a trick that I just do here- I do it in multiple places. Clearly, however, it’s some kind of bad practice and is causing a crashed script- which is in turn crashing entire chains of scenes.
Does anyone have any advice as to how I should handle this case instead? Why wouldn’t my card scene have a ._ready() function, when it extends Control? And why would this work in the editor, but not in the actual debug version of the game?
LemonadeFlashbang | 2021-01-26 19:17
Adding the scenes to the scenetree before initializing them and removing the call has fixed the issue.
That’s obviously the correct way to do things, so this is definitely on me. It seems that we can’t call _ready() explicitly in the actual executable but can in the editor. I’m not sure why this is exactly, or if it’s been fixed in a later version of Godot.
This shouldn’t be an issue for 99% of games since calling _ready() explicitly is a bad practice to begin with.
I’m not sure if this is true of newer versions of Godot, but if this is intended behavior there should be a warning inside the editor to prevent issues like this from happening to others.
Thanks to everyone who took the time to take a look and think about it!
LemonadeFlashbang | 2021-01-27 02:22