tutorials/scripting/gdscript/gdscript_basics

[giscus[bot]]

tutorials/scripting/gdscript/gdscript_basics

GDScript is a high-level, object-oriented, imperative, and gradually typed programming language built for Godot. It uses an indentation-based syntax similar to languages like Python. Its goal is to...

https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html

[mccolljr]

Is there a concept of "generators" in gdscript? For example:

for obj in compute_a_long_list():
    do_something(obj)

func compute_a_long_list():
    # in c# it would be yield return 1
    # yield return obj1
    # yield return obj2
    # etc...

[Calinou]

GDScript supports custom iterators, but I don't know if that's the same as generators.

[enetheru]

4.3 introduced PackedVector4

[Calinou]

• Fixed in Document PackedVector4Array godot-docs#9865.

[Marenz]

Is there a way to use await with signals that have parameters, as in, get access to them?
e.g.:

signal user_ready(id: int)
signal user_changed_color(id: int, color: Color)
func foo():
    await user_ready # no access to id?
    await user_changed_color # Access to id & color?    

[nonchip]

await returns the only argument or array of arguments, so this should work:

signal user_ready(id: int)
signal user_changed_color(id: int, color: Color)
func foo():
    var id: int = await user_ready
func bar():
    var params: Array = await user_changed_color
    var id:     int   = params[0]
    var color:  Color = params[1]

wish we had destructuring assignment for cases like that. imagine just being able to do var [id: int, color: Color] = await user_changed_color!

also this seems mentioned nowhere in the docs, had to dig my way all the way through the compiler source to find confirmation: https://github.com/godotengine/godot/blob/e4e024ab88efe74677769395886bc1b09eccbac7/modules/gdscript/gdscript_function.cpp#L137

also note that signals can be called with an arbitrary amount of arguments, the declaration is mostly for doc purposes, as you can see by Signal not even knowing about it, so what it returns gets decided at the time of the signal being handled, which can be quite "fun" (yknow, not "haha-funny" but the other kind) depending on your situation...

[Lazy-Rabbit-2001]

Since typed dictionaries are introduced in 4.4, a new section similar to "Typed Arrays" should be added for "Dictionary" section.
Meanwhile, @icon can be also used for unnamed scripts and works as usual, which I think should be noted, too.

[Lazy-Rabbit-2001]

yes, you can have a try, especially opening its document if you have any documental comment in the script with no class_name, where you will see its custom icon at the top of the page of its document

[Calinou]

Meanwhile, @icon can be also used for unnamed scripts and works as usual, which I think should be noted, too.

Reading the page again, I think this is already stated above:

# (optional) icon to show in the editor dialogs:
@icon("res://path/to/optional/icon.svg")

There's no implication that you have to use class_name along with it.

[7ombie]

I'm just learning GDScript now, and didn't infer anything like that either.

[Sithoid]

Bump to that. For anyone who googles in the meantime, it's

var typed_dict : Dictionary[key_type, value_type] # e.g. Dictionary[StringName, Texture2D]

This syntax isn't mentioned here or on the Dictionary class reference page.

[Calinou]

Pull request opened:

• Document typed dictionaries in GDScript godot-docs#10747

[Gonderage]

On property getters, does a property run its getter each time the property appears, or is the property's calculation cached?

Silly example:

var my_var : int:
     get = expensive_function

func expensive_function():
    # Does a lot of stuff

func my_function():
    var new_int := 0
    for x in big_number:
        new_int += my_var      # does this call the getter each time?
        new_int += my_var + 1  # or is it cached for future lines?
        new_int += my_var + 2
    return new_int

[Gonderage]

Also, if a property is used in the getter itself, does it recursively call its getter? Example I'm working on right now:

var direction : Vector2: get = get_direction
signal just_moved

func get_direction() -> Vector2:
	var vector := Input.get_vector("move_left","move_right","move_up","move_down")
	var rotation : float = get_window().get_camera_3d().global_rotation.y
	# To check if I just started moving, I need to
	# know the direction from the previous input.
	if direction.length_squared() > 0.1 and vector.length_squared() < 0.1:
		just_moved.emit()
	return vector.rotated(-rotation)

[Gonderage]

nvm the second one, i just reread that getters dont recursively call themselves

[GeminiSquishGames]

On the warning about lambdas, is the third code block not just repeating the second, failing to actually represent the difference in variants outside of the lambda's scope that are pass-by-reference data types?

[Sibert-Aerts]

Yes, but it's emphasizing to people unfamiliar with pass-by-reference data types that even though you can't reassign variables from a lambda, you can (re)assign entries in an array or dictionary, and in fact generally affect Object state. Naively someone might otherwise think a lambda is completely functionally "closed off", unable to perform any side effects on any state, when really it's specifically local variables that are an exception.

[Zehir]

Concerning boolean operations in GDScript, the order of parameters is important.

For the or operator, if the first element is true, the second is not checked.
For the and operator, if the first element is false, the second is not checked.

Some other languages check both methods before comparing the results.

func _ready():
	print(test_1(true) or test_2(false))  # test_1        true
	print(test_1(false) or test_2(true))  # test_1 test_2 true
	print(test_1(true) and test_2(false)) # test_1 test_2 false
	print(test_1(false) and test_2(true)) # test_1        false

func test_1(value: bool) -> bool:
	print("test_1")
	return value

func test_2(value: bool) -> bool:
	print("test_2")
	return value

An other exemple with the following code:

func _unhandled_input(event):
	if hovering:
		if event.is_action_pressed("left_click"):
			toggle_selection(hovering)

The code is equivalent to:

func _unhandled_input(event):
	if hovering and event.is_action_pressed("left_click"):
			toggle_selection(hovering)

In both cases, if hovering is falsy the is_action_pressed is not called.

[Calinou]

This is because GDScript performs lazy evaluation. It only evaluates what's actually needed to improve performance. Nearly all programming languages out there do this.

In other words, in a series of or conditions, as soon as one of them evaluates to true (read from left to right), the others will be skipped. In a series of and conditions, this happens as soon as one of them evaluates to false instead.

[nonchip]

now if only they'd also be able to return variants, then we could actually use that fact for something useful like in lua...

[CouchSloth]

Does Return stop a function or does it just return a value? If it does not, what is the reasoning behind removing that feature from Return?

[CouchSloth]

and in 4.3 Return will stop working and a function will run without breaking_exit_[ing] at the Return lines.

that's just plain incorrect, return always returns the execution back to the caller, and sometimes even with a return value. and that is very much in the documentation (see gdscript reference/basics):

A function can return at any point.

combine that with the fact you just learned what a function is in the CS50 linked in "Getting Started". and essentially every programming language works like that. and your CPU's callstack.

Well, it didn't work as return should work, and broke code.
Without proper documentation we can not know to put in a bug report or not. It's a different language, I can not assume that it does or doesn't work the same. It's not incorrect if it happens raondomly, just the why comes into question. I was already going to submit a report with Gemni's response. Thanks for the reply, because you at least double confirmed, and helped people see where they should see to get more info.

[nonchip]

Well, it didn't work as return should work, and broke code.

it did. i don't know how you think it should work, but it always worked the exact same way which always was the exact same way as pretty much any programming language's "return". please stop claiming otherwise, just because you misunderstood something or just wrote a bug. return was always return and always returned. it doing that is not "breaking code". and it always "should" work like that and always did. there's no version of gdscript in which return doesn't return.

[CouchSloth]

it did. i don't know how you think it should work, but it always worked the exact same way which always was the exact same way as pretty much any programming language's "return". please stop claiming otherwise, just because you misunderstood something or just wrote a bug. return was always return and always returned. it doing that is not "breaking code". and it always "should" work like that and always did. there's no version of gdscript in which return doesn't return.

Weirdly hostile for me asking for clarification so I can report a bug in the porgram, but alright, buddy.
Edit: For clarification, the code was working, multiple people looked at it, and godot stopped running the code as normal until multiple restarts. The code? If array size is equal to 1 exit function. This somehow stopped working until the computer was restarted. Making up bug report and replicating bug as many times as I can to get the team as much information as possible. The issue was it wasn't exiting after godot was open and running after a certain period of time, not return was exiting as we wanted.

[nonchip]

again, there is no bug in the program. i don't know who looked at it, but nothing you describe can be explained by "return randomly not working", if that was ever the case it would've been found immediately, so please stop insisting on this, especially in this space which is very much not meant for that kinda discussion.

[tx350z]

I am wondering if the code in question is a tool script attached to a scene that is part of an editor plugin main screen. When the scene is opened for editing, the script code runs (as it should) even when the plugin is disabled. If the scene script relies on context established by other plugin code, strange behavior can result. I've had cases where data is corrupted and editor crashes occur. It's not a bug, it's just the reality of live editing code that is effectively part of the editor.

[lamdevhs]

A warning for people trying to use static variables in editor plugin code: you need to put @tool at the top of the script, even if the class is fully static. If your editor plugin tries to read a static variable from a static class, you'll get null.

I think it should be documented, because static methods can be called without issues from editor plugins, but as soon as you try to read a static variable it all goes to hell without any warning. I posted a bug report on the godot doc repository.

[mvuets]

for i in 3:
	statement # Similar to range(3).

If it's similar and not equivalent, what exactly is the difference? Is either form obsolete/recommended?

[lamdevhs]

It's almost certainly more efficient. range(3) creates a list/array in memory, before looping through its values. I'm assuming for i in N is a shorthand that is smarter, and which uses a counter variable instead, like in C/C++/Java/Javascript when you write for (i = 0; i < N; i++) if you're familiar with one of these lower level languages.

If you need a list of numbers, use range(). Otherwise, if you need to repeat an action N times, just use for i in N, it's probably more efficient and at any rate more concise.

[mvuets]

range(3) creates a list/array in memory, before looping through its values.

That's not the case according to another example from the same code block I'd quoted earlier:

for i in range(1, 3):
	statement # Similar to [1, 2] but does not allocate an array.

[lamdevhs]

oh really, I didn't know! well then, I guess range() is already a shorthand somehow (i.e. special syntax), so for i in N is just a shorthand of a shorthand. use whichever one you like, but there's no point using range() if you don't need two parameters.

[mvuets]

@lamdevhs, there is a point: range() communicates the intent to a reader better than a bare expression. It's unclear what for p in players would iterate over: a range of number, each character in a string, item in an array, key in a dictionary?.. On contrary, for p in range(players) suggests (and enforces) a numerical loop.

Anyway, my question stands. I'd like to know what does the documentation imply with that "similar". If the two forms eventually results to the same AST or effectively work the same in runtime, then perhaps it can be rephrased from "similar" to "analogous" or "equivalent".

[emitc2h]

It would be neat if the editor could detect that functions are coroutines and annotate them as such, in a similar way that it detects when a function has a signal connected to it (from the editor) and shows a little green icon.

[Calinou]

Please open feature proposals on the Godot proposals repository.

[alanhe]

In the example, probably lowercase String_arg.

func my_function(int_arg := 42, String_arg := "string"):
	pass

[seedandsyntax]

There is a typo in the Abstract Classes comments, got me a bit confused so pointing it out...

...
# This is an example of a concrete subclass of AbstractSubClass.
# This class can be instantiated using `AbstractClass.ConcreteSubclass.new()`
# in other scripts, even though it's part of an abstract `class_name` script.
class ConcreteClass extends AbstractSubClass:
	func _ready():
		print("Concrete class ready.")

The comment should be: AbstractClass.ConcreteClass.new().

[DevSavvySerge]

I was not aware properties cannot be overridden in subclasses. I now have to replace many if them with get_xxx, set_xxx in my code base.