• Godot Help

  • passing a parameter on a Button .connect signal in Godot 4.2

I want to pass a parameter back with a button press. The below method worked under Godot 3.5:
description_button_node.connect("pressed", self, "_OnTechnologyDescription_pressed", [param1])
under Godot 4 it throws the following error
Invalid call to function 'connect' in base 'Button'. Expected 3 arguments.
any ideas out there?

  • Jesusemora and kuligs2 replied to this.

  • grymjack if you would like some advice: avoid lambdas, they make your code messy and hard to read. create a function in the main script and call it from there or pass a callable.
    also, don't put callables between ""s, you will mistype a letter and cause the game to crash.

    grymjack button_element.connect("pressed", func(): self._OnScienceDescription_pressed(scienceid_element.text))

    don't do this.
    do:
    button_element.pressed.connect(_OnScienceDescriptor_pressed.bind(scienceid_element.text))

    it's the clearer form and the way it's done in godot 4.

        grymjack you call connect on the signal.
        dbutton.pressed.connect(techdesp)

        For passing params use bind on the callable (function):

        dbutton.pressed.connect(techdesp.bind(param1))

            kuligs2 I am creating on 'on the fly' flowchart tree (technology/science abilities) based on values in a database. A generic '?' button is placed in all the different flow chart item types that the user could press to open documentation on that position in the chart. I wanted to create a parameter that would be sent back with the button press that would identify the item in the flowchart the user was clicking on.

              Jesusemora this is what I ended up doing

              button_element.connect("pressed", func(): self._OnScienceDescription_pressed(scienceid_element.text))

                  grymjack if you would like some advice: avoid lambdas, they make your code messy and hard to read. create a function in the main script and call it from there or pass a callable.
                  also, don't put callables between ""s, you will mistype a letter and cause the game to crash.

                  grymjack button_element.connect("pressed", func(): self._OnScienceDescription_pressed(scienceid_element.text))

                  don't do this.
                  do:
                  button_element.pressed.connect(_OnScienceDescriptor_pressed.bind(scienceid_element.text))

                  it's the clearer form and the way it's done in godot 4.

                        Jesusemora avoid lambdas, they make your code messy and hard to read. create a function in the main script and call it from there or pass a callable.

                        Don't see how lambdas make code messy. A lambda and a regular method look exactly the same in the code but with lambdas you get the added benefit of closure. This can make code shorter and less convoluted in many cases.

                            xyz Don't see how lambdas make code messy.

                            because you are writing a function horizontally on an indentation language, it breaks the style and it's difficult to tell where the function begins and where it ends.
                            They are (arguably) ok in languages with semicolons and brackets, but not in gdscript where we use end-of-lines to break code.
                            Maybe I confused "lambdas" from other languages with how they work in gdscript. What I meant was, functions written horizontally or as parameters of another function.

                            In the gdscript style guide there are some rules that would be broken by the usage of lambdas inside parentheses:
                            https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_styleguide.html

                            Line length¶

                            Keep individual lines of code under 100 characters.

                            If you can, try to keep lines under 80 characters. This helps to read the code on small displays and with two scripts opened side-by-side in an external text editor. For example, when looking at a differential revision.

                            One statement per line¶

                            Never combine multiple statements on a single line. No, C programmers, not even with a single line conditional statement.

                            Format multiline statements for readability¶

                            When you have particularly long if statements or nested ternary expressions, wrapping them over multiple lines improves readability. Since continuation lines are still part of the same expression, 2 indent levels should be used instead of one.

                            GDScript allows wrapping statements using multiple lines using parentheses or backslashes. Parentheses are favored in this style guide since they make for easier refactoring. With backslashes, you have to ensure that the last line never contains a backslash at the end. With parentheses, you don't have to worry about the last line having a backslash at the end.

                            When wrapping a conditional expression over multiple lines, the and/or keywords should be placed at the beginning of the line continuation, not at the end of the previous line.

                            this line has 101 characters, I counted them, but I could tell from a glance that it begins to get too long:
                            button_element.connect("pressed", func(): self._OnScienceDescription_pressed(scienceid_element.text))

                            It would probably look cleaner if the lambda is defined beforehand:

                            var lambda = func():
     self._OnScienceDescription_pressed(scienceid_element.text)

button_element.pressed.connect(lambda)

                            but the function _OnScienceDescription_pressed can itself be passed as a callable without the need to define a lambda:
                            button_element.pressed.connect(_OnScienceDescriptor_pressed.bind(scienceid_element.text))

                                Jesusemora because you are writing a function horizontally on an indentation language, it breaks the style and it's difficult to tell where the function begins and where it ends.

                                It's possible to make a lambda look almost like a normal function.

                                	tween.tween_method(\
		func(x: float):\
			path_follow.progress_ratio =\
		                x if left_to_right else 1.0 - x;\
			brush.position = path_follow.global_position,\
		0.0, 1.0, duration)

                                But when it gets that complicated, it may be better not to use a lambda. I wrote that code not too long ago, and I can't remember what it's supposed to be doing. 🙂

                                  @Jesusemora @DaveTheCoder Dudes, lambdas don't need to be inlined or one-lined. They are like normal inner functions in Python. For example:

                                  func add_repeated(src: Array, dest: Array) -> Array:
	src = src.duplicate()
	
	var f = func(a):
		src.push_back(src.pop_front())
		return a + src[-1]
		
	return dest.map(f)

                                  Even when inlined you can still write them "normally":

                                  func add_repeated(src: Array, dest: Array) -> Array:
	src = src.duplicate()

	return dest.map(
		func(a):
			src.push_back(src.pop_front())
			return a + src[-1]
	)

                                  One more benefit you get when using them as ad hoc callbacks is that they're not associated with any object. So if an object in whose method you created a lambda callable gets deleted, the callable (+its context/closure) will still be alive as long as there are existing references to it.

                                  6 days later

                                  Jesusemora sorry for the late response. I have changed my code as per your suggestion. Thank you for the answer.