RimWorld Wiki - User contributions [en]

Topic:Vrbkob5ggehrr5al

2021-01-12T21:03:53Z

Alistaire (talk | contribs) commented on "Question:" (How are you supposed to cut something with a wood knife)

Modding Tutorials/Setting up a solution

2018-06-04T21:18:06Z

Alistaire: /* Sharpdevelop */

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

In this tutorial you will learn how to set up a solution, along with instructions on setting the output directory and files for more convenient building right into the Assemblies folder.

=Requirements=

* The manual option in this tutorial requires you to have [[Modding_Tutorials/Mod_folder_structure#The Source and Assemblies folders|set up a Source and Assemblies folder]] (the Visual Studio automatic option sets this up for you).
* You will want to have an IDE installed: [[Modding Tutorials/Recommended software#IDE's|Recommended IDE's]]. 

=Setting up a solution=
Setting up can be different for different IDE's. Feel free to add '''''complete''''' instructions for your IDE of choice.

===Visual Studio Community 2017===
''NOTE: Visual Studio 2017 is a rather heavy application (2-3 GB for basic functionality) but has a bit more functionality. Only Install if your computer can handle it! The tutorial is similar for Visual Studio 2015.''

==== Option 1 (Manual Method):====
# Create a new class library project
## Once loaded, go to File -> New -> Project...
## Go to Templates -> Visual C# -> Class Library (Be sure to select the *.NET Framework* version, not *.NET Standard*) [[File:Capture.png|200px|thumb|right|Installing the .NET framework]]
## Enter your name and solution name in the lower pane.
## Choose a location, preferably: <pre>(RimWorldInstallFolder)/Mods/(YourModName)/Source</pre>
## ''Optional'': Untick "Create directory for solution"
# In your project, set target framework and various other porperties
## In your Solution Explorer, right click your project -> Properties
## Once in your properties, select Application -> Set Target Framework to .NET Framework 3.5 (No client profile)
## ''Optional'': Change your Assembly and Namespace names to anything of your choice
## Go to Build -> Advanced... and set "Debugging information" to none
## Leave Advanced..., and set the Output Path to "..\..\Assemblies\" (The Assemblies folder in your mod folder)
# Add references to RimWorld code
## Expand your project. Then right click "References" -> Add Reference...
## Click Browse...
## Navigate towards <pre>RimWorld******/RimWorld******_Data/Managed</pre> and select files: <pre>Assembly-CSharp.dll
UnityEngine.dll</pre>
## Click "Add"
## Right click on both Assembly-CSharp.dll and UnityEngine.dll and set Copy Local to False (Properties pane).

====Option 2 (Automatic Method):====
# Open Visual Studio
# Once loaded, go to File -> New -> From Cookiecutter...
# Search for ''rimworld''
# Double-click ''cookiecutter-rimworld-mod-development''
# Change the Template Options:
## ''Create To'' => ''Your/Rimworld/Mod/Directory''
## ''mod_name''
## ''namespace_name'' (don't change if unsure)
## ''author'' => ''your steam username''
## ''target_version'' => current RW version (can leave blank for most up-to-date)
## ''in_game_description'' (not required, can change later in About-Release.xml)
## ''url'' (can leave blank for link to your Steam Workshop profile)
# Click "Create and Open Folder"

===Sharpdevelop===
'''Caution:''' Sharpdevelop (or #develop) does NOT CURRENTLY allow for C# 6.0+ syntax without plugins and does NOT ALLOW for C# 7.0+ syntax at all. For your average project this does not matter, however some existing projects are already built entirely upon C# 6.0+ syntax which can not be compiled anymore in Sharpdevelop. Visual Studio does not have these issues and should be your go-to for compiling large projects such as Combat Extended.

# Create a new class library project in your [[Modding Tutorials/Recommended software#IDE.27s|IDE of choice]];
## Go to File -> New -> Solution;
## Go to C# or .NET -> Library or Class Library (NOT portable);
## Enter a project name (solution name automatically updated);
## Choose a location, preferably: <pre>(RimWorldInstallFolder)/Mods/(YourModName)/Source</pre>
## ''Optional'': Untick "Create a directory for solution"/"Create a project within the solution directory",
# In your project, add references to Assembly-CSharp.dll and UnityEngine.dll:
## In your IDE project file browser, right-click the "References" folder and "Add reference";
## Choose the ".NET Assembly Browser" tab and "Browse...";
## Navigate towards <pre>RimWorld******/RimWorld******_Data/Managed</pre> and select files: <pre>Assembly-CSharp.dll
UnityEngine.dll</pre>
## Click "Open" then "OK";
## In the References folder, right-click Assembly-CSharp -> Properties and change "Local copy" to False. Do the same for UnityEngine,
# In your project properties, change the target framework to .NET 3.5:
## In your IDE project file browser, right-click "(YourSolutionName)";
## Choose Properties;
## Go to the "Compiling" tab, "Output", "Target framework", "Change" and choose ".NET Framework 3.5",
# In your project properties, change the build events so only a single file is built:
## Go to the "Compiling" tab, "Output", "Debug info" and choose "No debug information";
## Right-click your .cs files -> Properties and change "Copy to output" (If you haven't resized the properties bar, this will be truncated to "Copy to out") to Never,
# In your project properties, fix the output location to put the DLL in the Assemblies folder:
## Go to the "Compiling" tab, "Output", "Output path" and change the output path to "..\..\Assemblies\". 

===Xamarin===
The setup is similar as the one above. A few special points to address:
# Mono 4.X isn't backward compatible so you may need to install an older 3.X version of Mono in order to compile against .NET3.5 dlls.
# Make sure you uncheck "Use MSBuild build engine (recommended for this project type)" under project > options > build > general

===macOS===
There is no best practice for modding on a Mac since Xamarin is not backwards compatible with .Net3.5. That said, there is a very practical way around this by virtualizing Visual Studio and ILSpy on macOS with VirtualBox. This approach allows the use of macOS or Windows development tools, but relies on Visual Studio for compilation.
# [https://github.com/roxxploxx/RimWorldModGuide/wiki/SHORTTUTORIAL%3A-Mac-Modding-HowTo Mac Modding HowTo]
# Follow the above steps for Visual Studio

=See also=
* [[Modding Tutorials/Writing custom code|Writing custom code]] continues on setting up your solution. 

[[Category:Modding tutorials]]

Modding Tutorials/Setting up a solution

2018-06-04T21:17:33Z

Alistaire: /* Sharpdevelop */ Warning on use

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

In this tutorial you will learn how to set up a solution, along with instructions on setting the output directory and files for more convenient building right into the Assemblies folder.

=Requirements=

* The manual option in this tutorial requires you to have [[Modding_Tutorials/Mod_folder_structure#The Source and Assemblies folders|set up a Source and Assemblies folder]] (the Visual Studio automatic option sets this up for you).
* You will want to have an IDE installed: [[Modding Tutorials/Recommended software#IDE's|Recommended IDE's]]. 

=Setting up a solution=
Setting up can be different for different IDE's. Feel free to add '''''complete''''' instructions for your IDE of choice.

===Visual Studio Community 2017===
''NOTE: Visual Studio 2017 is a rather heavy application (2-3 GB for basic functionality) but has a bit more functionality. Only Install if your computer can handle it! The tutorial is similar for Visual Studio 2015.''

==== Option 1 (Manual Method):====
# Create a new class library project
## Once loaded, go to File -> New -> Project...
## Go to Templates -> Visual C# -> Class Library (Be sure to select the *.NET Framework* version, not *.NET Standard*) [[File:Capture.png|200px|thumb|right|Installing the .NET framework]]
## Enter your name and solution name in the lower pane.
## Choose a location, preferably: <pre>(RimWorldInstallFolder)/Mods/(YourModName)/Source</pre>
## ''Optional'': Untick "Create directory for solution"
# In your project, set target framework and various other porperties
## In your Solution Explorer, right click your project -> Properties
## Once in your properties, select Application -> Set Target Framework to .NET Framework 3.5 (No client profile)
## ''Optional'': Change your Assembly and Namespace names to anything of your choice
## Go to Build -> Advanced... and set "Debugging information" to none
## Leave Advanced..., and set the Output Path to "..\..\Assemblies\" (The Assemblies folder in your mod folder)
# Add references to RimWorld code
## Expand your project. Then right click "References" -> Add Reference...
## Click Browse...
## Navigate towards <pre>RimWorld******/RimWorld******_Data/Managed</pre> and select files: <pre>Assembly-CSharp.dll
UnityEngine.dll</pre>
## Click "Add"
## Right click on both Assembly-CSharp.dll and UnityEngine.dll and set Copy Local to False (Properties pane).

====Option 2 (Automatic Method):====
# Open Visual Studio
# Once loaded, go to File -> New -> From Cookiecutter...
# Search for ''rimworld''
# Double-click ''cookiecutter-rimworld-mod-development''
# Change the Template Options:
## ''Create To'' => ''Your/Rimworld/Mod/Directory''
## ''mod_name''
## ''namespace_name'' (don't change if unsure)
## ''author'' => ''your steam username''
## ''target_version'' => current RW version (can leave blank for most up-to-date)
## ''in_game_description'' (not required, can change later in About-Release.xml)
## ''url'' (can leave blank for link to your Steam Workshop profile)
# Click "Create and Open Folder"

===Sharpdevelop===
Sharpdevelop (or #develop) does NOT CURRENTLY allow for C# 6.0+ syntax without plugins and does NOT ALLOW for C# 7.0+ syntax at all. For your average project this does not matter, however some existing projects are already built entirely upon C# 6.0+ syntax which can not be compiled anymore in Sharpdevelop. Visual Studio does not have these issues and should be your go-to for compiling large projects such as Combat Extended.

# Create a new class library project in your [[Modding Tutorials/Recommended software#IDE.27s|IDE of choice]];
## Go to File -> New -> Solution;
## Go to C# or .NET -> Library or Class Library (NOT portable);
## Enter a project name (solution name automatically updated);
## Choose a location, preferably: <pre>(RimWorldInstallFolder)/Mods/(YourModName)/Source</pre>
## ''Optional'': Untick "Create a directory for solution"/"Create a project within the solution directory",
# In your project, add references to Assembly-CSharp.dll and UnityEngine.dll:
## In your IDE project file browser, right-click the "References" folder and "Add reference";
## Choose the ".NET Assembly Browser" tab and "Browse...";
## Navigate towards <pre>RimWorld******/RimWorld******_Data/Managed</pre> and select files: <pre>Assembly-CSharp.dll
UnityEngine.dll</pre>
## Click "Open" then "OK";
## In the References folder, right-click Assembly-CSharp -> Properties and change "Local copy" to False. Do the same for UnityEngine,
# In your project properties, change the target framework to .NET 3.5:
## In your IDE project file browser, right-click "(YourSolutionName)";
## Choose Properties;
## Go to the "Compiling" tab, "Output", "Target framework", "Change" and choose ".NET Framework 3.5",
# In your project properties, change the build events so only a single file is built:
## Go to the "Compiling" tab, "Output", "Debug info" and choose "No debug information";
## Right-click your .cs files -> Properties and change "Copy to output" (If you haven't resized the properties bar, this will be truncated to "Copy to out") to Never,
# In your project properties, fix the output location to put the DLL in the Assemblies folder:
## Go to the "Compiling" tab, "Output", "Output path" and change the output path to "..\..\Assemblies\". 

===Xamarin===
The setup is similar as the one above. A few special points to address:
# Mono 4.X isn't backward compatible so you may need to install an older 3.X version of Mono in order to compile against .NET3.5 dlls.
# Make sure you uncheck "Use MSBuild build engine (recommended for this project type)" under project > options > build > general

===macOS===
There is no best practice for modding on a Mac since Xamarin is not backwards compatible with .Net3.5. That said, there is a very practical way around this by virtualizing Visual Studio and ILSpy on macOS with VirtualBox. This approach allows the use of macOS or Windows development tools, but relies on Visual Studio for compilation.
# [https://github.com/roxxploxx/RimWorldModGuide/wiki/SHORTTUTORIAL%3A-Mac-Modding-HowTo Mac Modding HowTo]
# Follow the above steps for Visual Studio

=See also=
* [[Modding Tutorials/Writing custom code|Writing custom code]] continues on setting up your solution. 

[[Category:Modding tutorials]]

Modding Tutorials/Writing custom code

2017-05-13T08:18:28Z

Alistaire: /* Writing code */

{{BackToTutorials}}
{{Credit|[[User:TheTynan|TheTynan]]|extra=1}} 

This tutorial gives you a broad idea how to work on a C# solution. 

=Requirements=

* This tutorial requires you to have [[Modding Tutorials/Setting up a solution|set up a solution]]. 

=Creating a class=


===Sharpdevelop===

When you start your software you'll see a '''Projects''' file explorer to the left, a '''Properties''' explorer to the right and currently opened files in the middle.

* With your solution open, create a new class inside your '''Projects''' explorer;
*# If you don't have [[Modding Tutorials/Setting up a solution|your solution]] open you can do so by clicking File -> Open -> Project/Solution.. or by choosing a recent project on the '''Start page''' in the middle;
*# If it's not expanded, click the + next to "Solution ''MySolutionName''". Right-click ''MyProjectName'' (this could be the same as ''MySolutionName'' or different, depending on how you set up the solution);
*# Select Add -> New Item.. -> '''Categories:''' C# -> '''Templates:''' Class -> '''File Name:''' ''MyClassName''.cs,

====Template====

Let's go over the template:

<source lang="csharp">/*
* Created by SharpDevelop.
* User: You
* Date: 01-01-1970
* Time: 00:00
*
* To change this template use Tools | Options | Coding | Edit Standard Headers.
*/
using System;

namespace MyNameSpace
{
/// <summary>
/// Description of MyClassName.
/// </summary>
public class MyClassName
{
public MyClassName()
{
}
}
}</source> 

====Using====

The first thing you notice is ''using System;'' which indicates this class can call anything from the namespace ''System'' without calling it like ''System.Class.SomeDataType'' but rather ''SomeDataType''. This is very useful because we don't have to worry about such calls anymore (for now). 

The next section shows which namespaces you could put in ''using''. 

====Namespace====

Next up is the ''namespace MyNameSpace'' part - in principle everything inside of a namespace knows everything else inside of that namespace. If you were to make a folder inside of your project (''MyProjectName'' not Solution ''MySolutionName''), any classes inside of that folder would have the namespace ''MyNameSpace.MyFolderName''. '''That's a different namespace''' and unless you tell other classes that it exists (''using MyNameSpace.MyFolderName;'') they won't accept calls to parts of that namespace without that namespace as a prefix. 

Anything inside of ''MyNameSpace.MyFolderName'' does however know of everything inside ''MyNameSpace'', just nothing about other subfolders of ''MyNameSpace''. 

By default your project knows nothing. Adding DLL references to the ''References'' folder (as done in the previous tutorial) allows you to reference them with ''using'':

<source lang="csharp">
namespace MyNameSpace {} /* Assuming MyNameSpace is your ROOT NAMESPACE (MyProjectName ->
Properties -> Application -> Root namespace), this will compile. */

namespace MyNameSpace.MyFolderName {} /* Assuming this class is inside of the folder MyFolderName inside of
MyProjectName, this will compile. Other classes outside of the folder
will have to reference this, this class will have to reference classes
in different subfolders (but not the ones in the root folder). */

namespace RimWorld {} /* Don't do this. It will compile if RimWorld is your root namespace
but it's bad practice. */

namespace System {} /* No, just no. */
</source> 

You can set your project's namespace by right-clicking MyProjectName -> Properties -> Application -> Root namespace. Please take some time to make it unique so no compatibility issues will arise with other mods, for your and everyone else's sanity. 

Some very useful namespaces in general are the following: 

{|
! Namespace !! What does it do?
|-
| System.Collections.Generic || Makes it so you can use part of the IEnumerable interface, which is used for datatypes like List<>.
|-
| System.Linq || Allows for cool operations on the IEnumerable interface such as ''.Where()'' which accepts lambda operations (oh my!).
|-
| System.Text.RegularExpressions || Introduces Regular Expressions (RegEx) to C# which allows for intricate operations on strings.
|-
| System.Collections || Holds other parts of the IEnumerable interface you will require when inheriting from that class.
|-
| System.Text || Contains the ''StringBuilder'' which accepts a list of strings and returns them in a specific way.
|} 

And the namespaces for RimWorld in particular are these: 

{|
! Namespace !! What does it do?
|-
| RimWorld || Many classes can be found in this namespace.
|-
| RimWorld.Planet || Everything (almost everything) having to do with the planet savefile is in here.
|-
| RimWorld.SquadAI || Holds the squad AI, clearly. You'll know it when you need this.
|-
| Verse || Sometimes more complex classes are found here.
|-
| Verse.AI || You might never have to touch this either.
|-
| Verse.Grammar || Contains functionality for the Languages folder and other things having to do with text operations such as the art flavour text generator.
|-
| Verse.Noise || Something something you'll never need this.
|-
| Verse.Sound || Much like Verse.Noise except it's required to play sounds directly with your code.
|-
| Verse.Steam || Steam integration by Tynan - it's not active so you won't need it.
|-
| UnityEngine || Contains many more methods you most likely won't need.
|-
|} 

The difference between RimWorld and Verse is not very clear and you might as well add both using statements whenever you want. 
If you want to use the exact functionality of a base game class you're best off copying all its ''using'' statements, its ''namespace'' and the namespace of its parent. 

====Summary====

This summary is part of the template but it's not required. It can help other people understand your code better when you provide the source but besides that you really don't need it. 

====Class and Constructor====

This is your class definition. To access anything inside of a ''public class'' you will need a reference to an instance of that class: 

<source lang="csharp">
MyClassNamefoo = new MyClassName();
</source> 

The brackets at ''new MyClassName()'' indicate you're creating this instance without ''parameters'' which is possible because your class contains a constructor (anything inside of ''class MyClassName'' which has parameters and isn't a method, often abbreviated '''.ctor''') which accepts a call without parameters: 

<source lang="csharp">
public class MyClassName
{
public MyClassName() /* No parameters */
{
}

public MyClassName(string foo, int bar) /* Required parameters of datatypes string and int */
{
}

public MyClassName(string foo = "none supplied", int bar = 42) /* Default parameters " " " */
{
}
}</source> 

The last implementation of the constructor (''MyNameSpace.MyClassName.MyClassName'' inside of ''MyNameSpace.MyClassName'') is capable of accepting zero to two parameters while the second implementation of the constructor will only accept calls with exactly two parameters. 

=Writing code=

# [[Modding Tutorials/Decompiling source code|Decompile source code]] to take a look at the game's existing code;
## If you get stuck on anything, any modding questions can be asked on the [https://ludeon.com/forums/index.php?board=14.0 subforum],
# Compile your class into a .dll;
## Most IDE's, integrated development environments, have a button that says "Compile" or you could press F5 or a similar hotkey. Compiling is entirely driven by the software, you only have to supply a location for it to compile to - as explained in [[Modding Tutorials/Setting up a solution|Setting up a solution]].
## Make sure your project's output type is "class library";
## '' '''Note:''' by default, Visual Studio will compile all the references of the project as well, so you’ll get a copy of UnityEngine.dll and Assembly-CSharp.dll and some others. Just take ''MyModName.dll'' and place it in the ''MyModName/Assemblies'' folder. If you have [[Modding Tutorials/Setting up a solution|set up a solution]] according to the tutorial you don't have this problem,
# Reference the classes in your .dll from the xml data in the MyModName/Defs folder;
## '''Example:''' Create a new ThingDef with a <thingClass> that points to a class in your .dll,
# The game should load your class now; 

=See also=

* [[Modding_Tutorials/Distribution|Distribution]] details how to release your mod.
* [[Modding Tutorials/Assembly Modding Example|Assembly modding example]] contains a small modding example. 

[[Category:Modding tutorials]]

Modding Tutorials/Setting up a solution

2017-05-13T08:17:22Z

Alistaire: /* Visual Studio Community 2017 */ Removed the unrelated text about .NET 7.0 and the comparison to SharpDevelop, fixed the note being in italics

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

In this tutorial you will learn how to set up a solution, along with instructions on setting the output directory and files for more convenient building right into the Assemblies folder.

=Requirements=

* This tutorial requires you to have [[Modding_Tutorials/Mod_folder_structure#The Source and Assemblies folders|set up a Source and Assemblies folder]].
* You will want to have an IDE installed: [[Modding Tutorials/Recommended software#IDE's|Recommended IDE's]]. 

=Setting up a solution=
Setting up can be different for different IDE's. Feel free to add '''''complete''''' instructions for your IDE of choice.

===Visual Studio Community 2017===
''NOTE: Visual Studio 2017 is a rather heavy application (2-3 GB for basic functionality) but has a bit more functionality. Only Install if your computer can handle it! The tutorial is similar for Visual Studio 2015.''
# Create a new class library project
## Once loaded, go to File -> New -> Project...
## Go to Templates -> Visual C# -> Class Library (.NET Framework if applicable)
## Enter your name and solution name in the lower pane.
## Choose a location, preferably: <pre>(RimWorldInstallFolder)/Mods/(YourModName)/Source</pre>
## ''Optional'': Untick "Create directory for solution"
# In your project, set target framework and various other porperties
## In your Solution Explorer, right click your project -> Properties
## Once in your properties, select Application -> Set Target Framework to .NET Framework 3.5 (No client profile)
## ''Optional'': Change your Assembly and Namespace names to anything of your choice
## Go to Build -> Advanced... -> Debugging information and set it to none
## Leave Advanced..., and set the Output Path to "..\..\Assemblies\" (The Assemblies folder in your mod folder)
# Add references to RimWorld code
## Expand your project. Then right click "References" -> Add Reference...
## Click Browse...
## Navigate towards <pre>RimWorld******/RimWorld******_Data/Managed</pre> and select files: <pre>Assembly-CSharp.dll
UnityEngine.dll</pre>
## Click "Add"
## Right click on both Assembly-CSharp.dll and UnityEngine.dll and set Copy Local to False (Properties pane).

===Sharpdevelop===
# Create a new class library project in your [[Modding Tutorials/Recommended software#IDE.27s|IDE of choice]];
## Go to File -> New -> Solution;
## Go to C# or .NET -> Library or Class Library (NOT portable);
## Enter a project name (solution name automatically updated);
## Choose a location, preferably: <pre>(RimWorldInstallFolder)/Mods/(YourModName)/Source</pre>
## ''Optional'': Untick "Create a directory for solution"/"Create a project within the solution directory",
# In your project, add references to Assembly-CSharp.dll and UnityEngine.dll:
## In your IDE project file browser, right-click the "References" folder and "Add reference";
## Choose the ".NET Assembly Browser" tab and "Browse...";
## Navigate towards <pre>RimWorld******/RimWorld******_Data/Managed</pre> and select files: <pre>Assembly-CSharp.dll
UnityEngine.dll</pre>
## Click "Open" then "OK";
## In the References folder, right-click Assembly-CSharp -> Properties and change "Local copy" to False. Do the same for UnityEngine,
# In your project properties, change the target framework to .NET 3.5:
## In your IDE project file browser, right-click "(YourSolutionName)";
## Choose Properties;
## Go to the "Compiling" tab, "Output", "Target framework", "Change" and choose ".NET Framework 3.5",
# In your project properties, change the build events so only a single file is built:
## Go to the "Compiling" tab, "Output", "Debug info" and choose "No debug information";
## Right-click your .cs files -> Properties and change "Copy to output" (If you haven't resized the properties bar, this will be truncated to "Copy to out") to Never,
# In your project properties, fix the output location to put the DLL in the Assemblies folder:
## Go to the "Compiling" tab, "Output", "Output path" and change the output path to "..\..\Assemblies\". 

===Xamarin===
The setup is similar as the one above. A few special points to address:
# Mono 4.X isn't backward compatible so you may need to install an older 3.X version of Mono in order to compile against .NET3.5 dlls.
# Make sure you uncheck "Use MSBuild build engine (recommended for this project type)" under project > options > build > general

=See also=
* [[Modding Tutorials/Writing custom code|Writing custom code]] continues on setting up your solution. 

[[Category:Modding tutorials]]

Modding Tutorials/Writing custom code

2017-05-13T08:15:11Z

Alistaire: /* Writing code */ Additional explanation on compiling

{{BackToTutorials}}
{{Credit|[[User:TheTynan|TheTynan]]|extra=1}} 

This tutorial gives you a broad idea how to work on a C# solution. 

=Requirements=

* This tutorial requires you to have [[Modding Tutorials/Setting up a solution|set up a solution]]. 

=Creating a class=


===Sharpdevelop===

When you start your software you'll see a '''Projects''' file explorer to the left, a '''Properties''' explorer to the right and currently opened files in the middle.

* With your solution open, create a new class inside your '''Projects''' explorer;
*# If you don't have [[Modding Tutorials/Setting up a solution|your solution]] open you can do so by clicking File -> Open -> Project/Solution.. or by choosing a recent project on the '''Start page''' in the middle;
*# If it's not expanded, click the + next to "Solution ''MySolutionName''". Right-click ''MyProjectName'' (this could be the same as ''MySolutionName'' or different, depending on how you set up the solution);
*# Select Add -> New Item.. -> '''Categories:''' C# -> '''Templates:''' Class -> '''File Name:''' ''MyClassName''.cs,

====Template====

Let's go over the template:

<source lang="csharp">/*
* Created by SharpDevelop.
* User: You
* Date: 01-01-1970
* Time: 00:00
*
* To change this template use Tools | Options | Coding | Edit Standard Headers.
*/
using System;

namespace MyNameSpace
{
/// <summary>
/// Description of MyClassName.
/// </summary>
public class MyClassName
{
public MyClassName()
{
}
}
}</source> 

====Using====

The first thing you notice is ''using System;'' which indicates this class can call anything from the namespace ''System'' without calling it like ''System.Class.SomeDataType'' but rather ''SomeDataType''. This is very useful because we don't have to worry about such calls anymore (for now). 

The next section shows which namespaces you could put in ''using''. 

====Namespace====

Next up is the ''namespace MyNameSpace'' part - in principle everything inside of a namespace knows everything else inside of that namespace. If you were to make a folder inside of your project (''MyProjectName'' not Solution ''MySolutionName''), any classes inside of that folder would have the namespace ''MyNameSpace.MyFolderName''. '''That's a different namespace''' and unless you tell other classes that it exists (''using MyNameSpace.MyFolderName;'') they won't accept calls to parts of that namespace without that namespace as a prefix. 

Anything inside of ''MyNameSpace.MyFolderName'' does however know of everything inside ''MyNameSpace'', just nothing about other subfolders of ''MyNameSpace''. 

By default your project knows nothing. Adding DLL references to the ''References'' folder (as done in the previous tutorial) allows you to reference them with ''using'':

<source lang="csharp">
namespace MyNameSpace {} /* Assuming MyNameSpace is your ROOT NAMESPACE (MyProjectName ->
Properties -> Application -> Root namespace), this will compile. */

namespace MyNameSpace.MyFolderName {} /* Assuming this class is inside of the folder MyFolderName inside of
MyProjectName, this will compile. Other classes outside of the folder
will have to reference this, this class will have to reference classes
in different subfolders (but not the ones in the root folder). */

namespace RimWorld {} /* Don't do this. It will compile if RimWorld is your root namespace
but it's bad practice. */

namespace System {} /* No, just no. */
</source> 

You can set your project's namespace by right-clicking MyProjectName -> Properties -> Application -> Root namespace. Please take some time to make it unique so no compatibility issues will arise with other mods, for your and everyone else's sanity. 

Some very useful namespaces in general are the following: 

{|
! Namespace !! What does it do?
|-
| System.Collections.Generic || Makes it so you can use part of the IEnumerable interface, which is used for datatypes like List<>.
|-
| System.Linq || Allows for cool operations on the IEnumerable interface such as ''.Where()'' which accepts lambda operations (oh my!).
|-
| System.Text.RegularExpressions || Introduces Regular Expressions (RegEx) to C# which allows for intricate operations on strings.
|-
| System.Collections || Holds other parts of the IEnumerable interface you will require when inheriting from that class.
|-
| System.Text || Contains the ''StringBuilder'' which accepts a list of strings and returns them in a specific way.
|} 

And the namespaces for RimWorld in particular are these: 

{|
! Namespace !! What does it do?
|-
| RimWorld || Many classes can be found in this namespace.
|-
| RimWorld.Planet || Everything (almost everything) having to do with the planet savefile is in here.
|-
| RimWorld.SquadAI || Holds the squad AI, clearly. You'll know it when you need this.
|-
| Verse || Sometimes more complex classes are found here.
|-
| Verse.AI || You might never have to touch this either.
|-
| Verse.Grammar || Contains functionality for the Languages folder and other things having to do with text operations such as the art flavour text generator.
|-
| Verse.Noise || Something something you'll never need this.
|-
| Verse.Sound || Much like Verse.Noise except it's required to play sounds directly with your code.
|-
| Verse.Steam || Steam integration by Tynan - it's not active so you won't need it.
|-
| UnityEngine || Contains many more methods you most likely won't need.
|-
|} 

The difference between RimWorld and Verse is not very clear and you might as well add both using statements whenever you want. 
If you want to use the exact functionality of a base game class you're best off copying all its ''using'' statements, its ''namespace'' and the namespace of its parent. 

====Summary====

This summary is part of the template but it's not required. It can help other people understand your code better when you provide the source but besides that you really don't need it. 

====Class and Constructor====

This is your class definition. To access anything inside of a ''public class'' you will need a reference to an instance of that class: 

<source lang="csharp">
MyClassNamefoo = new MyClassName();
</source> 

The brackets at ''new MyClassName()'' indicate you're creating this instance without ''parameters'' which is possible because your class contains a constructor (anything inside of ''class MyClassName'' which has parameters and isn't a method, often abbreviated '''.ctor''') which accepts a call without parameters: 

<source lang="csharp">
public class MyClassName
{
public MyClassName() /* No parameters */
{
}

public MyClassName(string foo, int bar) /* Required parameters of datatypes string and int */
{
}

public MyClassName(string foo = "none supplied", int bar = 42) /* Default parameters " " " */
{
}
}</source> 

The last implementation of the constructor (''MyNameSpace.MyClassName.MyClassName'' inside of ''MyNameSpace.MyClassName'') is capable of accepting zero to two parameters while the second implementation of the constructor will only accept calls with exactly two parameters. 

=Writing code=

# [[Modding Tutorials/Decompiling source code|Decompile source code]] to take a look at the game's existing code;
## If you get stuck on anything, any modding questions can be asked on the [https://ludeon.com/forums/index.php?board=14.0 subforum],
# Compile your class into a .dll;
## Most IDE's, integrated development environments, have a button that says "Compile" or you could press F5 or a similar hotkey. Compiling is entirely driven by the software, you only have to supply a location for it to compile to.
## Make sure your project's output type is "class library";
## '' '''Note:''' by default, Visual Studio will compile all the references of the project as well, so you’ll get a copy of UnityEngine.dll and Assembly-CSharp.dll and some others. Just take ''MyModName.dll'' and place it in the ''MyModName/Assemblies'' folder. If you have [[Modding Tutorials/Setting up a solution|set up a solution]] according to the tutorial you don't have this problem,
# Reference the classes in your .dll from the xml data in the MyModName/Defs folder;
## '''Example:''' Create a new ThingDef with a <thingClass> that points to a class in your .dll,
# The game should load your class now; 

=See also=

* [[Modding_Tutorials/Distribution|Distribution]] details how to release your mod.
* [[Modding Tutorials/Assembly Modding Example|Assembly modding example]] contains a small modding example. 

[[Category:Modding tutorials]]

Template:LudeonThread

2016-08-23T08:09:22Z

Alistaire: Fixed the msg part of the template

<noinclude>{{Documentation}}</noinclude><includeonly>[{{{link|http://ludeon.com/forums/index.php?{{{3|topic}}}={{{1|{{{topic|}}}}}}}}}{{#if:{{{msg|}}}|.msg{{{msg|}}}#msg{{{msg|}}}|}} {{{2|Thread}}}]</includeonly><noinclude>[[Category:Templates]]</noinclude>

Template:LudeonThread

2016-08-23T07:59:19Z

Alistaire:

<noinclude>{{Documentation}}</noinclude><includeonly>[{{{link|http://ludeon.com/forums/index.php?{{{3|topic}}}={{{1|{{{topic|}}}}}}}}}{{#if:{{{msg|}}}|.msg{{{msg|}}}#{{{msg|}}}|}} {{{2|Thread}}}]</includeonly><noinclude>[[Category:Templates]]</noinclude>

Template:LudeonThread

2016-07-15T20:38:15Z

Alistaire: noincluded category

<noinclude>{{Documentation}}</noinclude><includeonly>[{{{link|http://ludeon.com/forums/index.php?{{{3|topic}}}={{{1|{{{number|}}}}}}}}} {{{2|Thread}}}]</includeonly><noinclude>[[Category:Templates]]</noinclude>

Modding Tutorials/Recommended software

2016-07-05T12:57:44Z

Alistaire:

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

=What you'll learn=

This tutorial lists a few programs you could use to edit XML and C# code. 

=XML Code Editors=

===Basic Editors===

Just about any text editor can write XML code, but as a modder you will want to at the very least see when you forgot closing brackets, a closing tag and other syntax errors. 

Notepad doesn't do this, so if you're even somewhat serious about modding, the following software will help you immensely: 

{| class="wikitable"
! Software !! OS !! Description
|-
| [NotepadQQ] || Linux || Notepadqq is a Notepad++-like editor for the Linux desktop so has the exact same UI and functions as Notepad++
|-
| [http://notepad-plus-plus.org/download/ Notepad++] || Windows || Has well implemented auto-completion and a very customizable user interface. Can be used to write both XML and C# code, although C# software usually has its own text editor
|-
| [http://www.sublimetext.com/ Sublime Text] || Mono || Natively supports many programming languages and markup languages, and its functionality can be extended by users with plugins - A brief overview of its functionality can be found [http://webdesign.tutsplus.com/tutorials/useful-shortcuts-for-a-faster-workflow-in-sublime-text-3--cms-22185 here] and a full course [http://code.tutsplus.com/courses/perfect-workflow-in-sublime-text-2 here]
|-
| [http://www.pnotepad.org/download/ Programmer's Notepad] || Windows || More lightweight with a less cluttered interface than Notepad++, also capable of editing both XML and C# code
|-
| [http://xmlnotepad.codeplex.com/releases/ XML Notepad] || Windows || XML-oriented editor with a lot of features you will most likely never use in Rimworld modding
|-
| [http://www.geany.org/ Geany] || Any || Extremely lightweight text editor with syntax highlighting and some other basic features oriented towards XML and code editing.
|} 

===Advanced Editors===

There's many editors out there specifically made for XML code. Because Rimworld uses XML in a very simple way, advanced code editors are rarely needed. In case you're ever in need of one, however, the following ones might help: 

{| class="wikitable"
! Software !! OS !! Description
|-
| [http://sourceforge.net/projects/xpontus/files/ XPontus] || Windows || Has a tree view and is capable of checking XML for errors, fixing tabs and creating schema's detailing every tag's data types
|-
| [http://xmlgrid.net/ XMLGrid] || - || Capable of validating XML and turning it into Excel Spreadsheets, XSD Charts and an online table detailing each tag of a certain type and its contents
|-
| [http://codebeautify.org/xmlviewer Codebeautify's xmlviewer] || - || Can display as a tree view, automatically format/indent your code and can validate and show errors too. Also have a function share code (like [http://codebeautify.org/xmlviewer/b39586 that])
|} 

=IDE's=

C# code is best edited in an IDE (Integrated Development Environment) to make the process of editing code, managing a solution's content and compiling its projects both easier and faster. Any IDE for C# will probably work just fine, so here's a list of suggested editors: 

{| class="wikitable"
! Software !! OS !! Description
|-
| [http://www.visualstudio.com/ Visual Studio] || Windows || Very extensive IDE with paid, trial and free versions. Any of these versions will probably work, so you might as well take [https://www.visualstudio.com/products/visual-studio-community-vs Visual Studio Community 2015] which is free for individuals and small teams
|-
| [http://www.icsharpcode.net/OpenSource/SD/Download/ SharpDevelop] || Windows || Free IDE specifically made for C#
|-
| [http://www.monodevelop.com/download/ MonoDevelop] || Mono1 || Free, cross-platform IDE with customizable user interface. Has support for C# as well as some other languages you won't need for Rimworld
|-
| [http://www.xamarin.com/platform Xamarin] || Mac || It's free but you need to register to download it. Probably your best option on a mac. PLEASE SOMEONE FIX THIS LINK
|}

# Windows, Mac and Linux 

Whichever IDE you choose, make sure it's capable of compiling for .NET Framework 3.5. If you for whatever reason don't have this framework installed, you can download it [https://www.microsoft.com/en-us/download/details.aspx?id=21 here]. 

=Additional C# Software=

Besides your IDE it's strongly recommended to install the following software for decompiling: 

{| class="wikitable"
! Software !! OS !! Description
|-
| [http://ilspy.net/ ILSpy] || Windows || Software which is capable of [[Modding Tutorials/Decompiling source code|decompiling source code]], which is very useful in Rimworld modding
|-
| [http://www.monodevelop.com/download/ MonoDevelop] || Mono || The Linux version of the software has an integrated decompiler for .DLLs
|} 

=Graphics Software=

For making textures you will need graphics software. Any image editing program should work, and if you have an alternative to the following links that's probably okay: 

{| class="wikitable"
! Software !! OS !! Description
|-
| [http://www.photofiltre-studio.com/download-en.htm Photofiltre Studio] || Windows || Functional software with very little user interface clutter for its applications. Doesn't support pen tablet, and has a 100% free (non-trial) version called [http://photofiltre.free.fr/download_en.htm Photofiltre]
|-
| [http://inkscape.org/en/download/ Inkscape] || Mono || Free vector graphic program with a steeper learning curve due to the vector based image editing. Vector graphics can look better than bitmap graphics in Rimworld
|-
| [http://www.photoshop.com/products Photoshop] || Windows/Mac || Paid software with a trial version. Rimworld's original graphics are made in Photoshop (they're .PSD files)
|-
| [http://www.gimp.org/ Gimp] || Mono || A free, open-source alternative to Photoshop that's been around since 1998. Gimp has a large user community, with great list of [http://www.gimp.org/tutorials/ tutorials] on the official sites
|} 

=Audio Software=

Recording your own audio for mods might be too much to ask, but editing audio is always possible. This can be done with the following software or your own alternative: 

{| class="wikitable"
! Software !! OS !! Description
|-
| [http://sourceforge.net/projects/audacity/ Audacity] || Mono || Audio editing software with many tutorials online, lots of useful functionality and a relatively readable interface
|} 

=Next up=

# [[Modding Tutorials/XML file structure|XML File Structure]] starts you off with the XML side of modding.
# [[Modding_Tutorials/Setting up a solution|Setting up]] starts you off with the C# side of modding. Knowledge of the XML part can and will be very useful. 

[[Category:Modding tutorials]]

Modding Tutorials/Mod folder structure

2016-05-12T19:51:12Z

Alistaire: /* The Source and Assemblies folders */

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

This tutorial introduces you to the mod folder structure and shows you a standard folder structure setup to help you start out. 

[[Modding Tutorials/Mod folder structure#Complete mod folder structure|Complete mod folder structure]] is a list of all folders you might find in your average mod directory. This includes /Core/. 

=Requirements=

* [[Modding Tutorials/Folder structure|Exploring the Folder Structure]] starts off explaining the folder structure. This is part two if you will. 

=What you'll learn=

You'll learn the following mod structure: 

YourModName/
About/
About.xml
Preview.png
Assemblies/
ProjectName.dll
Defs/
(..)
Languages/
English/
Strings/
NameBanks/
Sounds/
Source/
ProjectName/
ProjectName.sln
Textures/

.. Along with a few tips on how to keep your mod folder structure readable and functional. 

=Standard mod folder structure=

Mod folders are located in the mods folder, which is located as such: 

RimWorld******/
Mods/

..relative to your RimWorld install directory. Each mod is a sub folder of this Mods folder and each mod has to follow the following structure precisely. 

==The About folder==
{{Main|Modding Tutorials/About folder}} 

Making a mod starts with you making a folder structure. Some mods need textures and sounds, while others are XML or even C# only. 
Every mod does however require the following structure to show up in the mods list: 

YourModName/
About/
About.xml

Along with this vital information it's possible to add a preview image for your mod. This makes the structure as follows: 

YourModName/
About/
About.xml
Preview.png

The size of the base game Preview.png is 400x61 pixels, but some mods use higher preview images. The image is centered in the mod's description, and can be of any size. 

==The Defs folders==
{{Main|Modding Tutorials/Defs folder}} 

If your mod adds new content, chances are you're going to use XML files. These files are going to be stored in the folder structure as follows: 

YourModName/
Defs/
BiomeDefs/
Biomes.xml
BodyDefs/
Bodies.xml
BodyPartDefs/
BodyParts.xml
(..)

The contents of a Def folder don't follow a clear naming convention, but the folder names are generally the same in every mod. 
Using a non-standard name is going to make it harder for others to navigate your mod's folders, so it is advised to keep the folder names consistent with the base game. 

Typically, the files inside these folders are named after their contents: 

Core/
Defs/
ThingDefs/
Apparel_Hats.xml
Apparel_Shield.xml
(..)
Weapons_Melee.xml
Weapons_RangedNeolithic.xml

This makes it easier for people to navigate XML code. If your mod is going to add both apparel and weapons, or even both hats and shoes, you're best off separating the XML code in their respective files. 
Some mod authors choose to make a separate file for each of their items. This makes it easier for others to remove only part of your mod and keep the rest of it, but with very large mods it makes it harder to navigate the folder. 

==The Textures and Sounds folders==
{{Main|Modding Tutorials/Textures folder|Modding Tutorials/Sounds folder}} 

If you're using Defs chances are you're creating a content mod. This type of mod is most likely very dull without its own custom graphics and sounds. Adding such content requires the following folders: 

YourModName/
Textures/
Sounds/

The contents of the Textures and Sounds folder usually aren't the same between mods. The base game sorts these files in various folders and subfolders, but in the end it's very hard to navigate them based on the folder names. 
It's possible to categorize this content by item (submachinegun#1, pistol#3) or item type (guns, buildings), as an example. Whatever you do it's best to keep the structure consistent throughout both folders. 

==The Source and Assemblies folders==
{{Main|Modding Tutorials/Setting up a solution}} 

If you want to take a shot at [[Modding Tutorials/Writing custom code|C# modding]], you want an '''empty''' Source and an '''empty''' Assemblies folder. You'll want to [[Modding Tutorials/Setting up a solution|create the C# project]] inside your Source folder, and compile the class library into the Assemblies folder. These things are processed automatically by your [[Modding Tutorials/Recommended software#IDE's|IDE]], so you don't have to make these folder structures yourself: 

YourModName/
Assemblies/
ProjectName.dll
Source/
SolutionName/
SolutionName.sln
ProjectName/
ProjectName.csproj
(..)

''Or:''

YourModName/
Assemblies/
ProjectName.dll
Source/
ProjectName/
SolutionName.sln
ProjectName.csproj
(..)

'''Once again''', the structure of these folders is decided almost entirely by the author's editing software. Therefore the only things you have to set up are the following folders: 

YourModName/
Assemblies/
Source/

.. And then once you create a solution starting in ../YourModName/Source/ everything else will be sorted out by the software. People don't navigate these folders, they open ProjectName.sln to navigate it using their software of choice. 

==The Languages folder==
{{Main|Modding Tutorials/Languages folder}} 

Unless you're on a translation team, you're unlikely to need this folder a lot. If you want to randomly generate names using your own words, you will however have to use this folder: 

YourModName/
Languages/
English/
Strings/
NameBanks/

In this folder you put .txt files with a new word on every line. Using XML you will then be able to randomly pick one of the lines in the file. 
In the average mod the rest of the folder is quite useless. You are unlikely to translate your mod into tens of different languages. 

=Complete mod folder structure=

*/
About/
About.xml
Preview.png-
Assemblies/-
*.dll+
Defs/-
*Defs/+
*.xml+
Languages/-
*/*
DefInjected/-
*Defs/+
*.xml+
Keyed/-
*.xml+
Strings/-
NameBanks/
*.txt+
FriendlyName.txt-
LangIcon.png
LanguageInfo.xml
Sounds/-
*/*#
*.wav+
Source/-
*/*#
bin/
Debug/
*.**
obj/
Debug/
*.**
Properties/-
AssemblyInfo.cs
Source-DLLs/-
Assembly-CSharp.dll
UnityEngine.dll
*.csproj
*.OpenCover.Settings
*.sln
*/*#
*.cs+
Textures/-
*/*#
*.psd*
*.psd.meta*
*.png*

Anything with a / at the end is a folder;
Anything with a . in it is a file;
The * in *.* and */ stands for any arbitrary string;
The * after a file/folder stands for an occurence of >= 0;
The + after a file/folder stands for an occurrence of > 0;
The - after a file/folder stands for an occurrence of <= 1;
The # after a folder stands for a folder depth of >= 0.

=Next up=
* [[Modding Tutorials/Recommended software|Recommended Software]]

[[Category:Modding tutorials]]

Modding Tutorials/Decompiling source code

2016-04-24T09:31:21Z

Alistaire: /* ILSpy */ Request to add github links.

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

The base game provides a bunch of code snippets in ''../Source/'', relative to your Rimworld installation. Since this isn't a lot, one might want to take a look at the game's full source code: 

=Decompiling source code=

===ILSpy===

One method is to use ILSpy. This software is recommended because its settings are correct on a clean install. It is for Windows only, but you can compile it yourself as a CLI application for Mono framework on OS X and Linux, see [https://github.com/icsharpcode/ILSpy/issues/691 (This issue)] or [https://github.com/icsharpcode/ILSpy/issues/416 (This issue)] on GitHub for more info. 

# Download [http://ilspy.net/ ILSpy] (Download Binaries) and extract it to a directory of your choosing. Optionally create a desktop shortcut;
# '''Either''': associate the .dll extension with ILSpy:
## Navigate to ''Assembly-CSharp.dll'' in ''../Rimworld***_Data/Managed/'', relative to your Rimworld installation and with *** being a version number;
## Right-click "Open with" and select a standard program. Navigate to your ILSpy installation and double-click ''ILSpy.exe'', tick the checkbox and accept;
## Double-click ''Assembly-CSharp.dll'',
# '''Or''': open ILSpy and open a .dll:
## Open ILSpy;
## Go to File -> Open or press Ctrl+O, navigate to ''../Rimworld***_Data/Managed/'', relative to your Rimworld installation and with *** being a version number;
## Select ''Assembly-CSharp.dll'' and confirm,
# Click the "+" next to ''Assembly-CSharp (***)'', you will now see a list including the items ''Rimworld'' and ''Verse'';
# Take your time to look through the source code, to make yourself familiar. If you ever need the source code, open ILSpy again:
## Ctrl+Shift+F or Ctrl+E opens the search bar which can be used to search through all loaded assemblies;
## Ctrl+F opens a search bar for the currently opened decompiled class. 

===MonoDevelop===

MonoDevelop is capable of decompiling DLLs, albeit using clumsy initial settings. It is Linux only, otherwise you have to download Xamarin Studio which doesn't have a decompiler. 

# Download [http://www.monodevelop.com/download/ MonoDevelop] and install it;
# '''Either''': associate the .dll extension with MonoDevelop:
## Navigate to ''Assembly-CSharp.dll'' in ''../Rimworld***_Data/Managed/'', relative to your Rimworld installation and with *** being a version number;
## Right-click "Open with" and select MonoDevelop as standard program;
## Double-click ''Assembly-CSharp.dll'',
# '''Or''': open MonoDevelop and open a .dll:
## Open MonoDevelop;
## Go to File -> Open, navigate to ''../Rimworld***_Data/Managed/'', relative to your Rimworld installation and with *** being a version number;
## Select ''Assembly-CSharp.dll'' and confirm,
# '''Very important''': search for a dropdown called "Visibility" and change it from "Only public members" to "All members";
# '''Very important''': search for a dropdown called "Language" and change it from "Summary" to "C#";
# Click the "+" next to ''Assembly-CSharp (***)'', you will now see a list including the items ''Rimworld'' and ''Verse'';
# Take your time to look through the source code, to make yourself familiar. If you ever need the source code, open ''Assembly-CSharp.dll'' again. 

=See also=

* [[Modding Tutorials/Writing custom code|Writing custom code]] shows a broad overview of C# coding. 

[[Category:Modding tutorials]]

Modding Tutorials/XML file structure

2016-04-09T17:27:25Z

Alistaire: /* Basegun thingDef */ Changed Abstract for A13

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

In this tutorial we will start learning the XML syntax, why the base game uses it and what everything about it does. 

=What you'll learn=

You'll learn the default structure of def files: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<Def Name="Parent" Abstract="True">
</Def>

<Def ParentName="Parent">
</Def>


</Defs></source> 

.. Along with how inheritance using Name, ParentName and Abstract works. 

=Default Def structure=
===Standard defs===

Find a Def .xml file in the Core folder, for example thingDefs/Weapons_Guns.xml: 

Core/
Defs/
ThingDefs/
Weapons_Guns.xml

<source lang="xml">../Mods/Core/Defs/ThingDefs/Weapons_Guns.xml</source> 

The first thing in this file is the following line: 
<source lang="xml"><?xml version="1.0" encoding="utf-8"?></source> 

Which tells us this .xml files uses UTF-8 encoding and XML version 1.0, which are the default values for these fields - some XML editors choose to hide this line on editing and then save it on top of the document without ever asking the user about it. 

After that, the structure of the file consists of '''<Defs>''' and '''<Def>''' tags: 
<source lang="xml"><Defs>
<Def>
</Def>



<Def>
</Def>
</Defs></source> 

Each '''<Def>''' contains something's ''def'' (or definition), which can be used to specify each and every modifiable property, e.g for a certain ''thing'' (thingDef). 

===Differences in defs===

If you look through some .xml files, you'll find the code is inconsistent in the use of some defs; 

Several ''Buildings_**.xml'' files use the '''<Buildings>''' tag instead of the '''<Defs>''' one. They then proceed to use '''<thingDef>''''s inside the '''<Buildings>''' tag. 
Other ''Buildings_**.xml'' files use '''<Defs>''' instead of '''<ThingDefs>''', and some even use '''<GameData>''' instead of '''<ThingDefs>'''. 

This implies that the name of the beginning and ending tags isn't important. Rimworld doesn't read their names, it just looks whether they exist. 

This '''doesn't''' mean that '''<Def>''' tags are interchangeable. Using "<Def>" will break the game; you will have to specify what C# class will be loaded to parse its contents. 

===Full code===

'''It is important that your file follows this structure to the point where mods won't work with multiple <Defs>, or a <Def> outside of <Defs>:''' 
<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<Def>
</Def>



<Def>
</Def>
</Defs></source> 

=Inheritance=

'''Summary''': In XML, inheritance is used to decrease redundancy. If something has a ParentName="YourParentName", it takes all contents from Name="YourParentName". In case this ParentName is incomplete this will crash the game, and you stop it from being loaded into the game with Abstract="True". 

===Basegun thingDef===

The first thing in ''Weapons_Guns.xml'' is a '''<thingDef>''' with a Name and Abstract ''type'': 
<source lang="xml"><ThingDef Name="BaseGun" Abstract="True"></source> 

The Abstract type means that contents of this '''<thingDef>''' will not be loaded into the game, that after reading and processing the information in this tag it (the game) will finish reading the XML file ('''entire mod folder as of Alpha 13''') and '''discard''' this tag and its contents, leaving alone (not discarding) anything that might have copied (taken, inherited) the contents of it. All of this is done with this tag: 
<source lang="xml"><ThingDef Abstract="True"></source> 

The Name type means the contents of this '''<thingDef>''' can be ''inherited'' by (read: copied by) another '''<thingDef>'''. This way you can write everything you're going to repeat a lot throughout the file in a single location, such as the following: 
<source lang="xml"><category>Item</category></source> 

Which notifies that this '''<thingDef>''' is of the ''Item'' category, as opposed to those of the ''Building'' category. Because there's a lot of ''tags'' repeated throughout every thing, this greatly compacts the XML file. 
The full BaseGun parent only has to be defined once in a file, and can then be inherited (copied) with: 
<source lang="xml"><ThingDef ParentName="BaseGun"></source> 

'''<thingDef ParentName="Parent">''' inherits all contents from '''<thingDef Name="Parent">'''. It is common practice to copy the vanilla BaseGun parent and paste it on top of a mod's Weapons_Guns.xml file. 
Another parent is BaseBullet which holds every standard bullet's commonly repeated properties, such as the property that bullets don't use hitpoints: 
<source lang="xml"><useHitPoints>False</useHitPoints></source> 

The last '''<thingDef>''' on top of the file is one with the Name type ''BaseHumanGun'' and the ParentName type ''BaseGun''. It inherits the contents of BaseGun and is inherited by everything with '''<thingDef ParentName="BaseHumanGun">''': 
<source lang="xml"><ThingDef Name="BaseHumanGun" ParentName="BaseGun" Abstract="True"></source> 

A list representation of how inheritance works in Rimworld's XML might help you out, either early on or to collect your thoughts after reading the above. 

# Game launches
# Game loads mods individually:
## Inheritance information is taken from each tag
## Anything with a PARENTNAME type inherits (read: copies) and applies all content from its associated NAME type
##* Anything that gets content is a child
##* Anything that sends it is a parent
##* It's possible to be both of these
## Content information (read: everything between the <thingDef>) is taken and applied for each tag
##* All interfering content from parents is now overwritten
## Now that all <Def>s know their contents, ABSTRACT type defs are discarded and therefore ignored by the game
## All <Def>s and their contents finish loading
# Game finishes loading mods 

===Breakdown===

Let's break down the inheritance chunks of the BaseGun code: 
<source lang="xml"><thingDef Name="BaseGun" Abstract="True">
</thingDef>

<thingDef Name="BaseHumanGun" ParentName="BaseGun" Abstract="True">
</thingDef>

<thingDef Name="BaseBullet" Abstract="True">
</thingDef></source>

{| class="wikitable"
!colspan="2"|<ThingDef Name="BaseGun" Abstract="True">
|-
| <thingDef> || The name of this ''tag'', which is read by the game and processed into a correct definition based on this name. All tags in ''../Mods/Core/Defs/ThingDefs/'' use the '''<thingDef>''' tag.
|-
| Name="BaseGun" || The Name ''type'' of this tag. This tag is a parent with the Name value of "BaseGun".
|-
| Abstract="True" || The [https://en.wikipedia.org/wiki/Abstract_type Abstract type] of this tag is True. This makes it so that the contents of this tag aren't ''instantiated'', which in practice means the contents of it can only be inherited by other tags and won't be loaded into the game because its only purpose is in inheritance, in being a parent. "Is the only use of this '''<thingDef>''' to be inherited from? Yes: add Abstract="True". No: don't."
|-
!colspan="2"|<ThingDef Name="BaseHumanGun" ParentName="BaseGun" Abstract="True">
|-
| ParentName="BaseGun" || The ParentName type of this tag. This tag inherits from a parent with the Name value of "BaseGun".
|} 

===Full code===

After the addition of inheritance, our XML file structure looks like this: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<Def Name="Parent" Abstract="True">
</Def>

<Def ParentName="Parent">
</Def>


</Defs></source> 

* '''<Defs>''' can have any name you want;
* '''<Def>''' has to have a specific name.

=Next up=

* [[Modding Tutorials/Weapons Guns|Weapons_Guns.xml]] continues explanations on the BaseGun parent, the tags inside its '''<thingDef>''''s and further information on modding in weaponry.

[[Category:Modding tutorials]]

Modding Tutorials/Assets

2016-04-09T17:23:13Z

Alistaire: Created

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

In this tutorial you will learn how to rip base game assets through the use of Unity Assets Explorer and XnConvert.

=Requirements=

* You will want to have the following software installed:
*# [http://zenhax.com/viewtopic.php?t=36 Unity Assets Explorer v1.3+] (there are newer versions available) for ripping Unity .assets files;
*# [http://www.xnview.com/en/xnconvert/#downloads XnConvert] for mass-converting .dds/.tex files to .png or whichever is your preferred format. 

=Unity Assets Explorer=
To convert game assets from a Unity .assets file into their original file formats we can use Unity Assets Explorer. 
The download page of the software provides a tutorial however we will be listing the steps you have to take in this section as well. 

# Download Unity Assets Explorer;
## Search the software or download [http://zenhax.com/viewtopic.php?t=36 here (v1.3)];
## ''Optional'': drag the executable just outside your RimWorld root folder or in a similar location for ease of access;
## Take note of the location of the .exe file since the output folders will be generated in that same location,
# Open Unity Assets Explorer and select source files;
## Double-click the executable, allow it to run if such prompt comes up.
## "Open Assets-file", select <pre>RimWorld******\RimWorld******_Data\resources.assets</pre>
# Decide which assets you want to rip;
#* '''Textures''': Sort by "TYPE", select all "Texture2D - ***" and Right-click, "Extract This Files"[sic];
#* '''Sounds''': Sort by "TYPE", select all "AudioClip" '''but no AudioClip - OGGVORBIS''' and Right-click, "Extract This Files"[sic],
#* ''The default settings for extraction are sufficient.''
# Navigate towards your Unity Assets Explorer location, refresh with F5. A folder called "resources" should be created. 

=XnConvert=
The output format of Unity Assets Explorer for textures is .dds or .tex and all textures are flipped vertically. This can be fixed through the use of XnConvert. 

# Download XnConvert;
## Download [http://www.xnview.com/en/xnconvert/#downloads here];
# Open the software and select files to be converted;
## Double-click the executable or shortcut;
## "Add folder...", select the output '''folder''' containing all .dds and .tex files;
# Select actions to be performed per file;
## Go to "Actions [0/0]", select "Add action>" -> "Image" -> "Mirror";
## Tick "Vertical", make sure the action is "Enabled";
## ''Optional'': look at the preview before and after tabs to make sure the correct actions are being applied,
# Choose output format and directory;
## "Output": choose "Folder", decide on the folder location;
## "Filename": choose "{Filename}", optionally add "_out" or similar;
## "Format": choose "PNG - Portable Network Graphics" or whichever file format you prefer;
## ''Optional'': "After conversion" tick "Clear the 'Input' file(s)",
# Click "Convert", wait;
# The resource files are now fully converted to your format of choice and are present in the specified Output folder. 

=See also=
* [[Modding Tutorials/Recommended software#Graphics Software|Recommended graphics software]] for suggestions on software for further editing or viewing of source files. 

[[Category:Modding tutorials]]

Modding Tutorials

2016-04-09T17:22:35Z

Alistaire: /* General modding */

{| align=center
! {{MainSection_Nav}}
|}
{| align=center
| {{Mods_Nav}}
|}
<hr>

This is the table of contents for the modding tutorial. Here, you'll learn step by step how to create mods of gradually increasing complexity.

In light of little official documentation, this collection of tutorials has been written in hopes that more players will know how to modify RimWorld and make mods that further broaden horizons and make the game appealing to more audiences despite its early state.

==Table of contents==

===Introduction===

# [[Installing mods|Installing Mods]]
# [[Modding Tutorials/Folder structure|Exploring the Folder Structure]]
# [[Modding Tutorials/Mod folder structure|Mod Folder Structure]]
#* [[Modding Tutorials/About folder|About folder]]
#* [[Modding Tutorials/Defs folder|Defs folder]]
#* [[Modding Tutorials/Languages folder|Languages folder]]
#* [[Modding Tutorials/Textures folder|Textures folder]]
#* [[Modding Tutorials/Sounds folder|Sounds folder]]
# [[Modding Tutorials/Recommended software|Recommended Software]]

===General modding===

* [[Modding Tutorials/Testing mods|Testing Mods]]
** [[Modding Tutorials/Development mode|Development Mode]]
* [[Modding Tutorials/Sounds|Adding and Testing Sounds]]
* [[Modding Tutorials/Assets|Decompiling Texture/Sound Assets]]

===XML tutorials===

# [[Modding Tutorials/XML file structure|XML File Structure]]
# [[Modding Tutorials/XML Defs|Introduction to XML Defs]]
#* [[Modding Tutorials/Compatibility with defs|XML Def Compatibility]]
# In-depth XML Def tutorials
#* [[Modding Tutorials/Weapons Guns|Weapons_Guns.xml Explained]] 

''The following tutorials are likely outdated''
* [[Modding Tutorials/Getting Started|Getting Started]]
* [[Modding Tutorials/Items|Items]]
* [[Modding Tutorials/Flooring|Flooring]]
* [[Modding Tutorials/Weapons|Weapons]]
* [[Modding Tutorials/Furniture|Buildings and Furniture]]
* [[Modding Tutorials/Plants|Plants]]
* [[Modding Tutorials/Food|Food]]
* [[Modding Tutorials/Races and Pawns|Races and Pawns]]
* [[Modding_Tutorials/Smelter|Buildings and Furniture: Creating a Smelter]]

===C# tutorials===
# [[Modding_Tutorials/Setting up a solution|Setting up]]
# [[Modding_Tutorials/Decompiling source code|Decompiling Source Code]]
# [[Modding_Tutorials/Writing custom code|Writing Custom Code]]
# [[Modding_Tutorials/Def classes|Introduction to Def Classes]]
#* [[Modding_Tutorials/Modifying defs|Def Class Compatibility]]
# [[Modding_Tutorials/Compatibility_with_DLLs|Mod DLL Compatibility]]
#* [[Modding_Tutorials/Injection|C# Injection]]
# [[Modding_Tutorials/Distribution|Distribution]] 
''Examples:''
* [[Modding Tutorials/Assembly Modding Example|Assembly Modding]]

==See also==

* [[:Category:Defs|List of Defs]]

[[Category:Modding tutorials]]

Modding Tutorials

2016-04-09T12:30:00Z

Alistaire: /* General modding */

{| align=center
! {{MainSection_Nav}}
|}
{| align=center
| {{Mods_Nav}}
|}
<hr>

This is the table of contents for the modding tutorial. Here, you'll learn step by step how to create mods of gradually increasing complexity.

In light of little official documentation, this collection of tutorials has been written in hopes that more players will know how to modify RimWorld and make mods that further broaden horizons and make the game appealing to more audiences despite its early state.

==Table of contents==

===Introduction===

# [[Installing mods|Installing Mods]]
# [[Modding Tutorials/Folder structure|Exploring the Folder Structure]]
# [[Modding Tutorials/Mod folder structure|Mod Folder Structure]]
#* [[Modding Tutorials/About folder|About folder]]
#* [[Modding Tutorials/Defs folder|Defs folder]]
#* [[Modding Tutorials/Languages folder|Languages folder]]
#* [[Modding Tutorials/Textures folder|Textures folder]]
#* [[Modding Tutorials/Sounds folder|Sounds folder]]
# [[Modding Tutorials/Recommended software|Recommended Software]]

===General modding===

* [[Modding Tutorials/Testing mods|Testing Mods]]
** [[Modding Tutorials/Development mode|Development Mode]]
* [[Modding Tutorials/Sounds|Adding and Testing Sounds]]
* [[Modding Tutorials/Assets|Ripping Textures]]

===XML tutorials===

# [[Modding Tutorials/XML file structure|XML File Structure]]
# [[Modding Tutorials/XML Defs|Introduction to XML Defs]]
#* [[Modding Tutorials/Compatibility with defs|XML Def Compatibility]]
# In-depth XML Def tutorials
#* [[Modding Tutorials/Weapons Guns|Weapons_Guns.xml Explained]] 

''The following tutorials are likely outdated''
* [[Modding Tutorials/Getting Started|Getting Started]]
* [[Modding Tutorials/Items|Items]]
* [[Modding Tutorials/Flooring|Flooring]]
* [[Modding Tutorials/Weapons|Weapons]]
* [[Modding Tutorials/Furniture|Buildings and Furniture]]
* [[Modding Tutorials/Plants|Plants]]
* [[Modding Tutorials/Food|Food]]
* [[Modding Tutorials/Races and Pawns|Races and Pawns]]
* [[Modding_Tutorials/Smelter|Buildings and Furniture: Creating a Smelter]]

===C# tutorials===
# [[Modding_Tutorials/Setting up a solution|Setting up]]
# [[Modding_Tutorials/Decompiling source code|Decompiling Source Code]]
# [[Modding_Tutorials/Writing custom code|Writing Custom Code]]
# [[Modding_Tutorials/Def classes|Introduction to Def Classes]]
#* [[Modding_Tutorials/Modifying defs|Def Class Compatibility]]
# [[Modding_Tutorials/Compatibility_with_DLLs|Mod DLL Compatibility]]
#* [[Modding_Tutorials/Injection|C# Injection]]
# [[Modding_Tutorials/Distribution|Distribution]] 
''Examples:''
* [[Modding Tutorials/Assembly Modding Example|Assembly Modding]]

==See also==

* [[:Category:Defs|List of Defs]]

[[Category:Modding tutorials]]

Modding Tutorials/Setting up a solution

2016-04-09T11:02:52Z

Alistaire: /* Sharpdevelop */ Updated to not include the Source-DLLs folder

Modding Tutorials/Decompiling source code

2015-12-06T11:31:21Z

Alistaire: /* ILSpy */ Added info on searching

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

The base game provides a bunch of code snippets in ''../Source/'', relative to your Rimworld installation. Since this isn't a lot, one might want to take a look at the game's full source code: 

=Decompiling source code=

===ILSpy===

One method is to use ILSpy. This software is recommended because its settings are correct on a clean install. It is Windows only, though. 

# Download [http://ilspy.net/ ILSpy] (Download Binaries) and extract it to a directory of your choosing. Optionally create a desktop shortcut;
# '''Either''': associate the .dll extension with ILSpy:
## Navigate to ''Assembly-CSharp.dll'' in ''../Rimworld***_Data/Managed/'', relative to your Rimworld installation and with *** being a version number;
## Right-click "Open with" and select a standard program. Navigate to your ILSpy installation and double-click ''ILSpy.exe'', tick the checkbox and accept;
## Double-click ''Assembly-CSharp.dll'',
# '''Or''': open ILSpy and open a .dll:
## Open ILSpy;
## Go to File -> Open or press Ctrl+O, navigate to ''../Rimworld***_Data/Managed/'', relative to your Rimworld installation and with *** being a version number;
## Select ''Assembly-CSharp.dll'' and confirm,
# Click the "+" next to ''Assembly-CSharp (***)'', you will now see a list including the items ''Rimworld'' and ''Verse'';
# Take your time to look through the source code, to make yourself familiar. If you ever need the source code, open ILSpy again:
## Ctrl+Shift+F or Ctrl+E opens the search bar which can be used to search through all loaded assemblies;
## Ctrl+F opens a search bar for the currently opened decompiled class. 

===MonoDevelop===

MonoDevelop is capable of decompiling DLLs, albeit using clumsy initial settings. It is Linux only, otherwise you have to download Xamarin Studio which doesn't have a decompiler. 

# Download [http://www.monodevelop.com/download/ MonoDevelop] and install it;
# '''Either''': associate the .dll extension with MonoDevelop:
## Navigate to ''Assembly-CSharp.dll'' in ''../Rimworld***_Data/Managed/'', relative to your Rimworld installation and with *** being a version number;
## Right-click "Open with" and select MonoDevelop as standard program;
## Double-click ''Assembly-CSharp.dll'',
# '''Or''': open MonoDevelop and open a .dll:
## Open MonoDevelop;
## Go to File -> Open, navigate to ''../Rimworld***_Data/Managed/'', relative to your Rimworld installation and with *** being a version number;
## Select ''Assembly-CSharp.dll'' and confirm,
# '''Very important''': search for a dropdown called "Visibility" and change it from "Only public members" to "All members";
# '''Very important''': search for a dropdown called "Language" and change it from "Summary" to "C#";
# Click the "+" next to ''Assembly-CSharp (***)'', you will now see a list including the items ''Rimworld'' and ''Verse'';
# Take your time to look through the source code, to make yourself familiar. If you ever need the source code, open ''Assembly-CSharp.dll'' again. 

=See also=

* [[Modding Tutorials/Writing custom code|Writing custom code]] shows a broad overview of C# coding. 

[[Category:Modding tutorials]]

Modding Tutorials/Writing custom code

2015-11-25T15:14:32Z

Alistaire: /* Namespace */ Fixed error in code MyNameSpace -> RimWorld

{{BackToTutorials}}
{{Credit|[[User:TheTynan|TheTynan]]|extra=1}} 

This tutorial gives you a broad idea how to work on a C# solution. 

=Requirements=

* This tutorial requires you to have [[Modding Tutorials/Setting up a solution|set up a solution]]. 

=Creating a class=


===Sharpdevelop===

When you start your software you'll see a '''Projects''' file explorer to the left, a '''Properties''' explorer to the right and currently opened files in the middle.

* With your solution open, create a new class inside your '''Projects''' explorer;
*# If you don't have [[Modding Tutorials/Setting up a solution|your solution]] open you can do so by clicking File -> Open -> Project/Solution.. or by choosing a recent project on the '''Start page''' in the middle;
*# If it's not expanded, click the + next to "Solution ''MySolutionName''". Right-click ''MyProjectName'' (this could be the same as ''MySolutionName'' or different, depending on how you set up the solution);
*# Select Add -> New Item.. -> '''Categories:''' C# -> '''Templates:''' Class -> '''File Name:''' ''MyClassName''.cs,

====Template====

Let's go over the template:

<source lang="csharp">/*
* Created by SharpDevelop.
* User: You
* Date: 01-01-1970
* Time: 00:00
*
* To change this template use Tools | Options | Coding | Edit Standard Headers.
*/
using System;

namespace MyNameSpace
{
/// <summary>
/// Description of MyClassName.
/// </summary>
public class MyClassName
{
public MyClassName()
{
}
}
}</source> 

====Using====

The first thing you notice is ''using System;'' which indicates this class can call anything from the namespace ''System'' without calling it like ''System.Class.SomeDataType'' but rather ''SomeDataType''. This is very useful because we don't have to worry about such calls anymore (for now). 

The next section shows which namespaces you could put in ''using''. 

====Namespace====

Next up is the ''namespace MyNameSpace'' part - in principle everything inside of a namespace knows everything else inside of that namespace. If you were to make a folder inside of your project (''MyProjectName'' not Solution ''MySolutionName''), any classes inside of that folder would have the namespace ''MyNameSpace.MyFolderName''. '''That's a different namespace''' and unless you tell other classes that it exists (''using MyNameSpace.MyFolderName;'') they won't accept calls to parts of that namespace without that namespace as a prefix. 

Anything inside of ''MyNameSpace.MyFolderName'' does however know of everything inside ''MyNameSpace'', just nothing about other subfolders of ''MyNameSpace''. 

By default your project knows nothing. Adding DLL references to the ''References'' folder (as done in the previous tutorial) allows you to reference them with ''using'':

<source lang="csharp">
namespace MyNameSpace {} /* Assuming MyNameSpace is your ROOT NAMESPACE (MyProjectName ->
Properties -> Application -> Root namespace), this will compile. */

namespace MyNameSpace.MyFolderName {} /* Assuming this class is inside of the folder MyFolderName inside of
MyProjectName, this will compile. Other classes outside of the folder
will have to reference this, this class will have to reference classes
in different subfolders (but not the ones in the root folder). */

namespace RimWorld {} /* Don't do this. It will compile if RimWorld is your root namespace
but it's bad practice. */

namespace System {} /* No, just no. */
</source> 

You can set your project's namespace by right-clicking MyProjectName -> Properties -> Application -> Root namespace. Please take some time to make it unique so no compatibility issues will arise with other mods, for your and everyone else's sanity. 

Some very useful namespaces in general are the following: 

{|
! Namespace !! What does it do?
|-
| System.Collections.Generic || Makes it so you can use part of the IEnumerable interface, which is used for datatypes like List<>.
|-
| System.Linq || Allows for cool operations on the IEnumerable interface such as ''.Where()'' which accepts lambda operations (oh my!).
|-
| System.Text.RegularExpressions || Introduces Regular Expressions (RegEx) to C# which allows for intricate operations on strings.
|-
| System.Collections || Holds other parts of the IEnumerable interface you will require when inheriting from that class.
|-
| System.Text || Contains the ''StringBuilder'' which accepts a list of strings and returns them in a specific way.
|} 

And the namespaces for RimWorld in particular are these: 

{|
! Namespace !! What does it do?
|-
| RimWorld || Many classes can be found in this namespace.
|-
| RimWorld.Planet || Everything (almost everything) having to do with the planet savefile is in here.
|-
| RimWorld.SquadAI || Holds the squad AI, clearly. You'll know it when you need this.
|-
| Verse || Sometimes more complex classes are found here.
|-
| Verse.AI || You might never have to touch this either.
|-
| Verse.Grammar || Contains functionality for the Languages folder and other things having to do with text operations such as the art flavour text generator.
|-
| Verse.Noise || Something something you'll never need this.
|-
| Verse.Sound || Much like Verse.Noise except it's required to play sounds directly with your code.
|-
| Verse.Steam || Steam integration by Tynan - it's not active so you won't need it.
|-
| UnityEngine || Contains many more methods you most likely won't need.
|-
|} 

The difference between RimWorld and Verse is not very clear and you might as well add both using statements whenever you want. 
If you want to use the exact functionality of a base game class you're best off copying all its ''using'' statements, its ''namespace'' and the namespace of its parent. 

====Summary====

This summary is part of the template but it's not required. It can help other people understand your code better when you provide the source but besides that you really don't need it. 

====Class and Constructor====

This is your class definition. To access anything inside of a ''public class'' you will need a reference to an instance of that class: 

<source lang="csharp">
MyClassNamefoo = new MyClassName();
</source> 

The brackets at ''new MyClassName()'' indicate you're creating this instance without ''parameters'' which is possible because your class contains a constructor (anything inside of ''class MyClassName'' which has parameters and isn't a method, often abbreviated '''.ctor''') which accepts a call without parameters: 

<source lang="csharp">
public class MyClassName
{
public MyClassName() /* No parameters */
{
}

public MyClassName(string foo, int bar) /* Required parameters of datatypes string and int */
{
}

public MyClassName(string foo = "none supplied", int bar = 42) /* Default parameters " " " */
{
}
}</source> 

The last implementation of the constructor (''MyNameSpace.MyClassName.MyClassName'' inside of ''MyNameSpace.MyClassName'') is capable of accepting zero to two parameters while the second implementation of the constructor will only accept calls with exactly two parameters. 

=Writing code=

# [[Modding Tutorials/Decompiling source code|Decompile source code]] to take a look at the game's existing code;
## If you get stuck on anything, any modding questions can be asked on the [https://ludeon.com/forums/index.php?board=14.0 subforum],
# Compile your class into a .dll;
## Make sure your project's output type is "class library";
## '' '''Note:''' by default, Visual Studio will compile all the references of the project as well, so you’ll get a copy of UnityEngine.dll and Assembly-CSharp.dll and some others. Just take ''MyModName.dll'' and place it in the ''MyModName/Assemblies'' folder. If you have [[Modding Tutorials/Setting up a solution|set up a solution]] according to the tutorial you don't have this problem,
# Reference the classes in your .dll from the xml data in the MyModName/Defs folder;
## '''Example:''' Create a new ThingDef with a <thingClass> that points to a class in your .dll,
# The game should load your class now; 

=See also=

* [[Modding_Tutorials/Distribution|Distribution]] details how to release your mod.
* [[Modding Tutorials/Assembly Modding Example|Assembly modding example]] contains a small modding example. 

[[Category:Modding tutorials]]

Modding Tutorials/Writing custom code

2015-11-23T14:46:14Z

Alistaire: /* Namespace */ Made it more "interactive" with changing text into code

{{BackToTutorials}}
{{Credit|[[User:TheTynan|TheTynan]]|extra=1}} 

This tutorial gives you a broad idea how to work on a C# solution. 

=Requirements=

* This tutorial requires you to have [[Modding Tutorials/Setting up a solution|set up a solution]]. 

=Creating a class=


===Sharpdevelop===

When you start your software you'll see a '''Projects''' file explorer to the left, a '''Properties''' explorer to the right and currently opened files in the middle.

* With your solution open, create a new class inside your '''Projects''' explorer;
*# If you don't have [[Modding Tutorials/Setting up a solution|your solution]] open you can do so by clicking File -> Open -> Project/Solution.. or by choosing a recent project on the '''Start page''' in the middle;
*# If it's not expanded, click the + next to "Solution ''MySolutionName''". Right-click ''MyProjectName'' (this could be the same as ''MySolutionName'' or different, depending on how you set up the solution);
*# Select Add -> New Item.. -> '''Categories:''' C# -> '''Templates:''' Class -> '''File Name:''' ''MyClassName''.cs,

====Template====

Let's go over the template:

<source lang="csharp">/*
* Created by SharpDevelop.
* User: You
* Date: 01-01-1970
* Time: 00:00
*
* To change this template use Tools | Options | Coding | Edit Standard Headers.
*/
using System;

namespace MyNameSpace
{
/// <summary>
/// Description of MyClassName.
/// </summary>
public class MyClassName
{
public MyClassName()
{
}
}
}</source> 

====Using====

The first thing you notice is ''using System;'' which indicates this class can call anything from the namespace ''System'' without calling it like ''System.Class.SomeDataType'' but rather ''SomeDataType''. This is very useful because we don't have to worry about such calls anymore (for now). 

The next section shows which namespaces you could put in ''using''. 

====Namespace====

Next up is the ''namespace MyNameSpace'' part - in principle everything inside of a namespace knows everything else inside of that namespace. If you were to make a folder inside of your project (''MyProjectName'' not Solution ''MySolutionName''), any classes inside of that folder would have the namespace ''MyNameSpace.MyFolderName''. '''That's a different namespace''' and unless you tell other classes that it exists (''using MyNameSpace.MyFolderName;'') they won't accept calls to parts of that namespace without that namespace as a prefix. 

Anything inside of ''MyNameSpace.MyFolderName'' does however know of everything inside ''MyNameSpace'', just nothing about other subfolders of ''MyNameSpace''. 

By default your project knows nothing. Adding DLL references to the ''References'' folder (as done in the previous tutorial) allows you to reference them with ''using'':

<source lang="csharp">
namespace MyNameSpace {} /* Assuming MyNameSpace is your ROOT NAMESPACE (MyProjectName ->
Properties -> Application -> Root namespace), this will compile. */

namespace MyNameSpace.MyFolderName {} /* Assuming this class is inside of the folder MyFolderName inside of
MyProjectName, this will compile. Other classes outside of the folder
will have to reference this, this class will have to reference classes
in different subfolders (but not the ones in the root folder). */

namespace RimWorld {} /* Don't do this. It will compile if MyNameSpace is your root namespace
but it's bad practice. */

namespace System {} /* No, just no. */
</source> 

You can set your project's namespace by right-clicking MyProjectName -> Properties -> Application -> Root namespace. Please take some time to make it unique so no compatibility issues will arise with other mods, for your and everyone else's sanity. 

Some very useful namespaces in general are the following: 

{|
! Namespace !! What does it do?
|-
| System.Collections.Generic || Makes it so you can use part of the IEnumerable interface, which is used for datatypes like List<>.
|-
| System.Linq || Allows for cool operations on the IEnumerable interface such as ''.Where()'' which accepts lambda operations (oh my!).
|-
| System.Text.RegularExpressions || Introduces Regular Expressions (RegEx) to C# which allows for intricate operations on strings.
|-
| System.Collections || Holds other parts of the IEnumerable interface you will require when inheriting from that class.
|-
| System.Text || Contains the ''StringBuilder'' which accepts a list of strings and returns them in a specific way.
|} 

And the namespaces for RimWorld in particular are these: 

{|
! Namespace !! What does it do?
|-
| RimWorld || Many classes can be found in this namespace.
|-
| RimWorld.Planet || Everything (almost everything) having to do with the planet savefile is in here.
|-
| RimWorld.SquadAI || Holds the squad AI, clearly. You'll know it when you need this.
|-
| Verse || Sometimes more complex classes are found here.
|-
| Verse.AI || You might never have to touch this either.
|-
| Verse.Grammar || Contains functionality for the Languages folder and other things having to do with text operations such as the art flavour text generator.
|-
| Verse.Noise || Something something you'll never need this.
|-
| Verse.Sound || Much like Verse.Noise except it's required to play sounds directly with your code.
|-
| Verse.Steam || Steam integration by Tynan - it's not active so you won't need it.
|-
| UnityEngine || Contains many more methods you most likely won't need.
|-
|} 

The difference between RimWorld and Verse is not very clear and you might as well add both using statements whenever you want. 
If you want to use the exact functionality of a base game class you're best off copying all its ''using'' statements, its ''namespace'' and the namespace of its parent. 

====Summary====

This summary is part of the template but it's not required. It can help other people understand your code better when you provide the source but besides that you really don't need it. 

====Class and Constructor====

This is your class definition. To access anything inside of a ''public class'' you will need a reference to an instance of that class: 

<source lang="csharp">
MyClassNamefoo = new MyClassName();
</source> 

The brackets at ''new MyClassName()'' indicate you're creating this instance without ''parameters'' which is possible because your class contains a constructor (anything inside of ''class MyClassName'' which has parameters and isn't a method, often abbreviated '''.ctor''') which accepts a call without parameters: 

<source lang="csharp">
public class MyClassName
{
public MyClassName() /* No parameters */
{
}

public MyClassName(string foo, int bar) /* Required parameters of datatypes string and int */
{
}

public MyClassName(string foo = "none supplied", int bar = 42) /* Default parameters " " " */
{
}
}</source> 

The last implementation of the constructor (''MyNameSpace.MyClassName.MyClassName'' inside of ''MyNameSpace.MyClassName'') is capable of accepting zero to two parameters while the second implementation of the constructor will only accept calls with exactly two parameters. 

=Writing code=

# [[Modding Tutorials/Decompiling source code|Decompile source code]] to take a look at the game's existing code;
## If you get stuck on anything, any modding questions can be asked on the [https://ludeon.com/forums/index.php?board=14.0 subforum],
# Compile your class into a .dll;
## Make sure your project's output type is "class library";
## '' '''Note:''' by default, Visual Studio will compile all the references of the project as well, so you’ll get a copy of UnityEngine.dll and Assembly-CSharp.dll and some others. Just take ''MyModName.dll'' and place it in the ''MyModName/Assemblies'' folder. If you have [[Modding Tutorials/Setting up a solution|set up a solution]] according to the tutorial you don't have this problem,
# Reference the classes in your .dll from the xml data in the MyModName/Defs folder;
## '''Example:''' Create a new ThingDef with a <thingClass> that points to a class in your .dll,
# The game should load your class now; 

=See also=

* [[Modding_Tutorials/Distribution|Distribution]] details how to release your mod.
* [[Modding Tutorials/Assembly Modding Example|Assembly modding example]] contains a small modding example. 

[[Category:Modding tutorials]]

Modding Tutorials/Writing custom code

2015-11-23T14:29:33Z

Alistaire: Added lots of extra info on namespace, using etc.

{{BackToTutorials}}
{{Credit|[[User:TheTynan|TheTynan]]|extra=1}} 

This tutorial gives you a broad idea how to work on a C# solution. 

=Requirements=

* This tutorial requires you to have [[Modding Tutorials/Setting up a solution|set up a solution]]. 

=Creating a class=


===Sharpdevelop===

When you start your software you'll see a '''Projects''' file explorer to the left, a '''Properties''' explorer to the right and currently opened files in the middle.

* With your solution open, create a new class inside your '''Projects''' explorer;
*# If you don't have [[Modding Tutorials/Setting up a solution|your solution]] open you can do so by clicking File -> Open -> Project/Solution.. or by choosing a recent project on the '''Start page''' in the middle;
*# If it's not expanded, click the + next to "Solution ''MySolutionName''". Right-click ''MyProjectName'' (this could be the same as ''MySolutionName'' or different, depending on how you set up the solution);
*# Select Add -> New Item.. -> '''Categories:''' C# -> '''Templates:''' Class -> '''File Name:''' ''MyClassName''.cs,

====Template====

Let's go over the template:

<source lang="csharp">/*
* Created by SharpDevelop.
* User: You
* Date: 01-01-1970
* Time: 00:00
*
* To change this template use Tools | Options | Coding | Edit Standard Headers.
*/
using System;

namespace MyNameSpace
{
/// <summary>
/// Description of MyClassName.
/// </summary>
public class MyClassName
{
public MyClassName()
{
}
}
}</source> 

====Using====

The first thing you notice is ''using System;'' which indicates this class can call anything from the namespace ''System'' without calling it like ''System.Class.SomeDataType'' but rather ''SomeDataType''. This is very useful because we don't have to worry about such calls anymore (for now). 

The next section shows which namespaces you could put in ''using''. 

====Namespace====

Next up is the ''namespace MyNameSpace'' part - in principle everything inside of a namespace knows everything else inside of that namespace. If you were to make a folder inside of your project (''MyProjectName'' not Solution ''MySolutionName''), any classes inside of that folder would have the namespace ''MyNameSpace.MyFolderName''. '''That's a different namespace''' and unless you tell other classes that it exists (''using MyNameSpace.MyFolderName;'') they won't accept calls to parts of that namespace without that namespace as a prefix. 

Anything inside of ''MyNameSpace.MyFolderName'' does however know of everything inside ''MyNameSpace'', just nothing about other subfolders of ''MyNameSpace''. 

Some very useful namespaces in general are the following: 

{|
! Namespace !! What does it do?
|-
| System.Collections.Generic || Makes it so you can use part of the IEnumerable interface, which is used for datatypes like List<>.
|-
| System.Linq || Allows for cool operations on the IEnumerable interface such as ''.Where()'' which accepts lambda operations (oh my!).
|-
| System.Text.RegularExpressions || Introduces Regular Expressions (RegEx) to C# which allows for intricate operations on strings.
|-
| System.Collections || Holds other parts of the IEnumerable interface you will require when inheriting from that class.
|-
| System.Text || Contains the ''StringBuilder'' which accepts a list of strings and returns them in a specific way.
|} 

And the namespaces for RimWorld in particular are these: 

{|
! Namespace !! What does it do?
|-
| RimWorld || Many classes can be found in this namespace.
|-
| RimWorld.Planet || Everything (almost everything) having to do with the planet savefile is in here.
|-
| RimWorld.SquadAI || Holds the squad AI, clearly. You'll know it when you need this.
|-
| Verse || Sometimes more complex classes are found here.
|-
| Verse.AI || You might never have to touch this either.
|-
| Verse.Grammar || Contains functionality for the Languages folder and other things having to do with text operations such as the art flavour text generator.
|-
| Verse.Noise || Something something you'll never need this.
|-
| Verse.Sound || Much like Verse.Noise except it's required to play sounds directly with your code.
|-
| Verse.Steam || Steam integration by Tynan - it's not active so you won't need it.
|-
| UnityEngine || Contains many more methods you most likely won't need.
|-
|} 

The difference between RimWorld and Verse is not very clear and you might as well add both using statements whenever you want. 
If you want to use the exact functionality of a base game class you're best off copying all its ''using'' statements, its ''namespace'' and the namespace of its parent. 

====Summary====

This summary is part of the template but it's not required. It can help other people understand your code better when you provide the source but besides that you really don't need it. 

====Class and Constructor====

This is your class definition. To access anything inside of a ''public class'' you will need a reference to an instance of that class: 

<source lang="csharp">
MyClassNamefoo = new MyClassName();
</source> 

The brackets at ''new MyClassName()'' indicate you're creating this instance without ''parameters'' which is possible because your class contains a constructor (anything inside of ''class MyClassName'' which has parameters and isn't a method, often abbreviated '''.ctor''') which accepts a call without parameters: 

<source lang="csharp">
public class MyClassName
{
public MyClassName() /* No parameters */
{
}

public MyClassName(string foo, int bar) /* Required parameters of datatypes string and int */
{
}

public MyClassName(string foo = "none supplied", int bar = 42) /* Default parameters " " " */
{
}
}</source> 

The last implementation of the constructor (''MyNameSpace.MyClassName.MyClassName'' inside of ''MyNameSpace.MyClassName'') is capable of accepting zero to two parameters while the second implementation of the constructor will only accept calls with exactly two parameters. 

=Writing code=

# [[Modding Tutorials/Decompiling source code|Decompile source code]] to take a look at the game's existing code;
## If you get stuck on anything, any modding questions can be asked on the [https://ludeon.com/forums/index.php?board=14.0 subforum],
# Compile your class into a .dll;
## Make sure your project's output type is "class library";
## '' '''Note:''' by default, Visual Studio will compile all the references of the project as well, so you’ll get a copy of UnityEngine.dll and Assembly-CSharp.dll and some others. Just take ''MyModName.dll'' and place it in the ''MyModName/Assemblies'' folder. If you have [[Modding Tutorials/Setting up a solution|set up a solution]] according to the tutorial you don't have this problem,
# Reference the classes in your .dll from the xml data in the MyModName/Defs folder;
## '''Example:''' Create a new ThingDef with a <thingClass> that points to a class in your .dll,
# The game should load your class now; 

=See also=

* [[Modding_Tutorials/Distribution|Distribution]] details how to release your mod.
* [[Modding Tutorials/Assembly Modding Example|Assembly modding example]] contains a small modding example. 

[[Category:Modding tutorials]]

Modding Tutorials/Setting up a solution

2015-11-09T21:48:18Z

Alistaire: /* Requirements */

Modding Tutorials/Mod folder structure

2015-11-02T20:08:54Z

Alistaire: Fixed main page links

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

This tutorial introduces you to the mod folder structure and shows you a standard folder structure setup to help you start out. 

[[Modding Tutorials/Mod folder structure#Complete mod folder structure|Complete mod folder structure]] is a list of all folders you might find in your average mod directory. This includes /Core/. 

=Requirements=

* [[Modding Tutorials/Folder structure|Exploring the Folder Structure]] starts off explaining the folder structure. This is part two if you will. 

=What you'll learn=

You'll learn the following mod structure: 

YourModName/
About/
About.xml
Preview.png
Assemblies/
ProjectName.dll
Defs/
(..)
Languages/
English/
Strings/
NameBanks/
Sounds/
Source/
ProjectName/
ProjectName.sln
Textures/

.. Along with a few tips on how to keep your mod folder structure readable and functional. 

=Standard mod folder structure=

Mod folders are located in the mods folder, which is located as such: 

RimWorld******/
Mods/

..relative to your RimWorld install directory. Each mod is a sub folder of this Mods folder and each mod has to follow the following structure precisely. 

==The About folder==
{{Main|Modding Tutorials/About folder}} 

Making a mod starts with you making a folder structure. Some mods need textures and sounds, while others are XML or even C# only. 
Every mod does however require the following structure to show up in the mods list: 

YourModName/
About/
About.xml

Along with this vital information it's possible to add a preview image for your mod. This makes the structure as follows: 

YourModName/
About/
About.xml
Preview.png

The size of the base game Preview.png is 400x61 pixels, but some mods use higher preview images. The image is centered in the mod's description, and can be of any size. 

==The Defs folders==
{{Main|Modding Tutorials/Defs folder}} 

If your mod adds new content, chances are you're going to use XML files. These files are going to be stored in the folder structure as follows: 

YourModName/
Defs/
BiomeDefs/
Biomes.xml
BodyDefs/
Bodies.xml
BodyPartDefs/
BodyParts.xml
(..)

The contents of a Def folder don't follow a clear naming convention, but the folder names are generally the same in every mod. 
Using a non-standard name is going to make it harder for others to navigate your mod's folders, so it is advised to keep the folder names consistent with the base game. 

Typically, the files inside these folders are named after their contents: 

Core/
Defs/
ThingDefs/
Apparel_Hats.xml
Apparel_Shield.xml
(..)
Weapons_Melee.xml
Weapons_RangedNeolithic.xml

This makes it easier for people to navigate XML code. If your mod is going to add both apparel and weapons, or even both hats and shoes, you're best off separating the XML code in their respective files. 
Some mod authors choose to make a separate file for each of their items. This makes it easier for others to remove only part of your mod and keep the rest of it, but with very large mods it makes it harder to navigate the folder. 

==The Textures and Sounds folders==
{{Main|Modding Tutorials/Textures folder|Modding Tutorials/Sounds folder}} 

If you're using Defs chances are you're creating a content mod. This type of mod is most likely very dull without its own custom graphics and sounds. Adding such content requires the following folders: 

YourModName/
Textures/
Sounds/

The contents of the Textures and Sounds folder usually aren't the same between mods. The base game sorts these files in various folders and subfolders, but in the end it's very hard to navigate them based on the folder names. 
It's possible to categorize this content by item (submachinegun#1, pistol#3) or item type (guns, buildings), as an example. Whatever you do it's best to keep the structure consistent throughout both folders. 

==The Source and Assemblies folders==

If you want to take a shot at [[Modding Tutorials/Writing custom code|C# modding]], you want an '''empty''' Source and an '''empty''' Assemblies folder. You'll want to [[Modding Tutorials/Setting up a solution|create the C# project]] inside your Source folder, and compile the class library into the Assemblies folder. These things are processed automatically by your [[Modding Tutorials/Recommended software#IDE's|IDE]], so you don't have to make these folder structures yourself: 

YourModName/
Assemblies/
ProjectName.dll
Source/
SolutionName/
SolutionName.sln
ProjectName/
ProjectName.csproj
(..)

''Or:''

YourModName/
Assemblies/
ProjectName.dll
Source/
ProjectName/
SolutionName.sln
ProjectName.csproj
(..)

'''Once again''', the structure of these folders is decided almost entirely by the author's editing software. Therefore the only things you have to set up are the following folders: 

YourModName/
Assemblies/
Source/

.. And then once you create a solution starting in ../YourModName/Source/ everything else will be sorted out by the software. People don't navigate these folders, they open ProjectName.sln to navigate it using their software of choice. 

==The Languages folder==
{{Main|Modding Tutorials/Languages folder}} 

Unless you're on a translation team, you're unlikely to need this folder a lot. If you want to randomly generate names using your own words, you will however have to use this folder: 

YourModName/
Languages/
English/
Strings/
NameBanks/

In this folder you put .txt files with a new word on every line. Using XML you will then be able to randomly pick one of the lines in the file. 
In the average mod the rest of the folder is quite useless. You are unlikely to translate your mod into tens of different languages. 

=Complete mod folder structure=

*/
About/
About.xml
Preview.png-
Assemblies/-
*.dll+
Defs/-
*Defs/+
*.xml+
Languages/-
*/*
DefInjected/-
*Defs/+
*.xml+
Keyed/-
*.xml+
Strings/-
NameBanks/
*.txt+
FriendlyName.txt-
LangIcon.png
LanguageInfo.xml
Sounds/-
*/*#
*.wav+
Source/-
*/*#
bin/
Debug/
*.**
obj/
Debug/
*.**
Properties/-
AssemblyInfo.cs
Source-DLLs/-
Assembly-CSharp.dll
UnityEngine.dll
*.csproj
*.OpenCover.Settings
*.sln
*/*#
*.cs+
Textures/-
*/*#
*.psd*
*.psd.meta*
*.png*

Anything with a / at the end is a folder;
Anything with a . in it is a file;
The * in *.* and */ stands for any arbitrary string;
The * after a file/folder stands for an occurence of >= 0;
The + after a file/folder stands for an occurrence of > 0;
The - after a file/folder stands for an occurrence of <= 1;
The # after a folder stands for a folder depth of >= 0.

=Next up=
* [[Modding Tutorials/Recommended software|Recommended Software]]

[[Category:Modding tutorials]]

Modding Tutorials

2015-11-02T20:07:45Z

Alistaire: /* Introduction */ Added sub pages for mod folder structure links

{| align=center
! {{MainSection_Nav}}
|}
{| align=center
| {{Mods_Nav}}
|}
<hr>

This is the table of contents for the modding tutorial. Here, you'll learn step by step how to create mods of gradually increasing complexity.

In light of little official documentation, this collection of tutorials has been written in hopes that more players will know how to modify RimWorld and make mods that further broaden horizons and make the game appealing to more audiences despite its early state.

==Table of contents==

===Introduction===

# [[Installing mods|Installing Mods]]
# [[Modding Tutorials/Folder structure|Exploring the Folder Structure]]
# [[Modding Tutorials/Mod folder structure|Mod Folder Structure]]
#* [[Modding Tutorials/About folder|About folder]]
#* [[Modding Tutorials/Defs folder|Defs folder]]
#* [[Modding Tutorials/Languages folder|Languages folder]]
#* [[Modding Tutorials/Textures folder|Textures folder]]
#* [[Modding Tutorials/Sounds folder|Sounds folder]]
# [[Modding Tutorials/Recommended software|Recommended Software]]

===General modding===

* [[Modding Tutorials/Testing mods|Testing Mods]]
** [[Modding Tutorials/Development mode|Development Mode]]
* [[Modding Tutorials/Sounds|Adding and Testing Sounds]]

===XML tutorials===

# [[Modding Tutorials/XML file structure|XML File Structure]]
# [[Modding Tutorials/XML Defs|Introduction to XML Defs]]
#* [[Modding Tutorials/Compatibility with defs|XML Def Compatibility]]
# In-depth XML Def tutorials
#* [[Modding Tutorials/Weapons Guns|Weapons_Guns.xml Explained]] 

''The following tutorials are likely outdated''
* [[Modding Tutorials/Getting Started|Getting Started]]
* [[Modding Tutorials/Items|Items]]
* [[Modding Tutorials/Flooring|Flooring]]
* [[Modding Tutorials/Weapons|Weapons]]
* [[Modding Tutorials/Furniture|Buildings and Furniture]]
* [[Modding Tutorials/Plants|Plants]]
* [[Modding Tutorials/Food|Food]]
* [[Modding Tutorials/Races and Pawns|Races and Pawns]]
* [[Modding_Tutorials/Smelter|Buildings and Furniture: Creating a Smelter]]

===C# tutorials===
# [[Modding_Tutorials/Setting up a solution|Setting up]]
# [[Modding_Tutorials/Decompiling source code|Decompiling Source Code]]
# [[Modding_Tutorials/Writing custom code|Writing Custom Code]]
# [[Modding_Tutorials/Def classes|Introduction to Def Classes]]
#* [[Modding_Tutorials/Modifying defs|Def Class Compatibility]]
# [[Modding_Tutorials/Compatibility_with_DLLs|Mod DLL Compatibility]]
#* [[Modding_Tutorials/Injection|C# Injection]]
# [[Modding_Tutorials/Distribution|Distribution]] 
''Examples:''
* [[Modding Tutorials/Assembly Modding Example|Assembly Modding]]

==See also==

* [[:Category:Defs|List of Defs]]

[[Category:Modding tutorials]]

Modding Tutorials/Mod folder structure

2015-11-02T20:03:22Z

Alistaire: Added requirements

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

This tutorial introduces you to the mod folder structure and shows you a standard folder structure setup to help you start out. 

[[Modding Tutorials/Mod folder structure#Complete mod folder structure|Complete mod folder structure]] is a list of all folders you might find in your average mod directory. This includes /Core/. 

=Requirements=

* [[Modding Tutorials/Folder structure|Exploring the Folder Structure]] starts off explaining the folder structure. This is part two if you will. 

=What you'll learn=

You'll learn the following mod structure: 

YourModName/
About/
About.xml
Preview.png
Assemblies/
ProjectName.dll
Defs/
(..)
Languages/
English/
Strings/
NameBanks/
Sounds/
Source/
ProjectName/
ProjectName.sln
Textures/

.. Along with a few tips on how to keep your mod folder structure readable and functional. 

=Standard mod folder structure=

Mod folders are located in the mods folder, which is located as such: 

RimWorld******/
Mods/

..relative to your RimWorld install directory. Each mod is a sub folder of this Mods folder and each mod has to follow the following structure precisely. 

==The About folder==
{{Main|Modding Tutorials/About}} 

Making a mod starts with you making a folder structure. Some mods need textures and sounds, while others are XML or even C# only. 
Every mod does however require the following structure to show up in the mods list: 

YourModName/
About/
About.xml

Along with this vital information it's possible to add a preview image for your mod. This makes the structure as follows: 

YourModName/
About/
About.xml
Preview.png

The size of the base game Preview.png is 400x61 pixels, but some mods use higher preview images. The image is centered in the mod's description, and can be of any size. 

==The Defs folders==
{{Main|Modding Tutorials/Defs}} 

If your mod adds new content, chances are you're going to use XML files. These files are going to be stored in the folder structure as follows: 

YourModName/
Defs/
BiomeDefs/
Biomes.xml
BodyDefs/
Bodies.xml
BodyPartDefs/
BodyParts.xml
(..)

The contents of a Def folder don't follow a clear naming convention, but the folder names are generally the same in every mod. 
Using a non-standard name is going to make it harder for others to navigate your mod's folders, so it is advised to keep the folder names consistent with the base game. 

Typically, the files inside these folders are named after their contents: 

Core/
Defs/
ThingDefs/
Apparel_Hats.xml
Apparel_Shield.xml
(..)
Weapons_Melee.xml
Weapons_RangedNeolithic.xml

This makes it easier for people to navigate XML code. If your mod is going to add both apparel and weapons, or even both hats and shoes, you're best off separating the XML code in their respective files. 
Some mod authors choose to make a separate file for each of their items. This makes it easier for others to remove only part of your mod and keep the rest of it, but with very large mods it makes it harder to navigate the folder. 

==The Textures and Sounds folders==
{{Main|Modding Tutorials/Textures|Modding Tutorials/Sounds}} 

If you're using Defs chances are you're creating a content mod. This type of mod is most likely very dull without its own custom graphics and sounds. Adding such content requires the following folders: 

YourModName/
Textures/
Sounds/

The contents of the Textures and Sounds folder usually aren't the same between mods. The base game sorts these files in various folders and subfolders, but in the end it's very hard to navigate them based on the folder names. 
It's possible to categorize this content by item (submachinegun#1, pistol#3) or item type (guns, buildings), as an example. Whatever you do it's best to keep the structure consistent throughout both folders. 

==The Source and Assemblies folders==

If you want to take a shot at [[Modding Tutorials/Writing custom code|C# modding]], you want an '''empty''' Source and an '''empty''' Assemblies folder. You'll want to [[Modding Tutorials/Setting up a solution|create the C# project]] inside your Source folder, and compile the class library into the Assemblies folder. These things are processed automatically by your [[Modding Tutorials/Recommended software#IDE's|IDE]], so you don't have to make these folder structures yourself: 

YourModName/
Assemblies/
ProjectName.dll
Source/
SolutionName/
SolutionName.sln
ProjectName/
ProjectName.csproj
(..)

''Or:''

YourModName/
Assemblies/
ProjectName.dll
Source/
ProjectName/
SolutionName.sln
ProjectName.csproj
(..)

'''Once again''', the structure of these folders is decided almost entirely by the author's editing software. Therefore the only things you have to set up are the following folders: 

YourModName/
Assemblies/
Source/

.. And then once you create a solution starting in ../YourModName/Source/ everything else will be sorted out by the software. People don't navigate these folders, they open ProjectName.sln to navigate it using their software of choice. 

==The Languages folder==

Unless you're on a translation team, you're unlikely to need this folder a lot. If you want to randomly generate names using your own words, you will however have to use this folder: 

YourModName/
Languages/
English/
Strings/
NameBanks/

In this folder you put .txt files with a new word on every line. Using XML you will then be able to randomly pick one of the lines in the file. 
In the average mod the rest of the folder is quite useless. You are unlikely to translate your mod into tens of different languages. 

=Complete mod folder structure=

*/
About/
About.xml
Preview.png-
Assemblies/-
*.dll+
Defs/-
*Defs/+
*.xml+
Languages/-
*/*
DefInjected/-
*Defs/+
*.xml+
Keyed/-
*.xml+
Strings/-
NameBanks/
*.txt+
FriendlyName.txt-
LangIcon.png
LanguageInfo.xml
Sounds/-
*/*#
*.wav+
Source/-
*/*#
bin/
Debug/
*.**
obj/
Debug/
*.**
Properties/-
AssemblyInfo.cs
Source-DLLs/-
Assembly-CSharp.dll
UnityEngine.dll
*.csproj
*.OpenCover.Settings
*.sln
*/*#
*.cs+
Textures/-
*/*#
*.psd*
*.psd.meta*
*.png*

Anything with a / at the end is a folder;
Anything with a . in it is a file;
The * in *.* and */ stands for any arbitrary string;
The * after a file/folder stands for an occurence of >= 0;
The + after a file/folder stands for an occurrence of > 0;
The - after a file/folder stands for an occurrence of <= 1;
The # after a folder stands for a folder depth of >= 0.

=Next up=
* [[Modding Tutorials/Recommended software|Recommended Software]]

[[Category:Modding tutorials]]

Modding Tutorials/Setting up a solution

2015-11-02T19:50:47Z

Alistaire: /* Setting up a solution */ Note on the method being different for other IDEs

Talk:Modding Tutorials/Setting up a solution/Specific IDE instructions/reply

2015-11-02T19:48:01Z

Alistaire: Reply to Specific IDE instructions

Feel free to add subsections to "Setting up a solution" for MonoDevelop. I wrote the page for SharpDevelop and have no access to MonoDevelop myself.

Modding Tutorials/Mod folder structure

2015-11-02T18:25:46Z

Alistaire: /* Standard mod folder structure */ Added info regarding Mods folder

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

This tutorial introduces you to the mod folder structure and shows you a standard folder structure setup to help you start out. 

[[Modding Tutorials/Mod folder structure#Complete mod folder structure|Complete mod folder structure]] is a list of all folders you might find in your average mod directory. This includes /Core/. 

=What you'll learn=

You'll learn the following mod structure: 

YourModName/
About/
About.xml
Preview.png
Assemblies/
ProjectName.dll
Defs/
(..)
Languages/
English/
Strings/
NameBanks/
Sounds/
Source/
ProjectName/
ProjectName.sln
Textures/

.. Along with a few tips on how to keep your mod folder structure readable and functional. 

=Standard mod folder structure=

Mod folders are located in the mods folder, which is located as such: 

RimWorld******/
Mods/

..relative to your RimWorld install directory. Each mod is a sub folder of this Mods folder and each mod has to follow the following structure precisely. 

==The About folder==
{{Main|Modding Tutorials/About}} 

Making a mod starts with you making a folder structure. Some mods need textures and sounds, while others are XML or even C# only. 
Every mod does however require the following structure to show up in the mods list: 

YourModName/
About/
About.xml

Along with this vital information it's possible to add a preview image for your mod. This makes the structure as follows: 

YourModName/
About/
About.xml
Preview.png

The size of the base game Preview.png is 400x61 pixels, but some mods use higher preview images. The image is centered in the mod's description, and can be of any size. 

==The Defs folders==
{{Main|Modding Tutorials/Defs}} 

If your mod adds new content, chances are you're going to use XML files. These files are going to be stored in the folder structure as follows: 

YourModName/
Defs/
BiomeDefs/
Biomes.xml
BodyDefs/
Bodies.xml
BodyPartDefs/
BodyParts.xml
(..)

The contents of a Def folder don't follow a clear naming convention, but the folder names are generally the same in every mod. 
Using a non-standard name is going to make it harder for others to navigate your mod's folders, so it is advised to keep the folder names consistent with the base game. 

Typically, the files inside these folders are named after their contents: 

Core/
Defs/
ThingDefs/
Apparel_Hats.xml
Apparel_Shield.xml
(..)
Weapons_Melee.xml
Weapons_RangedNeolithic.xml

This makes it easier for people to navigate XML code. If your mod is going to add both apparel and weapons, or even both hats and shoes, you're best off separating the XML code in their respective files. 
Some mod authors choose to make a separate file for each of their items. This makes it easier for others to remove only part of your mod and keep the rest of it, but with very large mods it makes it harder to navigate the folder. 

==The Textures and Sounds folders==
{{Main|Modding Tutorials/Textures|Modding Tutorials/Sounds}} 

If you're using Defs chances are you're creating a content mod. This type of mod is most likely very dull without its own custom graphics and sounds. Adding such content requires the following folders: 

YourModName/
Textures/
Sounds/

The contents of the Textures and Sounds folder usually aren't the same between mods. The base game sorts these files in various folders and subfolders, but in the end it's very hard to navigate them based on the folder names. 
It's possible to categorize this content by item (submachinegun#1, pistol#3) or item type (guns, buildings), as an example. Whatever you do it's best to keep the structure consistent throughout both folders. 

==The Source and Assemblies folders==

If you want to take a shot at [[Modding Tutorials/Writing custom code|C# modding]], you want an '''empty''' Source and an '''empty''' Assemblies folder. You'll want to [[Modding Tutorials/Setting up a solution|create the C# project]] inside your Source folder, and compile the class library into the Assemblies folder. These things are processed automatically by your [[Modding Tutorials/Recommended software#IDE's|IDE]], so you don't have to make these folder structures yourself: 

YourModName/
Assemblies/
ProjectName.dll
Source/
SolutionName/
SolutionName.sln
ProjectName/
ProjectName.csproj
(..)

''Or:''

YourModName/
Assemblies/
ProjectName.dll
Source/
ProjectName/
SolutionName.sln
ProjectName.csproj
(..)

'''Once again''', the structure of these folders is decided almost entirely by the author's editing software. Therefore the only things you have to set up are the following folders: 

YourModName/
Assemblies/
Source/

.. And then once you create a solution starting in ../YourModName/Source/ everything else will be sorted out by the software. People don't navigate these folders, they open ProjectName.sln to navigate it using their software of choice. 

==The Languages folder==

Unless you're on a translation team, you're unlikely to need this folder a lot. If you want to randomly generate names using your own words, you will however have to use this folder: 

YourModName/
Languages/
English/
Strings/
NameBanks/

In this folder you put .txt files with a new word on every line. Using XML you will then be able to randomly pick one of the lines in the file. 
In the average mod the rest of the folder is quite useless. You are unlikely to translate your mod into tens of different languages. 

=Complete mod folder structure=

*/
About/
About.xml
Preview.png-
Assemblies/-
*.dll+
Defs/-
*Defs/+
*.xml+
Languages/-
*/*
DefInjected/-
*Defs/+
*.xml+
Keyed/-
*.xml+
Strings/-
NameBanks/
*.txt+
FriendlyName.txt-
LangIcon.png
LanguageInfo.xml
Sounds/-
*/*#
*.wav+
Source/-
*/*#
bin/
Debug/
*.**
obj/
Debug/
*.**
Properties/-
AssemblyInfo.cs
Source-DLLs/-
Assembly-CSharp.dll
UnityEngine.dll
*.csproj
*.OpenCover.Settings
*.sln
*/*#
*.cs+
Textures/-
*/*#
*.psd*
*.psd.meta*
*.png*

Anything with a / at the end is a folder;
Anything with a . in it is a file;
The * in *.* and */ stands for any arbitrary string;
The * after a file/folder stands for an occurence of >= 0;
The + after a file/folder stands for an occurrence of > 0;
The - after a file/folder stands for an occurrence of <= 1;
The # after a folder stands for a folder depth of >= 0.

=Next up=
* [[Modding Tutorials/Recommended software|Recommended Software]]

[[Category:Modding tutorials]]

Modding Tutorials/Compatibility with defs

2015-10-02T08:30:51Z

Alistaire: /* Next up */ Added more compatibility guides

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

In this tutorial you will learn different ways to make XML mods compatible and how to link existing and modded recipes, facilities and buildings with eachother.

=What you'll learn=

You'll learn how to implement your mods into existing defs, how to fix compatibility between XML mods and how to make modded recipes, facilities and buildings interact with eachother without overwriting the base game. 

=Overwriting defs=
===Core defs===

The least elegant way to go about compatibility is to have a modified copy of a core def in your mod file. You have to rely on load order to make the mod work, let's say you want to change the damage of a pistol: 

Core/
Defs/
ThingDefs/
Weapons_Guns.xml
YourModName/
Defs/
ThingDefs/
YourFileName.xml

.. and contents:

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>


<ThingDef ParentName="BaseBullet">
<defName>Bullet_Pistol</defName>
<projectile>
<DamageAmountBase>9</DamageAmountBase>
</projectile>

</ThingDef>


</Defs></source> 

The above code adds something that already exists on the /Core/ mod - to make it overwrite the core mod, this mod has to be loaded after it. Practically every mod is loaded after the core mod, so this shouldn't be a problem. 

The problem arises when multiple mods edit ''Bullet_Pistol'', and as a rule of thumb the last loaded version of a defName is kept. 

===Mod defs===

{|
!colspan=3| I modify.. !! What do?
|-
|rowspan=2| ..Core.. ||colspan=2| ..Def values || Add the defs you want to overwrite to your mod and load the mod after Core
|-
|colspan=2| ..Class references || Add the defs you want to overwrite to your mod and load the mod after Core, use C# to [[Modding Tutorials/Modifying defs|modify def classes]].
|-
|rowspan=8| ..a mod's.. ||rowspan=3| ..Def changes.. || ..directly || Make a choice which value to keep (merge them if possible) - if it's the only difference in the core def overwrites between the mods, simply loading one after the other will fix the compatibility, if that's not possible make a merged patch
|-
| ..collaterally || The easiest way to fix this is by making a patch, including the same def with both modifications applied to them - this def can then be loaded after both of the mods2
|-
| (both of the above) || Make a compatibility patch: take the def from both mods and try to merge as many values as you can, compare it to the core def, see if you can figure it out through XML only
|-
|rowspan=2| ..Class reference changes.. || ..directly || E.g <thingClass> added twice: [[Modding Tutorials/Compatibility with DLLs|create a DLL patch]]3
|-
| ..not directly || E.g Mod A <ThingDef> and Mod B <projectile> Class changes: this will work fine with an XML patch3
|-
|rowspan=2| ..Def values.. || ..intentionally || Add the defs you want to overwrite to your mod and load it after their mod1
|-
| ..unintentionally || Rename your defs, try to figure the compatibility out through contacting the author, make a compatibility patch
|-
|colspan=2| ..Class references || E.g <ThingDef Class="namespace.class"> added twice: [[Modding Tutorials/Compatibility with DLLs|create a DLL patch]]3
|} 

# If your mod requires another mod to function and you want to change something about their mod, let's say CustomShotgun should do 20 damage instead of 25, your mod has to include CustomShotgun's def and be loaded after their mod.
# Mod A changes CoreDef's label to "hunting shotgun", mod B changes CoreDef's soundInteract to "InteractPistol", patch AB does both to fix their compatibility issues.
# When mod A adds Class="ModANamespace.ModAClass" to a defName's ThingDef and mod B adds Class="ModBNamespace.ModBClass" this is a non XML-patchable incompatibility. This means that if A adds a Class to the <projectile> tag and B adds a Class to the <thingDef> tag you're perfectly fine. This tutorial won't cover creating DLL patches because it's more in-depth, but [[Modding Tutorials/Compatibility with DLLs|create a DLL patch]] and [[Modding Tutorials/Injection|C# injection]] will. 

=Referencing defs=
===RecipeDef===

In case your mod adds a new recipe for the [[Cook stove]], you might think it's necessary to overwrite part of its thingDef. This is however completely unnecessary - the C# code base contains a tag which allows you to make your ''recipe'' choose which ''building'' to attach to (instead of the other way round): 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<RecipeDef>
<defName>BakeBread</defName>
<recipeMaker>
<recipeUsers>
<li>CookStove</li>
</recipeUsers>

</recipeMaker>

</RecipeDef>
</Defs></source> 

If you want your ''building'' to choose which ''recipes'' to display, you do the following: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<ThingDef>
<defName>BakeryOven</defName>
<recipes>
<li>BakeBread</li>
</recipes>

</ThingDef>
</Defs></source> 

The BakeBread recipe will now show up in both the BakeryOven and CookStove, without the mod having to modify CookStove's <recipes> list. 

===Facilities===

Buildings with the "CompAffectedByFacilities" compClass can choose which facilities should link to them. In the base game it isn't used the other way round - facilities don't do this - but the C# code base has a tag for it: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<ThingDef>
<defName>BadIdeaShredder</defName>
<comps>
<li>
<compClass>CompFacility</compClass>
<statOffsets>
<ResearchSpeedFactor>0.05</ResearchSpeedFactor>
</statOffsets>
<linkableBuildings>
<li>ResearchBench</li>
</linkableBuildings>
</li>
</comps>

</ThingDef>
</Defs></source> 

Linking existing facilities to modded buildings is also possible by doing what existing buildings already do: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<ThingDef>
<defName>MyFirstWorkshop</defName>
<comps>
<li>
<compClass>CompAffectedByFacilities</compClass>
<linkableFacilities>
<li>ToolCabinet</li>
</linkableFacilities>
</li>
</comps>

</ThingDef>
</Defs></source> 

BadIdeaShredder can now be attached to the vanilla ResearchBench, and the vanilla ToolCabinet can now be attached to MyFirstWorkshop. 

=Next up=

* [[Modding_Tutorials/Modifying defs|Def Class Compatibility]] explains compatibility from the Def Class side of things.
* [[Modding Tutorials/Compatibility with DLLs|Create a DLL patch]] continues explanations on compatibility patching and referencing existing items.
* [[Modding Tutorials/Injection|C# injection]] is an in-depth guide on using C# injection to resolve compatibility issues. 

[[Category:Modding tutorials]]

Modding Tutorials/Recommended software

2015-10-02T08:28:24Z

Alistaire: Added next up

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

=What you'll learn=

This tutorial lists a few programs you could use to edit XML and C# code. 

=XML Code Editors=

===Basic Editors===

Just about any text editor can write XML code, but as a modder you will want to at the very least see when you forgot closing brackets, a closing tag and other syntax errors. 

Notepad doesn't do this, so if you're even somewhat serious about modding, the following software will help you immensely: 

{| class="wikitable"
! Software !! OS !! Description
|-
| [http://notepad-plus-plus.org/download/ Notepad++] || Windows || Has well implemented auto-completion and a very customizable user interface. Can be used to write both XML and C# code, although C# software usually has its own text editor
|-
| [http://www.sublimetext.com/ Sublime Text] || Mono || Natively supports many programming languages and markup languages, and its functionality can be extended by users with plugins - A brief overview of its functionality can be found [http://webdesign.tutsplus.com/tutorials/useful-shortcuts-for-a-faster-workflow-in-sublime-text-3--cms-22185 here] and a full course [http://code.tutsplus.com/courses/perfect-workflow-in-sublime-text-2 here]
|-
| [http://www.pnotepad.org/download/ Programmer's Notepad] || Windows || More lightweight with a less cluttered interface than Notepad++, also capable of editing both XML and C# code
|-
| [http://xmlnotepad.codeplex.com/releases/ XML Notepad] || Windows || XML-oriented editor with a lot of features you will most likely never use in Rimworld modding
|} 

===Advanced Editors===

There's many editors out there specifically made for XML code. Because Rimworld uses XML in a very simple way, advanced code editors are rarely needed. In case you're ever in need of one, however, the following ones might help: 

{| class="wikitable"
! Software !! OS !! Description
|-
| [http://sourceforge.net/projects/xpontus/files/ XPontus] || Windows || Has a tree view and is capable of checking XML for errors, fixing tabs and creating schema's detailing every tag's data types
|-
| [http://xmlgrid.net/ XMLGrid] || - || Capable of validating XML and turning it into Excel Spreadsheets, XSD Charts and an online table detailing each tag of a certain type and its contents
|-
| [http://codebeautify.org/xmlviewer Codebeautify's xmlviewer] || - || Can display as a tree view, automatically format/indent your code and can validate and show errors too. Also have a function share code (like [http://codebeautify.org/xmlviewer/b39586 that])
|} 

=IDE's=

C# code is best edited in an IDE (Integrated Development Environment) to make the process of editing code, managing a solution's content and compiling its projects both easier and faster. Any IDE for C# will probably work just fine, so here's a list of suggested editors: 

{| class="wikitable"
! Software !! OS !! Description
|-
| [http://www.visualstudio.com/ Visual Studio] || Windows || Very extensive IDE with paid, trial and free versions. Any of these versions will probably work, so you might as well take [https://www.visualstudio.com/products/visual-studio-community-vs Visual Studio Community 2013] which is free for individuals and small teams
|-
| [http://www.icsharpcode.net/OpenSource/SD/Download/ SharpDevelop] || Windows || Free IDE specifically made for C#
|-
| [http://www.monodevelop.com/download/ MonoDevelop] || Mono1 || Free, cross-platform IDE with customizable user interface. Has support for C# as well as some other languages you won't need for Rimworld
|}

# Windows, Mac and Linux 

Whichever IDE you choose, make sure it's capable of compiling for .NET Framework 3.5. If you for whatever reason don't have this framework installed, you can download it [https://www.microsoft.com/en-us/download/details.aspx?id=21 here]. 

=Additional C# Software=

Besides your IDE it's strongly recommended to install the following software for decompiling: 

{| class="wikitable"
! Software !! OS !! Description
|-
| [http://ilspy.net/ ILSpy] || Windows || Software which is capable of [[Modding Tutorials/Decompiling source code|decompiling source code]], which is very useful in Rimworld modding
|-
| [http://www.monodevelop.com/download/ MonoDevelop] || Mono || The Linux version of the software has an integrated decompiler for .DLLs
|} 

=Graphics Software=

For making textures you will need graphics software. Any image editing program should work, and if you have an alternative to the following links that's probably okay: 

{| class="wikitable"
! Software !! OS !! Description
|-
| [http://www.photofiltre-studio.com/download-en.htm Photofiltre Studio] || Windows || Functional software with very little user interface clutter for its applications. Doesn't support pen tablet, and has a 100% free (non-trial) version called [http://photofiltre.free.fr/download_en.htm Photofiltre]
|-
| [http://inkscape.org/en/download/ Inkscape] || Mono || Free vector graphic program with a steeper learning curve due to the vector based image editing. Vector graphics can look better than bitmap graphics in Rimworld
|-
| [http://www.photoshop.com/products Photoshop] || Windows/Mac || Paid software with a trial version. Rimworld's original graphics are made in Photoshop (they're .PSD files)
|-
| [http://www.gimp.org/ Gimp] || Mono || A free, open-source alternative to Photoshop that's been around since 1998. Gimp has a large user community, with great list of [http://www.gimp.org/tutorials/ tutorials] on the official sites
|} 

=Audio Software=

Recording your own audio for mods might be too much to ask, but editing audio is always possible. This can be done with the following software or your own alternative: 

{| class="wikitable"
! Software !! OS !! Description
|-
| [http://sourceforge.net/projects/audacity/ Audacity] || Mono || Audio editing software with many tutorials online, lots of useful functionality and a relatively readable interface
|} 

=Next up=

# [[Modding Tutorials/XML file structure|XML File Structure]] starts you off with the XML side of modding.
# [[Modding_Tutorials/Setting up a solution|Setting up]] starts you off with the C# side of modding. Knowledge of the XML part can and will be very useful. 

[[Category:Modding tutorials]]

Modding Tutorials/Compatibility with defs

2015-10-02T08:25:11Z

Alistaire: /* Facilities */ Clarified which are modded and which are vanilla buildings

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

In this tutorial you will learn different ways to make XML mods compatible and how to link existing and modded recipes, facilities and buildings with eachother.

=What you'll learn=

You'll learn how to implement your mods into existing defs, how to fix compatibility between XML mods and how to make modded recipes, facilities and buildings interact with eachother without overwriting the base game. 

=Overwriting defs=
===Core defs===

The least elegant way to go about compatibility is to have a modified copy of a core def in your mod file. You have to rely on load order to make the mod work, let's say you want to change the damage of a pistol: 

Core/
Defs/
ThingDefs/
Weapons_Guns.xml
YourModName/
Defs/
ThingDefs/
YourFileName.xml

.. and contents:

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>


<ThingDef ParentName="BaseBullet">
<defName>Bullet_Pistol</defName>
<projectile>
<DamageAmountBase>9</DamageAmountBase>
</projectile>

</ThingDef>


</Defs></source> 

The above code adds something that already exists on the /Core/ mod - to make it overwrite the core mod, this mod has to be loaded after it. Practically every mod is loaded after the core mod, so this shouldn't be a problem. 

The problem arises when multiple mods edit ''Bullet_Pistol'', and as a rule of thumb the last loaded version of a defName is kept. 

===Mod defs===

{|
!colspan=3| I modify.. !! What do?
|-
|rowspan=2| ..Core.. ||colspan=2| ..Def values || Add the defs you want to overwrite to your mod and load the mod after Core
|-
|colspan=2| ..Class references || Add the defs you want to overwrite to your mod and load the mod after Core, use C# to [[Modding Tutorials/Modifying defs|modify def classes]].
|-
|rowspan=8| ..a mod's.. ||rowspan=3| ..Def changes.. || ..directly || Make a choice which value to keep (merge them if possible) - if it's the only difference in the core def overwrites between the mods, simply loading one after the other will fix the compatibility, if that's not possible make a merged patch
|-
| ..collaterally || The easiest way to fix this is by making a patch, including the same def with both modifications applied to them - this def can then be loaded after both of the mods2
|-
| (both of the above) || Make a compatibility patch: take the def from both mods and try to merge as many values as you can, compare it to the core def, see if you can figure it out through XML only
|-
|rowspan=2| ..Class reference changes.. || ..directly || E.g <thingClass> added twice: [[Modding Tutorials/Compatibility with DLLs|create a DLL patch]]3
|-
| ..not directly || E.g Mod A <ThingDef> and Mod B <projectile> Class changes: this will work fine with an XML patch3
|-
|rowspan=2| ..Def values.. || ..intentionally || Add the defs you want to overwrite to your mod and load it after their mod1
|-
| ..unintentionally || Rename your defs, try to figure the compatibility out through contacting the author, make a compatibility patch
|-
|colspan=2| ..Class references || E.g <ThingDef Class="namespace.class"> added twice: [[Modding Tutorials/Compatibility with DLLs|create a DLL patch]]3
|} 

# If your mod requires another mod to function and you want to change something about their mod, let's say CustomShotgun should do 20 damage instead of 25, your mod has to include CustomShotgun's def and be loaded after their mod.
# Mod A changes CoreDef's label to "hunting shotgun", mod B changes CoreDef's soundInteract to "InteractPistol", patch AB does both to fix their compatibility issues.
# When mod A adds Class="ModANamespace.ModAClass" to a defName's ThingDef and mod B adds Class="ModBNamespace.ModBClass" this is a non XML-patchable incompatibility. This means that if A adds a Class to the <projectile> tag and B adds a Class to the <thingDef> tag you're perfectly fine. This tutorial won't cover creating DLL patches because it's more in-depth, but [[Modding Tutorials/Compatibility with DLLs|create a DLL patch]] and [[Modding Tutorials/Injection|C# injection]] will. 

=Referencing defs=
===RecipeDef===

In case your mod adds a new recipe for the [[Cook stove]], you might think it's necessary to overwrite part of its thingDef. This is however completely unnecessary - the C# code base contains a tag which allows you to make your ''recipe'' choose which ''building'' to attach to (instead of the other way round): 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<RecipeDef>
<defName>BakeBread</defName>
<recipeMaker>
<recipeUsers>
<li>CookStove</li>
</recipeUsers>

</recipeMaker>

</RecipeDef>
</Defs></source> 

If you want your ''building'' to choose which ''recipes'' to display, you do the following: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<ThingDef>
<defName>BakeryOven</defName>
<recipes>
<li>BakeBread</li>
</recipes>

</ThingDef>
</Defs></source> 

The BakeBread recipe will now show up in both the BakeryOven and CookStove, without the mod having to modify CookStove's <recipes> list. 

===Facilities===

Buildings with the "CompAffectedByFacilities" compClass can choose which facilities should link to them. In the base game it isn't used the other way round - facilities don't do this - but the C# code base has a tag for it: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<ThingDef>
<defName>BadIdeaShredder</defName>
<comps>
<li>
<compClass>CompFacility</compClass>
<statOffsets>
<ResearchSpeedFactor>0.05</ResearchSpeedFactor>
</statOffsets>
<linkableBuildings>
<li>ResearchBench</li>
</linkableBuildings>
</li>
</comps>

</ThingDef>
</Defs></source> 

Linking existing facilities to modded buildings is also possible by doing what existing buildings already do: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<ThingDef>
<defName>MyFirstWorkshop</defName>
<comps>
<li>
<compClass>CompAffectedByFacilities</compClass>
<linkableFacilities>
<li>ToolCabinet</li>
</linkableFacilities>
</li>
</comps>

</ThingDef>
</Defs></source> 

BadIdeaShredder can now be attached to the vanilla ResearchBench, and the vanilla ToolCabinet can now be attached to MyFirstWorkshop. 

=Next up=

* [[Modding Tutorials/Compatibility with DLLs|Create a DLL patch]] continues explanations on compatibility patching and referencing existing items.
* [[Modding Tutorials/Injection|C# injection]] is an in-depth guide on using C# injection to resolve compatibility issues. 

[[Category:Modding tutorials]]

Modding Tutorials/Compatibility with defs

2015-10-02T08:21:42Z

Alistaire: /* Referencing defs */ Changed Smithing bench to Cook stove to make sense for the example

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

In this tutorial you will learn different ways to make XML mods compatible and how to link existing and modded recipes, facilities and buildings with eachother.

=What you'll learn=

You'll learn how to implement your mods into existing defs, how to fix compatibility between XML mods and how to make modded recipes, facilities and buildings interact with eachother without overwriting the base game. 

=Overwriting defs=
===Core defs===

The least elegant way to go about compatibility is to have a modified copy of a core def in your mod file. You have to rely on load order to make the mod work, let's say you want to change the damage of a pistol: 

Core/
Defs/
ThingDefs/
Weapons_Guns.xml
YourModName/
Defs/
ThingDefs/
YourFileName.xml

.. and contents:

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>


<ThingDef ParentName="BaseBullet">
<defName>Bullet_Pistol</defName>
<projectile>
<DamageAmountBase>9</DamageAmountBase>
</projectile>

</ThingDef>


</Defs></source> 

The above code adds something that already exists on the /Core/ mod - to make it overwrite the core mod, this mod has to be loaded after it. Practically every mod is loaded after the core mod, so this shouldn't be a problem. 

The problem arises when multiple mods edit ''Bullet_Pistol'', and as a rule of thumb the last loaded version of a defName is kept. 

===Mod defs===

{|
!colspan=3| I modify.. !! What do?
|-
|rowspan=2| ..Core.. ||colspan=2| ..Def values || Add the defs you want to overwrite to your mod and load the mod after Core
|-
|colspan=2| ..Class references || Add the defs you want to overwrite to your mod and load the mod after Core, use C# to [[Modding Tutorials/Modifying defs|modify def classes]].
|-
|rowspan=8| ..a mod's.. ||rowspan=3| ..Def changes.. || ..directly || Make a choice which value to keep (merge them if possible) - if it's the only difference in the core def overwrites between the mods, simply loading one after the other will fix the compatibility, if that's not possible make a merged patch
|-
| ..collaterally || The easiest way to fix this is by making a patch, including the same def with both modifications applied to them - this def can then be loaded after both of the mods2
|-
| (both of the above) || Make a compatibility patch: take the def from both mods and try to merge as many values as you can, compare it to the core def, see if you can figure it out through XML only
|-
|rowspan=2| ..Class reference changes.. || ..directly || E.g <thingClass> added twice: [[Modding Tutorials/Compatibility with DLLs|create a DLL patch]]3
|-
| ..not directly || E.g Mod A <ThingDef> and Mod B <projectile> Class changes: this will work fine with an XML patch3
|-
|rowspan=2| ..Def values.. || ..intentionally || Add the defs you want to overwrite to your mod and load it after their mod1
|-
| ..unintentionally || Rename your defs, try to figure the compatibility out through contacting the author, make a compatibility patch
|-
|colspan=2| ..Class references || E.g <ThingDef Class="namespace.class"> added twice: [[Modding Tutorials/Compatibility with DLLs|create a DLL patch]]3
|} 

# If your mod requires another mod to function and you want to change something about their mod, let's say CustomShotgun should do 20 damage instead of 25, your mod has to include CustomShotgun's def and be loaded after their mod.
# Mod A changes CoreDef's label to "hunting shotgun", mod B changes CoreDef's soundInteract to "InteractPistol", patch AB does both to fix their compatibility issues.
# When mod A adds Class="ModANamespace.ModAClass" to a defName's ThingDef and mod B adds Class="ModBNamespace.ModBClass" this is a non XML-patchable incompatibility. This means that if A adds a Class to the <projectile> tag and B adds a Class to the <thingDef> tag you're perfectly fine. This tutorial won't cover creating DLL patches because it's more in-depth, but [[Modding Tutorials/Compatibility with DLLs|create a DLL patch]] and [[Modding Tutorials/Injection|C# injection]] will. 

=Referencing defs=
===RecipeDef===

In case your mod adds a new recipe for the [[Cook stove]], you might think it's necessary to overwrite part of its thingDef. This is however completely unnecessary - the C# code base contains a tag which allows you to make your ''recipe'' choose which ''building'' to attach to (instead of the other way round): 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<RecipeDef>
<defName>BakeBread</defName>
<recipeMaker>
<recipeUsers>
<li>CookStove</li>
</recipeUsers>

</recipeMaker>

</RecipeDef>
</Defs></source> 

If you want your ''building'' to choose which ''recipes'' to display, you do the following: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<ThingDef>
<defName>BakeryOven</defName>
<recipes>
<li>BakeBread</li>
</recipes>

</ThingDef>
</Defs></source> 

The BakeBread recipe will now show up in both the BakeryOven and CookStove, without the mod having to modify CookStove's <recipes> list. 

===Facilities===

Buildings with the "CompAffectedByFacilities" compClass can choose which facilities should link to them. In the base game it isn't used the other way round - facilities don't do this - but the C# code base has a tag for it: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<ThingDef>
<defName>BadIdeaShredder</defName>
<comps>
<li>
<compClass>CompFacility</compClass>
<statOffsets>
<ResearchSpeedFactor>0.05</ResearchSpeedFactor>
</statOffsets>
<linkableBuildings>
<li>ResearchBench</li>
</linkableBuildings>
</li>
</comps>

</ThingDef>
</Defs></source> 

Linking existing facilities to modded buildings is also possible by doing what existing buildings already do: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<ThingDef>
<defName>ToolWorkshop</defName>
<comps>
<li>
<compClass>CompAffectedByFacilities</compClass>
<linkableFacilities>
<li>ToolCabinet</li>
</linkableFacilities>
</li>
</comps>

</ThingDef>
</Defs></source> 

BadIdeaShredder can now be attached to ResearchBench, and ToolCabinet can now be attached to ToolWorkshop. 

=Next up=

* [[Modding Tutorials/Compatibility with DLLs|Create a DLL patch]] continues explanations on compatibility patching and referencing existing items.
* [[Modding Tutorials/Injection|C# injection]] is an in-depth guide on using C# injection to resolve compatibility issues. 

[[Category:Modding tutorials]]

Modding Tutorials

2015-10-02T08:15:32Z

Alistaire: /* General modding */ Added Testing Sounds link here

{| align=center
! {{MainSection_Nav}}
|}
{| align=center
| {{Mods_Nav}}
|}
<hr>

This is the table of contents for the modding tutorial. Here, you'll learn step by step how to create mods of gradually increasing complexity.

In light of little official documentation, this collection of tutorials has been written in hopes that more players will know how to modify RimWorld and make mods that further broaden horizons and make the game appealing to more audiences despite its early state.

==Table of contents==

===Introduction===

# [[Installing mods|Installing Mods]]
# [[Modding Tutorials/Folder structure|Exploring the Folder Structure]]
# [[Modding Tutorials/Mod folder structure|Mod Folder Structure]]
# [[Modding Tutorials/Recommended software|Recommended Software]]

===General modding===

* [[Modding Tutorials/Testing mods|Testing Mods]]
** [[Modding Tutorials/Development mode|Development Mode]]
* [[Modding Tutorials/Sounds|Adding and Testing Sounds]]

===XML tutorials===

# [[Modding Tutorials/XML file structure|XML File Structure]]
# [[Modding Tutorials/XML Defs|Introduction to XML Defs]]
#* [[Modding Tutorials/Compatibility with defs|XML Def Compatibility]]
# In-depth XML Def tutorials
#* [[Modding Tutorials/Weapons Guns|Weapons_Guns.xml Explained]] 

''The following tutorials are likely outdated''
* [[Modding Tutorials/Getting Started|Getting Started]]
* [[Modding Tutorials/Items|Items]]
* [[Modding Tutorials/Flooring|Flooring]]
* [[Modding Tutorials/Weapons|Weapons]]
* [[Modding Tutorials/Furniture|Buildings and Furniture]]
* [[Modding Tutorials/Plants|Plants]]
* [[Modding Tutorials/Food|Food]]
* [[Modding Tutorials/Races and Pawns|Races and Pawns]]
* [[Modding_Tutorials/Smelter|Buildings and Furniture: Creating a Smelter]]

===C# tutorials===
# [[Modding_Tutorials/Setting up a solution|Setting up]]
# [[Modding_Tutorials/Decompiling source code|Decompiling Source Code]]
# [[Modding_Tutorials/Writing custom code|Writing Custom Code]]
# [[Modding_Tutorials/Def classes|Introduction to Def Classes]]
#* [[Modding_Tutorials/Modifying defs|Def Class Compatibility]]
# [[Modding_Tutorials/Compatibility_with_DLLs|Mod DLL Compatibility]]
#* [[Modding_Tutorials/Injection|C# Injection]]
# [[Modding_Tutorials/Distribution|Distribution]] 
''Examples:''
* [[Modding Tutorials/Assembly Modding Example|Assembly Modding]]

==See also==

* [[:Category:Defs|List of Defs]]

[[Category:Modding tutorials]]

Modding Tutorials

2015-10-02T08:15:07Z

Alistaire: /* XML tutorials */ Changed list a bit

{| align=center
! {{MainSection_Nav}}
|}
{| align=center
| {{Mods_Nav}}
|}
<hr>

This is the table of contents for the modding tutorial. Here, you'll learn step by step how to create mods of gradually increasing complexity.

In light of little official documentation, this collection of tutorials has been written in hopes that more players will know how to modify RimWorld and make mods that further broaden horizons and make the game appealing to more audiences despite its early state.

==Table of contents==

===Introduction===

# [[Installing mods|Installing Mods]]
# [[Modding Tutorials/Folder structure|Exploring the Folder Structure]]
# [[Modding Tutorials/Mod folder structure|Mod Folder Structure]]
# [[Modding Tutorials/Recommended software|Recommended Software]]

===General modding===

* [[Modding Tutorials/Testing mods|Testing Mods]]
** [[Modding Tutorials/Development mode|Development Mode]]

===XML tutorials===

# [[Modding Tutorials/XML file structure|XML File Structure]]
# [[Modding Tutorials/XML Defs|Introduction to XML Defs]]
#* [[Modding Tutorials/Compatibility with defs|XML Def Compatibility]]
# In-depth XML Def tutorials
#* [[Modding Tutorials/Weapons Guns|Weapons_Guns.xml Explained]] 

''The following tutorials are likely outdated''
* [[Modding Tutorials/Getting Started|Getting Started]]
* [[Modding Tutorials/Items|Items]]
* [[Modding Tutorials/Flooring|Flooring]]
* [[Modding Tutorials/Weapons|Weapons]]
* [[Modding Tutorials/Furniture|Buildings and Furniture]]
* [[Modding Tutorials/Plants|Plants]]
* [[Modding Tutorials/Food|Food]]
* [[Modding Tutorials/Races and Pawns|Races and Pawns]]
* [[Modding_Tutorials/Smelter|Buildings and Furniture: Creating a Smelter]]

===C# tutorials===
# [[Modding_Tutorials/Setting up a solution|Setting up]]
# [[Modding_Tutorials/Decompiling source code|Decompiling Source Code]]
# [[Modding_Tutorials/Writing custom code|Writing Custom Code]]
# [[Modding_Tutorials/Def classes|Introduction to Def Classes]]
#* [[Modding_Tutorials/Modifying defs|Def Class Compatibility]]
# [[Modding_Tutorials/Compatibility_with_DLLs|Mod DLL Compatibility]]
#* [[Modding_Tutorials/Injection|C# Injection]]
# [[Modding_Tutorials/Distribution|Distribution]] 
''Examples:''
* [[Modding Tutorials/Assembly Modding Example|Assembly Modding]]

==See also==

* [[:Category:Defs|List of Defs]]

[[Category:Modding tutorials]]

Modding Tutorials

2015-10-02T08:09:01Z

Alistaire: /* C# tutorials */ Added stripped part of Modifying Defs tutorial link

{| align=center
! {{MainSection_Nav}}
|}
{| align=center
| {{Mods_Nav}}
|}
<hr>

This is the table of contents for the modding tutorial. Here, you'll learn step by step how to create mods of gradually increasing complexity.

In light of little official documentation, this collection of tutorials has been written in hopes that more players will know how to modify RimWorld and make mods that further broaden horizons and make the game appealing to more audiences despite its early state.

==Table of contents==

===Introduction===

# [[Installing mods|Installing Mods]]
# [[Modding Tutorials/Folder structure|Exploring the Folder Structure]]
# [[Modding Tutorials/Mod folder structure|Mod Folder Structure]]
# [[Modding Tutorials/Recommended software|Recommended Software]]

===General modding===

* [[Modding Tutorials/Testing mods|Testing Mods]]
** [[Modding Tutorials/Development mode|Development Mode]]

===XML tutorials===

# [[Modding Tutorials/XML file structure|XML File Structure]]
#* [[Modding Tutorials/Weapons Guns|Weapons_Guns.xml Explained]]
# [[Modding Tutorials/Compatibility with defs|Compatibility with Existing Defs]]
# [[Modding Tutorials/Sounds|Adding and Testing Sounds]] 

''The following tutorials are likely outdated''
* [[Modding Tutorials/Getting Started|Getting Started]]
* [[Modding Tutorials/Items|Items]]
* [[Modding Tutorials/Flooring|Flooring]]
* [[Modding Tutorials/Weapons|Weapons]]
* [[Modding Tutorials/Furniture|Buildings and Furniture]]
* [[Modding Tutorials/Plants|Plants]]
* [[Modding Tutorials/Food|Food]]
* [[Modding Tutorials/Races and Pawns|Races and Pawns]]
* [[Modding_Tutorials/Smelter|Buildings and Furniture: Creating a Smelter]]

===C# tutorials===
# [[Modding_Tutorials/Setting up a solution|Setting up]]
# [[Modding_Tutorials/Decompiling source code|Decompiling Source Code]]
# [[Modding_Tutorials/Writing custom code|Writing Custom Code]]
# [[Modding_Tutorials/Def classes|Introduction to Def Classes]]
#* [[Modding_Tutorials/Modifying defs|Def Class Compatibility]]
# [[Modding_Tutorials/Compatibility_with_DLLs|Mod DLL Compatibility]]
#* [[Modding_Tutorials/Injection|C# Injection]]
# [[Modding_Tutorials/Distribution|Distribution]] 
''Examples:''
* [[Modding Tutorials/Assembly Modding Example|Assembly Modding]]

==See also==

* [[:Category:Defs|List of Defs]]

[[Category:Modding tutorials]]

Modding Tutorials/Def classes

2015-10-02T08:08:11Z

Alistaire: Created, ripped from the Modifying Defs tutorial

{{BackToTutorials}}

This tutorial provides you with an introduction to Def Classes in C#. It shows what effects each part of the C# code has on the XML format. 

=Requirements=

* This tutorial requires you to know [[Modding Tutorials/Writing custom code|how to write custom code]].
* [[Modding Tutorials/Decompiling source code|Decompiling source code]] is required. 

=Modifying defs=

There's a few ways to modify existing def formats. We'll go over writing a ''custom defClass'', ''custom comp'' and other ways of integrating XML tags into C# for example through the use of ''weaponTags'' or ''apparelTags''. 

==Vanilla defClasses==

This chapter helps you develop a broad understanding of the def classes. First we take a look at tags inside <thingDef>, then we take a look at tags inside those tags and finally we take a look at <li> items. 

===Tags===

The structure of a base game defClass might look like this: 

<source lang="csharp">using RimWorld;
using System;
using UnityEngine;

namespace SomeNameSpace
{
public class SomeDef : Def
{
public SomeType someTagName;
public SomeOtherType someOtherTagName;

public SomeType someGetClass
{
get
{
return (SomeType)this.someOtherTagName;
}
}
}
}</source> 

A few notes could be made about this code. 
* Without the ''using'' part, you'd have to call for '''''Namespace'''.Class.Method()'' instead of ''Class.Method()'' or ''((Class)partOfClass).Method()'',<source lang="csharp">using ...; /* this tells the compiler which namespaces to look for when searching for class and method calls. */</source> 
* The ''':''' is inheritance and means you can access all methods in the parent and you can call back to for example the ''Tick()'' method using '''''base'''.Tick()'',<source lang="csharp">public class SomeDef : Def /* inherits "everything" from Def, !! except for privates !! */</source> 
* Everything of the following format '''is an XML tag''':<source lang="csharp">public SomeType someTagName /* shows up as <ThingDef><someTagName>SomeType value</someTagName></ThingDef> */</source> 
* Besides these tags there's also script-only methods in the code:<source lang="csharp">public SomeType someGetClass /* this is only used in C#. XML doesn't change anything about this */</source> 
* Specifically ''get'' methods are only there for easily accessing or calculating certain values:<source lang="csharp">return ...; /* example: "public bool IsApparel()" returns "this.apparel != null". This could be checked easily but Thing.IsApparel() is more readable sometimes */</source> 

In practice one could find the following code: 

<source lang="csharp">using RimWorld;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using UnityEngine;

namespace Verse
{
public class ThingDef : BuildableDef /* BuildableDef inherits from Def */
{
public bool alwaysHaulable;

public bool designateHaulable;

public StuffProperties stuffProps; /* the StuffProperties class defines what this might look like in XML */

public bool IsStuff
{
get
{
return this.stuffProps != null; /* with some types you can check whether they're defined by checking if they're not equal to null */
}
}

public bool EverHaulable
{
get
{
return this.alwaysHaulable || this.designateHaulable; /* "return A || B" will return true if either A or B is true, and false if both are false. */
}
}
}
}</source> 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<ThingDefs>
<thingDef>
<alwaysHaulable>true</alwaysHaulable>
<stuffProps>

</stuffProps>
</thingDef>
</ThingDefs></source> 
*Note: these are snippets of Verse.ThingDef. To find the full source please [[Modding Tutorials/Decompiling source code|decompile the source code]] yourself. 

===Subtags===

To explain how subtags work we'll take a look at (parts of) StuffProperties. The contents of the StuffProperties class, formally called Verse.StuffProperties, are very similar to the ThingDef class. The structure is mostly the same. 
In case you're wondering why we didn't have to add "using Verse;" to access Verse.StuffProperties, "namespace Verse {}" basically includes a ''using'' statement. 

<source lang="csharp">using RimWorld;
using System;
using System.Collections.Generic;
using UnityEngine;

namespace Verse
{
public class StuffProperties
{
public bool smeltable;

public StuffAppearance appearance;

public SoundDef soundImpactStuff;

public List<StatModifier> statOffsets;

public List<StuffCategoryDef> categories = new List<StuffCategoryDef>();
}
}</source> 
*Note: These are snippets of Verse.StuffProperties. To find the full source please [[Modding Tutorials/Decompiling source code|decompile the source code]] yourself. 

Because SomeDef defines which subtags it has you have to modify Verse.SomeDef to alter which subtags it has (this includes modified versions of existing subtags, you have to modify SomeDef at some point). 
This is one of the reasons you might be better off [[Modding Tutorials/Modifying defs#Custom comp|writing a custom comp]]. These can be added to an XML overwrite or [[Modding Tutorials/Injection|injected through C#]]. 

===Lists===

Some tags include a list (it contains <li> subtags). If you look at the subtags of StuffProperties you can see two List<SomeType> elements. If you look at the XML you can see a clear distinction between the two: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<ThingDefs>
<thingDef>
<stuffProps>
<categories>
<li>Metallic</li> /* Metallic is a defName from a StuffCategoryDef */
</categories>
<statOffsets>
<Beauty>6</Beauty> /* Beauty is a defName from a StatDef, but the list's type is StatModifier */
</statOffsets>
</stuffProps>
</thingDef>
</ThingDefs></source> 

A clear difference between the two is that one of them defines a list and the other one doesn't. If you look at RimWorld.StatModifier you can find another cause: 

<source lang="csharp">using System;
using System.Xml;
using Verse;

namespace RimWorld
{
public class StatModifier
{
public StatDef stat;

public float value;

public void LoadDataFromXmlCustom(XmlNode xmlRoot)
{
CrossRefLoader.RegisterObjectWantsCrossRef(this, "stat", xmlRoot.Name);
this.value = (float)ParseHelper.FromString(xmlRoot.FirstChild.Value, typeof(float));
}
}
}</source> 
*Note: These are snippets of RimWorld.StatModifier. To find the full source please [[Modding Tutorials/Decompiling source code|decompile the source code]] yourself. 

Because of this code the two act completely differently. One is a list with integer keys and StuffCategoryDef values, the other is a list with StatDef keys and float values. 


=See also=

* [[Modding Tutorials/Compatibility with defs|XML Def Compatibility]] explains compatibility from the XML side of things.
* [[Modding Tutorials/Modifying defs|Def Class Compatibility]] explains compatibility from the C# side of things. 

[[Category:Modding tutorials]]

Modding Tutorials/Modifying defs

2015-10-02T08:06:54Z

Alistaire: Stripped part of it to be in the Introduction to Def Classes

{{BackToTutorials}}

This tutorial shows you several ways to modify defs' (ThingDef, PawnKindDef) C# classes and alternatives to changing the XML format for them. 

There's several ways to achieve this goal. Three are listed here. 

=Requirements=

* [[Modding Tutorials/Decompiling source code|Decompiling source code]] is required.
* This tutorial requires you to know [[Modding Tutorials/Writing custom code|how to write custom code]].
* [[Modding Tutorials/Def classes|Introduction to Def Classes]] is highly recommended. 

==Custom def class==

The use of def classes is very popular in small mods. As long as the defs in the mod aren't overwriting core defs, it's very compatible. 

===Pros and cons===

Def classes require a pretty hefty overhaul of XML code to work. First of all you will have to change anything in the inheritance to refer to the same class: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<ThingDefs>
<thingDef Name="BaseThing" Class="myNamespace.myCustomClass">
</thingDef>

<thingDef Name="BaseSpecificThing" ParentName="BaseThing" Class="myNamespace.myCustomClass">
</thingDef>

<thingDef ParentName="BaseSpecificThing" Class="myNamespace.myCustomClass">
</thingDef>
</ThingDefs></source> 

And in case you have more thingDefs which require the changes that come with myNamespace.myCustomClass you'll have to set all of their classes for it to work. 
Applied to core defs this way of doing things introduces incompatibilities with other mods that modify the same def. Creating compatibility patches is inevitable. 

On the plus side you make it possible to change the root thingDef tags. In most cases you don't need this but certain things such as Pawn code might have no alternatives. 

===Example===

This example will simply add a new tag to the root thingDef. This is the best or even only way to implement new tags through custom def classes: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<ThingDefs>
<thingDef Name="BaseGun" Class="myNamespace.ThingDef_CustomTag">
</thingDef>

<thingDef Name="BaseHumanGun" ParentName="BaseGun" Class="myNamespace.ThingDef_CustomTag">
</thingDef>

<thingDef ParentName="BaseHumanGun" Class="myNamespace.ThingDef_CustomTag">
<myNewFloat>1.1</myNewFloat>
<myNewBool>true</myNewBool>
<myNewThingDefList>
<li>Silver</li>
<li>Pistol</li>
</myNewThingDefList>
</thingDef>
</ThingDefs></source> 

Without assigning the Class to each thingDef inheriting from and being inherited by a certain thingDef with a certain Class, '''the mod will cause errors'''. 
Now for the code we will have to create one C# class, namely myNamespace.ThingDef_CustomTag:

<source lang="csharp">using RimWorld;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using UnityEngine;

namespace myNameSpace
{
public class ThingDef_CustomTag : ThingDef
{
public float myNewFloat;

public bool myNewBool;

public List<ThingDef> myNewThingDefList = new List<ThingDef>();
}
}</source> 

And now that that exists you can call on it with any ThingDef as input like so: 

<source lang="csharp"> ThingDef_CustomTag customThingDef = someThingDef as ThingDef_CustomTag;
if (customThingDef != null)
{
if (2 * Rand.Value() > customThingDef.myNewFloat)
{
ThingDef_CustomTag customThingDef2 = customThingDef.myNewThingDefList.RandomElement() as ThingDef_Custom;
if (customThingDef2 != null)
{
return customThingDef2 .myNewBool;
}
return false;
}
return customThingDef.myNewBool;
}</source> 

Please note that any of the code might not work in a newer alpha. It's for demonstration purposes only. 

===Counterexample===
''The following method shows you '''why not to use''' custom defs. In some cases you could attempt to use this method but it's generally considered the least favourable way to deal with things.'' 

For this example we're gonna '''try to''' change the <race> tag to contain more tags. The value of these tags isn't exactly important, as is explained in the first few sections: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<ThingDefs>
<thingDef Name="BaseRace" Class="myNamespace.ThingDefWithCustomRaceProps">
</thingDef>

<thingDef Name="BaseAnimalRace" ParentName="BaseRace" Class="myNamespace.ThingDefWithCustomRaceProps">
</thingDef>

<thingDef ParentName="BaseAnimalRace" Class="myNamespace.ThingDefWithCustomRaceProps">
<race Class="myNamespace.RacePropertiesCustom">
<myNewFloat>1.1</myNewFloat>
<myNewBool>true</myNewBool>
<myNewThingDefList>
<li>Silver</li>
<li>Pistol</li>
</myNewThingDefList>
</race>
</thingDef>
</ThingDefs></source> 

Without assigning the Class to each thingDef inheriting from and being inherited by a certain thingDef with a certain Class, '''the mod will cause errors'''. 
Now for the code we will have to create two C# classes, namely myNamespace.ThingDefWithCustomRaceProps and myNamespace.RacePropertiesCustom:

<source lang="csharp">using RimWorld;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using UnityEngine;

namespace myNameSpace
{
public class ThingDefWithCustomRaceProps : ThingDef
{
new public RacePropertiesCustom race; /* requires the new keyword to overwrite the existing race */
}
}</source> 

And for the RacePropertiesCustom we make the following script: 

<source lang="csharp">using RimWorld;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using UnityEngine;

namespace myNameSpace
{
public class RacePropertiesCustom : RaceProperties
{
public float myNewFloat;

public bool myNewBool;

public List<ThingDef> myNewThingDefList = new List<ThingDef>();
}
}</source> 

One might think that's all required to make it work. However. 
Since the race variable tag is called by several methods all around the game's script, and it's called like ((ThingDef)someVariable).race.someMethod(), this means it won't use YOUR ThingDefWithCustomRaceProps and to fix this the only thing you can do is modify '''all''' these classes to cast to ThingDefWithCustomRaceProps like (ThingDefWithCustomRaceProps)((ThingDef)someVariable).race.someMethod(), which is less than ideal in every single case. It means copying and rewriting large portions of code, finding out they're called by certain other methods that also require the same treatment to call the new custom method to fix the custom thingDef class you made. 

For this reason custom defs are advised against. 

==Custom comp class==

Comp classes are a more advanced method of introducing compatibility to mods. Large mods might prefer comps to defs because it requires less XML editing in most cases. Along with that it's possible to inject comps into almost everything (because almost everything inherits from ThingWithComps) without having to change the comp while defs require a new class for each SomeDef they overwrite (E.g PawnKindDef and ThingDef require different classes) 

===Pros and cons===

Comps are easier to add than defClasses and can be injected by C# code. It's lighter on the XML code (doesn't require inheritance to be consistent) and C# code in most cases because it's more of a contained system. There's many hooks implemented which call for C# comp classes, such as CompTick() and PostDestroy(). Just like defs they can introduce incompatibilities. Adding another mod's comps requires the game to have both mods loaded, which can be a problem. Implementing smarter injection might fix this[?] in case a mod isn't loaded, but it's not possible to guarantee that the comp is actually added. 

===Method===

==Checking for tags==

Instead of using custom defClasses and comps you could also use tags. This is especially useful for lightweight features and simple compatibility. 

===Pros and cons===

Some tags are never used by a certain Thing such as ApparelTag on a Building. If a tag is never used it doesn't throw an error and therefore you could introduce as many useless tags as you want to a mod without the game complaining. When other mods check for these tags they can also do it without a problem. This way you could add tags of whatever name you want and let others check for this tag for compatibility. 

===Method===

=See also=

* [[Modding Tutorials/Compatibility with defs|Compatibility with defs]] explains compatibility from the XML side of things. 

[[Category:Modding tutorials]]

Installing mods

2015-10-02T06:18:05Z

Alistaire: Fixed ludeonthread template

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

=What you'll learn=

You'll learn where to install your downloaded mods and how to activate them, along with some notes on compatibility and backups. 

=Finding mods=

Look online and find a mod that you want to try out. The main source for finding mods is the {{LudeonThread|15|mod release section|board}} on the forums. 

Once you find a mod you like that is '''compatible''' with the version of RimWorld you have, you can download them from their individual threads. 

=Installation=

# Open the downloaded ZIP archive;
# Go to your [[save file#Save file locations|RimWorld download location]];
# '''Windows''':
## Drag and drop the extracted ModName folder into your RimWorld***Win/Mods/ folder (not in Core);
# '''Mac''':
## Right-click the RimWorld application and ''show package contents'';
## Drag and drop the ZIP archive's ModName folder into your Mods folder (not in Core) in the application package;
# Start up your game;
# Click the Mods button and activate your mods.

Some mods require a fresh world generation to work. 

===Editing mods folder===

In case your game stops running after you installed a mod, it's useful to have a backup of the mods folder somewhere. This way, you will always be able to undo a mistake that may occur. 

It is also very important to never delete the ThingCategories.xml file in your mod pack; doing this will result in a black screen when trying to start the game up. 

===Compatibility===

Not all mods are compatible with eachother: 

* Many content mods; such as Weapon, Apparel, Faction or even Hair mods; are compatible with eachother;
* Mods that change the same base game files, such as combat overhaul mods, are usually incompatible;
* Mods that add functionality to base game things are compatible but usually won't include the things from content mods;
* Modpack authors try to make mods in their pack compatible with eachother. Adding or updating mods might break the pack.

You will know if you have incompatible mods if you are having serious gameplay issues, such as unplaceable items, graphical issues, colonists getting stuck, etc. 
Having a console error might point to incompatibility as well, but some mods are expected to have console errors on start up. 

=Next up=

*[[Modding Tutorials/Folder structure|Exploring the Folder Structure]]

[[Category:Modding]][[Category:Modding tutorials]]

Template:LudeonThread

2015-10-02T06:17:06Z

Alistaire: Fixed brackets

<noinclude>{{Documentation}}</noinclude><includeonly>[{{{link|http://ludeon.com/forums/index.php?{{{3|topic}}}={{{1|{{{number|}}}}}}}}} {{{2|Thread}}}]</includeonly>

Template:LudeonThread

2015-10-02T06:15:35Z

Alistaire: Changed alt to {{{2}}}, {{{2}}} to {{{3}}}

<noinclude>{{Documentation}}</noinclude><includeonly>[{{{link|http://ludeon.com/forums/index.php?{{{3|topic}}}={{{1|{{{number|}}}}}}}}} {{{{{{2|Thread}}}]</includeonly>

Modding Tutorials/Compatibility with defs

2015-09-20T18:57:29Z

Alistaire: /* Mod defs */ Changed a few links

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

In this tutorial you will learn different ways to make XML mods compatible and how to link existing and modded recipes, facilities and buildings with eachother.

=What you'll learn=

You'll learn how to implement your mods into existing defs, how to fix compatibility between XML mods and how to make modded recipes, facilities and buildings interact with eachother without overwriting the base game. 

=Overwriting defs=
===Core defs===

The least elegant way to go about compatibility is to have a modified copy of a core def in your mod file. You have to rely on load order to make the mod work, let's say you want to change the damage of a pistol: 

Core/
Defs/
ThingDefs/
Weapons_Guns.xml
YourModName/
Defs/
ThingDefs/
YourFileName.xml

.. and contents:

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>


<ThingDef ParentName="BaseBullet">
<defName>Bullet_Pistol</defName>
<projectile>
<DamageAmountBase>9</DamageAmountBase>
</projectile>

</ThingDef>


</Defs></source> 

The above code adds something that already exists on the /Core/ mod - to make it overwrite the core mod, this mod has to be loaded after it. Practically every mod is loaded after the core mod, so this shouldn't be a problem. 

The problem arises when multiple mods edit ''Bullet_Pistol'', and as a rule of thumb the last loaded version of a defName is kept. 

===Mod defs===

{|
!colspan=3| I modify.. !! What do?
|-
|rowspan=2| ..Core.. ||colspan=2| ..Def values || Add the defs you want to overwrite to your mod and load the mod after Core
|-
|colspan=2| ..Class references || Add the defs you want to overwrite to your mod and load the mod after Core, use C# to [[Modding Tutorials/Modifying defs|modify def classes]].
|-
|rowspan=8| ..a mod's.. ||rowspan=3| ..Def changes.. || ..directly || Make a choice which value to keep (merge them if possible) - if it's the only difference in the core def overwrites between the mods, simply loading one after the other will fix the compatibility, if that's not possible make a merged patch
|-
| ..collaterally || The easiest way to fix this is by making a patch, including the same def with both modifications applied to them - this def can then be loaded after both of the mods2
|-
| (both of the above) || Make a compatibility patch: take the def from both mods and try to merge as many values as you can, compare it to the core def, see if you can figure it out through XML only
|-
|rowspan=2| ..Class reference changes.. || ..directly || E.g <thingClass> added twice: [[Modding Tutorials/Compatibility with DLLs|create a DLL patch]]3
|-
| ..not directly || E.g Mod A <ThingDef> and Mod B <projectile> Class changes: this will work fine with an XML patch3
|-
|rowspan=2| ..Def values.. || ..intentionally || Add the defs you want to overwrite to your mod and load it after their mod1
|-
| ..unintentionally || Rename your defs, try to figure the compatibility out through contacting the author, make a compatibility patch
|-
|colspan=2| ..Class references || E.g <ThingDef Class="namespace.class"> added twice: [[Modding Tutorials/Compatibility with DLLs|create a DLL patch]]3
|} 

# If your mod requires another mod to function and you want to change something about their mod, let's say CustomShotgun should do 20 damage instead of 25, your mod has to include CustomShotgun's def and be loaded after their mod.
# Mod A changes CoreDef's label to "hunting shotgun", mod B changes CoreDef's soundInteract to "InteractPistol", patch AB does both to fix their compatibility issues.
# When mod A adds Class="ModANamespace.ModAClass" to a defName's ThingDef and mod B adds Class="ModBNamespace.ModBClass" this is a non XML-patchable incompatibility. This means that if A adds a Class to the <projectile> tag and B adds a Class to the <thingDef> tag you're perfectly fine. This tutorial won't cover creating DLL patches because it's more in-depth, but [[Modding Tutorials/Compatibility with DLLs|create a DLL patch]] and [[Modding Tutorials/Injection|C# injection]] will. 

=Referencing defs=
===RecipeDef===

In case your mod adds a new recipe for the [[Smithing bench|smithing bench]], you might think it's necessary to overwrite part of its thingDef. This is however completely unnecessary - the C# code base contains a tag which allows you to make your ''recipe'' choose which ''building'' to attach to (instead of the other way round): 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<RecipeDef>
<defName>BakeBread</defName>
<recipeMaker>
<recipeUsers>
<li>CookStove</li>
</recipeUsers>

</recipeMaker>

</RecipeDef>
</Defs></source> 

If you want your ''building'' to choose which ''recipes'' to display, you do the following: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<ThingDef>
<defName>BakeryOven</defName>
<recipes>
<li>BakeBread</li>
</recipes>

</ThingDef>
</Defs></source> 

The BakeBread recipe will now show up in both the BakeryOven and CookStove, without the mod having to modify CookStove's <recipes> list. 

===Facilities===

Buildings with the "CompAffectedByFacilities" compClass can choose which facilities should link to them. In the base game it isn't used the other way round - facilities don't do this - but the C# code base has a tag for it: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<ThingDef>
<defName>BadIdeaShredder</defName>
<comps>
<li>
<compClass>CompFacility</compClass>
<statOffsets>
<ResearchSpeedFactor>0.05</ResearchSpeedFactor>
</statOffsets>
<linkableBuildings>
<li>ResearchBench</li>
</linkableBuildings>
</li>
</comps>

</ThingDef>
</Defs></source> 

Linking existing facilities to modded buildings is also possible by doing what existing buildings already do: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<ThingDef>
<defName>ToolWorkshop</defName>
<comps>
<li>
<compClass>CompAffectedByFacilities</compClass>
<linkableFacilities>
<li>ToolCabinet</li>
</linkableFacilities>
</li>
</comps>

</ThingDef>
</Defs></source> 

BadIdeaShredder can now be attached to ResearchBench, and ToolCabinet can now be attached to ToolWorkshop. 

=Next up=

* [[Modding Tutorials/Compatibility with DLLs|Create a DLL patch]] continues explanations on compatibility patching and referencing existing items.
* [[Modding Tutorials/Injection|C# injection]] is an in-depth guide on using C# injection to resolve compatibility issues. 

[[Category:Modding tutorials]]

Modding Tutorials/Modifying defs

2015-09-20T18:45:26Z

Alistaire: /* Custom def class */ Fixed namespaces

{{BackToTutorials}}

This tutorial shows you several ways to modify defs' (ThingDef, PawnKindDef) C# classes and alternatives to changing the XML format for them. 

=Requirements=

* This tutorial requires you to know [[Modding Tutorials/Writing custom code|how to write custom code]].
* [[Modding Tutorials/Decompiling source code|Decompiling source code]] is required. 

=Modifying defs=

There's a few ways to modify existing def formats. We'll go over writing a ''custom defClass'', ''custom comp'' and other ways of integrating XML tags into C# for example through the use of ''weaponTags'' or ''apparelTags''. 

==Vanilla defClasses==

This chapter helps you develop a broad understanding of the def classes. First we take a look at tags inside <thingDef>, then we take a look at tags inside those tags and finally we take a look at <li> items. 

===Tags===

The structure of a base game defClass might look like this: 

<source lang="csharp">using RimWorld;
using System;
using UnityEngine;

namespace SomeNameSpace
{
public class SomeDef : Def
{
public SomeType someTagName;
public SomeOtherType someOtherTagName;

public SomeType someGetClass
{
get
{
return (SomeType)this.someOtherTagName;
}
}
}
}</source> 

A few notes could be made about this code. 
* Without the ''using'' part, you'd have to call for '''''Namespace'''.Class.Method()'' instead of ''Class.Method()'' or ''((Class)partOfClass).Method()'',<source lang="csharp">using ...; /* this tells the compiler which namespaces to look for when searching for class and method calls. */</source> 
* The ''':''' is inheritance and means you can access all methods in the parent and you can call back to for example the ''Tick()'' method using '''''base'''.Tick()'',<source lang="csharp">public class SomeDef : Def /* inherits "everything" from Def, !! except for privates !! */</source> 
* Everything of the following format '''is an XML tag''':<source lang="csharp">public SomeType someTagName /* shows up as <ThingDef><someTagName>SomeType value</someTagName></ThingDef> */</source> 
* Besides these tags there's also script-only methods in the code:<source lang="csharp">public SomeType someGetClass /* this is only used in C#. XML doesn't change anything about this */</source> 
* Specifically ''get'' methods are only there for easily accessing or calculating certain values:<source lang="csharp">return ...; /* example: "public bool IsApparel()" returns "this.apparel != null". This could be checked easily but Thing.IsApparel() is more readable sometimes */</source> 

In practice one could find the following code: 

<source lang="csharp">using RimWorld;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using UnityEngine;

namespace Verse
{
public class ThingDef : BuildableDef /* BuildableDef inherits from Def */
{
public bool alwaysHaulable;

public bool designateHaulable;

public StuffProperties stuffProps; /* the StuffProperties class defines what this might look like in XML */

public bool IsStuff
{
get
{
return this.stuffProps != null; /* with some types you can check whether they're defined by checking if they're not equal to null */
}
}

public bool EverHaulable
{
get
{
return this.alwaysHaulable || this.designateHaulable; /* "return A || B" will return true if either A or B is true, and false if both are false. */
}
}
}
}</source> 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<ThingDefs>
<thingDef>
<alwaysHaulable>true</alwaysHaulable>
<stuffProps>

</stuffProps>
</thingDef>
</ThingDefs></source> 
*Note: these are snippets of Verse.ThingDef. To find the full source please [[Modding Tutorials/Decompiling source code|decompile the source code]] yourself. 

===Subtags===

To explain how subtags work we'll take a look at (parts of) StuffProperties. The contents of the StuffProperties class, formally called Verse.StuffProperties, are very similar to the ThingDef class. The structure is mostly the same. 
In case you're wondering why we didn't have to add "using Verse;" to access Verse.StuffProperties, "namespace Verse {}" basically includes a ''using'' statement. 

<source lang="csharp">using RimWorld;
using System;
using System.Collections.Generic;
using UnityEngine;

namespace Verse
{
public class StuffProperties
{
public bool smeltable;

public StuffAppearance appearance;

public SoundDef soundImpactStuff;

public List<StatModifier> statOffsets;

public List<StuffCategoryDef> categories = new List<StuffCategoryDef>();
}
}</source> 
*Note: These are snippets of Verse.StuffProperties. To find the full source please [[Modding Tutorials/Decompiling source code|decompile the source code]] yourself. 

Because SomeDef defines which subtags it has you have to modify Verse.SomeDef to alter which subtags it has (this includes modified versions of existing subtags, you have to modify SomeDef at some point). 
This is one of the reasons you might be better off [[Modding Tutorials/Modifying defs#Custom comp|writing a custom comp]]. These can be added to an XML overwrite or [[Modding Tutorials/Injection|injected through C#]]. 

===Lists===

Some tags include a list (it contains <li> subtags). If you look at the subtags of StuffProperties you can see two List<SomeType> elements. If you look at the XML you can see a clear distinction between the two: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<ThingDefs>
<thingDef>
<stuffProps>
<categories>
<li>Metallic</li> /* Metallic is a defName from a StuffCategoryDef */
</categories>
<statOffsets>
<Beauty>6</Beauty> /* Beauty is a defName from a StatDef, but the list's type is StatModifier */
</statOffsets>
</stuffProps>
</thingDef>
</ThingDefs></source> 

A clear difference between the two is that one of them defines a list and the other one doesn't. If you look at RimWorld.StatModifier you can find another cause: 

<source lang="csharp">using System;
using System.Xml;
using Verse;

namespace RimWorld
{
public class StatModifier
{
public StatDef stat;

public float value;

public void LoadDataFromXmlCustom(XmlNode xmlRoot)
{
CrossRefLoader.RegisterObjectWantsCrossRef(this, "stat", xmlRoot.Name);
this.value = (float)ParseHelper.FromString(xmlRoot.FirstChild.Value, typeof(float));
}
}
}</source> 
*Note: These are snippets of RimWorld.StatModifier. To find the full source please [[Modding Tutorials/Decompiling source code|decompile the source code]] yourself. 

Because of this code the two act completely differently. One is a list with integer keys and StuffCategoryDef values, the other is a list with StatDef keys and float values. 


==Custom def class==

The use of def classes is very popular in small mods. As long as the defs in the mod aren't overwriting core defs, it's very compatible. 

===Pros and cons===

Def classes require a pretty hefty overhaul of XML code to work. First of all you will have to change anything in the inheritance to refer to the same class: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<ThingDefs>
<thingDef Name="BaseThing" Class="myNamespace.myCustomClass">
</thingDef>

<thingDef Name="BaseSpecificThing" ParentName="BaseThing" Class="myNamespace.myCustomClass">
</thingDef>

<thingDef ParentName="BaseSpecificThing" Class="myNamespace.myCustomClass">
</thingDef>
</ThingDefs></source> 

And in case you have more thingDefs which require the changes that come with myNamespace.myCustomClass you'll have to set all of their classes for it to work. 
Applied to core defs this way of doing things introduces incompatibilities with other mods that modify the same def. Creating compatibility patches is inevitable. 

On the plus side you make it possible to change the root thingDef tags. In most cases you don't need this but certain things such as Pawn code might have no alternatives. 

===Example===

This example will simply add a new tag to the root thingDef. This is the best or even only way to implement new tags through custom def classes: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<ThingDefs>
<thingDef Name="BaseGun" Class="myNamespace.ThingDef_CustomTag">
</thingDef>

<thingDef Name="BaseHumanGun" ParentName="BaseGun" Class="myNamespace.ThingDef_CustomTag">
</thingDef>

<thingDef ParentName="BaseHumanGun" Class="myNamespace.ThingDef_CustomTag">
<myNewFloat>1.1</myNewFloat>
<myNewBool>true</myNewBool>
<myNewThingDefList>
<li>Silver</li>
<li>Pistol</li>
</myNewThingDefList>
</thingDef>
</ThingDefs></source> 

Without assigning the Class to each thingDef inheriting from and being inherited by a certain thingDef with a certain Class, '''the mod will cause errors'''. 
Now for the code we will have to create one C# class, namely myNamespace.ThingDef_CustomTag:

<source lang="csharp">using RimWorld;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using UnityEngine;

namespace myNameSpace
{
public class ThingDef_CustomTag : ThingDef
{
public float myNewFloat;

public bool myNewBool;

public List<ThingDef> myNewThingDefList = new List<ThingDef>();
}
}</source> 

And now that that exists you can call on it with any ThingDef as input like so: 

<source lang="csharp"> ThingDef_CustomTag customThingDef = someThingDef as ThingDef_CustomTag;
if (customThingDef != null)
{
if (2 * Rand.Value() > customThingDef.myNewFloat)
{
ThingDef_CustomTag customThingDef2 = customThingDef.myNewThingDefList.RandomElement() as ThingDef_Custom;
if (customThingDef2 != null)
{
return customThingDef2 .myNewBool;
}
return false;
}
return customThingDef.myNewBool;
}</source> 

Please note that any of the code might not work in a newer alpha. It's for demonstration purposes only. 

===Counterexample===
''The following method shows you '''why not to use''' custom defs. In some cases you could attempt to use this method but it's generally considered the least favourable way to deal with things.'' 

For this example we're gonna '''try to''' change the <race> tag to contain more tags. The value of these tags isn't exactly important, as is explained in the first few sections: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<ThingDefs>
<thingDef Name="BaseRace" Class="myNamespace.ThingDefWithCustomRaceProps">
</thingDef>

<thingDef Name="BaseAnimalRace" ParentName="BaseRace" Class="myNamespace.ThingDefWithCustomRaceProps">
</thingDef>

<thingDef ParentName="BaseAnimalRace" Class="myNamespace.ThingDefWithCustomRaceProps">
<race Class="myNamespace.RacePropertiesCustom">
<myNewFloat>1.1</myNewFloat>
<myNewBool>true</myNewBool>
<myNewThingDefList>
<li>Silver</li>
<li>Pistol</li>
</myNewThingDefList>
</race>
</thingDef>
</ThingDefs></source> 

Without assigning the Class to each thingDef inheriting from and being inherited by a certain thingDef with a certain Class, '''the mod will cause errors'''. 
Now for the code we will have to create two C# classes, namely myNamespace.ThingDefWithCustomRaceProps and myNamespace.RacePropertiesCustom:

<source lang="csharp">using RimWorld;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using UnityEngine;

namespace myNameSpace
{
public class ThingDefWithCustomRaceProps : ThingDef
{
new public RacePropertiesCustom race; /* requires the new keyword to overwrite the existing race */
}
}</source> 

And for the RacePropertiesCustom we make the following script: 

<source lang="csharp">using RimWorld;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using UnityEngine;

namespace myNameSpace
{
public class RacePropertiesCustom : RaceProperties
{
public float myNewFloat;

public bool myNewBool;

public List<ThingDef> myNewThingDefList = new List<ThingDef>();
}
}</source> 

One might think that's all required to make it work. However. 
Since the race variable tag is called by several methods all around the game's script, and it's called like ((ThingDef)someVariable).race.someMethod(), this means it won't use YOUR ThingDefWithCustomRaceProps and to fix this the only thing you can do is modify '''all''' these classes to cast to ThingDefWithCustomRaceProps like (ThingDefWithCustomRaceProps)((ThingDef)someVariable).race.someMethod(), which is less than ideal in every single case. It means copying and rewriting large portions of code, finding out they're called by certain other methods that also require the same treatment to call the new custom method to fix the custom thingDef class you made. 

For this reason custom defs are advised against. 

==Custom comp class==

Comp classes are a more advanced method of introducing compatibility to mods. Large mods might prefer comps to defs because it requires less XML editing in most cases. Along with that it's possible to inject comps into almost everything (because almost everything inherits from ThingWithComps) without having to change the comp while defs require a new class for each SomeDef they overwrite (E.g PawnKindDef and ThingDef require different classes) 

===Pros and cons===

Comps are easier to add than defClasses and can be injected by C# code. It's lighter on the XML code (doesn't require inheritance to be consistent) and C# code in most cases because it's more of a contained system. There's many hooks implemented which call for C# comp classes, such as CompTick() and PostDestroy(). Just like defs they can introduce incompatibilities. Adding another mod's comps requires the game to have both mods loaded, which can be a problem. Implementing smarter injection might fix this[?] in case a mod isn't loaded, but it's not possible to guarantee that the comp is actually added. 

===Method===

==Checking for tags==

Instead of using custom defClasses and comps you could also use tags. This is especially useful for lightweight features and simple compatibility. 

===Pros and cons===

Some tags are never used by a certain Thing such as ApparelTag on a Building. If a tag is never used it doesn't throw an error and therefore you could introduce as many useless tags as you want to a mod without the game complaining. When other mods check for these tags they can also do it without a problem. This way you could add tags of whatever name you want and let others check for this tag for compatibility. 

===Method===

=See also=

* [[Modding Tutorials/Compatibility with defs|Compatibility with defs]] explains compatibility from the XML side of things. 

[[Category:Modding tutorials]]

Modding Tutorials/Modifying defs

2015-09-20T18:29:58Z

Alistaire: /* Custom def class */ Finished custom def class

{{BackToTutorials}}

This tutorial shows you several ways to modify defs' (ThingDef, PawnKindDef) C# classes and alternatives to changing the XML format for them. 

=Requirements=

* This tutorial requires you to know [[Modding Tutorials/Writing custom code|how to write custom code]].
* [[Modding Tutorials/Decompiling source code|Decompiling source code]] is required. 

=Modifying defs=

There's a few ways to modify existing def formats. We'll go over writing a ''custom defClass'', ''custom comp'' and other ways of integrating XML tags into C# for example through the use of ''weaponTags'' or ''apparelTags''. 

==Vanilla defClasses==

This chapter helps you develop a broad understanding of the def classes. First we take a look at tags inside <thingDef>, then we take a look at tags inside those tags and finally we take a look at <li> items. 

===Tags===

The structure of a base game defClass might look like this: 

<source lang="csharp">using RimWorld;
using System;
using UnityEngine;

namespace SomeNameSpace
{
public class SomeDef : Def
{
public SomeType someTagName;
public SomeOtherType someOtherTagName;

public SomeType someGetClass
{
get
{
return (SomeType)this.someOtherTagName;
}
}
}
}</source> 

A few notes could be made about this code. 
* Without the ''using'' part, you'd have to call for '''''Namespace'''.Class.Method()'' instead of ''Class.Method()'' or ''((Class)partOfClass).Method()'',<source lang="csharp">using ...; /* this tells the compiler which namespaces to look for when searching for class and method calls. */</source> 
* The ''':''' is inheritance and means you can access all methods in the parent and you can call back to for example the ''Tick()'' method using '''''base'''.Tick()'',<source lang="csharp">public class SomeDef : Def /* inherits "everything" from Def, !! except for privates !! */</source> 
* Everything of the following format '''is an XML tag''':<source lang="csharp">public SomeType someTagName /* shows up as <ThingDef><someTagName>SomeType value</someTagName></ThingDef> */</source> 
* Besides these tags there's also script-only methods in the code:<source lang="csharp">public SomeType someGetClass /* this is only used in C#. XML doesn't change anything about this */</source> 
* Specifically ''get'' methods are only there for easily accessing or calculating certain values:<source lang="csharp">return ...; /* example: "public bool IsApparel()" returns "this.apparel != null". This could be checked easily but Thing.IsApparel() is more readable sometimes */</source> 

In practice one could find the following code: 

<source lang="csharp">using RimWorld;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using UnityEngine;

namespace Verse
{
public class ThingDef : BuildableDef /* BuildableDef inherits from Def */
{
public bool alwaysHaulable;

public bool designateHaulable;

public StuffProperties stuffProps; /* the StuffProperties class defines what this might look like in XML */

public bool IsStuff
{
get
{
return this.stuffProps != null; /* with some types you can check whether they're defined by checking if they're not equal to null */
}
}

public bool EverHaulable
{
get
{
return this.alwaysHaulable || this.designateHaulable; /* "return A || B" will return true if either A or B is true, and false if both are false. */
}
}
}
}</source> 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<ThingDefs>
<thingDef>
<alwaysHaulable>true</alwaysHaulable>
<stuffProps>

</stuffProps>
</thingDef>
</ThingDefs></source> 
*Note: these are snippets of Verse.ThingDef. To find the full source please [[Modding Tutorials/Decompiling source code|decompile the source code]] yourself. 

===Subtags===

To explain how subtags work we'll take a look at (parts of) StuffProperties. The contents of the StuffProperties class, formally called Verse.StuffProperties, are very similar to the ThingDef class. The structure is mostly the same. 
In case you're wondering why we didn't have to add "using Verse;" to access Verse.StuffProperties, "namespace Verse {}" basically includes a ''using'' statement. 

<source lang="csharp">using RimWorld;
using System;
using System.Collections.Generic;
using UnityEngine;

namespace Verse
{
public class StuffProperties
{
public bool smeltable;

public StuffAppearance appearance;

public SoundDef soundImpactStuff;

public List<StatModifier> statOffsets;

public List<StuffCategoryDef> categories = new List<StuffCategoryDef>();
}
}</source> 
*Note: These are snippets of Verse.StuffProperties. To find the full source please [[Modding Tutorials/Decompiling source code|decompile the source code]] yourself. 

Because SomeDef defines which subtags it has you have to modify Verse.SomeDef to alter which subtags it has (this includes modified versions of existing subtags, you have to modify SomeDef at some point). 
This is one of the reasons you might be better off [[Modding Tutorials/Modifying defs#Custom comp|writing a custom comp]]. These can be added to an XML overwrite or [[Modding Tutorials/Injection|injected through C#]]. 

===Lists===

Some tags include a list (it contains <li> subtags). If you look at the subtags of StuffProperties you can see two List<SomeType> elements. If you look at the XML you can see a clear distinction between the two: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<ThingDefs>
<thingDef>
<stuffProps>
<categories>
<li>Metallic</li> /* Metallic is a defName from a StuffCategoryDef */
</categories>
<statOffsets>
<Beauty>6</Beauty> /* Beauty is a defName from a StatDef, but the list's type is StatModifier */
</statOffsets>
</stuffProps>
</thingDef>
</ThingDefs></source> 

A clear difference between the two is that one of them defines a list and the other one doesn't. If you look at RimWorld.StatModifier you can find another cause: 

<source lang="csharp">using System;
using System.Xml;
using Verse;

namespace RimWorld
{
public class StatModifier
{
public StatDef stat;

public float value;

public void LoadDataFromXmlCustom(XmlNode xmlRoot)
{
CrossRefLoader.RegisterObjectWantsCrossRef(this, "stat", xmlRoot.Name);
this.value = (float)ParseHelper.FromString(xmlRoot.FirstChild.Value, typeof(float));
}
}
}</source> 
*Note: These are snippets of RimWorld.StatModifier. To find the full source please [[Modding Tutorials/Decompiling source code|decompile the source code]] yourself. 

Because of this code the two act completely differently. One is a list with integer keys and StuffCategoryDef values, the other is a list with StatDef keys and float values. 


==Custom def class==

The use of def classes is very popular in small mods. As long as the defs in the mod aren't overwriting core defs, it's very compatible. 

===Pros and cons===

Def classes require a pretty hefty overhaul of XML code to work. First of all you will have to change anything in the inheritance to refer to the same class: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<ThingDefs>
<thingDef Name="BaseThing" Class="myNamespace.myCustomClass">
</thingDef>

<thingDef Name="BaseSpecificThing" ParentName="BaseThing" Class="myNamespace.myCustomClass">
</thingDef>

<thingDef ParentName="BaseSpecificThing" Class="myNamespace.myCustomClass">
</thingDef>
</ThingDefs></source> 

And in case you have more thingDefs which require the changes that come with myNamespace.myCustomClass you'll have to set all of their classes for it to work. 
Applied to core defs this way of doing things introduces incompatibilities with other mods that modify the same def. Creating compatibility patches is inevitable. 

On the plus side you make it possible to change the root thingDef tags. In most cases you don't need this but certain things such as Pawn code might have no alternatives. 

===Example===

This example will simply add a new tag to the root thingDef. This is the best or even only way to implement new tags through custom def classes: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<ThingDefs>
<thingDef Name="BaseGun" Class="myNamespace.ThingDef_CustomTag">
</thingDef>

<thingDef Name="BaseHumanGun" ParentName="BaseGun" Class="myNamespace.ThingDef_CustomTag">
</thingDef>

<thingDef ParentName="BaseHumanGun" Class="myNamespace.ThingDef_CustomTag">
<myNewFloat>1.1</myNewFloat>
<myNewBool>true</myNewBool>
<myNewThingDefList>
<li>Silver</li>
<li>Pistol</li>
</myNewThingDefList>
</thingDef>
</ThingDefs></source> 

Without assigning the Class to each thingDef inheriting from and being inherited by a certain thingDef with a certain Class, '''the mod will cause errors'''. 
Now for the code we will have to create one C# class, namely myNamespace.ThingDef_CustomTag:

<source lang="csharp">using RimWorld;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using UnityEngine;

namespace Verse
{
public class ThingDef_CustomTag : ThingDef
{
public float myNewFloat;

public bool myNewBool;

public List<ThingDef> myNewThingDefList = new List<ThingDef>();
}
}</source> 

And now that that exists you can call on it with any ThingDef as input like so: 

<source lang="csharp"> ThingDef_CustomTag customThingDef = someThingDef as ThingDef_CustomTag;
if (customThingDef != null)
{
if (2 * Rand.Value() > customThingDef.myNewFloat)
{
ThingDef_CustomTag customThingDef2 = customThingDef.myNewThingDefList.RandomElement() as ThingDef_Custom;
if (customThingDef2 != null)
{
return customThingDef2 .myNewBool;
}
return false;
}
return customThingDef.myNewBool;
}</source> 

Please note that any of the code might not work in a newer alpha. It's for demonstration purposes only. 

===Counterexample===
''The following method shows you '''why not to use''' custom defs. In some cases you could attempt to use this method but it's generally considered the least favourable way to deal with things.'' 

For this example we're gonna '''try to''' change the <race> tag to contain more tags. The value of these tags isn't exactly important, as is explained in the first few sections: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<ThingDefs>
<thingDef Name="BaseRace" Class="myNamespace.ThingDefWithCustomRaceProps">
</thingDef>

<thingDef Name="BaseAnimalRace" ParentName="BaseRace" Class="myNamespace.ThingDefWithCustomRaceProps">
</thingDef>

<thingDef ParentName="BaseAnimalRace" Class="myNamespace.ThingDefWithCustomRaceProps">
<race Class="myNamespace.RacePropertiesCustom">
<myNewFloat>1.1</myNewFloat>
<myNewBool>true</myNewBool>
<myNewThingDefList>
<li>Silver</li>
<li>Pistol</li>
</myNewThingDefList>
</race>
</thingDef>
</ThingDefs></source> 

Without assigning the Class to each thingDef inheriting from and being inherited by a certain thingDef with a certain Class, '''the mod will cause errors'''. 
Now for the code we will have to create two C# classes, namely myNamespace.ThingDefWithCustomRaceProps and myNamespace.RacePropertiesCustom:

<source lang="csharp">using RimWorld;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using UnityEngine;

namespace Verse
{
public class ThingDefWithCustomRaceProps : ThingDef
{
new public RacePropertiesCustom race; /* requires the new keyword to overwrite the existing race */
}
}</source> 

And for the RacePropertiesCustom we make the following script: 

<source lang="csharp">using RimWorld;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using UnityEngine;

namespace Verse
{
public class RacePropertiesCustom : RaceProperties
{
public float myNewFloat;

public bool myNewBool;

public List<ThingDef> myNewThingDefList = new List<ThingDef>();
}
}</source> 

One might think that's all required to make it work. However. 
Since the race variable tag is called by several methods all around the game's script, and it's called like ((ThingDef)someVariable).race.someMethod(), this means it won't use YOUR ThingDefWithCustomRaceProps and to fix this the only thing you can do is modify '''all''' these classes to cast to ThingDefWithCustomRaceProps like (ThingDefWithCustomRaceProps)((ThingDef)someVariable).race.someMethod(), which is less than ideal in every single case. It means copying and rewriting large portions of code, finding out they're called by certain other methods that also require the same treatment to call the new custom method to fix the custom thingDef class you made. 

For this reason custom defs are advised against. 

==Custom comp class==

Comp classes are a more advanced method of introducing compatibility to mods. Large mods might prefer comps to defs because it requires less XML editing in most cases. Along with that it's possible to inject comps into almost everything (because almost everything inherits from ThingWithComps) without having to change the comp while defs require a new class for each SomeDef they overwrite (E.g PawnKindDef and ThingDef require different classes) 

===Pros and cons===

Comps are easier to add than defClasses and can be injected by C# code. It's lighter on the XML code (doesn't require inheritance to be consistent) and C# code in most cases because it's more of a contained system. There's many hooks implemented which call for C# comp classes, such as CompTick() and PostDestroy(). Just like defs they can introduce incompatibilities. Adding another mod's comps requires the game to have both mods loaded, which can be a problem. Implementing smarter injection might fix this[?] in case a mod isn't loaded, but it's not possible to guarantee that the comp is actually added. 

===Method===

==Checking for tags==

Instead of using custom defClasses and comps you could also use tags. This is especially useful for lightweight features and simple compatibility. 

===Pros and cons===

Some tags are never used by a certain Thing such as ApparelTag on a Building. If a tag is never used it doesn't throw an error and therefore you could introduce as many useless tags as you want to a mod without the game complaining. When other mods check for these tags they can also do it without a problem. This way you could add tags of whatever name you want and let others check for this tag for compatibility. 

===Method===

=See also=

* [[Modding Tutorials/Compatibility with defs|Compatibility with defs]] explains compatibility from the XML side of things. 

[[Category:Modding tutorials]]

Modding Tutorials/Modifying defs

2015-09-20T16:29:14Z

Alistaire: Created, WIP

Modding Tutorials/Decompiling source code

2015-09-20T14:08:24Z

Alistaire: Added See Also, made somewhat more like the other tutorials

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

The base game provides a bunch of code snippets in ''../Source/'', relative to your Rimworld installation. Since this isn't a lot, one might want to take a look at the game's full source code: 

=Decompiling source code=

===ILSpy===

One method is to use ILSpy. This software is recommended because its settings are correct on a clean install. It is Windows only, though. 

# Download [http://ilspy.net/ ILSpy] (Download Binaries) and extract it to a directory of your choosing. Optionally create a desktop shortcut;
# '''Either''': associate the .dll extension with ILSpy:
## Navigate to ''Assembly-CSharp.dll'' in ''../Rimworld***_Data/Managed/'', relative to your Rimworld installation and with *** being a version number;
## Right-click "Open with" and select a standard program. Navigate to your ILSpy installation and double-click ''ILSpy.exe'', tick the checkbox and accept;
## Double-click ''Assembly-CSharp.dll'',
# '''Or''': open ILSpy and open a .dll:
## Open ILSpy;
## Go to File -> Open or press Ctrl+O, navigate to ''../Rimworld***_Data/Managed/'', relative to your Rimworld installation and with *** being a version number;
## Select ''Assembly-CSharp.dll'' and confirm,
# Click the "+" next to ''Assembly-CSharp (***)'', you will now see a list including the items ''Rimworld'' and ''Verse'';
# Take your time to look through the source code, to make yourself familiar. If you ever need the source code, open ILSpy again. 

===MonoDevelop===

MonoDevelop is capable of decompiling DLLs, albeit using clumsy initial settings. It is Linux only, otherwise you have to download Xamarin Studio which doesn't have a decompiler. 

# Download [http://www.monodevelop.com/download/ MonoDevelop] and install it;
# '''Either''': associate the .dll extension with MonoDevelop:
## Navigate to ''Assembly-CSharp.dll'' in ''../Rimworld***_Data/Managed/'', relative to your Rimworld installation and with *** being a version number;
## Right-click "Open with" and select MonoDevelop as standard program;
## Double-click ''Assembly-CSharp.dll'',
# '''Or''': open MonoDevelop and open a .dll:
## Open MonoDevelop;
## Go to File -> Open, navigate to ''../Rimworld***_Data/Managed/'', relative to your Rimworld installation and with *** being a version number;
## Select ''Assembly-CSharp.dll'' and confirm,
# '''Very important''': search for a dropdown called "Visibility" and change it from "Only public members" to "All members";
# '''Very important''': search for a dropdown called "Language" and change it from "Summary" to "C#";
# Click the "+" next to ''Assembly-CSharp (***)'', you will now see a list including the items ''Rimworld'' and ''Verse'';
# Take your time to look through the source code, to make yourself familiar. If you ever need the source code, open ''Assembly-CSharp.dll'' again. 

=See also=

* [[Modding Tutorials/Writing custom code|Writing custom code]] shows a broad overview of C# coding. 

[[Category:Modding tutorials]]

Modding Tutorials

2015-09-20T14:04:10Z

Alistaire: /* C# tutorials */ Added Modifying defs

{| align=center
! {{MainSection_Nav}}
|}
{| align=center
| {{Mods_Nav}}
|}
<hr>

This is the table of contents for the modding tutorial. Here, you'll learn step by step how to create mods of gradually increasing complexity.

In light of little official documentation, this collection of tutorials has been written in hopes that more players will know how to modify RimWorld and make mods that further broaden horizons and make the game appealing to more audiences despite its early state.

==Table of contents==

===Introduction===

# [[Installing mods|Installing Mods]]
# [[Modding Tutorials/Folder structure|Exploring the Folder Structure]]
# [[Modding Tutorials/Mod folder structure|Mod Folder Structure]]
# [[Modding Tutorials/Recommended software|Recommended Software]]

===General modding===

* [[Modding Tutorials/Testing mods|Testing Mods]]
** [[Modding Tutorials/Development mode|Development Mode]]

===XML tutorials===

# [[Modding Tutorials/XML file structure|XML File Structure]]
#* [[Modding Tutorials/Weapons Guns|Weapons_Guns.xml Explained]]
# [[Modding Tutorials/Compatibility with defs|Compatibility with Existing Defs]]
# [[Modding Tutorials/Sounds|Adding and Testing Sounds]] 

''The following tutorials are likely outdated''
* [[Modding Tutorials/Getting Started|Getting Started]]
* [[Modding Tutorials/Items|Items]]
* [[Modding Tutorials/Flooring|Flooring]]
* [[Modding Tutorials/Weapons|Weapons]]
* [[Modding Tutorials/Furniture|Buildings and Furniture]]
* [[Modding Tutorials/Plants|Plants]]
* [[Modding Tutorials/Food|Food]]
* [[Modding Tutorials/Races and Pawns|Races and Pawns]]
* [[Modding_Tutorials/Smelter|Buildings and Furniture: Creating a Smelter]]

===C# tutorials===
# [[Modding_Tutorials/Setting up a solution|Setting up]]
# [[Modding_Tutorials/Decompiling source code|Decompiling Source Code]]
# [[Modding_Tutorials/Writing custom code|Writing Custom Code]]
#* [[Modding_Tutorials/Modifying defs|Modifying Defs]]
# [[Modding_Tutorials/Compatibility_with_DLLs|Mod DLL Compatibility]]
#* [[Modding_Tutorials/Injection|C# Injection]]
# [[Modding_Tutorials/Distribution|Distribution]] 
''Examples:''
* [[Modding Tutorials/Assembly Modding Example|Assembly Modding]]

==See also==

* [[:Category:Defs|List of Defs]]

[[Category:Modding tutorials]]

Modding Tutorials/XML file structure

2015-08-26T18:38:11Z

Alistaire: /* Inheritance */ Summary added

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

In this tutorial we will start learning the XML syntax, why the base game uses it and what everything about it does. 

=What you'll learn=

You'll learn the default structure of def files: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<Def Name="Parent" Abstract="True">
</Def>

<Def ParentName="Parent">
</Def>


</Defs></source> 

.. Along with how inheritance using Name, ParentName and Abstract works. 

=Default Def structure=
===Standard defs===

Find a Def .xml file in the Core folder, for example thingDefs/Weapons_Guns.xml: 

Core/
Defs/
ThingDefs/
Weapons_Guns.xml

<source lang="xml">../Mods/Core/Defs/ThingDefs/Weapons_Guns.xml</source> 

The first thing in this file is the following line: 
<source lang="xml"><?xml version="1.0" encoding="utf-8"?></source> 

Which tells us this .xml files uses UTF-8 encoding and XML version 1.0, which are the default values for these fields - some XML editors choose to hide this line on editing and then save it on top of the document without ever asking the user about it. 

After that, the structure of the file consists of '''<Defs>''' and '''<Def>''' tags: 
<source lang="xml"><Defs>
<Def>
</Def>



<Def>
</Def>
</Defs></source> 

Each '''<Def>''' contains something's ''def'' (or definition), which can be used to specify each and every modifiable property, e.g for a certain ''thing'' (thingDef). 

===Differences in defs===

If you look through some .xml files, you'll find the code is inconsistent in the use of some defs; 

Several ''Buildings_**.xml'' files use the '''<Buildings>''' tag instead of the '''<Defs>''' one. They then proceed to use '''<thingDef>''''s inside the '''<Buildings>''' tag. 
Other ''Buildings_**.xml'' files use '''<Defs>''' instead of '''<ThingDefs>''', and some even use '''<GameData>''' instead of '''<ThingDefs>'''. 

This implies that the name of the beginning and ending tags isn't important. Rimworld doesn't read their names, it just looks whether they exist. 

This '''doesn't''' mean that '''<Def>''' tags are interchangeable. Using "<Def>" will break the game; you will have to specify what C# class will be loaded to parse its contents. 

===Full code===

'''It is important that your file follows this structure to the point where mods won't work with multiple <Defs>, or a <Def> outside of <Defs>:''' 
<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<Def>
</Def>



<Def>
</Def>
</Defs></source> 

=Inheritance=

'''Summary''': In XML, inheritance is used to decrease redundancy. If something has a ParentName="YourParentName", it takes all contents from Name="YourParentName". In case this ParentName is incomplete this will crash the game, and you stop it from being loaded into the game with Abstract="True". 

===Basegun thingDef===

The first thing in ''Weapons_Guns.xml'' is a '''<thingDef>''' with a Name and Abstract ''type'': 
<source lang="xml"><ThingDef Name="BaseGun" Abstract="True"></source> 

The Abstract type means that contents of this '''<thingDef>''' will not be loaded into the game, that after reading and processing the information in this tag it (the game) will finish reading the XML file and '''discard''' this tag and its contents, leaving alone (not discarding) anything that might have copied (taken, inherited) the contents of it. All of this is done with this tag: 
<source lang="xml"><ThingDef Abstract="True"></source> 

The Name type means the contents of this '''<thingDef>''' can be ''inherited'' by (read: copied by) another '''<thingDef>'''. This way you can write everything you're going to repeat a lot throughout the file in a single location, such as the following: 
<source lang="xml"><category>Item</category></source> 

Which notifies that this '''<thingDef>''' is of the ''Item'' category, as opposed to those of the ''Building'' category. Because there's a lot of ''tags'' repeated throughout every thing, this greatly compacts the XML file. 
The full BaseGun parent only has to be defined once in a file, and can then be inherited (copied) with: 
<source lang="xml"><ThingDef ParentName="BaseGun"></source> 

'''<thingDef ParentName="Parent">''' inherits all contents from '''<thingDef Name="Parent">'''. It is common practice to copy the vanilla BaseGun parent and paste it on top of a mod's Weapons_Guns.xml file. 
Another parent is BaseBullet which holds every standard bullet's commonly repeated properties, such as the property that bullets don't use hitpoints: 
<source lang="xml"><useHitPoints>False</useHitPoints></source> 

The last '''<thingDef>''' on top of the file is one with the Name type ''BaseHumanGun'' and the ParentName type ''BaseGun''. It inherits the contents of BaseGun and is inherited by everything with '''<thingDef ParentName="BaseHumanGun">''': 
<source lang="xml"><ThingDef Name="BaseHumanGun" ParentName="BaseGun" Abstract="True"></source> 

A list representation of how inheritance works in Rimworld's XML might help you out, either early on or to collect your thoughts after reading the above. 

# Game launches
# Game loads XML files:
## Inheritance information is taken from each tag
## Anything with a PARENTNAME type inherits (read: copies) and applies all content from its associated NAME type
##* Anything that gets content is a child
##* Anything that sends it is a parent
##* It's possible to be both of these
## Content information (read: everything between the <thingDef>) is taken and applied for each tag
##* All interfering content from parents is now overwritten
## Now that all <Def>s know their contents, ABSTRACT type defs are discarded and therefore ignored by the game
## All <Def>s and their contents finish loading
# Game finishes loading XML files 

===Breakdown===

Let's break down the inheritance chunks of the BaseGun code: 
<source lang="xml"><thingDef Name="BaseGun" Abstract="True">
</thingDef>

<thingDef Name="BaseHumanGun" ParentName="BaseGun" Abstract="True">
</thingDef>

<thingDef Name="BaseBullet" Abstract="True">
</thingDef></source>

{| class="wikitable"
!colspan="2"|<ThingDef Name="BaseGun" Abstract="True">
|-
| <thingDef> || The name of this ''tag'', which is read by the game and processed into a correct definition based on this name. All tags in ''../Mods/Core/Defs/ThingDefs/'' use the '''<thingDef>''' tag.
|-
| Name="BaseGun" || The Name ''type'' of this tag. This tag is a parent with the Name value of "BaseGun".
|-
| Abstract="True" || The [https://en.wikipedia.org/wiki/Abstract_type Abstract type] of this tag is True. This makes it so that the contents of this tag aren't ''instantiated'', which in practice means the contents of it can only be inherited by other tags and won't be loaded into the game because its only purpose is in inheritance, in being a parent. "Is the only use of this '''<thingDef>''' to be inherited from? Yes: add Abstract="True". No: don't."
|-
!colspan="2"|<ThingDef Name="BaseHumanGun" ParentName="BaseGun" Abstract="True">
|-
| ParentName="BaseGun" || The ParentName type of this tag. This tag inherits from a parent with the Name value of "BaseGun".
|} 

===Full code===

After the addition of inheritance, our XML file structure looks like this: 

<source lang="xml"><?xml version="1.0" encoding="utf-8"?>
<Defs>
<Def Name="Parent" Abstract="True">
</Def>

<Def ParentName="Parent">
</Def>


</Defs></source> 

* '''<Defs>''' can have any name you want;
* '''<Def>''' has to have a specific name.

=Next up=

* [[Modding Tutorials/Weapons Guns|Weapons_Guns.xml]] continues explanations on the BaseGun parent, the tags inside its '''<thingDef>''''s and further information on modding in weaponry.

[[Category:Modding tutorials]]

Modding Tutorials

2015-08-25T10:50:53Z

Alistaire: /* Table of contents */ Added uniform capitalization on the links

{| align=center
! {{MainSection_Nav}}
|}
{| align=center
| {{Mods_Nav}}
|}
<hr>

This is the table of contents for the modding tutorial. Here, you'll learn step by step how to create mods of gradually increasing complexity.

In light of little official documentation, this collection of tutorials has been written in hopes that more players will know how to modify RimWorld and make mods that further broaden horizons and make the game appealing to more audiences despite its early state.

==Table of contents==

===Introduction===

# [[Installing mods|Installing Mods]]
# [[Modding Tutorials/Folder structure|Exploring the Folder Structure]]
# [[Modding Tutorials/Mod folder structure|Mod Folder Structure]]
# [[Modding Tutorials/Recommended software|Recommended Software]]

===General modding===

* [[Modding Tutorials/Testing mods|Testing Mods]]
** [[Modding Tutorials/Development mode|Development Mode]]

===XML tutorials===

# [[Modding Tutorials/XML file structure|XML File Structure]]
#* [[Modding Tutorials/Weapons Guns|Weapons_Guns.xml Explained]]
# [[Modding Tutorials/Compatibility with defs|Compatibility with Existing Defs]]
# [[Modding Tutorials/Sounds|Adding and Testing Sounds]] 

''The following tutorials are likely outdated''
* [[Modding Tutorials/Getting Started|Getting Started]]
* [[Modding Tutorials/Items|Items]]
* [[Modding Tutorials/Flooring|Flooring]]
* [[Modding Tutorials/Weapons|Weapons]]
* [[Modding Tutorials/Furniture|Buildings and Furniture]]
* [[Modding Tutorials/Plants|Plants]]
* [[Modding Tutorials/Food|Food]]
* [[Modding Tutorials/Races and Pawns|Races and Pawns]]
* [[Modding_Tutorials/Smelter|Buildings and Furniture: Creating a Smelter]]

===C# tutorials===
# [[Modding_Tutorials/Setting up a solution|Setting up]]
# [[Modding_Tutorials/Decompiling source code|Decompiling Source Code]]
# [[Modding_Tutorials/Writing custom code|Writing Custom Code]]
# [[Modding_Tutorials/Compatibility_with_DLLs|Mod DLL Compatibility]]
#* [[Modding_Tutorials/Injection|C# Injection]]
# [[Modding_Tutorials/Distribution|Distribution]] 
''Examples:''
* [[Modding Tutorials/Assembly Modding Example|Assembly Modding]]

==See also==

* [[:Category:Defs|List of Defs]]

[[Category:Modding tutorials]]

Modding Tutorials

2015-08-25T10:48:54Z

Alistaire: /* General modding */ Added red link

{| align=center
! {{MainSection_Nav}}
|}
{| align=center
| {{Mods_Nav}}
|}
<hr>

This is the table of contents for the modding tutorial. Here, you'll learn step by step how to create mods of gradually increasing complexity.

In light of little official documentation, this collection of tutorials has been written in hopes that more players will know how to modify RimWorld and make mods that further broaden horizons and make the game appealing to more audiences despite its early state.

==Table of contents==

===Introduction===

# [[Installing mods|Installing Mods]]
# [[Modding Tutorials/Folder structure|Exploring the Folder Structure]]
# [[Modding Tutorials/Mod folder structure|Mod Folder Structure]]
# [[Modding Tutorials/Recommended software|Recommended Software]]

===General modding===

* [[Modding Tutorials/Testing mods|Testing mods]]
** [[Modding Tutorials/Development mode|Development mode]]

===XML tutorials===

# [[Modding Tutorials/XML file structure|XML File Structure]]
#* [[Modding Tutorials/Weapons Guns|Weapons_Guns.xml Explained]]
# [[Modding Tutorials/Compatibility with defs|Compatibility with existing defs]]
# [[Modding Tutorials/Sounds|Adding and testing sounds]] 

''The following tutorials are likely outdated''
* [[Modding Tutorials/Getting Started|Getting Started]]
* [[Modding Tutorials/Items|Items]]
* [[Modding Tutorials/Flooring|Flooring]]
* [[Modding Tutorials/Weapons|Weapons]]
* [[Modding Tutorials/Furniture|Buildings and Furniture]]
* [[Modding Tutorials/Plants|Plants]]
* [[Modding Tutorials/Food|Food]]
* [[Modding Tutorials/Races and Pawns|Races and Pawns]]
* [[Modding_Tutorials/Smelter|Buildings and Furniture: Creating a Smelter]]

===C# tutorials===
# [[Modding_Tutorials/Setting up a solution|Setting up]]
# [[Modding_Tutorials/Decompiling source code|Decompiling source code]]
# [[Modding_Tutorials/Writing custom code|Writing Custom Code]]
# [[Modding_Tutorials/Compatibility_with_DLLs|Mod DLL compatibility]]
#* [[Modding_Tutorials/Injection|C# injection]]
# [[Modding_Tutorials/Distribution|Distribution]] 
''Examples:''
* [[Modding Tutorials/Assembly Modding Example|Assembly Modding]]

==See also==

* [[:Category:Defs|List of Defs]]

[[Category:Modding tutorials]]

Modding Tutorials/Distribution

2015-08-25T10:48:02Z

Alistaire: Made more in line with other tutorials

{{BackToTutorials}}
{{Credit|[[User:Alistaire|Alistaire]]}} 

This tutorial suggests steps to take when releasing your mod. 

=Requirements=

* (Optional): This tutorial requires you to have [[Modding Tutorials/Setting up a solution|set up a solution]].
* (Optional): You will have to [[Modding Tutorials/Writing custom code|have written code]] (there's no use in an empty project). 

=Distribution=

# Compile all your DLLs and make sure they're in the Assemblies folder;
# Make a copy of your mod and call it (YourModName)-DEV or something along those lines. Strip all files standard users won't need out of the standard version:
## The Source folder is mostly useless for standard mod users;
## Backups of older versions of textures and such can be removed from the standard version;
## Make sure to remove as many XML comments as you want, don't leave spoilers in there for your upcoming updates!
# Update your About folder, that thing was made in a hurry anyways. Add a nice Preview.png to showcase your mod:
## Make sure you've updated the targetVersion tag,
# '''Optional:''' Release your source code.
## Some mods include the Source folder with the full C# project in it for other modders to check out;
## Some mods include a Dropbox download link to their source code in the mod's topic. This is also a possibility,
# Take a look at the "Mod release rules" {{LudeonThread|10561}};
# Along with that, this {{LudeonThread|7037}} has tips on host sites and further naming conventions. 

[[Category:Modding tutorials]]