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

ScriptEditor, GDScript - Typed @onready variables do not provide complete autocomplete dropdown #85035

Closed
awardell opened this issue Nov 17, 2023 · 4 comments
Labels

Comments

@awardell
Copy link
Contributor

awardell commented Nov 17, 2023

Godot version

Godot v4.2.beta (9df6491), also in earlier 4.X

System information

Godot v4.2.beta (9df6491) - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1080 Ti (NVIDIA; 31.0.15.3623) - AMD Ryzen Threadripper 1950X 16-Core Processor (32 Threads)

Issue description

In the script editor, when explicitly applying a typehint to an @onready variable, if the type is of a custom class, that custom class' member variables and functions will not be exposed to autocomplete. The autocomplete dropdown will display members of any built-in classes inherited from, but just not the custom class itself's members.

This might potentially point to a bug with the typehints in general, or just a bug related to autocomplete.

Steps to reproduce

Create a custom class and save it to resources like this example:

#res://my_custom_class.gd
class_name MyCustomClass
extends Sprite2D

var non_exported_node:Node
var non_exported_int:int
@export var exported_node:Node
@export var exported_int:int

To any node in the scene, attach a child Sprite2D and attach MyCustomClass to it.
To that parent node, attach and manually write out a script like this example:

extends Node2D

@onready var sprite:MyCustomClass = $Sprite2D

func _ready() -> void:
	var sprite2:MyCustomClass = sprite
	sprite. #no custom autocomplete hints
	sprite2. #custom autocomplete hints

Observe that after the . after sprite, the member variables of MyCustomClass will not display in the autocomplete dropdown. In contrast, after the . after sprite2, the member variables of MyCustomClass will display in the autocomplete dropdown. Going further, apply a cast to the onready variable rhs:

@onready var sprite:MyCustomClass = $Sprite2D as MyCustomClass

Observe now that the member variables of MyCustomClass all properly display in the autocomplete.

Minimal reproduction project

None should be necessary. Will upload one on request.

@awardell
Copy link
Contributor Author

Discovered by a user on this thread: https://godotforums.org/d/37587-at-onready-variable-doesnt-give-script-hints

@GreentheNinja
Copy link

GreentheNinja commented Nov 19, 2023

After testing for a bit, I found out that this is likely related to the scene-based autocomplete.

While editing a script connected to the root of the currently selected scene, you can get autocomplete hints for get_node. By using $, you also get autocomplete for the member variables of the node at the path.

There are two problems with this second system.

  1. It does not take into account the script that the target node possesses, meaning you can never get autocomplete for variables that aren't from built-in node types.
  2. It is not overridden if assigned to an explicitly typed variable. If you change the node at the target location to be a, say, CharacterBody2D, you will receive autocomplete for functions such as move_and_slide() even though the explicitly stated type derives from Sprite2D.

This can happen any time you use $ without as.

For a workaround, just swap $Sprite2D with get_node(^"Sprite2D"). This shouldn't change anything about how the script behaves aside from the autocomplete, so a type mismatch will throw an error unlike something like @onready var sprite := $Sprite2D as MyCustomClass which will just assign null instead. Edit: I was wrong about this. Apparently, get_node or editing from a different scene causes the same problem, but instead acting as if the target node was a bare Node instead.

@GreentheNinja
Copy link

I've just found out that this was actually already reported (#73638).

@awardell
Copy link
Contributor Author

Thanks for the detective work @GreentheNinja

I hadn't found 73638 when searching. Sorry about that. We'll close this one.

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

No branches or pull requests

3 participants