Creating signals generates no code in external editor

[chucklepie]

Bugsquad edit: This issue has been confirmed several times already. No need to confirm it further.

---

Godot version: 3.2.2 stable

OS/device including version: linux mint 64 bit

Issue description: I am using latest VSCode. External editor opens/switches to vscode when accessing code ok. However when I select to create a signal, it sets the signal as created in the godot IDE, it switches to vscode and opens the correct script file, but no code is generated, as per video, it simply jumps to line 1.

Additionally when you double click on the signal to go to the code it doesn't open editor. If I manually create the signal in the correct place, double clicking still does not open the editor. If I go to an existing signal already created then it switches to vscode fine.

As a side note, if I create a new script file and open it, vscode opens and the default templates are populated ok, so it is just signals and nothing to do with creating new code...

Project settings for vscode are: code -g {file}:{line}:{col}

Steps to reproduce:

1. create a signal
2. no code is created

[chucklepie]

I am now and again (i.e. not always), seeing this message in Godot, despite the files not being open in Godot:

Another resource is loaded from path 'res://entities/static/Missile_Launcher.gd' (possible cyclic resource inclusion).

[Calinou]

This seems to be a duplicate of https://github.com/godotengine/godot/issues/23208, but people are only reporting issues when using C# there.

[chucklepie]

That's quite a specific thing to do with the c# class file generation as well. Maybe this is better separate, but linked by reference?

On Sat, 15 Aug 2020, 15:24 Hugo Locurcio, notifications@github.com wrote:

This seems to be a duplicate of #23208 https://github.com/godotengine/godot/issues/23208, but people are only reporting issues when using C# there.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/41283#issuecomment-674404602, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADCERRMXX333BQ2S3YDRE43SA2LBVANCNFSM4QAI74GA .

[Calinou]

Cross-posting my comment for reference:

I think the issue has more to do with using an external editor than C# in itself.

A simple fix would be to save the file automatically when Godot creates the function in its built-in script editor. This way, the external editor will reload the file (if it supports automatic file reloading) and show the newly created function.

However, this is problematic if you've made unsaved changes in the external editor, since you'll see a "conflict prompt" in this case (as the file has been modified externally, yet you had unsaved changes). This could be alleviated by enabling the "save on focus loss" behavior in your external editor.

[shawkes]

That's quite a specific thing to do with the c# class file generation as well. Maybe this is better separate, but linked by reference?

That aspect (code being generated in the wrong place) is covered in a separate issue https://github.com/godotengine/godot/issues/12908

This and #23208 are the same underlying issue (PR will fix both), so closing one makes sense.

[AMOfficialGithub]

Does anyone know if this issue has been fixed yet?

[Calinou]

@AMOfficalGithub Not yet. https://github.com/godotengine/godot/pull/42416 needs to be merged for this to be fixed. Most modern IDEs reload modified files automatically. Therefore, saving the file implements this feature without having to do anything IDE-specific.

[samtsejerome]

This is still an issue in 3.2.3

[Calinou]

Reopening because the feature isn't working as intended when an external editor is configured: https://github.com/godotengine/godot/pull/42416#issuecomment-846427354

[Brin-o]

I'm on 3.3.2 stable using GDScript + VS Code on Windows and this is an issue as well

[prafulla-codes]

Hi, I am also facing this issue on godot v 3.2.3.stable.mono using C# + VS Code Configured on Windows 10

[mediad02]

This is the first time i'm commenting on a bug, but i would like to add some of my observations about godot not generating code in external editors.

I'm on Godot 3.2.2 stable and using VS Code with the godot-tools plugin

I get the same issue when creating a signal, godot does not auto generates the signal code in the external editor. but if I disconnect the signal, then disable external editor and open the scripts with the internal godot editor and then re-enable external editor and create the signal the code is auto generated within the external editor, VS Code.

if you didn't follow my procedure i can post screenshots of the steps to reproduce this.

[prafulla-codes]

Hi @mediad02 , yes it would be really helpful if you attach the screenshots, I will also help to test it out

[Calinou]

I get the same issue when creating a signal, godot does not auto generates the signal code in the external editor. but if I disconnect the signal, then disable external editor and open the scripts with the internal godot editor and then re-enable external editor and create the signal the code is auto generated within the external editor, VS Code.

This is expected, because the built-in script editor will save the script when adding a new signal: https://github.com/godotengine/godot/pull/42416

However, this does not happen if the built-in script editor is disabled (which automatically happens when an external editor is configured in the Editor Settings).

[mediad02]

Sorry for the delayed response, i was taking the screenshots for the response. i will post the screenshots in gif formal, hopefully the quality is good enough.

In conclusion, i think the best solution to this problem at the moment is to find a way for godot to have its external editor enabled and for every script created to be opened in the background by the internal editor and external editor as well.

[Calinou]

In conclusion, i think the best solution to this problem at the moment is to find a way for godot to have its external editor enabled and for every script created to be opened in the background by the internal editor and external editor as well.

This would be very confusing, as you could end up editing the script in the "wrong" editor and not see your changes in the other editor until you save the script. File conflicts on save will often happen if we do this.

[mediad02]

@Calinou it is a tedious process since everytime you create a new script you would have to make sure it is also open within the godot editor, but once its been open and you re-enable external editor there is no need to go back into the internal editor, since opening the scripts from the scenetree or file manager dock always opens them in the external editor.

[Edit] This is more so a work around to the bug, than a solution.. for people that insist using VSCode or other external editors, while we wait for the definitive fix... I myself prefer an external editor because of the quick response and intellisense...

[ericlothspeich]

Still an issue in 3.5

[otsoaingles]

I saw this issue today in 3.5.1 when following the "fist 2d game" tutorial.

Godot_v3.5.1-stable_mono_win64 Windows 11 Latest VS Code

[JohnC3]

Still an issue in 4.0 and 3.5. Following the first 2d game tutorial. Rider Windows 11 and windows 10.

This issue seems to be quite old it might make sense to document it in the tutorials. Perhaps offer a workaround assuming one works.

[nrmiller]

Just saw this is still active. I admit, this confused me since I'm very new to Godot! 😅

I'm not sure if this helps, but perhaps C# partial classes can be utilized. Instead of modifying the primary script, a Godot-managed partial class might be able to be generated and used.

In general though, it seems like C# grammar parsing may be needed so that Godot can know which class and indentation level to insert the snippet. Or maybe it can search for the _Ready() function and insert the event subscription logic too.

If the issue is more so concerned with discarding unsaved changes in the external editor, perhaps we can look into creating a VS Code Extension capable of merging the incoming changes with the unsaved changes.

[kastromatos]

This issue totally ruin experience for C# newcomers. It is definitely step forward, to use Godot and VS without side extension and you also able to debug in VS with some workaround, but 'no code generation' issue is a brick wall you cannot go through on very first steps in tutorial.

Godot_v4.1-stable_mono_win64 Windows 10 Visual Studio Enterprise 2022

[GarrickWinter]

I also ran into this while following the "Your First 2D Game" tutorial. While the issue itself isn't a devastating problem by any means, I think the fact that it's going to hit newcomers who are following an official tutorial is potentially severe from the perspective of the community's accessibility and growth.

I suggest rewriting the tutorial to explicitly mention the bug and provide a workaround. In particular, without the code generation working, the tutorial's suggestion of leaving the default connection settings seems to clash with the provided C# code. The tutorial suggests connecting to a function called __on_bodyentered, which matches the GDScript code but differs from the C# code presented, which is a function called OnBodyEntered.

It seems after some testing that Godot generates CS files that smooths over the formatting differences between __on_bodyentered and OnBodyEntered, but that's not something I would have expected or understood, and might be something worth contextualizing.

Godot 4.1.1 Mono / Windows 10 / Visual Studio Code

[Calinou]

@GarrickWinter Feel free to open a pull request by editing https://github.com/godotengine/godot-docs/blob/master/getting_started/first_2d_game/03.coding_the_player.rst :slightly_smiling_face:

I don't use C# myself, so I'm not sure what should be changed exactly on that page. It already mentions the code you should write after connecting the signal.

[GarrickWinter]

Thanks for prompting! I've made a pull request here. I think a small change to be more explicit, and an explicit warning about the bug, would be sufficient to smooth over this bump in the tutorial flow.

https://github.com/godotengine/godot-docs/pull/7915

[rickygai]

Godot version 4.1.1 VS Code version1.82.2 Godot Tools VS Code extension version 1.3.1 System information Windows 11

The problem occurred in Godot 4.1.1 with VSCode as well, even Godot IDE itself is not creating the signal connect routine correctly, the routine is created out of the scope of the class of the script attached such as below.

Please help to resolve this problem, it has been there for quite long.

[Eterxity]

still does not work as of v4.1.3.stable.mono.official [f06b6836a]

[Vysp3r]

This really needs to be added

[Calinou]

@Vysp3r Please don't bump issues without contributing significant new information. Use the :+1: reaction button on the first post instead.

[Hobitus]

I'm pretty sure the bug is in the _add_callback in the script_editor_plugin.cpp. we add the script to the editor with EditorNode::get_singleton()->push_item(scr.ptr());

This adds the script to the history, then call _edit_current in case of external editor it opens the external editor but doesn't add the script in the tab of the editor.

Then

the get edited resources never finds the script because it's not in the editor tab but in the external editor, so the call to add the function is never called.

    se->add_callback(p_function, p_args);

If there is a way to temporarily add the script to the internal editor? or maybe creating a scripteditorbase from a script instead of finding the tab with the script.

[EvilBarney]

Just adding that this is still an issue in Godot 4.2.1 with C# and Visual Studio 2022.

Godot is able to create and open new scripts ok, but connecting a signal doesn't generate any C# code regardless of saving the scene / rebuilding in VS or Godot / closing and re-opening the source file, etc.

Edit: as a suggestion, and also given that directly modifying the file may cause problems if it has unsaved changes in the external editor: We already have the ability to copy the signal name to the clipboard from the node panel. How about some way of either copying the full signature (in appropriate language) from the same place, or directly putting the handler code on the clipboard when connecting signals? In the latter case, if it's made obvious enough that that's happening (maybe a "Copy script code to clipboard" checkbox on the create panel), and Godot is still opening the appropriate file, then it's just a case of the user choosing where to hit ctrl-v.

[kastromatos]

Edit: as a suggestion, and also given that directly modifying the file may cause problems if it has unsaved changes in the external editor: We already have the ability to copy the signal name to the clipboard from the node panel. How about some way of either copying the full signature (in appropriate language) from the same place, or directly putting the handler code on the clipboard when connecting signals? In the latter case, if it's made obvious enough that that's happening (maybe a "Copy script code to clipboard" checkbox on the create panel), and Godot is still opening the appropriate file, then it's just a case of the user choosing where to hit ctrl-v.

@EvilBarney Nice catch but proposed and rejected almost a year ago: Crutch for outside editor code generation issue

[Calinou]

Nice catch but proposed and rejected almost a year ago:

I think this workaround makes a lot of sense, but there's another open proposal tracking it already: https://github.com/godotengine/godot-proposals/issues/3633

Therefore, your proposal was actually a duplicate of that one.

[kastromatos]

@Calinou Yeah... So we have 4 years old annoying bug and 3 years old proposed workaround both not implemented. At least this issue are in top 5 sorted by reaction in editor topic, so there is a hope that it will be noticed and fixed soon.