Debugging a Godot C# Project using Jetbrains RIder

Currently you know how to debug godot using vs code, but my personal favorite IDE is Jetbrains Rider because I know most of the hotkeys and I use their other IDE’s for work on a daily basis. Rider just made sense, plus nothing beats an IDE made for working with a language.

(We’ll be using this project for this example)

Setting up your godot project

So lets get right to it. The first process is similar to the vs code tutorial, we need to double check a few settings in your godot project. So first go to Project -> Project Settings -> Mono -> Debugger Agent and make sure “Wait For Debugger” is checked. Next we want to change the wait time, the time is set using milliseconds, I personally increased this value to 10 seconds because it gives you a little time to enable the debugger and let it set itself up before attaching itself to your godot project.

setup godot csharp jetbrains rider

Setting Remote Debugging in Jetbrains Rider

In order for jetbrains to connect to the mono debugger we need to setup our configuration. So first select the drop down below Tests and Tools menu and hit Edit Configuration. Next we want to add the new configuration by pressing the green plus symbol and selecting Mono Remote. From here we rename our remote debugger, I used “Godot” as the name, set our host and we want to share the remote debugger so check that option as well. We’ll leave the port default for now. Hit Apply then hit Okay.

jetbrains configuration godot 3 csharp remote debugging

Now we need to setup the port for Rider to match the debugger in Godot

First go back to your debugger settings in your godot project and copy the debugger port

copy port godot jetbrains remote debugger

Next we need to edit our configuration in jetbrains. So like we did before use the drop down and select edit configuration, find our remote mono configuration and paste the port we used in our godot project.

Lets Debug!

Now to debug it’s simple, I start by running the godot application either by individual scenes or the full game by pressing the play button either works. Wait for the window to popup then head over to jetbrains rider and hit the debug icon and wait a second. If successful you’ll see variables in the debugger and you should be able to do everything you could with the debugger such as step in, step out, etc… I will note that sometimes the debugger may not work, simply just repeat these steps and wait a second after the window launches before trying to debug and it should work normally.

jetbrains rider debug test godot csharp

Wait, I still can’t get debugging working in my current application!

There’s a chance that you have some unhandled exceptions in your application and the debugger by default does not catch them. Take a look here where I purposely add a NullReferenceException to my application.

exception jetbrains rider csharp

So how do you fix this you ask? It’s very simple. First click on the Run menu and go to the very bottom and select View Breakpoints or CTRL+Shift+F8 (on windows). Next check Any Exception under .NET Exception Breakpoints and try debugging again. (note: you can manually add specific exceptions if you highlight .NET Exception Breakpoints then hitting the Plus sign and typing in an exception name)

exception jetbrains rider csharp

And that’s about it. Happy Debugging!

Catching Exceptions when debugging your c# godot projects using visual studio code & Mono Debug Extension

So the guys over at Godosharp.Net wrote an article on how to setup the mono-debug extension to work with your godot projects. Well currently out of the box exceptions are not caught by default and you may want to catch NullReferenceException‘s when working on your games. So after combing through some source on the plugin I figured out how to do just that.

First you need to open your user settings.

As long as you have the Mono Debug extension installed start typing mono-debug and it should auto complete. If the auto complete doesn’t work you can simply add the following setting block to your user settings file and restart the editor.

Now to test add something like public Random Rand; to your scene script and try to debug. Currently we only have NullRefenceException enabled, but you can choose between never, always and unhandled. In the above settings to catch exceptions.

Happy Debugging!

Getting Visual Studio Code & Godot 3.0 Mono working on Windows

When working with godot 3.0 and the C# api you may want to have some intellisense support. Well, lately there’s been some confusion on how to properly get that working and I’m going to help you get started in a few easy steps.


Download & install the following

Now Omnisharp requires Windows 8 (.NET 4.5) SDK or the intellisense will not work.  Some people may already have this installed, some may not, but if intellisense doesn’t work this is one of the root causes on why it’s not working.

Gotcha: If your project name has spaces then omnisharp may not pick up the project and you’ll need to remove the spaces from your project name and files. Rule of thumb: never have spaces in your project name or filenames, it’ll probably cause more problems than it should.)

Get Coding

Once you’ve built your project, by either pressing the start scene icon or manually building from the mono tab at the bottom of your editor, open the project folder inside visual studio code. Now you should test the intellisense by typing GD.P to see if GD.Print auto-completes. If it auto-completes the godot method then you’ve successfully setup visual studio code to work on your godot 3 C# projects!

Happy Deving

Slim framework 3 – Passing Custom Headers to error pages

So during work today I ran into an issue. There were a lot of users connecting and some pages were showing Slim Frameworks custom error pages.

A website error has occurred. Sorry for the temporary inconvenience.

Now you’ve seen this error from time to time and usually it’s not a huge problem, for us that issue resulted in too many connections to our database at once while the page cache was rebuilding. Usually this fixes itself (and I probably should add a workaround to that soon), but we’re using Litespeed Cache. Litespeed sucks, not because it’s bad software, but because when shit hits the fan litespeed can cache it and it’s very painful to deal with. Which in our case it was caching that slim error page “website error has occurred”. That’s no good so I needed to tell litespeed not to cache the page when this happens.

Continue reading

Building Godot 3.1 Mono (C#) on Windows 10 using VS Build Tools 2017!

UPDATE: Added changes to reflect native tools for vs 2017 instead of 2015
UPDATE 2: Added general information to get 3.1 building
3: Updated title to reflect what’s going on in this article, this article is mostly for building godot mono from the source on windows 10 and I’ve written an article on vs code specifically: visual studio code setup. Also if you’re looking for a quick-start guide checkout my recent article.


Using this method doesn’t statically link mono into the export binary and requires you to ship the mono-sgen dll along side your executable. It’s recommended to use the official builds from the official website.


So recently I came across Godot from a reddit post because I got inspired to get back into gamedev. Problem was I couldn’t figured out a language to use because the languages I wanted to use is either not recommended for desktop game development (Java/Kotlin) or still in development without full windows support (Crystal). My friends been using unity lately and has been inspiring me, but I remember when Unity got it’s 2D support and I was excited to try it back then. When I thought about my experience I always had in the back of my mind how the latest C# support wasn’t really there yet, but it was improving and the scripting api was a mess (in my eyes).

I checked out godot’s website and skimmed the news and noticed oh cool 3.0 is almost out, what I failed to realize was 3.0 was already out I was just reading an old RC post and some how missed the announcement post and got really excited. I checked out the new docs for 3.0 and man does it look great. Although I do think getting things setup on windows could improve, everything else is spot on! Loving it guys, keep up the great work.

Fast Forward

So I bit the bullet and downloaded 3.0, had issues right away and then by the power of a lot of googling I came across two videos which saved me hours of stress (also please go check out their godot content and support those guys).

Now I didn’t know a lot of things regarding godot, like that I needed to rebuild it to make it properly work for me on my machine. So with a few guides (including the videos above) I ran into some common pitfalls and hopefully this guide should help you get EVERYTHING ready to make this go as smoothly as possible.


The following are things I used to build and get c# working with intellisense out of the box using visual studio code.

Alright, all the above is everything I needed to get godot compiling properly, and getting the scripts to work properly in visual studio code.

Setting up Scons

I had a little issue with scons when trying to figure out how to get it to work, but it looks like I just needed to make sure python and the python scripts path was added to my windows paths and I could call scons from the command line which should spit out some weird error instead of command doesn’t exist.

  • #:\Python27
  • #:\Python27\Scripts

Above paths where # is your Drive where python folder is installed because when you run the scons installer it’ll look for the python27 folder and install there. Simple enough.

Preparing for Godot 3.1

3.1 changes a lot in the build process. So I’m going to provide a few things to get you ready for building 3.1

Mono does not trust certifications by default. So we need to make sure we have them setup on windows by running the following commands in console (mozroots and certmgr should be provided by mono’s bin folder so make sure you have mono added to your path if it isn’t added automatically).

$ mozroots --import --sync
$ certmgr -ssl
$ certmgr -ssl
$ certmgr -ssl

This should allow you to build without hitting any errors with nuget.

Building Godot 3

Firstly I’m going to direct you to the official docs regarding building in case my instructions aren’t clear. I didn’t use Pywin32, then again I have an i7 4790K cpu so the build speed wasn’t too  slow, but probably could’ve been faster if I followed the official docs instead of 3rd party sources. Pywin32 is completely optional though not needed for this tutorial.

So the first thing you need to do is open the visual studio build tools command line. This does some fancy stuff like properly finding environment variables to let scons properly compile godot. Read the docs for more information on that. Now open your windows search menu and type in x64 Native Tools and you should see a list of options that look like the following:

The one you want is x64 Native Tools Command Prompt for VS 2017 or x86 for 32bit version of godot and mono. Make sure your mono installation matches the version you’re building (64bit mono + 64 bit build tool and vice versa).

(Note: You could also open up the windows start menu and select “V” and look under Visual C++ Build Tools to find the same exe. Also you don’t need to run this as administrator)

Cloning the Repo

Now that the visual c++ command prompt is open travel to the drive’s home path so in my case it’s C:\. Create a temporary directory called temp and travel inside the directory.

Go to the git repo and find the clone path for the version of godot you’re trying to build, we’ll be building master for now.  Try other releases if master gives you problems.

Type git clone repo/link to clone the repo inside of the current temp directory. It’ll look something like this:

git clone

Now travel inside of the repo path so you can build the project.

Building godot with mono support

This next part is pretty simple. If you’ve already installed Mono (which you should have), it’ll come with MSBuild 15.0 and you won’t have to deal with finding MSBuild yourself.  Mono should’ve already added itself to your paths and you’re already set for building the project.

We need to build godot twice, once without and once with mono glue. The first time allows us to get the mono modules to support C# scripting and the second build is to allow us to use C# scripts with mono support. So first lets build godot to generate our modules and to do that you need to run:

scons p=windows tools=yes module_mono_enabled=yes mono_glue=no

Now you have to wait a bit, check the docs if you want to speed up building with Pywin32. Could take upwards to 10-15 minutes depending on the speed of your cpu. Once the build is complete it’ll let you know and if you have any errors go back and make sure you didn’t miss installing any of the requirements I listed above and if you continue to have issues check the docs and let me know if I missed any steps as I’m a bit tired writing this as I just got done getting this to work perfectly for me.

Once that’s done go to the bin folder and get the exe name and copy it to your clipboard. In my case the exe is Now we need go back to the root godot folder to generate the glue code so we can rebuild w/ modules supported. So type the following in the command prompt:

bin\ --generate-mono-glue modules/mono/glue

If that doesn’t work go back to the bin folder and try: --generate-mono-glue ../modules/mono/glue

Which should do the same thing. Once that’s finished we need to rebuild godot with mono support. So type the following command and we’re done with the editor:

scons p=windows target=release_debug tools=yes module_mono_enabled=yes

(Tip: You can bundle mono with the editor by providing copy_mono_root=yes to the build command above)

You may also need export templates so the follow commands will do just fine:

scons p=windows target=release tools=no module_mono_enabled=yes
scons p=windows target=debug tools=no module_mono_enabled=yes

3.1 introduces a new ‘data.mono.[PLATFORM].[32/64].[release/debug]’ folder

When building templates these new data folders need to be added to the godot templates folder because it includes new assembly files when exporting.

Now you should be set on the build process. Move the godot folder to wherever you want and you should be able to execute it without any issues.

Testing Visual Studio Code

(Here’s a tutorial on getting c# working with visual studio code)

If you’ve never started up visual studio code just start it up and keep it open. Then with godot create a new scene and save it. Now create a new Panel and save it. Create a sub Label node and rename it to “my_label” and edit the text to say anything really. Press the play button to make sure godot runs and shows the text.

Update: forgot one important note, make sure in editor settings under Mono -> Builds that you select MS Build (System) instead on windows. This worked wonders for me, thanks to this guy for the suggestion.

Go to editor -> editor settings and select Visual Studio Code from the External Editior drop down option. Now add a script to the label and select C# from the language drop down and hit create. This should open my_label.cs in visual studio code without any issue. Inside the _Ready() methods body add the following:


Don’t copy and paste the above because we want to make sure the intellisense/autocomplete works. When typing GD. you should see a bunch of methods after the period and Print should be one of the methods in the list as you type. If you see that you have completed the setup of Godot and I hope you have fun going through the Step By Step tutorial and learn about the editor and scripting to start making your first game!