@Erich_L said: This video did not do so well as the first one I made called [Godot] Four Ways to Share Data Between Nodes. I don't know if I didn't explain as well or if there's just enough related videos already. One guy did comment saying he was inspired to fill in the parts I left out, so I figured might as well drop his work here:

hahaha look at his cover photo thing, love it!

Funny because his channel is bigger than yours and he has done quite a few signals tutorials. I guess the inspiration is to actually explain why you do things- which is failing of many tutorials. If Godot was prescriptive about how to do anything then tuturials but GODOT is especially nonprescriptive so how I know when you do something do I have to do it that or not. You should split it into 3 parts each with code stamps to split into parts- understanding signals descriptively and how to use inspector and how to code it and each could be 15 minutes.

So I finally watched the video. It was quite nice. I take back what I said about it being too long, the length was okay and it was very informative. I've been coding signals by hand in GDScript the whole time, but actually using it in the editor looks easier, not sure why I was so stubborn about it. Especially since you can see the list of available signals, easier than checking the documentation constantly. Also that control click to open the docs is a cool trick, I've been right-clicking but that seems quicker. Thanks for the great video.

I needed this and appreciated it.

Little thing I would suggest is to edit out the part where you redo the light that didn't work (12:00). I know it's good to know how to fix things but for basic tutorial I prefer to just follow steps that just works. (Maybe video could be something like "here's way 1, 2, 3, 4, done. and now if you want to edit your signal you can do this..")

Don't worry about video not doing so well. It is valuable for beginner like me

@cloa513 said: If Godot was prescriptive about how to do anything then tuturials but GODOT is especially nonprescriptive so how I know when you do something do I have to do it that or not. You should split it into 3 parts each with code stamps to split into parts- understanding signals descriptively and how to use inspector and how to code it and each could be 15 minutes.

I'm not sure what you mean by prescriptive? But you're right I should split the video up better. Fifteen minutes though is a tough pill to swallow already. The first reaction, as @cybereality pointed out, as mine usually is, is to look at that 15 min and want to look elsewhere. So 45 minutes makes me cringe. I didn't even think about talking about when one would want to use signals to clean up code tho.

@cybereality said: Also that control click to open the docs is a cool trick

Those little things can be so, so nice

@cybereality said: I've been coding signals by hand in GDScript the whole time, but actually using it in the editor looks easier

I think I have found one place where using code for signals is preferable (other than for programming reasons). If two nodes are connected in a scene and if you copy and paste them into another scene they lose their connection. Probably too much of a trivial thing for the devs to fix that (if viewed it as being broken).

@Gowydot When I looked at that part again and thinking from the viewers point of view... yeah I can imagine finding that really annoying. I drew that out way longer than needed, probably had some subconscious desire to appear clever seep out haha.

@Gowydot @cybereality @cloa513 thanks a ton for the feedback

@Erich_L said: I think I have found one place where using code for signals is preferable (other than for programming reasons). If two nodes are connected in a scene and if you copy and paste them into another scene they lose their connection. Probably too much of a trivial thing for the devs to fix that (if viewed it as being broken).

In that case they are no longer the same objects, though, so severing the connection makes sense. It would break in code as well (different node paths) so requires manual fixing either way.

@cybereality ah yep that totally makes sense.

@Erich_L said:

@cloa513 said: If Godot was prescriptive about how to do anything then tuturials but GODOT is especially nonprescriptive so how I know when you do something do I have to do it that or not. You should split it into 3 parts each with code stamps to split into parts- understanding signals descriptively and how to use inspector and how to code it and each could be 15 minutes.

I'm not sure what you mean by prescriptive? But you're right I should split the video up better. Fifteen minutes though is a tough pill to swallow already. The first reaction, as @cybereality pointed out, as mine usually is, is to look at that 15 min and want to look elsewhere. So 45 minutes makes me cringe. I didn't even think about talking about when one would want to use signals to clean up code tho.

@cybereality said: Also that control click to open the docs is a cool trick

Those little things can be so, so nice

I mean GODOT has dynamic variables and indentation rather that curly brackets and considerable code formulation choices which give a feeling of you can do things any old way and they will work. How about using a main node as a communication center for signals as cyberreality wrote somewhere. You don't even mentions signals in your other video about 4 ways of passing information between nodes.

Jam packed full of useful information to handle any regular sort of situation- I could sit through a lot of recording time for that.

@cloa513 said: You don't even mentions signals in your other video about 4 ways of passing information between nodes.

To be completely honest before I made that video I had never considered using signals that way before the comments on that video. I guess it just seemed so much easier to go either through the tree or through a global script, and when you start a project and get into the groove of it, it seems like the first few days of setup will end up defining how you build the rest of the project. I’m only on my second reasonably large Godot project. The next one I’ll definitely have more fun with signals. Anyway as such I was biased toward using signals for their built in node related functions.

I was thinking about the example projects you can download when you start up Godot, think it would be useful to talk through a handful of how some of those projects work as sort of a “learn by example” tutorial? I remember trying to open a few of those up when I just started out but instantly got overwhelmed and smoked.

a year later

It's so many people who come from east country can't see youtube videos.
What a pity!

    Jeango Any Chinese professor will tell you to use a VPN. VPNs are not illegal for you- they are just illegal to distribute. There's so many good resources on youtube the real pity is not spending 50-60块 a month to just get access.

        Erich_L I heared VPN about 20 years ago, I have never used it to fetch internet infos

          Erich_L VPNs are not illegal for you- they are just illegal to distribute.

          You have a poor understanding of the reality of authoritarian-totalitarian regimes. Laws change several times a day. What was legal an hour ago may be totally illegal an hour later.

          But there is another problem with video: not everyone knows enough of the language to understand what is being said. What is written can be translated.

            When I upload tutorial videos, I also upload a subtitle (closed captioning) text file with it. This allows YouTube to auto-translate the text in every language. It's a setting when you upload the video and really helps for an international audience.

              cybereality This allows YouTube to auto-translate the text in every language.

              The problem is that it's a translation from Google… with all of the resulting glitches — often of poor quality. Sometimes I understand the English original better than the translation.

              I translated the original subs through DeepL and added them into the downloaded video. But first the video has to be downloaded… and YouTube is trying to resist this. Well, anyway, it's kind of a hassle.

                  Tomcat The problem is that it's a translation from Google… with all of the resulting glitches — often of poor quality. Sometimes I understand the English original better than the translation.

                  Alas, what most people aren't aware of is that google translation is a crowd sourced effort. If you go to translate.google.com and you translate text from one language to another(if you are logged in at least) you can make corrections and suggestions of your own on the translation side of it to improve the translation service. The language to language translations that users have actively worked to improve do better than the ones that haven't gotten that treatment. Doesn't help that google never seriously advertised that aspect of it. TL;DR: it works better for some language to language translations than others.

                      Megalomaniak Doesn't help that google never seriously advertised that aspect of it.

                      Translation from DeepL is of much higher quality. And, given Google's policy, I'd rather help their alternatives. And to correct the translation, one must already understand the language.

                      With video translation, there is also a catch… sometimes, especially when the speech is slow, long phrases are torn into several screens and the translation, respectively, is made in pieces. That is, the translator, in principle, could cope with a long phrase, but the translation of the chunks turns the speech into nonsense. Or, on the contrary, they speak too fast (especially GameFromScratch is guilty of this) and the end of one phrase overlaps with the beginning of the other — again comes out mush. In general, "the book is better" 📖

                        Oh no doubt DeepL being a much newer solution is by default better but if one does want to see youtube auto translation improve it is worth noting that it is at the end users hands.