Closed BadBoyGodot closed 9 months ago
I think your assessment of this being problems with Godot rather than the add-on is spot-on. Refactoring is a really weak spot of Godot. First GDScript itself is weakly typed which makes creating working refactoring functionality infeasible, because there are a lot of cases where it's basically unknowable to static analysis of which type a given variable is. Second, there is the additional complexity that now the scene system (which is basically its own language) would need to trigger code refactorings (or vice versa). So I wouldn't hold my breath for any improvements on this front, they are unlikely to happen, unless the Godot devs make some fundamental changes to how the engine works.
I think one thing can be helped though:
If the function code is (...) cut-and-pasted to another location within the same script, a record remains under the 'Signals' tab pointing to the original line number. Double-clicking this record takes you to the incorrect line.
This is actually just some visual bug in the editor. The signal is still correctly connected to that function. Signals connections are made to a function name, not to a specific line number, so it doesn't matter where function is inside of the script, as long as it is there. You can freely move them around with cut/paste as long as their name and signature stays intact and the signal connections that you made in the editor will continue to work without you having to recreate them.
As for the renaming problem I don't have a solution right now that would safely automate this process, you'll have to make sure you don't skip a step (e.g. 1. remove signal connection, 2. rename node, 3. rename function , 4. recreate signal connection).
I think this makes it even more important to couple components as loosely as possible in godot, such that renaming things will not have ripple-effects all over your project.
When connecting to a state signal, there is no option to choose the location for the new code block. It is always appended after the last function in the script, which can make the code messy if multiple connections are made.
For the sake of long-term code cleanliness, I find myself needing to delete the code, remove the connection in the 'Signals' tab, reconnect, and accept that the new code will be added to the bottom of the script.
Since I've also run into this, let me tell you what I do.
It's not perfect, but it helps!
@Phanterm Thank you for the input!
Always keep my signal function blocks collapsed unless I'm actively working on them so it's easier to slot in/slot out signals.
This reminded me that godot has an update on code region https://github.com/godotengine/godot/pull/74843
I've been using statecharts extensively recently. As the scale of connecting to state signals directly in the editor increases, refactoring and deleting links have become a significant challenge. The pain points are as follows:
When the name of an already-connected node changes, the associated function name does not update. For example, in the platformer example, a node initially named 'jump enabled' might have a function _on_jump_enabled_state_physics_processing. If the node's name is changed to 'boost enabled,' the function name remains the same, even though everything still functions correctly.
If the function code is deleted or cut-and-pasted to another location within the same script, a record remains under the 'Signals' tab pointing to the original line number. Double-clicking this record takes you to the incorrect line.
When connecting to a state signal, there is no option to choose the location for the new code block. It is always appended after the last function in the script, which can make the code messy if multiple connections are made.
For the sake of long-term code cleanliness, I find myself needing to delete the code, remove the connection in the 'Signals' tab, reconnect, and accept that the new code will be added to the bottom of the script.
I believe these issues are more related to Godot than to statecharts. However, I'm curious if you have any workarounds to mitigate these challenges. As more people start using statecharts, I believe these refactoring issues could become a serious blocker. Thank you!