I put arguments into a signal like this:

my_signal(arg1,arg2)

But not telling the signal there will be arguments beforehand works just fine too?

signal my_signal

func _ready():
	my_signal.connect(_my_function)
	my_signal.emit(1,2)

func _my_function(arg1,arg2):
	print(arg1,arg2)

And if i try to do it the way the docs say, i get an error message. "Method expected 0 argument, but called with 2." But there are 2 arguments, old_value and new_value. So why the error?

var health = 10

signal health_changed(old_val, new_val)

func _ready():
	health_changed.connect(print_health)
	take_damage(1)

func take_damage(amount):
	var old_health = health
	health -= amount
	health_changed.emit(old_health, health)
	
func print_health():
	print(health)
  • trizZzle replied to this.

  • Squiddy you're using it right, the editor just doesn't like unused parameters.
    prefixing the parameter names with an underscore avoids the warnings entirely:

    func print_health(_old_health, _new_health):
    print(health)

    works for any function.

      Arguments must be listed both in the signal declaration and in the function you are connecting to the signal. In your example you forgot the two arguments in the print_health function.

        Squiddy I connected the signal to a function and both signals work as expected. So signals automatically pass all arguments you pass in when emmiting them even if you didn't declare them? 😯

        #signal look(look_input:Vector2)
signal look # works just fine

func _input(event: InputEvent) -> void:
	if event is InputEventMouseMotion:
		look.emit(-event.relative)

        Other script:

        func _ready():
      InputManager.look.connect(on_look)

func on_look(look_input: Vector2):
      my look code
          10 days later

          Zini

          Late reply but would this be the correct way to do it then?

          var health = 10

signal health_changed(old_val, new_val)

func _ready():
	health_changed.connect(print_health)
	take_damage(1)

func take_damage(amount):
	var old_health = health
	health -= amount
	health_changed.emit(old_health, health)
	
func print_health(old_health, new_health):
	print(health)

          It does get rid of the "missing arguments" error, but it's still giving me warning. " The parameter "new_health" is never used in the function "print_health()". If this is intended, prefix it with an underscore: "new_health""_

          So, i have to put the arguments in the function, but then it doesn't use those arguments...? I don't understand this at all.

          Please, someone explain it to me like i'm 5. How do i correctly use arguments with signals?

          This has been stumping me for months and i just don't understand what it wants from me...

              Squiddy The warning you got has nothing to do with signals. It just reminds you that a function didn't use one or more arguments it received. If you're sending old and new health to a signal handler, it should use those arguments in some way, at least print them out.

              Note that this is just a warning. Nothing bad will really happen if you just ignore it.

                @xyz I disagree on this one. For some types of functions it is perfectly normal not to use all arguments. Think overridden functions or signal handlers (like in this case). For example a signal may be connected to several functions, but not all functions will be interested in all the data the signal contains.

                Also, ignoring warning messages is generally a bad idea.

                @Squiddy You have two options here. You could do what the error message says. Prefix the argument name with a _ (i.e. _new_health) within the print_health functions.
                The other option is to make use of new_health (and old_health while we are at it). Note that in most cases you would connect the signal to a function that belongs to a different object, meaning the health variable would not be available there.

                  Zini Also, ignoring warning messages is generally a bad idea.

                  No, not really if you have full understanding of what a warning means and what are the potential pitfalls. That's why most compilers/interpreters have customizable warning policies.

                  In GDScript the appearance of all warning messages is completely optional. So if you know what are you doing, you can safely turn off all warning messages that annoy you.

                  In OP's particular case, ignoring the warning has zero actual consequences, although I do agree that underscoring the intentionally unused args is advisable.

                  • Zini replied to this.

                      Squiddy you're using it right, the editor just doesn't like unused parameters.
                      prefixing the parameter names with an underscore avoids the warnings entirely:

                      func print_health(_old_health, _new_health):
    print(health)

                      works for any function.

                        xyz In this specific case I agree with you. I actually have this particular warning disabled myself. I just don't think its a good advise to tell a clear beginner that they can ignore warnings. Your original post sounded a bit too much like a general statement about warnings to me. But maybe I have misunderstood what you meant.

                        • xyz replied to this.

                            Zini Also, ignoring warning messages is generally a bad idea.

                            Agreed.

                            As xyz said, ignoring a warning message in a particular case may be okay, provided that you understand the meaning of the warning, and you know that it doesn't matter in that case.

                            But warning messages should be removed, using an annotation or other method. Otherwise, actual error messages can be mixed in with the warning messages and missed. It also looks unprofessional in published software.

                              Zini I guess I worded it poorly if it sounded like a generalization. When writing on forums, I always assume that the narrow post context is implied.

                              To keep things pragmatic, I think this particular warning is actually beneficial to the OP's current situation. They should do their best to understand what it means, because it may indicate the place that can harbor future bugs. Namely, the OP should clarify to themselves why are they sending before/after health value via signal arguments, and then choose to ignore those and instead access the health property directly.