I’d like to hear how people feels about this before proposing it on github.
I was always bothered by the fact that when you use “make scene root” to root some node, all existing signal connection I created using editor is still attached to the old root node. I have to reattach the root script to the new root and reconnect all those signals by hands. These troubles could be saved if we add a “transfer script” functionality that reattach existing script with signal connections to a new node.
If this feature is troublousome to implement, AT THE VERY LEAST pops up an error message when a script with existing editor signal connection is detached.
TBH, I don’t use connections in the editor any more. I do them all in code, because I find it easier to just look at the _ready() function and see what’s connected than go to another tab.
6 Likes
That has not bothered me particularly, but in the same vein, a thing that really gets me is that when I duplicate a folder, and all the nodes and scripts are duplicated, all the nodes still have attached scripts from the original folder. Meaning I have to go through every node and resource to detach and reattach the duplicated scripts.
Now I do understand that copying a folder structure does not mean the code is interpreted and changed, and to do so might be highly problematic, so I get it, and it is I suppose a minor bug bear, but it is still can be rather frustrating when you forget and suddenly you are editing the wrong file. This happens more than I would care to admit to be honest.
I suppose this is like the signal connections, how can you tell if a signal is supposed to connect to the root, or to the node that it was indicated for. I suppose this is an impossible conundrum so we are stuck with this bug bear. Also, imagine if changing the root node meant all your scripts were fiddled with. As @dragonforge-dev said, what do you do about connections in code? Imagine if godot took bits of your script and put it where? Your new root node might not even have a script attached to it.
So I don’t think anything can be done about either of these things, there is just too much downside and complication and possibly unwanted ‘magic’ for it to be any other way.
4 Likes
I agree, guess the best way is to compel yourself to write connections in _ready(). No wonder why almost every experienced godot project I’ve seen so far does it this way.
1 Like
I also connect all signals in _ready, because the connection through the editor is so hard to keep track of, especially if you change names and stuff.
So maybe a feature proposal to change how signals are connected through the editor would be more interesting
3 Likes
Connecting signals through inspector is easier, but then maintaining them is harder, which is the exact opposite with connecting signals through code. It would be awesome to have the best of 2 worlds - be able to connect signals through inspector and have it automatically generate connection code in the ready function. It’d use the hell out of it 
4 Likes
This feels like something a more robust refactoring feature in the editor could handle. One of the things I miss in the Godot script editor is is being able to right-click on a variable name or function name and select Refactor and give it a new name and have it change in all files where it is used. Once that functionality exists, then what you’re proposing isn’t that far fetched.
It would be an improvement, but TBH, I probably wouldn’t use it that much. I only go over to the Node tab to see an easily available list of all the existing signals I can use, and the arguments for them.
I also simplified what I do in my response. I usually put them in ready, but I also put them other places. For example, I will have a state machine kick off a one-shot animation, and then connect to that animation_finished signal. Then once that signal is complete, I disconnect it. This became important when I was using an AnimatedSprite2D to trigger animations, because the animation_finished signal doesn’t tell you the name of the finished signal.
I also have gotten into the habit of connecting signals later than _ready(), because it’s too early. As scenes become more complex, you sometimes need to rely on something that may not be ready yet. I’ve encountered this a lot when loading data for settings. So I will wait for the ready signal and connect that in the _ready() function, then connect my signals in an _on_ready() function.
It has also been an issue with the way I create my state machines. I create a StateMachine node, and then hang State nodes off it. Then I can do things like delete the SpashScreensState in the GameStateMachine after the splash screens are complete and free up memory. Or I can create a FireballState for the PlayerStateMachine that allows the user to cast a fireball when a button is pressed, and add it to the player when they read a scroll teaching it to them. When a State is first constructed, it can exist before its StateMachine is fully constructed. So I delay the hooking up of signals by placing them in an _activate_state() function that is run by the StateMachine after it is fully constructed, and whenever a State is added to it.
All that being said, I can see how it would be useful. Even if I didn’t want the signal there, the code could be moved.
1 Like
That was exactly the argument that I had in mind while reading your post, but you gave it at the end yourself
All the good points nonetheless, interesting to hear about your approach
1 Like