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

Autoload scripts compile error are not reported (except confusing "Script does not inherit from Node") #78230

Closed
idbrii opened this issue Jun 14, 2023 · 6 comments · Fixed by #78540

Comments

@idbrii
Copy link
Contributor

idbrii commented Jun 14, 2023

Godot version

v4.0.3.stable.official [5222a99]

System information

Win 10

Issue description

When Autoload scripts have compile errors, the error is not printed to Output. Instead, they fail when Running with an error completely unrelated to what's wrong:

USER ERROR: Script does not inherit from Node: res://thetrouble.gd.
   at: start (main/main.cpp:2776)

There's no other information. I assume this message is because their failure to compile means they don't get associated as a Node child (related to #75388?)? But I don't understand why they don't have any errors reported. I think it only occurs if they were added to Autoload before they got compiled/used?

I am using an external editor (gvim) and godot's LSP support. That correctly shows the error, but only when I'm editing the broken file which makes it unclear what's wrong. (When I first encountered this problem, I looked at the files, saw they were extending Node2D and didn't understand the problem. It's possible the lsp was failing to show any errors, but it shows errors now.)

Steps to reproduce

  1. New project, add scene
  2. Add script "thetrouble.gd"
  3. Add thetrouble.gd as an Autoload
  4. Add invalid code to thetrouble.gd (two variables named seq)
  • Expected: compile error reported
  • Actual: No output
  1. Run project
  • Expected: compile error reported
  • Actual: Script does not inherit from Node: res://thetrouble.gd.
  1. Add valid code to thetrouble.gd (assign a value to seq)
  • Expected: compile error reported
  • Actual: No output

Note: If you mix up steps 2 and 3, the issue will not occur.

Workaround: Edit Autoloads and disable and re-enable thetrouble's autoload state and error messages appear. New errors even appear after this point.

Minimal reproduction project

repro.zip

@capnm
Copy link
Contributor

capnm commented Jun 15, 2023

On the current git tip you get on console:
(./editor/editor_autoload_settings.cpp:423) _create_autoload:
Script does not inherit from Node: res://thetrouble.gd.

But 4. Add invalid code to thetrouble.gd (two variables named seq)

LSP (vim, linux) reports the correct error here immediately after the code change as expected:

Screenshot1

@anvilfolk
Copy link
Contributor

Step 4 is resulting in an error for me from within Godot:

image

I am getting the issue in Step 5 though:

image

I'm not sure I understand what's wrong with 6 though. Valid code shouldn't result in a compile error!

Autoloads do seem to be loaded through the ResourceLoader::load() pathway, and apparently that's not resulting in errors being reported. Not sure why that would be though!

@Rindbee
Copy link
Contributor

Rindbee commented Jun 22, 2023

The following error message appears on the first run and does not reappear after that:

SCRIPT ERROR: Parse Error: Constant "seq" has the same name as a previously declared variable.
          at: GDScript::reload (res://thetrouble.gd:4)

This is a compile-time error message, if the script is cached, it won't be recompiled, so it won't reappear. It usually occurs when you modify and save the script.

@idbrii
Copy link
Contributor Author

idbrii commented Jun 22, 2023

I'm not sure I understand what's wrong with 6 though. Valid code shouldn't result in a compile error!

@anvilfolk There's still invalid code in the file, so I'd expect that modifying the file would recompile and re-emit the errors.

@OmarShehata
Copy link
Contributor

FYI this issue affects any attached script, when using an external an editor, not just autoload. For example, if you attach a script with a mix of tabs/spaces, you'll get a meaningful error the first time you edit it:

  res://script.gd:5 - Parse Error: Used tab character for indentation instead of space as used before in the file.

But running the scene, you will only get the following runtime error which makes it difficult to figure out what went wrong

E 0:00:00:0754   start: Script does not inherit from Node: res://script.gd.
  <C++ Error>    Condition "!valid_type" is true. Continuing.
  <C++ Source>   main/main.cpp:3039 @ start()

@akien-mga akien-mga added this to the 4.2 milestone Aug 3, 2023
@anvilfolk
Copy link
Contributor

@OmarShehata can you check whether the issue in your last message is fixed in master now, and if not, please open a new issue with it since it's slightly different than the original one? :)

IntangibleMatter pushed a commit to IntangibleMatter/godot that referenced this issue Aug 13, 2023
Currently, GDScripts who are only loaded through `ResourceLoader::load()`,
like Autoloads, do not have a pathway to announce there is an error in their
code. This contributes to significant confusion in error projects when
autoloads are involved. At least partially closes godotengine#78230.
YuriSizov pushed a commit to YuriSizov/godot that referenced this issue Sep 21, 2023
Currently, GDScripts who are only loaded through `ResourceLoader::load()`,
like Autoloads, do not have a pathway to announce there is an error in their
code. This contributes to significant confusion in error projects when
autoloads are involved. At least partially closes godotengine#78230.

(cherry picked from commit cca5717)
mandryskowski pushed a commit to mandryskowski/godot that referenced this issue Oct 11, 2023
Currently, GDScripts who are only loaded through `ResourceLoader::load()`,
like Autoloads, do not have a pathway to announce there is an error in their
code. This contributes to significant confusion in error projects when
autoloads are involved. At least partially closes godotengine#78230.
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