DaveTheCoder

cheers, i did see this way of doing, thanks for the code
looks quite a clean way to do it, especially if you're using a global
to keep play stats ect.

i'll try in the future

thanks

    JusTiCe8

    cheers for the answers, and it's not a negative to what you have said, but like i said, i still don't really see the benefit of using signals

    I mean if you design a sub-scene ready-to-use for a UI, you may have health, score, items in an inventory (current weapon), ammo, ...
    You're free to use your UI scene in many games, but not using all its features, like a game without ammo or items to pick/use, signal will just be some place-holder, you may later remove for optimization purpose.

    if i have a UI node with these other nodes i might as well use $score, $items ect...

    if i have to reference the UI at some ANY point, then i've created a coupling

      There has to be a coupling, or else there is no connection, the signal wouldn't know where to go.

      It's basically a message system, producer / consumer, server / client, publisher / subscriber. So there is always some connection.

      However, you can build systems on top of signals to make them more generic, like with Singletons / Autoloads.

        Regardless, there has to be a connection. Like there is a signal "button_up". Which button was up? If you have multiple buttons and they do different things it won't work.

        That's not a good example. The button's node reference or other identification can be passed as a signal parameter.

          Sure, but then you'd have potentially every node checking every single signal and having an if statement or match to see if it is relevant. That doesn't sound efficient.

          DaveTheCoder The button's node reference or other identification can be passed as a signal parameter.

          And this would be coupling, as you'd have to code the id number in somewhere. Just kicking the can down the street.

            thanks guys, understood.
            i was just fishing to see if there was a better way, agreed, there has to be a connection and it was lazy of me to think there wouldn't be... without cost anyway....
            i'll get back to it now, i suppose it's simple really, the writer of the code needs to keep track of the objects/nodes in play and know when they need updating of if they
            get destroyed counter this, by writing code to guard/cover all outcomes.

            thanks again

            Well signals are the base. You can build structures around them. If you use an Autoload, it is accessible everywhere, and you can send and receive signals in that one place.

            But then you would be responsible for tracking which objects are what, like using some id system like @DaveTheCoder suggested.

              cybereality If you use an Autoload

              In my reply above, I provided an example of using an autoload. My only gripe is that I have to declare the signals in the autoload, since they're emitted through that class. Ideally, I would like to (somehow) avoid that. Can you think of a way of doing that?

              I haven't played with signals in 4.0, and don't know if that provides a solution.

                Please use "4.0" in the link instead of "stable". "Latest" and "stable" are confusing terms these days. 😉

                That's just where google took me, but good point.