This thread is for VSCode impressions and support.
[Dev] Visual Studio Code (VSCode) Impressions + Support
- Thread starter Quintillus
- Start date
How did you generate the tasks.json and launch.json files, and where do they live?
I'm attempting to follow the guide at https://github.com/godotengine/godot-csharp-vscode, but despite having the C# and C# Tools for Godot plugins installed, when I get to the "Setup Debugging" step, I don't see the "C# Godot" options it lists, following either Option 1 or Option 2.
Potentially relevant question: Did you open the "Prototype" folder to open the project, or the C7.sln file? I've been doing the former, but maybe it's required to do the latter for the C# Tools for Godot to work properly.
Armageddon1
Chieftain
- Joined
- Aug 7, 2004
- Messages
- 47
In that post you quoted I generated both files.
The launch.json was generated from the "Run and Debug" menu (like the github repo describes as option 2 in "Setup Debugging").
I don't exactly remember how I set up tasks.json, just that in the post you quoted there was an option for setting up a dotnet build.
The next day, I saw your link to that github repo and decided to try changing my setup to match that. I had some trouble with tasks.json because I had copied my godot exe path wrong, but eventually I got it to work. Now my working configs look like:
tasks.json:
I tried setting up an alias for Godot studio so I could just reference it as "godot", but I couldn't find a good way to do that. I guess setting up an environment variable and referencing it like %GODOT% might work, but I haven't tried it.
I generated the launch.json file as described in the github repo, the relevant launch config that I was using to debug is:
In VS Code I'm opening the root folder, which is why those configs reference the program path as "${workspaceRoot}/C7" as opposed to "${workspaceRoot}" like the github repo does.
Looking at the github repo again, I remember doing the first option in the "Setup Debugging" section yesterday to generate the files.
I find the debugging works decently well, although sometimes it will freeze when stepping into functions, I'm guessing because it gets lost trying to dig into assemblies.
The launch.json was generated from the "Run and Debug" menu (like the github repo describes as option 2 in "Setup Debugging").
I don't exactly remember how I set up tasks.json, just that in the post you quoted there was an option for setting up a dotnet build.
The next day, I saw your link to that github repo and decided to try changing my setup to match that. I had some trouble with tasks.json because I had copied my godot exe path wrong, but eventually I got it to work. Now my working configs look like:
tasks.json:
Code:
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "build",
"command": "C:/<redacted>/Godot_v3.4.2-stable_mono_win64/Godot_v3.4.2-stable_mono_win64.exe",
"type": "process",
"args": [
"--build-solutions",
"--path",
"${workspaceRoot}/C7",
"--no-window",
"-q"
],
"problemMatcher": "$msCompile"
}
]
}I tried setting up an alias for Godot studio so I could just reference it as "godot", but I couldn't find a good way to do that. I guess setting up an environment variable and referencing it like %GODOT% might work, but I haven't tried it.
I generated the launch.json file as described in the github repo, the relevant launch config that I was using to debug is:
Code:
{
"name": "Launch",
"type": "godot-mono",
"request": "launch",
"mode": "executable",
"preLaunchTask": "build",
"executable": "C:/<redacted>/Godot_v3.4.2-stable_mono_win64/Godot_v3.4.2-stable_mono_win64.exe\r",
// See which arguments are available here:
// https://docs.godotengine.org/en/stable/getting_started/editor/command_line_tutorial.html
"executableArguments": [
"--path",
"${workspaceRoot}/C7"
]
}In VS Code I'm opening the root folder, which is why those configs reference the program path as "${workspaceRoot}/C7" as opposed to "${workspaceRoot}" like the github repo does.
Looking at the github repo again, I remember doing the first option in the "Setup Debugging" section yesterday to generate the files.
I find the debugging works decently well, although sometimes it will freeze when stepping into functions, I'm guessing because it gets lost trying to dig into assemblies.
Last edited:
The "Run and Debug"/Option 2 path worked just now on my desktop. I don't know why it wasn't working on my laptop when I tried it there a couple days ago; I'll try it there again later. I do get a very short window whose title is sometimes empty and sometimes "Select" and what appears to be miniscule command prompt-y font when I launch... but then it does hit my breakpoints and show variables and do useful things in debug mode.
Screenshot:
The text says, "at: {mono/modules/csharp_script.cpp 2308}", although I might be misreading the line number, it's very very small!
It doesn't appear to cause any problems, but I'm curious if anyone else sees it as well. Once the main menu shows up, the "Select" window is no longer present.
Armageddon1
Chieftain
- Joined
- Aug 7, 2004
- Messages
- 47
I'm not seeing a prompt like that, that happens when you run the debug configuration?
Do you see it happening before or after the build task?
Does it go away once the debugger launches?
What version of Godot studio are you using?
Do you see it happening before or after the build task?
Does it go away once the debugger launches?
What version of Godot studio are you using?
Yeah, via F5 or Run -> Start Debugging
During, assuming the build task is when it says "Building..." at the bottom of VSCode.
Yes, once C7's window appears.
Initially 3.4.3 x86, but it also occurs with 3.4.2 x64.
In your launch.json, you have a /r at the end:
"executable": "C:/<redacted>/Godot_v3.4.2-stable_mono_win64/Godot_v3.4.2-stable_mono_win64.exe\r",
Is that intentional? I don't have that, maybe that's why I'm seeing this dialog? I thought it was probably a typo but maybe it's suppressing the dialog. Although it doesn't seem to make a difference when I add \r at the end.
Also perhaps worth mentioning, it takes about 15 seconds to get to the main menu when debugging with VSCode for me, most of which is the Building... time with the tiny command prompt. This compare with about 4-5 seconds from Godot directly, and 3-3.5 seconds from the full-fat Visual Studio 2019 Community Edition (don't have metrics for Rider, but it was fast enough that it didn't feel slow, likely also less than 5 seconds).
Armageddon1
Chieftain
- Joined
- Aug 7, 2004
- Messages
- 47
That `\r` character was added automatically by the plugin when it generated the command. I couldn't see much of a difference between having it and not having it, so I just kept it. When I debug from VS Code it takes about 10 seconds to get to debugging, pretty much all that time is the build task. I wonder if those other IDEs are executing a build task every time before launching?
Also it sounds like that window is associated with the build task, I wonder if it also pops up if you do the build task on the command line. Like, open Powershell, cd to the directory where the Godot exe is, then execute the build command (you'll probably need to make some adjustments for the path to the C7 project).
Also it sounds like that window is associated with the build task, I wonder if it also pops up if you do the build task on the command line. Like, open Powershell, cd to the directory where the Godot exe is, then execute the build command (you'll probably need to make some adjustments for the path to the C7 project).
WildWeazel
Carthago Creanda Est
I finally got it! VS 1.65.2 on Linux x64 with the latest Development. I used the snippets from post #3 with my own paths, and eventually found by trying to redo it from the GUI that I needed another layer around the contents of launch.json:
Code:
{
"configurations": [
{
"name": "Launch",
...
}
]
}Armageddon1
Chieftain
- Joined
- Aug 7, 2004
- Messages
- 47
Yes, sorry I should've maybe used the full config file, I assumed people would generate the default launch.json file and add their own config. The one that's generated is like:
Code:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
// configuration JSONs go here
]
}Armageddon1
Chieftain
- Joined
- Aug 7, 2004
- Messages
- 47
Finally got around to replacing my SSD, re-installed everything following the setup doc this guide and it's working great. This time I didn't need to do anything to the for `tasks.json`, the one that was automatically generated by the extension works just fine. Looking forward to getting back into this!
WildWeazel
Carthago Creanda Est
Are you able to build and launch from VS Code with .NET 6? That's the setup I used on the developer VM. It builds but doesn't launch, just flashes the status bar orange with no message. But if I run the launch command manually in the terminal it works.
Here are what I generated:
tasks.json:
output:
Here are what I generated:
tasks.json:
launch.json:
output:
Armageddon1
Chieftain
- Joined
- Aug 7, 2004
- Messages
- 47
Turns out I was 147 commits behind the Development branch 
but even after pulling it still runs.
For tasks.json all it needs is the path to Godot.
Ditto for lauch.json, plus adding C7 to the end of the workspaceRoot.
When I run the Launch config from VS Code it pops up a terminal window in VS Code for doing the build:
Although, now after pulling I notice the game doesn't run any more
but even after pulling it still runs.For tasks.json all it needs is the path to Godot.
JSON:
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "build",
"command": "C:\\<path to godot>\\Godot_v3.5-stable_mono_win64.exe",
"type": "process",
"args": [
"--build-solutions",
"--path",
"${workspaceRoot}",
"--no-window",
"-q"
],
"problemMatcher": "$msCompile"
}
]
}Ditto for lauch.json, plus adding C7 to the end of the workspaceRoot.
JSON:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Launch",
"type": "godot-mono",
"request": "launch",
"mode": "executable",
"preLaunchTask": "build",
"executable": "<path to>\\Godot_v3.5-stable_mono_win64.exe",
// See which arguments are available here:
// https://docs.godotengine.org/en/stable/getting_started/editor/command_line_tutorial.html
"executableArguments": [
"--path",
"${workspaceRoot}\\C7"
]
}
]
}When I run the Launch config from VS Code it pops up a terminal window in VS Code for doing the build:
And then it launches the C7 app.
Although, now after pulling I notice the game doesn't run any more
Armageddon1
Chieftain
- Joined
- Aug 7, 2004
- Messages
- 47
PS: glad to know I'm not the only one getting the
messages. They're a bit off-putting but at least the app runs.
WildWeazel
Carthago Creanda Est
Still no luck. Copying yours, I had to append /C7 to the workspace path, but now it fails to build. It indicates a Mono log, which includes something like what I've seen before:
What file did you open to get that error? Most games should load now.
Using my tasks and your launch, same behavior as before.
What file did you open to get that error? Most games should load now.
Armageddon1
Chieftain
- Joined
- Aug 7, 2004
- Messages
- 47
I'm on Windows, maybe you need to do something additional for Linux.
I'm not opening any files, I'm just doing a new game and it shows that error.
I'm not opening any files, I'm just doing a new game and it shows that error.
WildWeazel
Carthago Creanda Est
Did you get past this? I can still run with the latest Development and the default map. Do you have any local changes?Although, now after pulling I notice the game doesn't run any more
Armageddon1
Chieftain
- Joined
- Aug 7, 2004
- Messages
- 47
I just checked again today, pulled down the latest development version, I have no local changes, but it still gets that error. I tried doing some debugging but all I can tell is it's an issue parsing the c7-static-map-save.json file. The debugger in VS code isn't the greatest but I'll see if I can get a better pinpoint on what isn't parsing right.
EDIT: not sure... the debugger isn't the best, it doesn't really match up on the lines in that part of the code and inspecting variables doesn't fully work. I thought it might be a caching issue but I downloaded the file fresh from Github and overwrote it but they were the same file.
Last edited:
Does it work to load Civ3 BIQ or SAV files? Not all of them are supported yet, but SAV files based on lightly modified scenarios (notably ones that leave the default units in-place) should generally work.
You can also re-generate the static JSON by going to the _Console/BuildDevSave folder, changing the Civ3 path in Program.cs, making sure you have the attached .SAV file in your Conquests save folder, and running "dotnet run" from the BuildDevSave folder. If that fixes the problem, it means that the static-json got out of sync on the Development branch. Which probably has happened at some point, as it requires manual rebuilding when we add support for importing new types of Civ3 data. I know it was working Tuesday night when I made and tested a dev build, but it may have been fixed by a merge I made Monday or Tuesday, and thus not been working as intended when you checked.
I've been developing on Windows 8.1 (primarily) and 10 (secondarily, but also a decent amount), so it probably just needs the static JSON rebuilt. But if you're running Windows 7/11, it's theoretically possible there's some odd quirk we haven't encountered.
It might be worth trying the virtual machine that @WildWeazel set up (https://github.com/C7-Game/Prototype/issues/263). I tested it a couple weeks ago and made extensive notes on that card on anything that wasn't super-intuitive, but aside from some issues with VMWare not persisting shared folders as well as hoped, and a bit of a performance penalty versus running it on raw metal, it worked well.
I haven't actually used the VSCode debugger enough to be of much help with it; in my experience it was slow to start, but I didn't observe the issues you noticed. I think @WildWeazel may have used it more, based on our IDE poll this spring?
If the timing works out for a burst of involvement at some point, I highly recommend trying Rider (wiki setup instructions for C7 + Rider), in large part because its debugger is top-notch, though it also has other aces up its sleeve such as superior refactoring and linting support. It also has a free 30-day trial.
Armageddon1
Chieftain
- Joined
- Aug 7, 2004
- Messages
- 47
I regenerated the file, it doesn't show a diff in git so it seems the one on the Development branch is current. However it still doesn't seem to work. I'll look into Rider at some point and see if debugging is better in that.
