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

Inconsistent base class detection #40584

Open
Rubonnek opened this issue Jul 22, 2020 · 10 comments · Fixed by #40781
Open

Inconsistent base class detection #40584

Rubonnek opened this issue Jul 22, 2020 · 10 comments · Fixed by #40781

Comments

@Rubonnek
Copy link
Member

Rubonnek commented Jul 22, 2020

Godot version:
3.2 branch commit 7b4b83e

OS/device including version:
Arch Linux

Issue description:
Attempting to add custom nodes using class_name and tool has inconsistent behavior -- some scripts seem to extend Reference as the base class when this is not the case.

Before following the steps to reproduce this issue, note that grid_background/grid_background.gd in the attached project extends TextureRect. Also grid_background/grid_texture.gd extends ImageTexture, but for some reason both are sometimes detected to extend Reference.

Steps to reproduce:

  1. Open project.godot and check out the original _global_script_classes:
_global_script_classes=[ {
"base": "Reference",
"class": "GridBackground",
"language": "GDScript",
"path": "res://grid_background/grid_background.gd"
}, {
"base": "Reference",
"class": "GridTexture",
"language": "GDScript",
"path": "res://grid_background/grid_texture.gd"
} ]
  1. Open the Godot Editor with godot -e, and when it finishes loading close it. There's a chance GridBackground and GridTexture still extend Reference according to project.godot, but if you look at their script they do not. This is the case I'm referring to -- you have reproduced the issue.
  2. On the other hand, if project.godot do not show Reference as the base classes, try the following.
  3. Rename grid_background folder to test1 for example.
  4. Open and close the Godot Editor.
  5. Check project.godot -> GridTexture and GridBackground now "extend" Reference at least according to that file.
  6. Reopening the project several times does not help in detecting the base class correctly either.

Minimal reproduction project:
InconsistentBaseClassDetection.zip

@Xrayez
Copy link
Contributor

Xrayez commented Jul 22, 2020

I can consistently reproduce this by renaming the folder to anything else containing those scripts. Upon saving, project.godot use correct "base" class as seen in scripts. The tool keyword is not required to reproduce this. Godot 3.2.2.stable.

After the folder renaming, when trying to modify the script to produce some parse error I get these errors popup everytime:

 res://test3/grid_background.gd:6 - Parse Error: Unique global class "GridBackground" already exists at path: res://test5/grid_background.gd
 modules/gdscript/gdscript.cpp:599 - Method failed. Returning: ERR_PARSE_ERROR
 res://test3/grid_texture.gd:6 - Parse Error: Unique global class "GridTexture" already exists at path: res://test5/grid_texture.gd
 modules/gdscript/gdscript.cpp:599 - Method failed. Returning: ERR_PARSE_ERROR

Notice different folder names. Likely different issue, but related to this one.

@Xrayez
Copy link
Contributor

Xrayez commented Jul 27, 2020

Yeah, the above errors are related to #35442. I've actually tried to fix it in #40634, also in hopes to fix this one as a byproduct, but to no avail.

@Rubonnek
Copy link
Member Author

Commit a97b843 is causing an inconsistent base class detection in my project again.

Seems like ResourceLoader::path_remap is not sufficient for non-exported projects.

I'll look into this again.

@Rubonnek Rubonnek reopened this Aug 25, 2020
@Rubonnek Rubonnek self-assigned this Aug 25, 2020
@akien-mga
Copy link
Member

akien-mga commented Aug 25, 2020

I guess it's probably best to revert #40781 and #41025 then if they're not working?

Done: #41501.

@Rubonnek
Copy link
Member Author

@akien-mga yeah, it was better to revert those in the meantime. Thanks!

I'm still not sure what is the root cause yet, but I'll keep digging.

@Rubonnek
Copy link
Member Author

Rubonnek commented Aug 28, 2020

The root of the problem is Godot's cache.

More specifically the file filesystem_cache6 stored at $HOME/.config/godot/projects/ which is written when the attached project is opened with godot -e for the first time is the culprit, however it turns out that subsequently opening the attached project will make Godot store this file at $HOME/.config/godot/projects/InconsistentBaseClassDetection-<hash_value>/filesystem_cache6 instead, which then will also cause problems. Deleting this filesystem_cache6 file at both of these locations allows Godot to detect base classes correctly.

It's important to point out that Godot's caching mechanism is not working properly when opening projects with godot -e directly for the first time without importing them through Project Manager first. This is because when using that command line, Godot will also cache other files, aside from filesystem_cache6, outside of their corresponding project folders and write them at $HOME/.config/godot/projects instead. Subsequently opening projects for the second time and onward, will write files to $HOME/.config/godot/projects/<project_name>-<hash>/ instead.

I'm not familiar with the relevant code that is causing this issue, and I will not be able to work on this anytime soon either. Clearing these caches works for me as a workaround in the meantime.

@YuriSizov
Copy link
Contributor

Global script cache behavior has been improved in 4.0 so this is likely fixed, so downgrading the milestone to 3.x.

@donn-xx
Copy link

donn-xx commented Jul 29, 2023

NOTE:I am not sure if this is the right thread.

Godot 4.1.1 stable, Ubuntu 22.04.02, Nvidia driver

I am having a hell of a bad time with these errors:
SCRIPT ERROR: Parse Error: Could not find base class
Could not find type "XXXX" in the current scope.

I have tried starting the project in these ways:
Godot_v4.1.1-stable_linux.x86_64 project.godot
Godot_v4.1.1-stable_linux.x86_64 -e project.godot
And starting it from the Project Manager

I have many scripts that use class_name that are @tools. It's a kind of random roll as to which class_name it will complain about each time I want to run something.

To "fix" it, I am forced to open each script and cut/past the class_name and then ctrl+s and after that I test by ctrl+clicking the class_name. If it shows a hand, it's kind-a-sort-a okay.

I am quite stressed by this bug as I am also writing an addon and I can't imagine how to explain it to potential users who can't run the addon because they hit these errors. Quite aside from being able to just use Godot myself.

HTH

@donn-xx
Copy link

donn-xx commented Jul 31, 2023

Adding some info:

If you delete the entire .godot directory and start your project, it rebuilds everything and after that the classes are recognized again.

A bit harsh, but hey..

@Eole211
Copy link

Eole211 commented Jan 11, 2024

I'm encountering the same issue with the ProtonScatter plugin. It only happen in my huge game project, and inconsistently : HungryProton/scatter#173 (comment)

Deleting the .godot folder do solve the problem for a while, but it still comes back. Next time it happens I'll make a diff of the .godot to see what changes after deleting and regenerating it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants