How do I compile a mod from its source code on Github?

[nukeboyt]

I have downloaded the source code mod.  I would like to make a minor tweak to the code and then recompile it to make it useable in the game (for my own personal use only).   How do I go about with the recompilation?

[ValiZockt]

It’s fairly straight forward:

1) Choose an IDE of your choice. Personally I use Visual Studio 2019. 

2) Open the Project in your IDE and add references (point to KSPs and Unity assemblies)

3) Depending on how old the mod is you’re trying to recompile, you have keep in mind that there were API changes throughout version, so you may have to adjust or change some parts of the code. 
 

4) Hit the Build Button. 
 

For more detailed instructions read through this post: 

 

 

 

 

[Lisias]

It may be intimidating at first, but it's really not that hard once you get your grasp on it.

First thing is to download and install Visual Studio Community Edition. The installer will do the heavy lifting for you.

Then, instead of downloading the code, it's better to  clone the repository. For that, you will need GIT. Using the embedded GIT client on VS is possible, but I hate this piece of crap, I prefer to use a proper GIT client, as Source Tree or Git Kraken.

If you never heard of GIT before, I strongly recommend you to read a good introductory tutorial about the matter.

Once you cloned the repository and installed the VS, all you need to do is to open the Solution File (SLN) using Visual Studio, and 80% of your problems are solved.

And so you will have something like this on your screen:

Spoiler

A Solution file is a collection of Projects. You  may find this overkill for your needs, as most of the time your add'ons consists on only one project.

Mas once your toys grow up on complexity, you realise that the Solution is, indeed, needed!

 

Now with 80% of your problems solved, we need to solve the other 80%.

Every project on KSP has a thingy called Dependency. It's something else that your code relies in order to work. Unity Engine is, obviously, one of them, and the KSP libraries are another. On Visual Studio, we set them on the References "folder" on the Project Explorer:

That ones inside the References thingy is each one of the Assemblies I used on this project.

An Assembly is a "collection of related code" on C#, and are usually delivered inside a file called DLL (Dynamic Linked File). This is a source of confusion, because DLLs were initially meant to deploy shared C++ compiled code, and when used for this, the dependency is the DLL itself. On C#, however, DLLs are only glorified ZIP files - the dependency is not the DLL, but what is inside it. So the DLL can have any name, as long the Assembly inside it has has the name you need.

But, yet, the Assemblies are deployed inside DLLs, and usually the DLL file name follows the name of the Assembly it delivers (but not always, pay attention to this detail as it can bite you on the SAS horribly).

What leads us to another problem. You will not get a References list nice and ready to be used as it's shown above. It's almost sure you will have a messed up References list, as shown below:

This means that the DLLs I'm using on my machine are not available on the same place on yours. This is the first thing you will have to fix in order to recompile the add'on.

There're many professional ways of solving this problem, but usually people playing with KSP add'ons are not professionals and, so, not prone to waste time on learning how to do it professionally. So let's do it the simple way: quick & dirty - it's how I do anyway...

The easiest way to fix that, so, it's just to pinpoint the References to your local KSP installment you want to use for toying - I strongly advise you to make a copy of your game and use only that copy for toying add'ons - you can really screw up things by mangling source code, compiling it and running it on KSP.

Believe on me, I know what I'm talking.  

So, take note of every red alerted Assembly name on the References and delete them (there's a glitch on Visual Studio that if you try to add new references for already existing ones, on deleting the crappy one the new one is deleted too - so it's better to delete them first).

Click on the crappy Assembly using the right mouse button and select Delete:

Now you will add the copies you have on your machine (you took notes of the Assemblies you deleted, right?). To do so, Right Click on References and select Add:

It will open a Modal Window, select the Net Assembly tab:

And then click on the Browse button under the list of current known Assemblies (I expect your list will be empty, mine if full of Assemblies from many different KSP versions):

From now on, it's hunt time, baby. You need to locate every needed DLL.

It sounds harder than it is, really. These DLLs are located on very specific places.

The KSP and Unity DLLs,  on Windows machines, will be on the Managed directory that it's on the KSP_Data directory on the same place where is the KSP.exe file. On Linux, if memory serves me well, it's the same. On MacOS things are different, you will find them on KSP.app/Contents/Resources/Data/Managed .

When the add'on your are mangling depends of other add'ons, you will find them on the GameData folder somewhere. You will need to dig a bit on these ones.

Now you are done. Build the Solution to see if everything is all right:

Once the building is done, you will find your compiled artefacts on the bin folder somewhere on the Solution's folder (dig a little, they are usually on the same place the SLN file is):

There 're Release and Debug  binaries. While developing, we usually shove a lot of debugging stuff that it's unwanted on the user's machine, so we get these debugging stuff ripped off the code when we compile a Release dll. You select Release or Debug on the top left of the Window (see the screenshot above where I tell how to Build the thing).

Now all you need is to copy the compiled DLL (only the one really generated is needed, on the example above, Score.dll) into the right place on the KSP's GameData folder and you are ready to screw up your KSP installment on new and exciting ways!!

Just always remember on doing thing on test beds (specialised copies meant to be mangled and mercilessly destroyed while testing things without risking your important savegames), and happy hacking!

Edited April 13, 2021 by Lisias
Eternal Tyops of the Englishless Mind

[Guest]

What is the change? It may be possible to do it with a MM patch that saves going through  lisias’ excellent instructions.

[Kwebib]

Wow, thank you, @Lisias. Definitely saving this for later.

[nukeboyt]

6 hours ago, Lisias said:

It may be intimidating at first, but it's really not hard once you get your grasp on it.

First thing is to download and install Visual Studio Community Edition. The installer will do the heavy lifting for you.

Then, instead of downloading the code, it's better to  clone the repository. For that, you will need GIT. Using the embedded GIT client on VS is possible, but I hate this piece of crap, I prefer to use a proper GIT client, as Source Tree or Git Kraken.

If you never heard of GIT before, I strongly recommend you to read a good introductory tutorial about the matter.

Once you cloned the repository and installed the VS, all you need to do is to open the Solution File (SLN) using Visual Studio, and 80% of your problems are solved.

And so you will have something like this on your screen:

  Reveal hidden contents

A Solution file is a collection of Projects. You  may find this overkill for your needs, as most of the time your add'ons consists on only one project.

Mas once your toys grow up on complexity, you realise that the Solution is, indeed, needed!

 

Now with 80% of your problems solved, we need to solve the other 80%.

Every project on KSP has a thingy called Dependency. It's something else that your code relies in order to work. Unity Engine is, obviously, one of them, and the KSP libraries are another. On Visual Studio, we set them on the References "folder" on the Project Explorer:

That ones inside the References thingy is each one of the Assemblies I used on this project.

An Assembly is a "collection of related code" on C#, and are usually delivered inside a file called DLL (Dynamic Linked File). This is a source of confusion, because DLLs are initially meant to deploy shared C++ compiled code, and when used for this, the dependency is the DLL itself. On C#, however, DLLs are only glorified ZIP files - the dependency is not the DLL, but what is inside it. So the DLL can have any name, as long the Assembly inside it has has the name you need.

But yet, the Assemblies are deployed inside DLLs, and usually the DLL file name follows the name of the Assembly it delivers (but not always, pay attention to this detail as it can bite you on the SAS horribly).

What leads to another problem. You will not get a References list nice and ready to be used as it's shown above. It's almost sure you will have a messed up References list, as shown below:

This means that the DLLs I'm using on my machine are not available on the same place on yours. This is the first thing you will have to fix in order to recompile the add'on.

There're many professional ways of solving this problem, but usually people playing with KSP add'ons are not professionals and, so, not prone to waste time to learn how to do it professionally. So lets do it the simple way: quick & dirty - it's how I do anyway...

The easiest way to fix that, so, it's just to pinpoint the References to your local KSP installment you want to use for toying - I strongly advise you to make a copy of your game and use only that copy for toying add'ons - you can really screw up things by mangling source code, compiling it and running it on KSP.

Believe on me, I know what I'm talking.  

So, take note of every red alert Assembly name on the References and delete them (there's a glitch on Visual Studio that if you try to add new references from already existing one, on deleting the crappy one the new one is deleted too - so it's better to deletem them first).

Click on the crappy Assembly using the right mouse button and select Delete:

Now you will add the copies you have on your machine (you took notes of the Assemblies you deleted, right?). To do so, Right Click on References and select Add:

It will open a Modal Window, select the Net Assembly tab:

And then click on the Browse button under the list of current known Assemblies (I expect your list will be empty, mine if full of Assemblies from many different KSP versions):

From now on, it's hunt time, baby. You need to locate every needed DLL.

It sounds harder than it is, really. These DLLs are located on very specific places.

The KSP and Unity DLLs,  on Windows machines, will be on the Managed directory that it's on the KSP_Data directory on the same place where is the KSP.exe file. On Linux, if memory serves me well, it's the same. On MacOS things are different, you will find them on KSP.app/Contents/Resources/Data/Managed .

When the add'on your are mangling depends of other add'ons, you will find them on the GameData folder somewhere. You will need to dig a bit on this ones.

Now you are done. Build the Solution to see if everything is all right:

Once the building is done, you will find your compiled artefacts on the bin folder somewhere on the Solution's folder (dig a little, they are usually on the same place the SLN file is):

There 're Release and Debug  binaries. While developing, we usually shove a lot of debugging stuff that it's unwanted on the user's machine, so we get these debugging stuff ripped off the code when we compile a Release dll. You select Release or Debug on the top left of the Window (see the screenshot above where I tell how to Build the thing).

Now all you need is to copy the compiled DLL (only the one really generated is needed, on the example above, Score.dll) into the right place on the KSP's GameData folder and you are ready to screw up your KSP installment on new and exciting ways!!

Just always remember on doing thing on test beds (specialised copies meant to be mangled and mercilessly destroyed while testing things without risking your important savegames), and happy hacking!

THANK YOU for the detailed how-to!

6 hours ago, Lisias said:

It may be intimidating at first, but it's really not hard once you get your grasp on it.

First thing is to download and install Visual Studio Community Edition. The installer will do the heavy lifting for you.

Then, instead of downloading the code, it's better to  clone the repository. For that, you will need GIT. Using the embedded GIT client on VS is possible, but I hate this piece of crap, I prefer to use a proper GIT client, as Source Tree or Git Kraken.

If you never heard of GIT before, I strongly recommend you to read a good introductory tutorial about the matter.

Once you cloned the repository and installed the VS, all you need to do is to open the Solution File (SLN) using Visual Studio, and 80% of your problems are solved.

And so you will have something like this on your screen:

  Reveal hidden contents

A Solution file is a collection of Projects. You  may find this overkill for your needs, as most of the time your add'ons consists on only one project.

Mas once your toys grow up on complexity, you realise that the Solution is, indeed, needed!

 

Now with 80% of your problems solved, we need to solve the other 80%.

Every project on KSP has a thingy called Dependency. It's something else that your code relies in order to work. Unity Engine is, obviously, one of them, and the KSP libraries are another. On Visual Studio, we set them on the References "folder" on the Project Explorer:

That ones inside the References thingy is each one of the Assemblies I used on this project.

An Assembly is a "collection of related code" on C#, and are usually delivered inside a file called DLL (Dynamic Linked File). This is a source of confusion, because DLLs are initially meant to deploy shared C++ compiled code, and when used for this, the dependency is the DLL itself. On C#, however, DLLs are only glorified ZIP files - the dependency is not the DLL, but what is inside it. So the DLL can have any name, as long the Assembly inside it has has the name you need.

But yet, the Assemblies are deployed inside DLLs, and usually the DLL file name follows the name of the Assembly it delivers (but not always, pay attention to this detail as it can bite you on the SAS horribly).

What leads to another problem. You will not get a References list nice and ready to be used as it's shown above. It's almost sure you will have a messed up References list, as shown below:

This means that the DLLs I'm using on my machine are not available on the same place on yours. This is the first thing you will have to fix in order to recompile the add'on.

There're many professional ways of solving this problem, but usually people playing with KSP add'ons are not professionals and, so, not prone to waste time to learn how to do it professionally. So lets do it the simple way: quick & dirty - it's how I do anyway...

The easiest way to fix that, so, it's just to pinpoint the References to your local KSP installment you want to use for toying - I strongly advise you to make a copy of your game and use only that copy for toying add'ons - you can really screw up things by mangling source code, compiling it and running it on KSP.

Believe on me, I know what I'm talking.  

So, take note of every red alert Assembly name on the References and delete them (there's a glitch on Visual Studio that if you try to add new references from already existing one, on deleting the crappy one the new one is deleted too - so it's better to deletem them first).

Click on the crappy Assembly using the right mouse button and select Delete:

Now you will add the copies you have on your machine (you took notes of the Assemblies you deleted, right?). To do so, Right Click on References and select Add:

It will open a Modal Window, select the Net Assembly tab:

And then click on the Browse button under the list of current known Assemblies (I expect your list will be empty, mine if full of Assemblies from many different KSP versions):

From now on, it's hunt time, baby. You need to locate every needed DLL.

It sounds harder than it is, really. These DLLs are located on very specific places.

The KSP and Unity DLLs,  on Windows machines, will be on the Managed directory that it's on the KSP_Data directory on the same place where is the KSP.exe file. On Linux, if memory serves me well, it's the same. On MacOS things are different, you will find them on KSP.app/Contents/Resources/Data/Managed .

When the add'on your are mangling depends of other add'ons, you will find them on the GameData folder somewhere. You will need to dig a bit on this ones.

Now you are done. Build the Solution to see if everything is all right:

Once the building is done, you will find your compiled artefacts on the bin folder somewhere on the Solution's folder (dig a little, they are usually on the same place the SLN file is):

There 're Release and Debug  binaries. While developing, we usually shove a lot of debugging stuff that it's unwanted on the user's machine, so we get these debugging stuff ripped off the code when we compile a Release dll. You select Release or Debug on the top left of the Window (see the screenshot above where I tell how to Build the thing).

Now all you need is to copy the compiled DLL (only the one really generated is needed, on the example above, Score.dll) into the right place on the KSP's GameData folder and you are ready to screw up your KSP installment on new and exciting ways!!

Just always remember on doing thing on test beds (specialised copies meant to be mangled and mercilessly destroyed while testing things without risking your important savegames), and happy hacking!

THANK YOU for the detailed how-to.   This will be very helpful!

[nukeboyt]

@Lisias   You obviously put a lot of work into your reply to my question and that is very much appreciated.   I want to get the full benefit of all your effort.   Is there supposed to be pictures embedded in your post?  I am presently only able to see a URL for each picture, and upon clicking, nothing comes up.
 

[Lisias]

1 hour ago, nukeboyt said:

@Lisias   You obviously put a lot of work into your reply to my question and that is very much appreciated.   I want to get the full benefit of all your effort.   Is there supposed to be pictures embedded in your post?  I am presently only able to see a URL for each picture, and upon clicking, nothing comes up.
 

Yes, and it's showing for me...  How is your browser configuration? Are you behind a firewall?

[nukeboyt]

7 minutes ago, Lisias said:

Yes, and it's showing for me...  How is your browser configuration? Are you behind a firewall?

Thanks.   Something wrong on my end.   When I use Firefox (rather than Chrome) the pictures work just fine.

 

[nukeboyt]

56 minutes ago, nukeboyt said:

Thanks.   Something wrong on my end.   When I use Firefox (rather than Chrome) the pictures work just fine.

 

At least I know that I'm not going crazy.   The problem is with chrome blocking mixed content:
https://www.searchenginejournal.com/chrome-81-will-not-load-mixed-content/358298/#close

 

[Lisias]

3 hours ago, nukeboyt said:

At least I know that I'm not going crazy.   The problem is with chrome blocking mixed content:
https://www.searchenginejournal.com/chrome-81-will-not-load-mixed-content/358298/#close

KRAP!!! This will screw up the local cache, forcing the browser to redownload the images every time you visit the page! KRAP!!

[nukeboyt]

@Lisias  Your instructions worked, and I was able to successfully re-compile the mod in question.     You are right, it wasn't as difficult as I had been thinking it would be.  For any that were wondering, I wanted to see if a problem I was having with SCANSat was able to be fixed with the proposed solution suggested in the issues section of GitHub.   (Issue #401).   Thanks to Vulcans22 for the fix to the problem in question.