Godot: [GDScript] class_name no longer functional

Created on 31 Jul 2018  路  7Comments  路  Source: godotengine/godot

Godot version:

3.1 3f01f40e91c962b68fd18c0ca00144dfb6aee65f

OS/device including version:

Arch Linux

Issue description:

class_name seems to no longer work, though it can be defined as usual.

  1. Custom nodes do not appear in the node list anymore.
  2. Extending a class via class_name throws an error.
  3. Autocomplete for static functions associated with that class do not appear.
  4. Creating an object with class_name does not work.
  5. Checking for an object's type with class_name does not work.

Minimal reproduction project:

minimal_proj.zip

bug core

Most helpful comment

This issue should be resolved now and everything should work again!

Note: it was a problem with the editor filesystem scan falsely detecting scripts as other resources. The editor uses a cache to not scan everything all the time, which also means that in order for the fix to work you need to either

A) change the scripts in question and save again, that triggers a re-scan.

B) clean the cache. On unix-y systems it's .config/godot/projects

After cleaning the cache, when starting the editor you might still see an error, but after you run your project once it should be gone. (it's just a print, not a critical error)

All 7 comments

I can confirm that all these things were working a week ago and now are broken.

In my initial examination of this, I was able to determine that the files[i]->script_class_name in EditorFileSystem::_scan_script_classes(...) is not properly set on scripts that are edited. It's an empty string on scripts that are modified, so they enter the continue section and never get added to the global classes.

When I came into my build, I already had some names cached, and everything was showing up fine for the two of them. But as soon as I edited one of the files, it suddenly disappeared. This leads me to believe that editing it somehow updated its cache with an empty string for the class name (because it isn't be set properly) which is causing the cascade of other registration issues.

There are several places where the property is set though, and whenever I set breakpoints at any of those locations (I tried lines 727 and 740 inside the files.front() for loop in _scan_new_dir() - I even tried a breakpoint at the beginning of the EditorFileSystem::scan() method), and tried to follow its execution, the breakpoints were never even triggered! Not sure why...

@Ranoller Yeah, that's when the feature was initially added. It was working fine though for about 2 weeks, iirc. Don't know what would've merged to break it.

Here?
From 9 days ago and breaks writing to vector like this: vector[1] = something

This issue should be resolved now and everything should work again!

Note: it was a problem with the editor filesystem scan falsely detecting scripts as other resources. The editor uses a cache to not scan everything all the time, which also means that in order for the fix to work you need to either

A) change the scripts in question and save again, that triggers a re-scan.

B) clean the cache. On unix-y systems it's .config/godot/projects

After cleaning the cache, when starting the editor you might still see an error, but after you run your project once it should be gone. (it's just a print, not a critical error)

Although @karroffel said the issue has been resolved, the editor still behaves the same - has the "3.1.1 stable.mono.official" version been patched?

Was this page helpful?
0 / 5 - 0 ratings