Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Imported pck files containing scripts using class_name do not work, all references break #61556

Closed
madmachinations opened this issue May 31, 2022 · 10 comments

Comments

@madmachinations
Copy link

madmachinations commented May 31, 2022


Bugsquad note: This issue has been confirmed several times already. No need to confirm it further.


Godot version

3.4.3 stable / 4.1.1 stable

System information

Linux, PopOS 20.04, GLES2, Intel Iris Plus Graphics G7, Mesa 21.2.2

Issue description

If you have declared global classes using class_name in your project, and you then export the project to a .pck file to be imported into a different project; All the references to these scripts/classes will break and the pack won't work.

Steps to reproduce

Create a project which includes a globally referenced class that has been declared using class_name, export this project to a pck file.

Create a second project which imports this pack file, and tries to load any scene whose script references that globally declared class.

Attempt to run the second project, it will fail. Debugger reports being unable to read the byte code in the script file.

But if you remove any references to this globally declared class in the first project, export the pack again, and attempt to load the second project with the new pack just using some basic scripting and no global classes - it works just fine.

Minimal reproduction project

game_test.zip

This file contains two projects:

A game project which includes a global class declared with class_name, that has been exported to a .pck file.

That pack file is inside the launcher project, which attempts to import and load the main scene from that pack file.

It breaks with the error specified above.

If you remove the three lines in the first project that reference and use the global Shibble class, and re-export the pack into the second project - it will run fine.

@madmachinations
Copy link
Author

The workaround I have implemented is to replicate the file structure of all named classes from project A into project B. And to strip those scripts of everything other than their class_name declarations.

This was the only way I could find to do it, other than refactoring all of my code to strip out all named classes and to use resource path references instead.

This adds all those definitions to project B's project.godot file, so when the pack is loaded and those scripts are overwritten, the references actually work.

I also have a singleton in the autoloads section of Project A, which does not work in Project B. This is related to an existing issue (#42002)

To make my singleton work I had to:

  1. Move all _ready code from my singleton to a custom setup method.

  2. Create an autoloaded singleton with the same reference name inside Project B, but it had to point to a different file name or this didn't work.

  3. After loading the pack, run the following for each singleton:

SINGLETON_REF.set_script(null)
SINGLETON_REF.set_script(load("res://path/to/imported/script))
SINGLETON_REF.setup()

@Calinou
Copy link
Member

Calinou commented Jun 1, 2022

Class name information is stored in project.godotand is exported as project.binary in the PCK. Unfortunately, this file cannot (and shouldn't) be overridden by another PCK loaded at run-time, so this is not technically possible to support with the current GDScript implementation.

@HaSa1002
Copy link
Contributor

HaSa1002 commented Sep 4, 2022

You can overwrite _global_script_classes using the overrides.cfg, causing a whole other can of worms. If one really wants to support these types maybe add a custom loader that registers them into the _global_script_classes in the ProjectSettings. Idk. This is super cheasy...

@dlstar89
Copy link

dlstar89 commented Apr 5, 2023

Remove my comment if not relevant but same issue is with Godot 4 (4.0.2) (Win11), so far as mentioned above the only way to go around this is to load('script_path').new(), using class_name of the class i.e. TestClass.new() causes error

@dlstar89
Copy link

@HaSa1002 by any chance do you know if the same can be done for Godot 4, as in is there a way to override global classes definition or something in the override.cfg?

@HaSa1002
Copy link
Contributor

Nope this was changed in the rebuild of GDScript. The GDScript team may know how to handle that nowadays. I dunno but maybe you can load the script and perform a reload? Like load(user://unsafe.gd).reload() no idea

ogapo added a commit to dykwia-labs/godot that referenced this issue Sep 25, 2023
…PCKs

fixes godotengine#82061
fixes godotengine#61556

Also, distinguish between main pack and DLC packs.
It's desirable to downloaded content to be as small as possible. This change avoids bloating non-main pack files with new versions of resources that are all read on startup and never used again. They have no effect if loaded after startup.
- project.godot/project.binary file
- extension_list.cfg
- app icon and boot_splash
- .ico and .icns files (these can still be opted in for DLC by listing them explicitly in the include filter)
ogapo added a commit to dykwia-labs/godot that referenced this issue Dec 8, 2023
…PCKs

fixes godotengine#82061
fixes godotengine#61556

Also, distinguish between main pack and DLC packs.
It's desirable to downloaded content to be as small as possible. This change avoids bloating non-main pack files with new versions of resources that are all read on startup and never used again. They have no effect if loaded after startup.
- project.godot/project.binary file
- extension_list.cfg
- app icon and boot_splash
- .ico and .icns files (these can still be opted in for DLC by listing them explicitly in the include filter)
@madmachinations
Copy link
Author

This is still a problem in Godot 4.1.1, any global classes which are imported via a pck file do not register

@teddybear082
Copy link

Glad I found all of this and now know I am not crazy after spending several hours this morning trying to get custom classes to register. Although I think I would have rather found out I was an idiot doing something wrong rather than finding out that godot 4 broke this functionality that was present in godot 3.x to add custom classes into override.cfg.

@jbromberg
Copy link

Can confirm this issue is still prevalent and basically breaks exporting your game as a pck or zip if you're using custom classes defined via class_name

@jbromberg
Copy link

This also leads to issues with identifying dependencies correctly. If I have a node with a script that references a static method of another script identified via class_name, that is not exported with the pck as a dependency of that script and the connection is lost and the script fails to execute.

dreed-sd pushed a commit to dreed-sd/godot that referenced this issue Apr 25, 2024
…PCKs

fixes godotengine#82061
fixes godotengine#61556

Also, distinguish between main pack and DLC packs.
It's desirable to downloaded content to be as small as possible. This change avoids bloating non-main pack files with new versions of resources that are all read on startup and never used again. They have no effect if loaded after startup.
- project.godot/project.binary file
- extension_list.cfg
- app icon and boot_splash
- .ico and .icns files (these can still be opted in for DLC by listing them explicitly in the include filter)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants