Medieval Engineers Wiki - User contributions [en]

Keen:Planet Modding/Voxel Materials

2017-05-05T13:04:55Z

Lukas:

Hello and welcome to the Modding of Voxel Materials guide for young Padawans. Feeling creative about changing the look of voxel materials? You think you’re really good, huh? Well, you’re in the right place then. Be prepared for a great journey saving the world by changing the look of the voxel worlds around you. Let’s just assume that you want to change the color of this beautiful green grass which grows on every EarthLike planet in the SE Universe! And let’s assume you want to change it to a crazy blue color. Why? Because we CAN, and you can too! Call NOW and get your free training program PLUS an amazing set of kitchen knives... wait... I meant something completely different...

[[File:Voxels 1-1.jpg|center|1200px]]

==Source Files==
Various files will be used as examples in this guide.<br/>
They can be downloaded here: http://www.medievalengineerswiki.com/uploaded_files/Voxel_material_modding_files.zip

==Voxel material definitions==
Ok, so to start - all voxel materials definitions are stored in the VoxelMaterials.sbc file. Find it and open it in MS Visual Studio or any other advanced text editor. Search for the following line in the code:

<pre><SubtypeId>Grass</SubtypeId></pre>

That’s where all the fun begins! So “Grass” is the name of the voxel material we’re looking for. It’s exactly how it is called in the game, and it’s exactly that green grass you see on the screenshot. Now let’s just make a quick overview of those code lines that define how particular voxel materials look and behave so you can brag about your programming skills to your girlfriend.

Every voxel material starts with the <VoxelMaterial> tag and ends with </VoxelMaterial> tag. You can refer to the “Understanding voxel material definitions” picture for a brief breakdown of the most important code definitions describing the look of a voxel material.

[[File:UpdatedVoxelmateriaDefinition.png|center]]

So first things first, you have to know that the grass you see in a screenshot consists of the Grass Voxel Material (Ground) and a set of different Grass Textures “growing” out of it and scattered randomly on it. So you will be creating/tweaking the textures for the both, because normally you don’t want blue grass to grow on a green surface, right? You do? Shut up, marine! You’re in the army now, son. Just do what you’ve been told to do, and we’ll do the thinking! Let’s start with the Surface definitions first and then continue on to the Grass itself.

==Understanding what Voxel Material (ground) is made of==
Basically, the following three lines define how our base Voxel Material’s surface will look, or to be more precise - which textures it will use to define this look.
<pre> <ColorMetalXZnY>Textures\Voxels\Grass_cm.dds</ColorMetalXZnY>
<NormalGlossXZnY>Textures\Voxels\Grass_ng.dds</NormalGlossXZnY>
<ExtXZnY>Textures\Voxels\Grass_add.dds</ExtXZnY> </pre>

Here’s what these code lines do:
<pre><ColorMetalXZnY>Textures\Voxels\Grass_cm.dds</ColorMetalXZnY></pre>
: Your Color+Metalness texture goes here. The letters “cm” in the “Grass_cm.dds” file stand for Color and Metalness. Color (or a diffuse/albedo map) is a standard RGB channel and Metalness is placed in the Alpha channel. You can go completely crazy in RGB colors. Do whatever you want. Metalness is a Black and White map only (normally NO grey halftones) which represents areas that are Metal only. You wouldn’t want to have metalness in your grass, would you? So that’s why it’s empty now (black).

[[File:Voxels 3-2.jpg|center]]

<pre><NormalGlossXZnY>Textures\Voxels\Grass_ng.dds</NormalGlossXZnY></pre>
: Your Normals+Glossiness texture goes here. The letters “ng” in the “Grass_ng.dds” file stand for Normal and Glossiness. Normal map is a standard RGB channels and the Glossiness map is placed in Alpha channel. As you can see here, the normal map resides on all RGB channels and we have subtle glossy areas (Black means NO Glossiness. White: 100% glossiness) scattered all around the grass surface.

[[File:Voxels 3-3.jpg|center]]

<pre><ExtXZnY>Textures\Voxels\Green_add.dds</ExtXZnY></pre>
: Your AO+ Emissivity+Dirt texture goes here. The letters “add” in the ”Grass_add.dds” file stand for Ambient Occlusion map, Emissivity map and Dirt map. Everything’s simple: AO goes to the Red channel, Emissivity goes in the Green channel and Dirt map goes to the Blue channel. In this particular example we see that currently we have a very subtle AO map (White areas mean no AO), no emissivity at all - because we don’t want our grass to glow in the dark (Black means no emissivity) and it has no dirt (White means NO Dirt).

[[File:Voxels 3-4.jpg|center]]

Now just open the first “Grass_cm.dds” texture in Photoshop and add a Hue/Saturation adjustment layer on top. Tick Colorize and make the color crazy Blue.

[[File:Voxels 3-5.jpg|center]]

Now just re-save this file as “GrassBlue_cm.dds” in the correct folder: (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Voxels). And of course we have to change the name in the VoxelMaterials.sbc file’s definitions, too, so the Engine knows which file to use instead of the old (green) one:

[[File:Voxels 3-6.jpg|center]]

Important note:
All textures must be saved in DDS format, DXT5, Interpolated Alpha format with “Generate MIP maps” ON.

[[File:Voxels 3-7.jpg|center]]

If you load the game now to see what happened to the grass, you will see that we’ve changed the color of the Grass Voxel Material (surface) only, while the Grass Plates which grow on it remain green. What the..?

[[File:Voxels 3-8.jpg|center|1200px]]

That’s because we didn’t change the Grass textures yet. We’ll do this in a minute, no worries.

Also, you may notice that if you move far enough from the surface, suddenly, instead of blue color – the old green starts to fade in. But didn’t we change it?! Time to panic right?

[[File:Voxels 3-9.jpg|center|1200px]]

Wrong! Those green textures that you see in the far distance are actually Far1 and Far2 textures, with Far3 Color at its farthest end. I said calm down, son, this is an order! We will talk about it in a minute! Don’t worry, we got you covered!

==Far textures==
Now that we got acquainted with “cm”, “ng” and “add” files, and know what they’re doing, it is time to speak of Far textures and their meaning in our lives. Briefly - the beautiful green grass field seen from the height of human eyes and the same field seen from the outer space will not look the same, obviously. While standing on it, you’re able to see all the details, even individual grass blades and flowers here and there, but when you’re in outer space and looking down on it from orbit - the base green color will mostly remain, but it’s color pattern and relief will change significantly. So it’s apparent that we have to substitute the base grass material seen from eye-height for one that might look like it's seen from outer space. Also, we have to “tell” the render engine at which particular distances it should load our Far Textures, and how big in scale they should be to represent the desired look. Here’s a picture so you can have an idea of how it currently looks.

[[File:Voxels 4-1.jpg|center|1200px]]

As you can see, Far1 and Far2 textures are represented by the same naming convention - “cm”, “ng” and “add” files. The Far3 Color, as Captain Obvious states, is defined by the RGB Color values only. It’s because when you too far away from the surface - having a simple color is more than enough.

[[File:Voxels 4-2.jpg|center]]

So please open the Far1 color+metalness texture file “EarthGreenGrass_Far1_cm.dds” in Photoshop, and add a simple Hue/Saturation adjustment layer on top. Change the Hue/ Saturation values so it looks bluish enough (or any other color you like). Do the same with Far2 color+metalness texture file “EarthGreenGrass_Far2_cm.dds”. Now you have completely blue Far1 and Farf2 textures. That’s exactly what we want. Finally, it’s time to change the Far3 Color which will be loaded at extremely far distances and which is still green. But we will change it in a sec.

[[File:Voxels 4-3.jpg|center|1200px]]

To choose the correct Far3 color to seamlessly blend with the Far2 Texture, you must first get rid of anything like fog or normal map effects that might get in the way and reduce the accuracy of color adjustments. So it’s better to choose your Far3 color with only the Base Color channel turned on (see the picture). To do so, hit F12 -> Render button –> tick the Render Debug checkbox –> tick the Base color in a newly opened Render Debug window.

Then hit F12 and then click the “Game” button. Tick the “Voxel Materials” checkbox and the Voxel Materials debug window will pop up on the right side with the drop down list where you can select any existing voxel materials in your world and adjust them.

[[File:Voxels 4-4.jpg|center|1200px]]

Holding “Alt” (you need to keep holding “Alt” while you operate in this window), select “Grass” material from the dropdown list and start adjusting the color with these three RGB sliders. We can get a good result with R-0, G-5 and B-25, as this color blends perfectly with other Far textures. But first we have to convert these RGB values to XYZ values before we paste them into the code.

[[File:Voxels 4-5.jpg|center]]

To find your X,Y and Z values simply divide each of your RGB values by 255. By dividing 0/255, 5/255 and 25/255 you get X-0, Y-0.02 and Z-0.10 respectively. Cool! Now just update the old XYZ values with these new ones in the code and load the game! You should see something similar to this.

[[File:Voxels 4-6.jpg|center|1200px]]

Also, the Voxel Materials debug window is convenient for interactive in-game adjustment of Far Textures’ Distance and Scale values. You can adjust the corresponding Far1 and Far2 Distance and Scale sliders, and you can set Far 3 RGB colors and see changes immediately, which is a lot better than guessing the correct numbers in the code. After you find the desired values for everything related to Far textures, you just copy those values to the definitions in the code. Very convenient, isn’t it?

Now about Distance and Scale definitions in the code. So, the following lines in the code:
<pre>
<Far1Distance>30</Far1Distance>
<Far2Distance>500</Far2Distance>
<Far3Distance>5000</Far2Distance>
</pre>
literally mean that the Far1 texture is seen at distances greater than 30 meters, the Far2 texture is seen on a distances greater than 500 meters, and finally the Far3 color is seen at distances greater than 5000 meters. It’s that simple. The following lines:
<pre>
<Far1Scale>200</Far1Scale>
<Far2Scale>1000</Far2Scale>
</pre>
define the scale (in meters) for the Far 1 and Far2 textures.

==Understanding what Grass is made of (Grass Plates)==
Below you can see all the grass textures our green grass consists of. It consists of 7 (seven) different grass plates (each with it’s own set of “cm” and “ng” files). Note that <Color></Color> tags are for “cm” files, and <Normal></Normal> tags are for “ng” files. Here they are:

[[File:Voxels 5-1.jpg|center]]

And that’s how their channels look in Photoshop:

[[File:Voxels 5-2.jpg|center]]

[[File:Voxels 5-3.jpg|center]]

[[File:Voxels 5-4.jpg|center]]

[[File:Voxels 5-5.jpg|center]]

[[File:Voxels 5-6.jpg|center]]

[[File:Voxels 5-7.jpg|center]]

[[File:Voxels 5-8.jpg|center]]

Why there are so many of them? More grass plates mean more variation in the overall feel and color of the grass, and thus it looks more real, which is exactly what we’re after (unless you really want to make an awful type of graphics intentionally of course!) If the whole field were made up of only one type of grass texture it would be way too repetitive, boring and too uniform of course.
Now you can say, hey, but didn’t we use the Alpha channel for Metalness in all “cm” type files?! Don’t worry, your grass won’t be metallic. Yes, though the “CM” abbreviation stands for Color and Metalness in the above files, remember that for Grass Plates only (ONLY), we use Alpha channel NOT for Metalness but for Alpha Mask, to cut out th Grass’ silhouette. Pretty simple right? But for all “NG” (normal/metalness) type of files everything stays the same – you have RGB channels for Normals and Alpha channel for Glossiness.

==Changing the Grass color==
Now that we know how our Grass is made, let’s make a simple color change again - from Green to Blue. So open all 7 (seven) Grass Plate files (“Grass_01_cm.dds”, “Grass_02_cm.dds”.. etc) in Photoshop, and for each of the files, add a simple Hue/Saturation adjustment layer on top. Change the Hue/ Saturation values so it looks bluish enough (or any other color you like)

[[File:Voxels 6-1.jpg|center]]

and then let’s re-save it as “GrassBlue_01_cm.dds” in the same folder (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Models\Environment\Grass). Please note that it’s different from the folder where you put your textures for the Voxel Surface materials. Repeat the same procedure for the rest of the "cm" textures (“GrassBlue_02_cm.dds” etc.) Then we go back into the code of VoxelMaterials.sbc and change the names of all 7 grass textures “Grass_01_cm.dds” etc. to “GrassBlue_01_cm.dds” which we’ve just created. You should end up with the following:

[[File:Voxels 6-2.jpg|center]]

Restart the game, or just reload the save and Voila. You have this crazy blue-colored grass. I wouldn’t step on it barefoot, to be honest. You never know who may live in the blue grass. You never know :)
[[File:Voxels 6-3.jpg|center|1200px]]

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding/Voxel Materials

2017-05-05T13:01:25Z

Lukas: /* Understanding what Voxel Material (ground) is made of */

Hello and welcome to the Modding of Voxel Materials guide for young Padawans. Feeling creative about changing the look of voxel materials? You think you’re really good, huh? Well, you’re in the right place then. Be prepared for a great journey saving the world by changing the look of the voxel worlds around you. Let’s just assume that you want to change the color of this beautiful green grass which grows on every EarthLike planet in the SE Universe! And let’s assume you want to change it to a crazy blue color. Why? Because we CAN, and you can too! Call NOW and get your free training program PLUS an amazing set of kitchen knives... wait... I meant something completely different...

[[File:UpdatedVoxelmateriaDefinition.png|center|1200px]]

==Source Files==
Various files will be used as examples in this guide.<br/>
They can be downloaded here: http://www.medievalengineerswiki.com/uploaded_files/Voxel_material_modding_files.zip

==Voxel material definitions==
Ok, so to start - all voxel materials definitions are stored in the VoxelMaterials.sbc file. Find it and open it in MS Visual Studio or any other advanced text editor. Search for the following line in the code:

<pre><SubtypeId>Grass</SubtypeId></pre>

That’s where all the fun begins! So “Grass” is the name of the voxel material we’re looking for. It’s exactly how it is called in the game, and it’s exactly that green grass you see on the screenshot. Now let’s just make a quick overview of those code lines that define how particular voxel materials look and behave so you can brag about your programming skills to your girlfriend.

Every voxel material starts with the <VoxelMaterial> tag and ends with </VoxelMaterial> tag. You can refer to the “Understanding voxel material definitions” picture for a brief breakdown of the most important code definitions describing the look of a voxel material.

[[File:Voxels 2-1.jpg|center]]

So first things first, you have to know that the grass you see in a screenshot consists of the Grass Voxel Material (Ground) and a set of different Grass Textures “growing” out of it and scattered randomly on it. So you will be creating/tweaking the textures for the both, because normally you don’t want blue grass to grow on a green surface, right? You do? Shut up, marine! You’re in the army now, son. Just do what you’ve been told to do, and we’ll do the thinking! Let’s start with the Surface definitions first and then continue on to the Grass itself.

==Understanding what Voxel Material (ground) is made of==
Basically, the following three lines define how our base Voxel Material’s surface will look, or to be more precise - which textures it will use to define this look.
<pre> <ColorMetalXZnY>Textures\Voxels\Grass_cm.dds</ColorMetalXZnY>
<NormalGlossXZnY>Textures\Voxels\Grass_ng.dds</NormalGlossXZnY>
<ExtXZnY>Textures\Voxels\Grass_add.dds</ExtXZnY> </pre>

Here’s what these code lines do:
<pre><ColorMetalXZnY>Textures\Voxels\Grass_cm.dds</ColorMetalXZnY></pre>
: Your Color+Metalness texture goes here. The letters “cm” in the “Grass_cm.dds” file stand for Color and Metalness. Color (or a diffuse/albedo map) is a standard RGB channel and Metalness is placed in the Alpha channel. You can go completely crazy in RGB colors. Do whatever you want. Metalness is a Black and White map only (normally NO grey halftones) which represents areas that are Metal only. You wouldn’t want to have metalness in your grass, would you? So that’s why it’s empty now (black).

[[File:Voxels 3-2.jpg|center]]

<pre><NormalGlossXZnY>Textures\Voxels\Grass_ng.dds</NormalGlossXZnY></pre>
: Your Normals+Glossiness texture goes here. The letters “ng” in the “Grass_ng.dds” file stand for Normal and Glossiness. Normal map is a standard RGB channels and the Glossiness map is placed in Alpha channel. As you can see here, the normal map resides on all RGB channels and we have subtle glossy areas (Black means NO Glossiness. White: 100% glossiness) scattered all around the grass surface.

[[File:Voxels 3-3.jpg|center]]

<pre><ExtXZnY>Textures\Voxels\Green_add.dds</ExtXZnY></pre>
: Your AO+ Emissivity+Dirt texture goes here. The letters “add” in the ”Grass_add.dds” file stand for Ambient Occlusion map, Emissivity map and Dirt map. Everything’s simple: AO goes to the Red channel, Emissivity goes in the Green channel and Dirt map goes to the Blue channel. In this particular example we see that currently we have a very subtle AO map (White areas mean no AO), no emissivity at all - because we don’t want our grass to glow in the dark (Black means no emissivity) and it has no dirt (White means NO Dirt).

[[File:Voxels 3-4.jpg|center]]

Now just open the first “Grass_cm.dds” texture in Photoshop and add a Hue/Saturation adjustment layer on top. Tick Colorize and make the color crazy Blue.

[[File:Voxels 3-5.jpg|center]]

Now just re-save this file as “GrassBlue_cm.dds” in the correct folder: (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Voxels). And of course we have to change the name in the VoxelMaterials.sbc file’s definitions, too, so the Engine knows which file to use instead of the old (green) one:

[[File:Voxels 3-6.jpg|center]]

Important note:
All textures must be saved in DDS format, DXT5, Interpolated Alpha format with “Generate MIP maps” ON.

[[File:Voxels 3-7.jpg|center]]

If you load the game now to see what happened to the grass, you will see that we’ve changed the color of the Grass Voxel Material (surface) only, while the Grass Plates which grow on it remain green. What the..?

[[File:Voxels 3-8.jpg|center|1200px]]

That’s because we didn’t change the Grass textures yet. We’ll do this in a minute, no worries.

Also, you may notice that if you move far enough from the surface, suddenly, instead of blue color – the old green starts to fade in. But didn’t we change it?! Time to panic right?

[[File:Voxels 3-9.jpg|center|1200px]]

Wrong! Those green textures that you see in the far distance are actually Far1 and Far2 textures, with Far3 Color at its farthest end. I said calm down, son, this is an order! We will talk about it in a minute! Don’t worry, we got you covered!

==Far textures==
Now that we got acquainted with “cm”, “ng” and “add” files, and know what they’re doing, it is time to speak of Far textures and their meaning in our lives. Briefly - the beautiful green grass field seen from the height of human eyes and the same field seen from the outer space will not look the same, obviously. While standing on it, you’re able to see all the details, even individual grass blades and flowers here and there, but when you’re in outer space and looking down on it from orbit - the base green color will mostly remain, but it’s color pattern and relief will change significantly. So it’s apparent that we have to substitute the base grass material seen from eye-height for one that might look like it's seen from outer space. Also, we have to “tell” the render engine at which particular distances it should load our Far Textures, and how big in scale they should be to represent the desired look. Here’s a picture so you can have an idea of how it currently looks.

[[File:Voxels 4-1.jpg|center|1200px]]

As you can see, Far1 and Far2 textures are represented by the same naming convention - “cm”, “ng” and “add” files. The Far3 Color, as Captain Obvious states, is defined by the RGB Color values only. It’s because when you too far away from the surface - having a simple color is more than enough.

[[File:Voxels 4-2.jpg|center]]

So please open the Far1 color+metalness texture file “EarthGreenGrass_Far1_cm.dds” in Photoshop, and add a simple Hue/Saturation adjustment layer on top. Change the Hue/ Saturation values so it looks bluish enough (or any other color you like). Do the same with Far2 color+metalness texture file “EarthGreenGrass_Far2_cm.dds”. Now you have completely blue Far1 and Farf2 textures. That’s exactly what we want. Finally, it’s time to change the Far3 Color which will be loaded at extremely far distances and which is still green. But we will change it in a sec.

[[File:Voxels 4-3.jpg|center|1200px]]

To choose the correct Far3 color to seamlessly blend with the Far2 Texture, you must first get rid of anything like fog or normal map effects that might get in the way and reduce the accuracy of color adjustments. So it’s better to choose your Far3 color with only the Base Color channel turned on (see the picture). To do so, hit F12 -> Render button –> tick the Render Debug checkbox –> tick the Base color in a newly opened Render Debug window.

Then hit F12 and then click the “Game” button. Tick the “Voxel Materials” checkbox and the Voxel Materials debug window will pop up on the right side with the drop down list where you can select any existing voxel materials in your world and adjust them.

[[File:Voxels 4-4.jpg|center|1200px]]

Holding “Alt” (you need to keep holding “Alt” while you operate in this window), select “Grass” material from the dropdown list and start adjusting the color with these three RGB sliders. We can get a good result with R-0, G-5 and B-25, as this color blends perfectly with other Far textures. But first we have to convert these RGB values to XYZ values before we paste them into the code.

[[File:Voxels 4-5.jpg|center]]

To find your X,Y and Z values simply divide each of your RGB values by 255. By dividing 0/255, 5/255 and 25/255 you get X-0, Y-0.02 and Z-0.10 respectively. Cool! Now just update the old XYZ values with these new ones in the code and load the game! You should see something similar to this.

[[File:Voxels 4-6.jpg|center|1200px]]

Also, the Voxel Materials debug window is convenient for interactive in-game adjustment of Far Textures’ Distance and Scale values. You can adjust the corresponding Far1 and Far2 Distance and Scale sliders, and you can set Far 3 RGB colors and see changes immediately, which is a lot better than guessing the correct numbers in the code. After you find the desired values for everything related to Far textures, you just copy those values to the definitions in the code. Very convenient, isn’t it?

Now about Distance and Scale definitions in the code. So, the following lines in the code:
<pre>
<Far1Distance>30</Far1Distance>
<Far2Distance>500</Far2Distance>
<Far3Distance>5000</Far2Distance>
</pre>
literally mean that the Far1 texture is seen at distances greater than 30 meters, the Far2 texture is seen on a distances greater than 500 meters, and finally the Far3 color is seen at distances greater than 5000 meters. It’s that simple. The following lines:
<pre>
<Far1Scale>200</Far1Scale>
<Far2Scale>1000</Far2Scale>
</pre>
define the scale (in meters) for the Far 1 and Far2 textures.

==Understanding what Grass is made of (Grass Plates)==
Below you can see all the grass textures our green grass consists of. It consists of 7 (seven) different grass plates (each with it’s own set of “cm” and “ng” files). Note that <Color></Color> tags are for “cm” files, and <Normal></Normal> tags are for “ng” files. Here they are:

[[File:Voxels 5-1.jpg|center]]

And that’s how their channels look in Photoshop:

[[File:Voxels 5-2.jpg|center]]

[[File:Voxels 5-3.jpg|center]]

[[File:Voxels 5-4.jpg|center]]

[[File:Voxels 5-5.jpg|center]]

[[File:Voxels 5-6.jpg|center]]

[[File:Voxels 5-7.jpg|center]]

[[File:Voxels 5-8.jpg|center]]

Why there are so many of them? More grass plates mean more variation in the overall feel and color of the grass, and thus it looks more real, which is exactly what we’re after (unless you really want to make an awful type of graphics intentionally of course!) If the whole field were made up of only one type of grass texture it would be way too repetitive, boring and too uniform of course.
Now you can say, hey, but didn’t we use the Alpha channel for Metalness in all “cm” type files?! Don’t worry, your grass won’t be metallic. Yes, though the “CM” abbreviation stands for Color and Metalness in the above files, remember that for Grass Plates only (ONLY), we use Alpha channel NOT for Metalness but for Alpha Mask, to cut out th Grass’ silhouette. Pretty simple right? But for all “NG” (normal/metalness) type of files everything stays the same – you have RGB channels for Normals and Alpha channel for Glossiness.

==Changing the Grass color==
Now that we know how our Grass is made, let’s make a simple color change again - from Green to Blue. So open all 7 (seven) Grass Plate files (“Grass_01_cm.dds”, “Grass_02_cm.dds”.. etc) in Photoshop, and for each of the files, add a simple Hue/Saturation adjustment layer on top. Change the Hue/ Saturation values so it looks bluish enough (or any other color you like)

[[File:Voxels 6-1.jpg|center]]

and then let’s re-save it as “GrassBlue_01_cm.dds” in the same folder (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Models\Environment\Grass). Please note that it’s different from the folder where you put your textures for the Voxel Surface materials. Repeat the same procedure for the rest of the "cm" textures (“GrassBlue_02_cm.dds” etc.) Then we go back into the code of VoxelMaterials.sbc and change the names of all 7 grass textures “Grass_01_cm.dds” etc. to “GrassBlue_01_cm.dds” which we’ve just created. You should end up with the following:

[[File:Voxels 6-2.jpg|center]]

Restart the game, or just reload the save and Voila. You have this crazy blue-colored grass. I wouldn’t step on it barefoot, to be honest. You never know who may live in the blue grass. You never know :)
[[File:Voxels 6-3.jpg|center|1200px]]

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding/Voxel Materials

2017-05-05T13:00:06Z

Lukas:

Hello and welcome to the Modding of Voxel Materials guide for young Padawans. Feeling creative about changing the look of voxel materials? You think you’re really good, huh? Well, you’re in the right place then. Be prepared for a great journey saving the world by changing the look of the voxel worlds around you. Let’s just assume that you want to change the color of this beautiful green grass which grows on every EarthLike planet in the SE Universe! And let’s assume you want to change it to a crazy blue color. Why? Because we CAN, and you can too! Call NOW and get your free training program PLUS an amazing set of kitchen knives... wait... I meant something completely different...

[[File:UpdatedVoxelmateriaDefinition.png|center|1200px]]

==Source Files==
Various files will be used as examples in this guide.<br/>
They can be downloaded here: http://www.medievalengineerswiki.com/uploaded_files/Voxel_material_modding_files.zip

==Voxel material definitions==
Ok, so to start - all voxel materials definitions are stored in the VoxelMaterials.sbc file. Find it and open it in MS Visual Studio or any other advanced text editor. Search for the following line in the code:

<pre><SubtypeId>Grass</SubtypeId></pre>

That’s where all the fun begins! So “Grass” is the name of the voxel material we’re looking for. It’s exactly how it is called in the game, and it’s exactly that green grass you see on the screenshot. Now let’s just make a quick overview of those code lines that define how particular voxel materials look and behave so you can brag about your programming skills to your girlfriend.

Every voxel material starts with the <VoxelMaterial> tag and ends with </VoxelMaterial> tag. You can refer to the “Understanding voxel material definitions” picture for a brief breakdown of the most important code definitions describing the look of a voxel material.

[[File:Voxels 2-1.jpg|center]]

So first things first, you have to know that the grass you see in a screenshot consists of the Grass Voxel Material (Ground) and a set of different Grass Textures “growing” out of it and scattered randomly on it. So you will be creating/tweaking the textures for the both, because normally you don’t want blue grass to grow on a green surface, right? You do? Shut up, marine! You’re in the army now, son. Just do what you’ve been told to do, and we’ll do the thinking! Let’s start with the Surface definitions first and then continue on to the Grass itself.

==Understanding what Voxel Material (ground) is made of==
Basically, the following three lines define how our base Voxel Material’s surface will look, or to be more precise - which textures it will use to define this look.

[[File:Voxels 3-1.jpg|center]]

Here’s what these code lines do:
<pre><ColorMetalXZnY>Textures\Voxels\Grass_cm.dds</ColorMetalXZnY></pre>
: Your Color+Metalness texture goes here. The letters “cm” in the “Grass_cm.dds” file stand for Color and Metalness. Color (or a diffuse/albedo map) is a standard RGB channel and Metalness is placed in the Alpha channel. You can go completely crazy in RGB colors. Do whatever you want. Metalness is a Black and White map only (normally NO grey halftones) which represents areas that are Metal only. You wouldn’t want to have metalness in your grass, would you? So that’s why it’s empty now (black).

[[File:Voxels 3-2.jpg|center]]

<pre><NormalGlossXZnY>Textures\Voxels\Grass_ng.dds</NormalGlossXZnY></pre>
: Your Normals+Glossiness texture goes here. The letters “ng” in the “Grass_ng.dds” file stand for Normal and Glossiness. Normal map is a standard RGB channels and the Glossiness map is placed in Alpha channel. As you can see here, the normal map resides on all RGB channels and we have subtle glossy areas (Black means NO Glossiness. White: 100% glossiness) scattered all around the grass surface.

[[File:Voxels 3-3.jpg|center]]

<pre><ExtXZnY>Textures\Voxels\Green_add.dds</ExtXZnY></pre>
: Your AO+ Emissivity+Dirt texture goes here. The letters “add” in the ”Grass_add.dds” file stand for Ambient Occlusion map, Emissivity map and Dirt map. Everything’s simple: AO goes to the Red channel, Emissivity goes in the Green channel and Dirt map goes to the Blue channel. In this particular example we see that currently we have a very subtle AO map (White areas mean no AO), no emissivity at all - because we don’t want our grass to glow in the dark (Black means no emissivity) and it has no dirt (White means NO Dirt).

[[File:Voxels 3-4.jpg|center]]

Now just open the first “Grass_cm.dds” texture in Photoshop and add a Hue/Saturation adjustment layer on top. Tick Colorize and make the color crazy Blue.

[[File:Voxels 3-5.jpg|center]]

Now just re-save this file as “GrassBlue_cm.dds” in the correct folder: (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Voxels). And of course we have to change the name in the VoxelMaterials.sbc file’s definitions, too, so the Engine knows which file to use instead of the old (green) one:

[[File:Voxels 3-6.jpg|center]]

Important note:
All textures must be saved in DDS format, DXT5, Interpolated Alpha format with “Generate MIP maps” ON.

[[File:Voxels 3-7.jpg|center]]

If you load the game now to see what happened to the grass, you will see that we’ve changed the color of the Grass Voxel Material (surface) only, while the Grass Plates which grow on it remain green. What the..?

[[File:Voxels 3-8.jpg|center|1200px]]

That’s because we didn’t change the Grass textures yet. We’ll do this in a minute, no worries.

Also, you may notice that if you move far enough from the surface, suddenly, instead of blue color – the old green starts to fade in. But didn’t we change it?! Time to panic right?

[[File:Voxels 3-9.jpg|center|1200px]]

Wrong! Those green textures that you see in the far distance are actually Far1 and Far2 textures, with Far3 Color at its farthest end. I said calm down, son, this is an order! We will talk about it in a minute! Don’t worry, we got you covered!

==Far textures==
Now that we got acquainted with “cm”, “ng” and “add” files, and know what they’re doing, it is time to speak of Far textures and their meaning in our lives. Briefly - the beautiful green grass field seen from the height of human eyes and the same field seen from the outer space will not look the same, obviously. While standing on it, you’re able to see all the details, even individual grass blades and flowers here and there, but when you’re in outer space and looking down on it from orbit - the base green color will mostly remain, but it’s color pattern and relief will change significantly. So it’s apparent that we have to substitute the base grass material seen from eye-height for one that might look like it's seen from outer space. Also, we have to “tell” the render engine at which particular distances it should load our Far Textures, and how big in scale they should be to represent the desired look. Here’s a picture so you can have an idea of how it currently looks.

[[File:Voxels 4-1.jpg|center|1200px]]

As you can see, Far1 and Far2 textures are represented by the same naming convention - “cm”, “ng” and “add” files. The Far3 Color, as Captain Obvious states, is defined by the RGB Color values only. It’s because when you too far away from the surface - having a simple color is more than enough.

[[File:Voxels 4-2.jpg|center]]

So please open the Far1 color+metalness texture file “EarthGreenGrass_Far1_cm.dds” in Photoshop, and add a simple Hue/Saturation adjustment layer on top. Change the Hue/ Saturation values so it looks bluish enough (or any other color you like). Do the same with Far2 color+metalness texture file “EarthGreenGrass_Far2_cm.dds”. Now you have completely blue Far1 and Farf2 textures. That’s exactly what we want. Finally, it’s time to change the Far3 Color which will be loaded at extremely far distances and which is still green. But we will change it in a sec.

[[File:Voxels 4-3.jpg|center|1200px]]

To choose the correct Far3 color to seamlessly blend with the Far2 Texture, you must first get rid of anything like fog or normal map effects that might get in the way and reduce the accuracy of color adjustments. So it’s better to choose your Far3 color with only the Base Color channel turned on (see the picture). To do so, hit F12 -> Render button –> tick the Render Debug checkbox –> tick the Base color in a newly opened Render Debug window.

Then hit F12 and then click the “Game” button. Tick the “Voxel Materials” checkbox and the Voxel Materials debug window will pop up on the right side with the drop down list where you can select any existing voxel materials in your world and adjust them.

[[File:Voxels 4-4.jpg|center|1200px]]

Holding “Alt” (you need to keep holding “Alt” while you operate in this window), select “Grass” material from the dropdown list and start adjusting the color with these three RGB sliders. We can get a good result with R-0, G-5 and B-25, as this color blends perfectly with other Far textures. But first we have to convert these RGB values to XYZ values before we paste them into the code.

[[File:Voxels 4-5.jpg|center]]

To find your X,Y and Z values simply divide each of your RGB values by 255. By dividing 0/255, 5/255 and 25/255 you get X-0, Y-0.02 and Z-0.10 respectively. Cool! Now just update the old XYZ values with these new ones in the code and load the game! You should see something similar to this.

[[File:Voxels 4-6.jpg|center|1200px]]

Also, the Voxel Materials debug window is convenient for interactive in-game adjustment of Far Textures’ Distance and Scale values. You can adjust the corresponding Far1 and Far2 Distance and Scale sliders, and you can set Far 3 RGB colors and see changes immediately, which is a lot better than guessing the correct numbers in the code. After you find the desired values for everything related to Far textures, you just copy those values to the definitions in the code. Very convenient, isn’t it?

Now about Distance and Scale definitions in the code. So, the following lines in the code:
<pre>
<Far1Distance>30</Far1Distance>
<Far2Distance>500</Far2Distance>
<Far3Distance>5000</Far2Distance>
</pre>
literally mean that the Far1 texture is seen at distances greater than 30 meters, the Far2 texture is seen on a distances greater than 500 meters, and finally the Far3 color is seen at distances greater than 5000 meters. It’s that simple. The following lines:
<pre>
<Far1Scale>200</Far1Scale>
<Far2Scale>1000</Far2Scale>
</pre>
define the scale (in meters) for the Far 1 and Far2 textures.

==Understanding what Grass is made of (Grass Plates)==
Below you can see all the grass textures our green grass consists of. It consists of 7 (seven) different grass plates (each with it’s own set of “cm” and “ng” files). Note that <Color></Color> tags are for “cm” files, and <Normal></Normal> tags are for “ng” files. Here they are:

[[File:Voxels 5-1.jpg|center]]

And that’s how their channels look in Photoshop:

[[File:Voxels 5-2.jpg|center]]

[[File:Voxels 5-3.jpg|center]]

[[File:Voxels 5-4.jpg|center]]

[[File:Voxels 5-5.jpg|center]]

[[File:Voxels 5-6.jpg|center]]

[[File:Voxels 5-7.jpg|center]]

[[File:Voxels 5-8.jpg|center]]

Why there are so many of them? More grass plates mean more variation in the overall feel and color of the grass, and thus it looks more real, which is exactly what we’re after (unless you really want to make an awful type of graphics intentionally of course!) If the whole field were made up of only one type of grass texture it would be way too repetitive, boring and too uniform of course.
Now you can say, hey, but didn’t we use the Alpha channel for Metalness in all “cm” type files?! Don’t worry, your grass won’t be metallic. Yes, though the “CM” abbreviation stands for Color and Metalness in the above files, remember that for Grass Plates only (ONLY), we use Alpha channel NOT for Metalness but for Alpha Mask, to cut out th Grass’ silhouette. Pretty simple right? But for all “NG” (normal/metalness) type of files everything stays the same – you have RGB channels for Normals and Alpha channel for Glossiness.

==Changing the Grass color==
Now that we know how our Grass is made, let’s make a simple color change again - from Green to Blue. So open all 7 (seven) Grass Plate files (“Grass_01_cm.dds”, “Grass_02_cm.dds”.. etc) in Photoshop, and for each of the files, add a simple Hue/Saturation adjustment layer on top. Change the Hue/ Saturation values so it looks bluish enough (or any other color you like)

[[File:Voxels 6-1.jpg|center]]

and then let’s re-save it as “GrassBlue_01_cm.dds” in the same folder (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Models\Environment\Grass). Please note that it’s different from the folder where you put your textures for the Voxel Surface materials. Repeat the same procedure for the rest of the "cm" textures (“GrassBlue_02_cm.dds” etc.) Then we go back into the code of VoxelMaterials.sbc and change the names of all 7 grass textures “Grass_01_cm.dds” etc. to “GrassBlue_01_cm.dds” which we’ve just created. You should end up with the following:

[[File:Voxels 6-2.jpg|center]]

Restart the game, or just reload the save and Voila. You have this crazy blue-colored grass. I wouldn’t step on it barefoot, to be honest. You never know who may live in the blue grass. You never know :)
[[File:Voxels 6-3.jpg|center|1200px]]

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding - Full Guide

2017-05-05T12:53:07Z

Lukas: Reverted edits by Lukas (talk) to last revision by CptTwinkie

==Introduction==
Hello fellow Medieval Engineers!
I would like to present you with a guide that will help you understand how we created planets at Keen Software House and how to mod your own into the game.
Feel free to use/alter company owned files for your Medieval Engineers mods.

So let's get to modding!

==Recommended Software==
# Microsoft Visual Studio - or Notepad++ (Link[notepad-plus-plus.org]) - for opening files with .sbc extension where we have definitions for every feature in the game.
# Adobe Photoshop - for editing material and heightmap textures
# World Machine Professional - for heightmap easier creation (much more realistic looking terrain, without manual work)

(Basic Edition is also available, but the max resolution output is limited to 512x512 pixels)
http://www.world-machine.com

===Advice===
We would like to mention one thing before you get into modding planets:
For your own sake we recommend you to load either PlanetTemplate or EarthLikeModExample and test/edit all the things there, so you get to know the system and how everything works.

After that you can create your own from scratch. This is entirely up to you.

==General modding principles - how to make any mod==
I will explain again basic principles of how mods are applied.

All of our vanilla source files are all saved in a folder called content in your *game folder. If no mods are assigned to a world that you are loading, game uses only files from this content folder but if there are mods, game loads also files from mod adding more content or potentially rewriting vanilla content based on content of the mod’s folder. Mod is nothing else but a folder with another files.
Mod files are stored in mods folder on your computer , and if you are using them for the first time, they are downloaded from workshop first time you try to load/connect to a world with those mods.
Mod folder: C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Mods
===Opening mod and examining mods content===
When you open Mods folder, you will see mods as files with .sbm extension. But they are really just folders and to examine them, all you have to do is rewrite the extension from .sbm to .rar and then you can open them with rar and examine content.
Mods are not listed with their names, but with their steam id number. To find specific mod, you have to go to the mods workshop page

Examining other mods similar to your idea is a fast way to learn.
Example:

<NoWiki>*</NoWiki>By default this is SteamLibrary\steamapps\common\MedievalEngineers\Content. You can also get there if you go to steam library(same place where you start the game), right-click Medieval Engineers, select properties, local files and finally click on “browse local files”.
==Materials modding==
In case you are thinking about making your own trees and voxel materials, we have some good news for you!

There are two separate guides that you can follow to make your own stuff.

General modding guide - get started

===Voxel material modding===
[[Official Content/Voxel Materials modding|Voxel Material modding]]

==Planet Size==
Planet size is defined in a scenarios.sbc. Every time you click on create new world in the game it uses scenario definition to create a new safe file. Although this scenario definition is not moddable, you can still use it to create a world and share the world itself on the workshop.

First go to where you have Medieval Engineers source files and find Data folder (SteamLibrary\steamapps\common\MedievalEngineers\Content\Data\Scenarios.sbx)

==All planet related files overview and where to find them==
To summarize how planet modding in ME works, we can say this:
We use 2 types of textures and then we define how the game should interpret those textures in definitions. One texture is heightmap that is used just for generating terrain shape, another one is used to place everything else on the planet (ores, trees and plants, bots).
[[File:Diagram.png|1024px|center]]

==Material Texture modding==
Material texture is used to store information about location of various planet surface features. These features are surface materials, biomes (trees, bots, plants,..etc) and where you can find ore. Each one of these uses one color channel. Surface materials use red channel. Biomes use green. Ores are in blue channel.
We use 6 material textures (2048x2048) for each planet. You can find all our material textures here: Content\Data\PlanetDataFiles.
Each planet has its own folder. The folder has to have the same name as the planet.

[[File:MaterialMapBreakdown.jpg|512px]]

Illustration of how are the material textures connected to each other:

[[File:Planet Material Texture Order.jpg|512px]]

====The process of material texture creation is really simple. You have two options:====
=====Copy an existing map to your folder and overwrite the green channel and edit them to your liking=====
This is highly recommended to avoid errors!
=====Create a new: step by step in Photoshop=====
#Set both width and height to 2048 pixels
#(for smaller planets this can also be 1024 or less, but all textures need to have the same resolution! Even the heightmap)
#Set resolution - Pixels/Inch to 72.
#Set colour mode to RGB Colour - 8bit
#Now start painting with the pencil tool on each RGB Channel separately.
#Never on all three at once! (It will F. up everything - trust me).

===Surface voxel material definitions modding - grass, sand, snow===

[[File:RedChannel.jpg|22px|frameless]]

Surface “voxel materials” refers to what you know as grass, soil, stone.. We use red channel of the material texture to set where all the terrain appears. Then you need to write definitions in the Content\Data\PlanetGenerator.sbc to tell game which voxel should appear at specific red channel value.
Example of the definition of road:
<pre>
<ComplexMaterials>
<MaterialGroup Name="Road" Value="67">
<Rule>
<Layers>
<Layer Material="Soil" Depth="2"/>
</Layers>
<Slope Min="0" Max="90"/>
</Rule>
</MaterialGroup>
</ComplexMaterials>
</pre>
Example of corresponding material texture with road:

[[File:RoadMaterialTextureExample.png|512px]]

====Complex materials====
Complex materials definition allows to paint the map with a set of “voxel coloring rules”. Meaning that one color value in red channel can color terrain with different voxels based on rules like slope, longitude or latitude and height. (So with our road example)
<pre>
<MaterialGroup Name="Forest_Grass" Value="120">
<Rule>
<Layers>
<Layer Material="Woods_grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="0" Max="25"/>
<Latitude Min="-180" Max="180"/>
<Longitude Min="-180" Max="180"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="25" Max="45"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Rocks_grass" Depth="2"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="45" Max="55"/>
</Rule>
</MaterialGroup>
</pre>
This definition says what voxels should be generated in spots, that are painted with red channel value of 120.
The rules in this definition will lead to following:
Flat lands (up to 20 degrees slope) will have Wood grass 1 m thick, soil will be right under the WoodGrass up to 5 m depth and there will be stone underneath the soil.
In places with medium slope, there is Grass instead of WoodGrass. And in slopes from 45 to 55 there is rocks grass 2 m thick with stone right away under it.
With this technology, we can make the color react on its own to terrain bumps or even position on planet. This saves lots of meticulous painting with heightmap.

<Layer Material="Woods_grass" Depth="1"/>
Material refers to voxelmaterial definition. (You can find it in Content\Data\VoxelMaterials.sbc). Depth means how deep should the material go under ground.
<Slope Min="0" Max="25"/>
Slope of the terrain in degrees.
<Latitude Min="-180" Max="180"/>
Latitude in degrees. 0 degree is an equator.
<Longitude Min="-180" Max="180"/>
Longitude in degrees. 0 is in the middle of front planetary texture. (Fareon Kingdom)

===Biomes definitions modding - trees, plants and bots===
[[File:GreenChannel.jpg|frameless|22px]]

Biomes refers to everything that is spawned on top of the planet. We use green channel of the material texture to set where all the terrain features appear and definitions in the Content\Data\Environment\ProceduralEnvironments.sbc to tell game which environment item should appear at specific green channel value. Also you need to assign Environment to planet in the Content\Data\PlanetGenerator.sbc in case you are adding a brand new planet.

====First make/modify environment:====
Go to Content\Data\Environment\ProceduralEnvironments.sbc

=====Procedural World Environment definition=====
This definition defines where will the environmental items spawn and with which density. (note: bots are also considered environmental item). Best way to explain how procedural environment is working is to imagine that it puts spots on entire surface of a planet. And when you start defining trees, bots and bushes, the spots get “reserved” by these categories based on how many of those should appear in the world according to your mod.
Spots are always different for each single planet.
In order to mod the procedural environment, mod our “Earth Environment” definition. Or create your own but if you do, don’t forget to also mod PlanetGeneratorDefinition, so that planet has your new procedura environment assigned to it.

=====Definition elements explained point by point:=====
<pre>
<Definition xsi:type="MyObjectBuilder_ProceduralWorldEnvironment">
<Id>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>Earth Environment</SubtypeId>
</Id>
</pre>
This part of definition is called ID. It says what type of definition this is <TypeID> and unique name of that definition <SubtypeID>.

<pre>
<MaxSyncLod>1</MaxSyncLod>
</pre>
This line defines how far away from player are the environmental items updating. This is important feature for optimization.

<pre>
<SectorSize>40</SectorSize>
</pre>
This is size of the environmental sector. It is a different sector than the claimable areas by players. It sets size of one environmental sector.

<pre>
<ItemsPerSqMeter>0.17</ItemsPerSqMeter>
</pre>
The line sets overall maximum density of all environmental items. To return to analogy i used in the introduction, this number increases the amount of spots on the planet that are reserved for all environmental items.

<pre>
<ScanningMethod>Random</ScanningMethod>
</pre>

<pre>
<ItemTypes Type="MyObjectBuilder_EnvironmentItemTypesDefinition" Subtype="Default"/>
</pre>
This sets which types of environmental items are used in this procedural environment definition. This guide explains what are Environmental item types in the very next section.

<ItemGroup Density=".017" Name="Bots" LodStart="1" LodEnd="1">
<Mapping>
<Material>Woods</Material>
<Item Type="Bot" Subtype="Deer"/>
</Mapping>
<Mapping>
<Biome>60</Biome>
<Height Min="0" Max"1"/>
<Latitude Min="-180" Max"180"/>
<Longitude Min="-180" Max"180"/>
<Slope Min="0" Max"1"/>
<Item Type="Bot" Subtype="Deer" Density="0.9"/>
<Item Type="Bot" Subtype="Barbarian" Density="0.1"/>
</Mapping>
</ItemGroup>
Item group is used to organize and better manage mappings. Mappings are definitions that actually add the environment items in the world. It is important to set Density correctly. Density (Density=".017") sets how many of the procedurally generated spots on the planet will be assigned to environmental items from this group. The name (Name="Bots") is only for naming purposes within definition and has no impact on the game. LodStart="1" and LodEnd="1" control how far from the player will the items appear.
<Biome>60</Biome> This section means that Items within this mapping will only appear on spaces that are painted with green channel value 60 on the material map.
<Material>Woods</Material> This means that the environmental items will only appear in the woods.
<Height Min="0" Max"1"/> Sets in which altitude should these environmental items appear. If this parameter is missing, items spawn in full range (Min="0" Max"1")
<Latitude Min="-180" Max"180"/> Sets at which latitude do the environment items spawn. If this parameter is missing, items spawn in full range (Min="-180" Max"180")
<Longitude Min="-180" Max"180"/> Sets at which longitude the environment items spawn. If this parameter is missing, items spawn in full range (Min="-180" Max"180")
<Slope Min="0" Max"90"/> Sets at which slopes the environment items spawn. If this parameter is missing, items spawn in full range (Min="0" Max"90")

<ItemGroup Density=".085" Name="Trees" LodStart="-1" LodEnd="1">...</ItemGroup>
LodStart="-1" means that the items will be visible all the time. Will not go into details about settings of this Item Group, since it more of the same.
<ItemGroup Density=".36" Name="Small Items" LodStart="0" LodEnd="0">...</ItemGroup>
</Definition>

=====Environment items=====
We learned how to assign environments to planets and how to mod environments themselves by changing densities and environment items. But we still don't know how to make the environment items themselves. Guides for those can be found on following links.

If you want to mod trees:

If you want to mod bushes and plants:

If you want to mod bots:

=====EnvironmentItemTypesDefinition=====
Here you define various types of items. Currently we have these types: Tree, Gatherable, Farmable, Static and Bot. Before you add any item, you must make sure it fits within these types of environment items or you created a new type for them.
<Definition xsi:type="MyObjectBuilder_EnvironmentItemTypesDefinition">
<Id Type="MyObjectBuilder_EnvironmentItemTypesDefinition" Subtype="Default"/>
<Item Name="Tree">...</Item>
<Item Name="Gatherable">...</Item>
<Item Name="Farmable">... </Item>
<Item Name="Static">...</Item>
<Item Name="Bot">...</Item>
</Definition>

EnvironmentItemTypes
<Item Name="Tree">
<ProxyActivationLod>0</ProxyActivationLod>
<Provider Type="MyObjectBuilder_ProceduralEnvironmentModuleDefinition" Subtype="Growable"/>
<Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Gatherable" />
<Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Cuttable" />
</Item>
Available proxy and providers:
Proxy Subtype="Gatherable"
This line adds ability to all environmental items of this type to use action “Gatherable”. Keep in mind that the tree itself has to be setup properly in order for this to work.
Proxy Subtype="Cuttable" />
This line adds ability to all environmental items of this type to use action “Cuttable”. Keep in mind that the tree itself has to be setup properly in order for this to work.
<ProxyActivationLod>0</ProxyActivationLod>
This line says from which lod is the game logic attached to the environmental item. (when set on 0 only trees very close to you become “gatherable” and “cuttable”). This way we don’t use game logic on environmental items that couldn’t be used anyway and game is better optimized thanks to that.
Provider Subtype="Growable”
This line adds ability to all environmental items of this type to grow. Keep in mind that the tree itself has to be setup properly in order for this to work.
Provider Subtype="Farmable”
This line adds ability to all environmental items of this type to be farmable. Keep in mind that the tree itself has to be setup properly in order for this to work.
Provider Subtype="Static”
This line adds basically adds items that do nothing. They are just visual props. Like some of our fern bushes.
Provider Subtype="BotSpawner”
It is important that all environmental item types that will contain some bots have botspawner

====Assign environment to a planet====
Last thing is to assign your brand new procedural environment to a planet where it is supposed to appear. Go to Content\Data\PlanetGenerator.sbc and find definition of the planet you want your environment to be on. Then assign the environment to the planet by adding following line to the planet definition with name of your environment:
<pre>
<Environment>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>NAMEOFYOURENVIRONMENTDEFINITION</SubtypeId>
</Environment>
</pre>
SutypeId refers to the name of the environment from:
Content\Data\Environment\ProceduralEnvironments.sbc

''Note: This is not necessary if you just modded existing vanilla environment and have not changed its SubtypeID''

===Ores definitions modding===
[[File:BlueChannel.jpg|frameless|22px]]

Ores are placed using blue channel of the material texture to set where should ore deposits appear. When your ore deposits are painted on the material map, you need to define what ores will be there. Go to Content\Data\Environment\ProceduralEnvironments.sbc to tell game which ore should appear at specific blue channel value.

<pre>
<OreMappings>
<Ore Value="130" Type="IronOre_RichYield" Start="3" Depth="7" TargetColor="#b7340a" ColorInfluence="15 "/>
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
<Ore Value="110" Type="IronOre_PoorYield" Start="2" Depth="5" TargetColor="#a76a41" ColorInfluence="15" />
</OreMappings>
</pre>
The section you need to use is Ore Mappings.
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
Value refers to blue channel value on material texture.
Type refers to name of a voxel material from Content\Data\VoxelMaterials.sbc.
Start is depth at which the ore deposit starts. Depth is how deep under ground it goes.
TargetColor is color that will be used to color surface above the ore.
ColorInfluence sets strenght of coloring.

==Working with RGB==
Ok, Steam won't let me share that link to a small RGB Photoshop tutorial with you, so just go to photoshopessentials.com and search for RGB and it's the first link.

This is a simple tutorial to explain you what we mean when we say Grayscale ID, which can also be called the RGB values
(each channel only has one number per shade of that color ranging from 0 to 255).

Here I have loaded a Biome map texture front_mat texture which is used on the Vanilla EarthLike planet.

[[File:RGBChannels.jpg|frameless]]These are the RGB channels as you can see them in Photoshop.

NOTE: Edit each RGB channel separately!

Always use the pencil tool to paint pixels.
The brush tool has a falloff that has different values and you will not have control over those!
[[File:Color Picker.jpg|thumb]]

You can see if the numbers are correct on the top right of the screen if you have your workspace set to Essentials.

Here you will enter the values you want to paint.
Make sure you check them before saving, sometimes Photoshop can move the number +-1 (personal experience).

It doesn't matter if the numbers match, just as long as you have the correct value (ID) in the correct channel!

==Height-maps modding - terrain shape, roads==
As mentioned in 2. Required software, we used the program World Machine to create our heightmaps and then we did some minor tweaks by hand (like putting in lakes and desert areas)

First, to explain how our planet heightmaps work:
We have 6 textures that connect together (image below). Our standard resolution for a big 120km planet is 2048x2048. But you can use a lower one if you want to.

To create your own heightmap, the best action would be to find a heightmap here:
C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\PlanetDataFiles

Then you can open the texture and place yours/paint yours on a new layer, flatten the image and save it as a .PNG

There are other options for you also!
You can visit[terrain.party] this site and download a heightmap from a real place on Earth. You can even set the size of the map (maximum is 60 km). And then you can edit it further in Photoshop.
You can try painting it yourself in Photoshop (or any other similar software, like Gimp).
You can also just try Googling for heightmaps and try which one suits you the best (keep in mind the resolution must be 512,1024, 2048!)
However you get your heightmap, always keep in mind how each texture of the heightmap is connected, so the seams need to fit together. Bad texture connection is very visible in the game.
Here is an image of how the textures are connected:

[[File:Planet Material Texture Order.jpg|512px]]

===Roads===
We created roads using World Machine tools. You can find guide how to do that in between World Machine tutorials.

==Atmosphere==
[[File:View Image.jpg|1024px]]

Here, you will find everything you ever wanted to know about Atmosphere Settings in Space Engineers but were afraid to ask, my dear friend. So without any further ado. Let’s start with the “Atmosphere” settings window which you access in-game by hitting F12 -> Render Button -> Atmosphere checkbox. The new Atmosphere settings window opens immediately on the right side of the screen, showing a bunch of tricky sliders.

[[File:Cloud Layers Definition.jpg|1024px]]

If your pants are still dry, and if by any chance you’re still reading this, let us assure you that everything is pretty simple and not so scary as it may seem when you first open it. So let’s start with the brief and really quick explanation of what every slider or group of sliders are meant for. Lastly, remember that to alter any setting in this Window you have to hold “Alt” on your keyboard.

Enable Atmosphere (checkbox) – Well, as Captain Obvious immediately states to us – it just enables or disables Atmosphere on a planet and nothing more.

Time of Day (slider) – Controls rotation of the Sun around a Planet. You’re given the Power to decide which time of day it is now. Cool isn’t it?

Pick Planet (Button) – In situations when you have more than one planet in your world, you may want to alter the settings of each planet’s atmosphere individually. So this button enables you to immediately pick the current atmosphere values of the planet you’re currently on. For example, fly to the Moon, press “Pick planet” button and you will get corresponding atmosphere values of that planet to play with. Fly back to Earth or any alien planet, and do the same to alter atmosphere settings of these planets. Yay!

Rayleigh Scattering R,G and B (sliders) – Group of three sliders which control the main, overall color of the Atmosphere. It’s that atmosphere color which is going to be seen from outer space and on the ground too! If you want to make your atmosphere alien green or purple – these are the correct set of sliders to play with. Each slider controls corresponding R,G or B (0-255) values. Pretty straightforward.

[[File:Atmosphere Settings.jpg|512px]]

Mie Scattering R, G and B (sliders) – Group of three sliders to control the color of the Sun glow. It would be weird to have Green atmosphere and Red sun glow right? You would normally want to set it to yellow or something light green or so. But it’s your choice you can make any color you want. But please note that in order to have noticeable results you have to actually HAVE that glow around your sun. This setting is called “Mie Height” and it has to be set to a fairly high value otherwise it wouldn’t be too prominent. We will talk about this “Mie Height” setting in a minute. No worries.

The following three sliders are complementary and play well together. It means you have to find a good balance setting them which is quite easy:

Rayleigh Height Surface (slider) – Controls the thickness of the atmospheric layer when you’re on or near planet’s Surface. For example. You normally want atmosphere layer to be fairly thick to cover high points of the planet’s surface like mountains and high hills while you’re on the ground because you have actual high picks in your surface geometry which you have to cover. Otherwise you would see black space when you’re on the high mountain. But technically, when you’re leaving the planet’s atmosphere all of these high peaks and mountains are starting to slowly collapse vertically forming a smooth spherical shape of the planet, if they wouldn’t - we would have planets looking like a spiky balls with mountain peaks sticking out in all directions. That’s why when all the high peaks are collapsed to the ground to form a perfect sphere - we are left with abnormally thick and wrong looking atmospheric layer thickness when observed from the outer space. How to fix this?! That’s where “Rayleigh Height Space” slider comes into play, as it controls the thickness of the atmospheric layer seen from outer space.

Rayleigh Height Space (slider) – Controls the thickness of atmospheric layer when you observing the planet from outer space. Like it was said earlier, settings for atmosphere thickness when you’re on the Surface and when you’re in an outer Space can’t be same and normally you want to make it much thinner when it is seen from outer space like it’s in real world. Refer to the following Pic to get better understanding.

Rayleigh Transition (slider) – Ok, so now that we have set the width of the planetary atmosphere for both - when we’re on the Surface and when we’re observing it from outer space, it is time to decide at which distance to switch between two, right? So that’s exactly what this slider does – sets the exact value at which distance that transition must happen. You can play around with this value to find the best setting, just remember that the main goal is to have this transition as smooth as possible, fortunately it’s super easy to achieve. Just make sure that while you’re on the ground and standing on a highest point you still see some atmosphere color (like Blue color in earthlike planets) ,and just about when you start to see the whole planet on your way to the outer space, switch it to the thinner (Rayleigh Height Space) version.

Mie Height (slider) – Controls the size of the outer glow effect of the Sun. Like it was said earlier, when you’re setting your color of the Glow effect via “Mie Scattering RGB” sliders, this particular setting (Mie Height) must be set to a fairly high value otherwise you won’t see it as there won’t be any glow. Look, you can’t change the color of a non-existing thing, soldier. Dismissed!

Sun size (slider) – Controls the size of the Sun.. What else did you expect from it?!

Sea Floor modifier (slider) – Defines the lowest (starting) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer starts. It depends on your planet’s relief, your lowest and highest peaks. Adjust individually for each planet. You’ll “feel” the right value immediately.

Atmosphere Top Modifier (slider) – Defines the highest (ending) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer stops. It depends on your planet’s relief. Adjust individually for each planet. You’ll “feel” the right value immediately. But normally you want this value to be set pretty high.

Intensity (slider) – Actually it should be called “Fog Intensity” as it’s exactly what it’s responsible for but I hope it will be changed by some coder guys eventually J. Controls the amount or intensity of the fog while you’re on or near the planet’s surface (doesn’t do anything when you’re in outer space).

Fog Intensity (slider) – And this, should be actually called “Fog Distance”. It controls the distance fog actually covers. The higher this value – more objects in front of view are covered with fog. (doesn’t do anything when you’re in outer space).

Restore (Button) – Ok, just in case you screw everything up, you always have a chance to revert all the changes you’ve made by clicking this Restore button, soldier! Very convenient isn’t it?!

==Atmosphere 2/2==
Ok, now that we got acquainted with all Atmosphere settings and know how they work, it is time for us to actually change a few settings to alter the look of our Atmosphere! Now the fun part begins. Let’s say that we want to change the color of Earthlike planet’s atmosphere from its natural Blue color to the Green one, so it looks more “alienish”. Please note, that all atmosphere settings are stored in “PlanetGeneratorDefinitions.sbc” file and they are NOT replaced even when you change these values in game and make a save. If you want to change those values you have to change them directly in the code of the “PlanetGeneratorDefinitions.sbc” file only! The system reads those atmosphere values from this file every time you’re loading your worlds.

But how for God’s sake would you know which values are correct and really desirable to put them in the code? This is really simple. You just adjust your atmosphere settings to your liking right in the game, and when you’re done and happy with it, you just copy those values into the code (you can screen grab the in-game view with Atmosphere Settings window or just write them down manually, not a big deal) But to paste those values in the code, you have to know WHERE to paste it, right? You don’t just randomly paste numbers into the code, do you? You may hurt yourself!

So please open “PlanetGeneratorDefinitions.sbc” file in any decent text editor and find the following line:
<pre>
<SubtypeId>EarthLike</SubtypeId>
</pre>
It’s a name or identifier of a planet, and since it’s named Earthlike, we know for sure that below are the definitions related to Earthlike planet. Cool! Now just scroll down to the part where you will see a commented (inactive) line of code which goes like:



Or alternatively, just Ctrl+F to find the following line. You must see something similar to this:

[[File:Atmosphere definition.jpg|512px]]

So here as you can see everything is pretty self-explanatory. Except a few lines that are just named differently in the code. If you want your atmosphere to “remember” the settings you have made you have to enter those values here to the corresponding lines. The following schematic pic shows dependencies between the code lines and the slider names in Atmosphere Settings window quite clearly:
(Click to enlarge)

[[File:In-game Atmosphere Debug Input.jpg|1024px]]

Now let’s just change the blue color of the atmosphere to orange. As you remember, group of three RGB sliders named “Rayleigh Scattering” are responsible for changing the main color of the Atmosphere. So why wait?

[[File:Mars-Like Atmosphere.jpg|1024px]]

Spectacular right? Now, let’s change the sun glow color “Mie Scattering RGB” to an orange tint too. It could stay the same yellow of course but let’s change it so you could have an idea. Remember to press “Alt” on your keyboard while you’re dragging those sliders.

[[File:Another Red Atmosphere.jpg|1024px]]

Ok, now it’s more orange but we have to increase the glow effect a bit to see it more prominently. And as we remember, the glow size control is “Mie Height” slider. Crank it up from 30 to 50.

Good, the glow effect became more prominent. Looking nice isn’t it? Of course, you can continue adjusting it and come up with really crazy results, but if you’re ok with what we already have, then just write down all the values that you currently have in your Atmosphere Settings window on the right or screenshot them and paste into any image editor for your reference. And back in the code editor, just enter those values into corresponding tags in the code and save it:

[[File:CloseUp Atmosphere definition.jpg|512px]]

That’s it! From now on, every time you load up your world with Earthlike planet in it, or spawn Earthlike planet, the atmosphere on it will be exactly the way you adjusted it via Atmosphere Settings! The God himself must have been using something like this we suppose..

[[File:Mars-like Atmosphere Final.jpg|1024px]]

==Clouds==
The first thing that should (probably) come in to your mind when you finally learn how to tweak Atmosphere settings, is probably how to change the look of the Clouds! Because, normally, when you change the color of the atmosphere you would like the clouds color to be relatively close to the Atmosphere color. In our Atmosphere guide (if you read it) we were sharing some knowledge about changing the look of the Atmosphere. We made it orange which is kind of cool all on its own, but what really draws our attention and not in a very good way – is the color of the clouds. As you can see they’re white which is looking wrong isn’t it? In an orange atmosphere environment you would expect orange or yellow clouds right? So that’s what we’ll be doing in a minute – changing the look of our cloud layer and getting to know their under-the-hoods.

Like with Atmosphere settings, the Clouds setting are stored in the same “PlanetGeneratorDefinitions.sbc” file located in KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Data and are individual for each planet. Usually we base our code lines so the Cloud definitions come right after Atmosphere definitions which makes it very convenient to search for. Just open your “PlanetGeneratorDefinitions.sbc” file in any decent advanced text editor and search for this commented (inactive) line of code:



Note: you can download the DDS files from here[mirror.keenswh.com]

[[File:Cloud Layers Definition.jpg|1024px]]

That’s where all the cloud settings for particular planet are stored. The following picture is a brief breakdown of cloud definitions:

Basically, the structure of placing clouds on any planet is as follows:
<pre>
<CloudLayers>
<CloudLayer>
Blah Blah Blah Beautiful Clouds Blah Blah Blah
</CloudLayer>
</CloudLayers>
</pre>
So, as you can see everything is super easy. Simply put, <CloudLayers> tags are meant for global separation of Cloud definitions from other code definitions and are here just to define where the code for the clouds start, while <CloudLayer> tags (again, don’t mistake with CloudLayers) are the actual cloud layers and each pair of these tags (<CloudLayer>…</CloudLayer>) define the look and behavior of each cloud layer. As Captain Obvious states - The more <CloudLayer> pairs you have.. umm - the more cloud layers you will have!

For example. You can have more than one Cloud layer, to simulate even more complex cloud patterns than you initially had in your texture file! And that’s when <InitialRotation> and <RotationAxis> tags come into play. You can assign values to these tags for each Cloud layer individually thus having the cloud spheres to be initially rotated and spinning on different angles creating more interesting and natural cloud patterns. So you basically just stack them this way:
<pre>
<CloudLayers>
<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>
</CloudLayers>
</pre>

That’s it! Now you have three Cloud Layers! And of course you can do it for the Far and the Near cloud layers as well.

Your main cloud color texture must be 4096x2048px RGB file saved in DDS format without alpha as “CloudName_cm.dds file” and it must contain only the color information of your clouds. For Alphamask file please create a separate file of the same 4096x2048px dimensions containing only Alpha mask, make it a greyscale file, save as DDS luminance format and name it “CloudName_Alphamask.dds”. Back in the code, in <texture> tags you just write “Cloudname.dds”, no worries - the engine will identify required “cm” and “alphamask” files itself, just make sure both files are in the correct folder. (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Models\Environment\Sky).

As you know, clouds that are seen from the outer space and the clouds that you see through your window don’t look the same because of the huge differences in scales in both cases. That’s why we have two types of clouds on each planet. First one (commented as “Far layer” in the code) – the clouds that you see from the outer space. They usually look like NASA satellite orbital photo shots.

[[File:Clouds.jpg|1024px]]

And the Second one (commented as “Near layer” in the code) – the clouds that are seen when you’re on the ground or close to it. These should look like a significantly zoomed version of the first ones - more detailed, wispy and more individual. Like the ones you used to see in the sky every day. Refer to the picture.

[[File:LargeClouds.jpg|1024px]]

Now, how to actually separate these two types of cloud layers and to make them come in layers – one after the other. This is very simple too. The maximum overall Altitude (height) of our atmosphere layer is 2. So we have to set up our cloud layers in a tricky way, so that when we’re in outer space - we would see the “Far layer” clouds ONLY, and as we’re getting lower (approaching the ground), on a particular altitude (height) smoothly switch to the “Near layer” clouds and have the “Far layer” clouds hidden. Sounds crazy but it will become clear if you look at the following pic:

[[File:CloudLayerDiagram.jpg|1024px]]

As you can see things are really self-explanatory here too. By setting the Start and End values in <FadeOutRelativeAltitude..> you basically create a vector, the starting point of which is infinity which means anything below this start point will be constant value, thus – making it possible to set the Far layer to be seen from outer space (values greater than 2), and preventing Near cloud layer from being seen - because it is set to fade out on 1.6. And vice versa – when you’re on the ground, you won’t see Far layer clouds layer because it faded out on much higher distance of 1.4. Not so hard right? Of course you can alter and tweak those values to your liking depending on the planets height maps/relief to get the desired transition between Far and Near cloud layers.

So now that we’re empowered with this knowledge, the only thing we’re left to do is to actually change the color of the clouds from white to yellow color so our clouds look more natural in an orange Atmosphere environment. As we remember, our clouds are consisting of two texture files – a file containing color information (usually just a plain color) and a file with an alpha mask only. We already know that the “Far layer” clouds (the ones seen from space) use “EarthFarClouds_cm.dds” texture file and the “Near layer” clouds use “Landsky_texture_cm.dds”. How we know that? It’s written in <texture> </texture> definitions, remember?

[[File:CloudTextureRoute.jpg|512px]]

Great! So now just open “EarthFarClouds_cm.dds” and the “Landsky_texture_cm.dds” and fill both files with plain yellow color and save them!

[[File:YellowCloud Texture.jpg|1024px]]

Start the game and spawn an Earthlike planet and voila! You got perfect yellow clouds!

[[File:Scenery With Yellow Clouds.jpg|1024px]]

==Planet ambient sounds modding - day/night biome sounds==

Sound rules are in the Content\Data\PlanetGeneratorDefinitions.sbc file. Here you can set different sounds based on player’s location or daytime on the planet.
<pre>
<SoundRule>
<Height Min="0" Max="0.5"/>
<Latitude Min="55" Max="80"/>
<SunAngleFromZenith Min="0" Max="180"/>
<EnvironmentSound>AmbIcelandDay</EnvironmentSound>
</SoundRule>
</pre>
Height stands for where you want the sound to play at the height of the heightmap (0-7200m). It is always +12% of the planet's diameter. 0 is from the the lowest start of the surface to 1.0 which is 100% of the surface (maximum height).
Latitude means angle from the equator. Therefore 0 to 20 will mean that this sound will mostly play in the desert area, 20-50 is mostly the green forest area, and so on.
SunAngleFromZenith NEEDS MORE INFO!!!
EnvironmentSound this is the name of the sound you want to use.

You can find all available sounds in Audio.sbc (location shown below) Here you will also put your own ambient sound with your own custom name.

How to implement custom ambient sound

All Ambient sounds are stored here:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Audio\ARC\AMB\

If you want your own sounds, they should be a loop sound, and on average should not be bigger than +-5 MB.
The supported format is: .xwm but .wav can also work, even though its file size is usually a lot bigger (not recommended).

Once your audio is done, implement it here in this file:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\Audio.sbc
<pre>
<Sound>
<Id>
<TypeId>MyObjectBuilder_AudioDefinition</TypeId>
<SubtypeId>AmbAlienForestDay</SubtypeId>
</Id>
<Category>AMB</Category>
<MaxDistance>100</MaxDistance>
<Volume>0.2</Volume>
<Loopable>true</Loopable>
<Waves>
<Wave Type="D2">
<Loop>ARC\AMB\AmbAlienForestDayLoop2d.xwm</Loop>
</Wave>
</Waves>
</Sound>
</pre>
Here edit only what is highlighted, otherwise I cannot guarantee that it will work properly!
<SubtypeId> This is how you will name your AMB sound, keeping in mind upper and lower case letters. Do not use _ or other special characters!
<Volume> This is self explanatory I hope.
<Loop> Here you just need to lead the definition to your file. ARC/AMB/ is the default location, so do not change that.
But if you want, you can make another folder in AMB for your custom ambient sounds for better organisation.

==In-game map modding==
Maps in Medieval Engineers are generated based on terrain and buildings on it. This means that they will work for any modded planet in their default form. That being said, the way map is generated is also fully moddable.

We definitions for map are located in Content\Data\Screens\MapDefinition.sbc. To mod maps you will have to alter/add definitions in this file, all vanilla textures for maps can be found in Content\Textures\GUI\Map. Feel free to use/alter any of them for creation of mods for Medieval Engineers.
Map content modding (Friend/foe display, tax notifications,...
In Medieval Engineers there are 2 view modes of map. Kingdom view which is showing entire kingdom and region view which is zoomed part of a kingdom map. Region is 1kmx1km large on 10 km diameter planet. Both views display different elements.
What is shown in these views depends on what layers it contains
<pre>
<Definition xsi:type="MyObjectBuilder_PlanetMapDefinition">
<Id Type="MyObjectBuilder_PlanetMapDefinition" Subtype="Main"/>
<BackgroundGenerator Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
<RegionView>
<Layers>...</Layers>
</RegionView>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</Definition>
</pre>
BackgroundGenerator refers to a definition of background texture that serves as a background on top of which all the map elements are placed.
<pre>
<RegionView>
<Layers>...</Layers>
</RegionView>
</pre>
The three dots in middle represent layers of elements that show in region view. List and description of all layers is in next section of this document.
<pre>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</pre>
The three dots in middle represent layers of elements that show in kingdom view. List and description of all layers is in next section of this document.
(I did not Kingdom view in its expanded form because it would take up too much space.)

===Layers description===
<pre><Layer xsi:type="MyObjectBuilder_MapBackgroundLayer" /></pre>
This layer draws the background. As generated based on chosen background definition.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaDevelopmentLayer">
<Threshold BlockCount="10" Sprite="Textures\GUI\Map\SmallGrid.png"/>
<Threshold BlockCount="30" Sprite="Textures\GUI\Map\MediumGrid.png"/>
<Threshold BlockCount="60" Sprite="Textures\GUI\Map\LargeGrid.png"/>
</Layer>
</pre>
This layer displays icons based on amount of blocks there is in an area. You can set the block thresholds, or mod the textures. It is also possible to add more thresholds. 80x80 px, png.

[[File:Smallest Settlement.png|150px|frameless]]
[[File:Medium Settlement.png|150px|frameless]]
[[File:LargestSettlement.png|150px|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_RegionFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for region, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaOwnershipLayer">
<AlliedBgColor Hex="#806464FF" />
<PlayerBgColor Hex="#8064FF64" />
<EnemyBgColor Hex="#80DC6415" />
</Layer>
</pre>
This layer defines color overlay over map areas based on ownership. You can mod which color is used for allies, your own areas or for enemies
<pre>
<Layer xsi:type="MyObjectBuilder_AreaUpkeepLayer">
<TaxIcon>Textures\GUI\Map\TaxIcon.png</TaxIcon>
</Layer>
</pre>
This layer displays tax icon on areas that belong to you and require tax payment soon. Texture is 80x80 pixels, png.
[[File:Taxes.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapPositionLayer">
<LocalPlayerImage>Textures\GUI\Map\PlayerPosition.png</LocalPlayerImage>
<OtherPlayersImage>Textures\GUI\Map\AllyPosition.png</OtherPlayersImage>
</Layer>
</pre>
PlanetMapPositionLayer displays player icon above area where they are.
[[File:Ally.png|frameless]]
[[File:Player.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_ActionTrackingLayer">
<ActionImage>Textures\GUI\Map\Action.png</ActionImage>
</Layer>
</pre>
Shows icon over an area on map with fighting / destruction.
[[File:AttackedArea.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_CurrentMapSelectionLayer">
<SelectionImage>Textures\GUI\Map\MapSelection.dds</SelectionImage>
</Layer>
</pre>
This is highlight of a region, that player selected with his mouse.
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapGridLayer">
<GridColor R="0" G="0" B="0" A="228"/>
</Layer>
</pre>
This layer sets which color is the grid drawn.
<pre>
<Layer xsi:type="MyObjectBuilder_KingdomFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for kingdom, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_RegionOwnershipLayer">
<PlayerIcon>Textures\GUI\Map\PlayerLandIcon.png</PlayerIcon>
<AllyIcon>Textures\GUI\Map\AllyLandIcon.png</AllyIcon>
<EnemyIcon>Textures\GUI\Map\EnemyLandIcon.png</EnemyIcon>
<PlayerAllyIcon>Textures\GUI\Map\PlayerAllyLandIcon.png</PlayerAllyIcon>
<PlayerEnemyIcon>Textures\GUI\Map\PlayerEnemyLandIcon.png</PlayerEnemyIcon>
<AllyEnemyIcon>Textures\GUI\Map\AllyEnemyLandIcon.png</AllyEnemyIcon>
<PlayerAllyEnemyIcon>Textures\GUI\Map\PlayerAllyEnemyLandIcon.png</PlayerAllyEnemyIcon>
</Layer>
</pre>
RegionOwnershipLayer generates textures used to express ownership on regional map.

===Background generator (trees, mountains, roads,...)===
Map background is where all the trees, mountains, hills are drawn. It is also capable of coloring map based on what is in planet’s material map (this is how we make roads for example).
All settings for map background are in MedievalMapBackgroundDefinition. The definition also in Content\Data\Screens\MapDefinition.sbc. I will go through various parts of the definition.

<pre><Id Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
Type of the definition says that this map background definition. Subtype is name of this specific background definition. If create your own background with unique subtype
Make sure you create your own background with unique subtype

<DrawHeightmap>false</DrawHeightmap>
When set on “true” planet’s heightmap is drawn under the map.
<Resolution>4096</Resolution><
Sets resolution of the generated in-game map.

<Features>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</Features>

<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</Definition>
</pre>
===Map Coloring===
You can use colors in material or biome map of a planet to appear on the game map. (roads for example). You define map coloring in a node called ”Features”. The coloring uses colors from planet material texture. You can learn more about material texture in biomes modding and surface material modding.
<pre>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
</pre>
This specific feature is used for painting roads on map with dark brown color. In Color you define which color will be the in-game map colored. Material=”67” decides where will be the color applied and refers to a red channel value on planet material texture.
<pre>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</pre>
This specific feature is used for painting forests on map with opaque brown. In Color you define which color will be the in-game map colored. Biome=”60” decides where will be the color applied and refers to a green channel value on planet material texture.

===Sprites===
Medieval Engineers map can also place sprites on map based on terrain shape. All the sprites are on one texture
<pre>
<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</pre>

[[File:AtlasCoordinateUsage.png|512px]]

Note: Illustrates how sprite is defined on our spritesheet. Example sprite:
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />

==Voxel color overlay modding==
We have a cool tech that enables us to color-shift color of almost any item in the game. Currently we are using it for trees(adds small color variations to the same model of a tree) and voxels above iron deposits.
==Fast travel settings modding==
In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around.
In this section of the guide we will show you how to mod which sectors are blocked.
There are 2 ways you can go about it:
===Generate automatically based on terrain shape===
Game is capable of creating fast travel map on its own based on height and terrain steepness. It is possible to mod thresholds for both height and steepness.
You will find the thresholds in Content\Data\Game\FastTravel.sbc. In a MyObjectBuilder_TerrainReachabilityProviderDefinition.
<RiseThreshold> - Sets min. terrain height change which will cause that area is unreachable.
<HeightThreshold> - Sets height of terrain after which area is unreachable, if it goes over this value. Range is 0 - 1.

If there are texture overrides in the definition, you have to erase them in order for the parameters to take effect. Texture overrides are nodes that are called in this fashion: <OverrideNAMEOFFACE>. You will learn more about these overrides in the next part of Fast travel modding.

===Creating fast travel texture override===
If you want to have full control over which areas are reachable and which are not regardless of terrain, you can create a simple texture on which you mark unreachable areas.

The texture is 80x80 pixels, RGB 8 bit. Black pixels forbid entrance.

When you have the texture, select route to it in the definition:
<pre><OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward></pre>
Reachability definition example:
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>
<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>
<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
</Definition>
</pre>
This definition would generate fast travel reachability everywhere, except for front planet face (Fareon kingdom) where fast travel reachability is created based on your texture.

===Development reachability===
Claimable area size, border highlight, contested timer modding
Size of the area and highlight properties are moddable as well.

===Area borders highlight===
<NeutralColor R="225" G="32" B="0" A="64" /> - Set color of an unowned territory
<SelfColor R="0" G="255" B="0" A="64" /> - Sets color of area border owned by you
<AliedColor R="65" G="105" B="225" A="64" /> - Sets color of area border that belongs to allies
<EnemyColor R="225" G="32" B="0" A="64" /> - Sets color of area border that is hostile
<WallSettings Depth="15" Rise="3" SegmentCount"71" End="115" /> - Changes shape of the border. Depth sets how deep is border submerged. Rise sets how tall is the border.
<Fade Start="71" End="115" /> - This sets at which point the border starts to fade.
Contested timer
When players claim area with claimblock, area goes to a “contested” phase for some amount of time, in this phase other players can still attempt to build their own claim block and claim the area. This time is moddable.
Content\Data\Game\SessionComponents.sbc contains definition called MyObjectBuilder_AreaOwnershipSystemDefinition. To mod this value, add this definition to your mod with changed value of <ContestedTimeInMinutes> parameter.

==Permissions modding - what is/isn’t allowed to do in claimed areas==
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.
Description of available actions to set permissions for:
Name=”Build” -> block placement permissions
Name=”Repair” -> Repairing/building already placed blocks
Name=”Deconstruct” -> Deconstructing
Name=”QuickDeconstruct” -> Faster deconstruction
Name=”VoxelEdit” -> Mining or shoveling
Name=”Destroy” -> Damage with hand weapons
Name=”Interaction” -> Chest opening, door opening
Name=”ClaimBlockInteraction” -> ClaimblockGui

===List of available Groupnames:===
Groupname: “Owner” -> Player who owns area
Groupname: “Allies” -> Mostly faction members of owner of the area
Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
Groupname: “Enemies” -> Players in factions that are hostile to your faction

==Compass modding==
It is possible to mod visual look of an in-game compass. All definitions of compass are stored in Content\Data\GUI\CompassDefinition.sbc. Our textures for compass are in Content\Textures\GUI\Compass folder if you want to check out how they look or use them in your mod.
===Creating compass texture atlas and setting coordinates for its elements===
Just like with map sprites, we save main compass elements on a single texture, then define parts of it using pixel coordinates. First setup origin point, then add width and height of the rectangle
Example texture coordinates for top part of the compass:
[[File:CompassTextureCoordinates.png|1024px]]
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>

===Explanation of compass definition line by line===
<pre><Texture>Textures/GUI/Compass/compass.png</Texture> </pre>
Route to a texture atlas.
<pre><KingdomIcon>Textures/GUI/Compass/Icon-Kingdom.png</KingdomIcon> </pre>
Route to icon symbolizing a kingdom.
<pre><Padding>7</Padding></pre>
Padding is added vertically between the top and bottom textures and the edges of the contents of the compass.
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>
Rectangle in the texture that contains the top part.
<pre><BottomCrop X="0" Y="0" Width="0" Height="0"/></pre>
Rectangle in the texture that contains the bottom part.
<pre><BackgroundCrop X="0" Y="64" Width="512" Height="64"/></pre>
Rectangle in the texture that contains the background.
<pre><ArrowCrop X="0" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the little marker used for elements that are drawn and have no icon.
<pre><MarkerCrop X="32" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the interval bars drawn every few degrees.
<pre><ShadowCrop X="64" Y="128" Width="80" Height="32" Left="8" Right="8"/></pre>
<pre><ShadowPadding Left="12" Top="8" Right="12" Bottom="8"/></pre>
Rectangle in the texture that contains the text shadows. Shadow is 3-Sliced, meaning the texture is split in three parts: [left|middle|right]
The sizes of left and right define the cropping lines that split the texture into three. The Sides are then always kep proportional as the texture is scaled.
<pre><VisibleRange>200</VisibleRange></pre>
Visible range in degrees.
<pre><Width>700</Width></pre>
Width in reference resolution pixels.
<pre><FontSize>1.1</FontSize></pre>
Scale of the font based on default.
<pre><VerticalOffset>0.065</VerticalOffset></pre>
Vertical offset from the top of the screen. 0 = top of the screen, 1 is the bottom. Compass is centered around this position.
<pre>
<TagStyles>
<TagStyle Tag="ClaimArea" Style="Bellow" MaxCharacters="15" Ellipsis="true"/>
<TagStyle Tag="Cardinal" Style="Above" MaxCharacters="1"/>
<TagStyle Tag="Kingdom" Style="Bellow"/>
</TagStyles>
</pre>
This section adds tags that are visible on compass and in which style. Currently we have 3 types of tags. Claim area - shows your claimed area on the compass, Kingdom tag shows kingdoms and Cardinal tag shows cardinal points (North, South,...). Each tag’s visual appearance is defined in tag/waypoint definition. Styles defines where should the text appear. Available styles: Center, IconOnly, NotShown, Bellow, Above.

===Explanation of Waypoint/Tag definition===
<pre>
<Definition xsi:type="MyObjectBuilder_WaypointDefinition">
<Id Type="MyObjectBuilder_WaypointDefinition" Subtype="Kingdom"/>
<IconPath>Textures/GUI/Compass/IconKeep.png</IconPath>
<Color R="255" G="255" B="255" A="255"/>
</Definition>
</pre>
IconPath contains path to the texture of kingdom icon. Color defines color of the text that is shown with the icon. (Example: Fareon, [[File:Kingdom Icon.png|thumb]])
===Compass texture vs in-game look comparison===
Texture:

[[File:Compas Texture with Zones.png|1024px]]

In-game look:

[[File:In-gameCompassZones.png|1024px]]
<NoWiki>*</NoWiki>note that background crop and bottom crop are not used in vanilla (empty opaque texture)

==Indestructible grids==
There is a way how to make some buildings in your save indestructible. We are using this feature for starting area buildings. Some you guys might make a good use of this feature in your pre-made worlds.

Currently, only way how to do this is to make edits to an existing save file. So you can only use it for world modding.

===Making indestructible cubegrids in existing safe===
Goal is to open world’s safe file in a text editor, find your cubegrid in it and add this tag to it: <DestructibleBlocks>true</DestructibleBlocks>.

#Find your save file. By default save files are stored in C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Saves
#Open folder with your save and find file called SANDBOX_0_0_0_.sbs. This file can be opened with any text editor you prefer.
#In the SANDBOX_0_0_0_.sbs search for the cubegrid name of the building you want to make indestructible. (use find/search function in your text editor, or you will grow old before you find it)
#Tip: To find out name of a cubegrid, create blueprint of the building. The name that the building saves as in your blueprint screen is the name of the cubegrid.
#You should find the name in tags called: <DisplayName>YOURCUBEGRIDNAME</DisplayName>
#Under the name, add following tag with setting set to false: <DestructibleBlocks>false</DestructibleBlocks>
#If you followed instruction, the indestructibility tag is now in node called <MyObjectBuilder_EntityBase> and not in any of its child nodes.
#Save the edited file.
#Load the save and test destructibility
#It worked! Enjoy
#It is still destructible. Go to point 1.

[[Category:Keen_Modding_Guides]]

Keen:New Component Modding Guide

2017-05-03T13:13:29Z

Lukas: /* MyCraftingComponentBlock */

Hello engineers,

With 0.4.14 we introduce a multitude of new entity components, as well as an upgrade to the subpart animation system to be more generic and easy to use.
==New Entity Components==
===MyEntityFXComponent===
The Entity FX component provides light, particle and sound effects to a block. See Data/CubeBlocks/Props/TorchStand.sbc for an example.
<source lang="xml">
<Definition xsi:type="MyObjectBuilder_EntityFXComponentDefinition">
<Id>
<TypeId>MyObjectBuilder_EntityFXComponent</TypeId>
<SubtypeId>TorchStand</SubtypeId>
</Id>
<Effects>
<Effect StartEvent="On" StopEvent="Off" Dummy="detector_fire">
<EffectId Type="MyObjectBuilder_EffectDefinition" Subtype="Torch"/>
</Effect>
</Effects>
</Definition>
</source>
The Effects contains a list of effects, as well as which events toggles them on and off and which dummy they respond to. Finally, they refer to the effect as defined in Data/FX/Effects.sbc.
===MotionEventsComponent===
The MotionEventsComponent is a simple component that can fire events on the entity depending on how fast it is moving. Look at Data/CubeBlocks/Miscellaneous/Projectiles.sbc for an example.
<source lang="xml">
<Definition xsi:type="MyObjectBuilder_MotionEventsComponentDefinition">
<Id Type="MyObjectBuilder_MotionEventsComponent" Subtype="CatapultProjectile"/>
<VelocityEvent Speed="20" Threshold="Below" Name="MovingSlow"/>
<VelocityEvent Speed="20" Threshold="Above" Name="MovingFast"/>
</Definition>
</source>
Each velocity event checks if the speed goes from either above to below a speed, or from below to above a speed, and then fires the event in Name on the object.
===MyCraftingComponentBlock===
The CraftingComponentBlock component adds crafting functionality to a block that relies on the presence of fuel. This is used for the bonfire and the furnace. See Data/CubeBlocks/Production/Bonfire.sbc for an example.
<source lang="xml">
<Definition xsi:type="MyObjectBuilder_CraftingComponentDefinition">
<Id Type="CraftingComponent" Subtype="BonFire"/>
<CraftingCategories>
<Category>Meals</Category>
</CraftingCategories>
<CraftingInventory>BonfireInventory</CraftingInventory>
<ProductionQueueSize>4</ProductionQueueSize>
<CraftingSpeedMultiplier>1</CraftingSpeedMultiplier>
<ConstrainInventory>true</ConstrainInventory>
</Definition>
</source>
CarftingCategories lists the categories of crafting recipes that can be crafted. CraftingInventory references an inventory component of the bonfire that is used for crafting. (Any block can have multiple inventories, this sets which one is used for crafting). ProductionQueueSize sets how long can crafting queue get. CraftingSpeedMultiplier can modify speed that recipes are being built with. This way you can make faster crafting stations. ConstrainInventory set to true will only allow items in its inventory, that are used for crafting by that block, or produced by this block.

===StockpileComponent===
The StockpileComponent component adds the ability to display the inventory items in the world on to the entity per subpart points. This component requires the CubeBlockSubpartComponent to be present. Look at Data/CubeBlocks/Storage/WoodenShelf.sbc for an example.
<source lang="xml">
<Definition xsi:type="MyObjectBuilder_StockpileComponentDefinition">
<Id>
<TypeId>MyObjectBuilder_StockpileComponent</TypeId>
<SubtypeId>WoodenShelf</SubtypeId>
</Id>
<SubpartNameFormat>Inventory_Slot_{0:00}</SubpartNameFormat>
<MaxNumberOfSubparts>3</MaxNumberOfSubparts>
</Definition>
</source>
The SubpartNameFormat specifies the numerated subpart names that are used for the system, and MaxNumberOfSubparts specifies the limit of visible subparts to try and assign contents to.
===CrankComponent===
The CrankComponent simply specifies the sound and angular speed and torque properties of a handcrank object. Look at Data/CubeBlocks/Mechanical/TurnWheel.sbc for an example.
<source lang="xml">
<Definition xsi:type="MyObjectBuilder_CrankComponentDefinition">
<Id>
<TypeId>CrankComponent</TypeId>
<SubtypeId>TurnCrossSmall</SubtypeId>
</Id>
<AngularImpulse>25</AngularImpulse>
<AngularVelocityLimit>4</AngularVelocityLimit>
<ActionSound>GearWheel</ActionSound>
</Definition>
</source>
AngularImpulse specifies the physical strength of the rotation, AngularVelocityLimit limits the rotation speed and ActionSound specifies the sound played while rotating.
===LockableRopeComponent===
The LockableRopeComponent specifies the lockable rope drum properties for when you want to make an object that behaves exactly like the lockable rope drum. Look at Data/CubeBlocks/Mechanical/RopeDrum.sbc for an example.
<source lang="xml">
<Definition xsi:type="MyObjectBuilder_LockableRopeComponentDefinition">
<Id>
<TypeId>MyObjectBuilder_LockableRopeComponent</TypeId>
<SubtypeId>LockableDrumSmall</SubtypeId>
</Id>
<MinRopeLength>0.7</MinRopeLength>
<MaxRopeLength>70</MaxRopeLength>
<DefaultMaxRopeLength>40</DefaultMaxRopeLength>
</Definition>
</source>
MinRopeLength and MaxRopeLength specify how long a rope can be, and DefaultMaxRopeLength specifies the default rope length when the drum is fully unwinded.
===TorsionSpringComponent===
The TorsionSpringComponent component specifies torsion spring properties. Look at Data/CubeBlocks/Mechanical/TorsionSpring.sbc for an example.
<source lang="xml">
<Definition xsi:type="MyObjectBuilder_TorsionSpringComponentDefinition">
<Id Type="MyObjectBuilder_TorsionSpringComponent" Subtype="RopePowerSmallCogWheel1"/>
<MaxAngularImpulse>800</MaxAngularImpulse>
<MaxAngle>135</MaxAngle>
<MaxFrictionTorque>30</MaxFrictionTorque>
</Definition>
</source>
MaxAngularImpulse specifies the maximum strength the block can provide, the MaxAngle is the maximum angle it rotates and MaxFrictionTorque is the maximum torque friction.
==New event system==
We changed the way the components interact with each other. This system provides a more elegant approach to handling events so that we do not need as many entity components to create specific effects without requiring programming.

Some examples exist in the definitions, for example, the CatapultProjectile, in Data/CubeBlocks/Miscellaneous/Projectiles.sbc. The MotionEvent component generates some events, and the EntityFXComponent listens to these events and plays an effect.

More components will be converted to integrate with this system in the future to allow, for example, the crafting blocks to trigger animations. This way you can see the SpinningWheel spin while it’s being operated, etc.
[[Category:Keen_Modding_Guides]]

Keen:Planet Modding - Full Guide

2017-03-16T14:47:41Z

Lukas:

Keen:Planet Modding - Full Guide

2017-03-13T16:41:12Z

Lukas: /* Definition elements explained point by point: */

==Introduction==
Hello fellow Medieval Engineers!
I would like to present you with a guide that will help you understand how we created planets at Keen Software House and how to mod your own into the game.
Feel free to use/alter company owned files for your Medieval Engineers mods.

So let's get to modding!

==Recommended Software==
# Microsoft Visual Studio - or Notepad++ (Link[notepad-plus-plus.org]) - for opening files with .sbc extension where we have definitions for every feature in the game.
# Adobe Photoshop - for editing material and heightmap textures
# World Machine Professional - for heightmap easier creation (much more realistic looking terrain, without manual work)

(Basic Edition is also available, but the max resolution output is limited to 512x512 pixels)
http://www.world-machine.com

===Advice===
We would like to mention one thing before you get into modding planets:
For your own sake we recommend you to load either PlanetTemplate or EarthLikeModExample and test/edit all the things there, so you get to know the system and how everything works.

After that you can create your own from scratch. This is entirely up to you.

==General modding principles - how to make any mod==
I will explain again basic principles of how mods are applied.

All of our vanilla source files are all saved in a folder called content in your *game folder. If no mods are assigned to a world that you are loading, game uses only files from this content folder but if there are mods, game loads also files from mod adding more content or potentially rewriting vanilla content based on content of the mod’s folder. Mod is nothing else but a folder with another files.
Mod files are stored in mods folder on your computer , and if you are using them for the first time, they are downloaded from workshop first time you try to load/connect to a world with those mods.
Mod folder: C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Mods
===Opening mod and examining mods content===
When you open Mods folder, you will see mods as files with .sbm extension. But they are really just folders and to examine them, all you have to do is rewrite the extension from .sbm to .rar and then you can open them with rar and examine content.
Mods are not listed with their names, but with their steam id number. To find specific mod, you have to go to the mods workshop page

Examining other mods similar to your idea is a fast way to learn.
Example:

<NoWiki>*</NoWiki>By default this is SteamLibrary\steamapps\common\MedievalEngineers\Content. You can also get there if you go to steam library(same place where you start the game), right-click Medieval Engineers, select properties, local files and finally click on “browse local files”.
==Materials modding==
In case you are thinking about making your own trees and voxel materials, we have some good news for you!

There are two separate guides that you can follow to make your own stuff.

General modding guide - get started

===Voxel material modding===
http://steamcommunity.com/sharedfiles/filedetails/?id=568406623

==Planet Size==
Planet size is defined in a scenarios.sbc. Every time you click on create new world in the game it uses scenario definition to create a new safe file. Although this scenario definition is not moddable, you can still use it to create a world and share the world itself on the workshop.

First go to where you have Medieval Engineers source files and find Data folder (SteamLibrary\steamapps\common\MedievalEngineers\Content\Data\Scenarios.sbx)

==All planet related files overview and where to find them==
To summarize how planet modding in ME works, we can say this:
We use 2 types of textures and then we define how the game should interpret those textures in definitions. One texture is heightmap that is used just for generating terrain shape, another one is used to place everything else on the planet (ores, trees and plants, bots).
[[File:Diagram.png|1024px|center]]

==Material Texture modding==
Material texture is used to store information about location of various planet surface features. These features are surface materials, biomes (trees, bots, plants,..etc) and where you can find ore. Each one of these uses one color channel. Surface materials use red channel. Biomes use green. Ores are in blue channel.
We use 6 material textures (2048x2048) for each planet. You can find all our material textures here: Content\Data\PlanetDataFiles.
Each planet has its own folder. The folder has to have the same name as the planet.

[[File:MaterialMapBreakdown.jpg|512px]]

Illustration of how are the material textures connected to each other:

[[File:Planet Material Texture Order.jpg|512px]]

====The process of material texture creation is really simple. You have two options:====
=====Copy an existing map to your folder and overwrite the green channel and edit them to your liking=====
This is highly recommended to avoid errors!
=====Create a new: step by step in Photoshop=====
#Set both width and height to 2048 pixels
#(for smaller planets this can also be 1024 or less, but all textures need to have the same resolution! Even the heightmap)
#Set resolution - Pixels/Inch to 72.
#Set colour mode to RGB Colour - 8bit
#Now start painting with the pencil tool on each RGB Channel separately.
#Never on all three at once! (It will F. up everything - trust me).

===Surface voxel material definitions modding - grass, sand, snow===

[[File:RedChannel.jpg|22px|frameless]]

Surface “voxel materials” refers to what you know as grass, soil, stone.. We use red channel of the material texture to set where all the terrain appears. Then you need to write definitions in the Content\Data\PlanetGenerator.sbc to tell game which voxel should appear at specific red channel value.
Example of the definition of road:
<pre>
<ComplexMaterials>
<MaterialGroup Name="Road" Value="67">
<Rule>
<Layers>
<Layer Material="Soil" Depth="2"/>
</Layers>
<Slope Min="0" Max="90"/>
</Rule>
</MaterialGroup>
</ComplexMaterials>
</pre>
Example of corresponding material texture with road:

[[File:RoadMaterialTextureExample.png|512px]]

====Complex materials====
Complex materials definition allows to paint the map with a set of “voxel coloring rules”. Meaning that one color value in red channel can color terrain with different voxels based on rules like slope, longitude or latitude and height. (So with our road example)
<pre>
<MaterialGroup Name="Forest_Grass" Value="120">
<Rule>
<Layers>
<Layer Material="Woods_grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="0" Max="25"/>
<Latitude Min="-180" Max="180"/>
<Longitude Min="-180" Max="180"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="25" Max="45"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Rocks_grass" Depth="2"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="45" Max="55"/>
</Rule>
</MaterialGroup>
</pre>
This definition says what voxels should be generated in spots, that are painted with red channel value of 120.
The rules in this definition will lead to following:
Flat lands (up to 20 degrees slope) will have Wood grass 1 m thick, soil will be right under the WoodGrass up to 5 m depth and there will be stone underneath the soil.
In places with medium slope, there is Grass instead of WoodGrass. And in slopes from 45 to 55 there is rocks grass 2 m thick with stone right away under it.
With this technology, we can make the color react on its own to terrain bumps or even position on planet. This saves lots of meticulous painting with heightmap.

<Layer Material="Woods_grass" Depth="1"/>
Material refers to voxelmaterial definition. (You can find it in Content\Data\VoxelMaterials.sbc). Depth means how deep should the material go under ground.
<Slope Min="0" Max="25"/>
Slope of the terrain in degrees.
<Latitude Min="-180" Max="180"/>
Latitude in degrees. 0 degree is an equator.
<Longitude Min="-180" Max="180"/>
Longitude in degrees. 0 is in the middle of front planetary texture. (Fareon Kingdom)

===Biomes definitions modding - trees, plants and bots===
[[File:GreenChannel.jpg|frameless|22px]]

Biomes refers to everything that is spawned on top of the planet. We use green channel of the material texture to set where all the terrain features appear and definitions in the Content\Data\Environment\ProceduralEnvironments.sbc to tell game which environment item should appear at specific green channel value. Also you need to assign Environment to planet in the Content\Data\PlanetGenerator.sbc in case you are adding a brand new planet.

====First make/modify environment:====
Go to Content\Data\Environment\ProceduralEnvironments.sbc

=====Procedural World Environment definition=====
This definition defines where will the environmental items spawn and with which density. (note: bots are also considered environmental item). Best way to explain how procedural environment is working is to imagine that it puts spots on entire surface of a planet. And when you start defining trees, bots and bushes, the spots get “reserved” by these categories based on how many of those should appear in the world according to your mod.
Spots are always different for each single planet.
In order to mod the procedural environment, mod our “Earth Environment” definition. Or create your own but if you do, don’t forget to also mod PlanetGeneratorDefinition, so that planet has your new procedura environment assigned to it.

=====Definition elements explained point by point:=====
<pre>
<Definition xsi:type="MyObjectBuilder_ProceduralWorldEnvironment">
<Id>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>Earth Environment</SubtypeId>
</Id>
</pre>
This part of definition is called ID. It says what type of definition this is <TypeID> and unique name of that definition <SubtypeID>.

<pre>
<MaxSyncLod>1</MaxSyncLod>
</pre>
This line defines how far away from player are the environmental items updating. This is important feature for optimization.

<pre>
<SectorSize>40</SectorSize>
</pre>
This is size of the environmental sector. It is a different sector than the claimable areas by players. It sets size of one environmental sector.

<pre>
<ItemsPerSqMeter>0.17</ItemsPerSqMeter>
</pre>
The line sets overall maximum density of all environmental items. To return to analogy i used in the introduction, this number increases the amount of spots on the planet that are reserved for all environmental items.

<pre>
<ScanningMethod>Random</ScanningMethod>
</pre>

<pre>
<ItemTypes Type="MyObjectBuilder_EnvironmentItemTypesDefinition" Subtype="Default"/>
</pre>
This sets which types of environmental items are used in this procedural environment definition. This guide explains what are Environmental item types in the very next section.

<ItemGroup Density=".017" Name="Bots" LodStart="1" LodEnd="1">
<Mapping>
<Material>Woods</Material>
<Item Type="Bot" Subtype="Deer"/>
</Mapping>
<Mapping>
<Biome>60</Biome>
<Height Min="0" Max"1"/>
<Latitude Min="-180" Max"180"/>
<Longitude Min="-180" Max"180"/>
<Slope Min="0" Max"1"/>
<Item Type="Bot" Subtype="Deer" Density="0.9"/>
<Item Type="Bot" Subtype="Barbarian" Density="0.1"/>
</Mapping>
</ItemGroup>
Item group is used to organize and better manage mappings. Mappings are definitions that actually add the environment items in the world. It is important to set Density correctly. Density (Density=".017") sets how many of the procedurally generated spots on the planet will be assigned to environmental items from this group. The name (Name="Bots") is only for naming purposes within definition and has no impact on the game. LodStart="1" and LodEnd="1" control how far from the player will the items appear.
<Biome>60</Biome> This section means that Items within this mapping will only appear on spaces that are painted with green channel value 60 on the material map.
<Material>Woods</Material> This means that the environmental items will only appear in the woods.
<Height Min="0" Max"1"/> Sets in which altitude should these environmental items appear. If this parameter is missing, items spawn in full range (Min="0" Max"1")
<Latitude Min="-180" Max"180"/> Sets at which latitude do the environment items spawn. If this parameter is missing, items spawn in full range (Min="-180" Max"180")
<Longitude Min="-180" Max"180"/> Sets at which longitude the environment items spawn. If this parameter is missing, items spawn in full range (Min="-180" Max"180")
<Slope Min="0" Max"90"/> Sets at which slopes the environment items spawn. If this parameter is missing, items spawn in full range (Min="0" Max"90")

<ItemGroup Density=".085" Name="Trees" LodStart="-1" LodEnd="1">...</ItemGroup>
LodStart="-1" means that the items will be visible all the time. Will not go into details about settings of this Item Group, since it more of the same.
<ItemGroup Density=".36" Name="Small Items" LodStart="0" LodEnd="0">...</ItemGroup>
</Definition>

=====Environment items=====
We learned how to assign environments to planets and how to mod environments themselves by changing densities and environment items. But we still don't know how to make the environment items themselves. Guides for those can be found on following links.

If you want to mod trees:

If you want to mod bushes and plants:

If you want to mod bots:

=====EnvironmentItemTypesDefinition=====
Here you define various types of items. Currently we have these types: Tree, Gatherable, Farmable, Static and Bot. Before you add any item, you must make sure it fits within these types of environment items or you created a new type for them.
<Definition xsi:type="MyObjectBuilder_EnvironmentItemTypesDefinition">
<Id Type="MyObjectBuilder_EnvironmentItemTypesDefinition" Subtype="Default"/>
<Item Name="Tree">...</Item>
<Item Name="Gatherable">...</Item>
<Item Name="Farmable">... </Item>
<Item Name="Static">...</Item>
<Item Name="Bot">...</Item>
</Definition>

EnvironmentItemTypes
<Item Name="Tree">
<ProxyActivationLod>0</ProxyActivationLod>
<Provider Type="MyObjectBuilder_ProceduralEnvironmentModuleDefinition" Subtype="Growable"/>
<Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Gatherable" />
<Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Cuttable" />
</Item>
Available proxy and providers:
Proxy Subtype="Gatherable"
This line adds ability to all environmental items of this type to use action “Gatherable”. Keep in mind that the tree itself has to be setup properly in order for this to work.
Proxy Subtype="Cuttable" />
This line adds ability to all environmental items of this type to use action “Cuttable”. Keep in mind that the tree itself has to be setup properly in order for this to work.
<ProxyActivationLod>0</ProxyActivationLod>
This line says from which lod is the game logic attached to the environmental item. (when set on 0 only trees very close to you become “gatherable” and “cuttable”). This way we don’t use game logic on environmental items that couldn’t be used anyway and game is better optimized thanks to that.
Provider Subtype="Growable”
This line adds ability to all environmental items of this type to grow. Keep in mind that the tree itself has to be setup properly in order for this to work.
Provider Subtype="Farmable”
This line adds ability to all environmental items of this type to be farmable. Keep in mind that the tree itself has to be setup properly in order for this to work.
Provider Subtype="Static”
This line adds basically adds items that do nothing. They are just visual props. Like some of our fern bushes.
Provider Subtype="BotSpawner”
It is important that all environmental item types that will contain some bots have botspawner

====Assign environment to a planet====
Last thing is to assign your brand new procedural environment to a planet where it is supposed to appear. Go to Content\Data\PlanetGenerator.sbc and find definition of the planet you want your environment to be on. Then assign the environment to the planet by adding following line to the planet definition with name of your environment:
<pre>
<Environment>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>NAMEOFYOURENVIRONMENTDEFINITION</SubtypeId>
</Environment>
</pre>
SutypeId refers to the name of the environment from:
Content\Data\Environment\ProceduralEnvironments.sbc

''Note: This is not necessary if you just modded existing vanilla environment and have not changed its SubtypeID''

===Ores definitions modding===
[[File:BlueChannel.jpg|frameless|22px]]

Ores are placed using blue channel of the material texture to set where should ore deposits appear. When your ore deposits are painted on the material map, you need to define what ores will be there. Go to Content\Data\Environment\ProceduralEnvironments.sbc to tell game which ore should appear at specific blue channel value.

<pre>
<OreMappings>
<Ore Value="130" Type="IronOre_RichYield" Start="3" Depth="7" TargetColor="#b7340a" ColorInfluence="15 "/>
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
<Ore Value="110" Type="IronOre_PoorYield" Start="2" Depth="5" TargetColor="#a76a41" ColorInfluence="15" />
</OreMappings>
</pre>
The section you need to use is Ore Mappings.
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
Value refers to blue channel value on material texture.
Type refers to name of a voxel material from Content\Data\VoxelMaterials.sbc.
Start is depth at which the ore deposit starts. Depth is how deep under ground it goes.
TargetColor is color that will be used to color surface above the ore.
ColorInfluence sets strenght of coloring.

==Working with RGB==
Ok, Steam won't let me share that link to a small RGB Photoshop tutorial with you, so just go to photoshopessentials.com and search for RGB and it's the first link.

This is a simple tutorial to explain you what we mean when we say Grayscale ID, which can also be called the RGB values
(each channel only has one number per shade of that color ranging from 0 to 255).

Here I have loaded a Biome map texture front_mat texture which is used on the Vanilla EarthLike planet.

[[File:RGBChannels.jpg|frameless]]These are the RGB channels as you can see them in Photoshop.

NOTE: Edit each RGB channel separately!

Always use the pencil tool to paint pixels.
The brush tool has a falloff that has different values and you will not have control over those!
[[File:Color Picker.jpg|thumb]]

You can see if the numbers are correct on the top right of the screen if you have your workspace set to Essentials.

Here you will enter the values you want to paint.
Make sure you check them before saving, sometimes Photoshop can move the number +-1 (personal experience).

It doesn't matter if the numbers match, just as long as you have the correct value (ID) in the correct channel!

==Height-maps modding - terrain shape, roads==
As mentioned in 2. Required software, we used the program World Machine to create our heightmaps and then we did some minor tweaks by hand (like putting in lakes and desert areas)

First, to explain how our planet heightmaps work:
We have 6 textures that connect together (image below). Our standard resolution for a big 120km planet is 2048x2048. But you can use a lower one if you want to.

To create your own heightmap, the best action would be to find a heightmap here:
C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\PlanetDataFiles

Then you can open the texture and place yours/paint yours on a new layer, flatten the image and save it as a .PNG

There are other options for you also!
You can visit[terrain.party] this site and download a heightmap from a real place on Earth. You can even set the size of the map (maximum is 60 km). And then you can edit it further in Photoshop.
You can try painting it yourself in Photoshop (or any other similar software, like Gimp).
You can also just try Googling for heightmaps and try which one suits you the best (keep in mind the resolution must be 512,1024, 2048!)
However you get your heightmap, always keep in mind how each texture of the heightmap is connected, so the seams need to fit together. Bad texture connection is very visible in the game.
Here is an image of how the textures are connected:

[[File:Planet Material Texture Order.jpg|512px]]

===Roads===
We created roads using World Machine tools. You can find guide how to do that in between World Machine tutorials.

==Atmosphere==
[[File:View Image.jpg|1024px]]

Here, you will find everything you ever wanted to know about Atmosphere Settings in Space Engineers but were afraid to ask, my dear friend. So without any further ado. Let’s start with the “Atmosphere” settings window which you access in-game by hitting F12 -> Render Button -> Atmosphere checkbox. The new Atmosphere settings window opens immediately on the right side of the screen, showing a bunch of tricky sliders.

[[File:Cloud Layers Definition.jpg|1024px]]

If your pants are still dry, and if by any chance you’re still reading this, let us assure you that everything is pretty simple and not so scary as it may seem when you first open it. So let’s start with the brief and really quick explanation of what every slider or group of sliders are meant for. Lastly, remember that to alter any setting in this Window you have to hold “Alt” on your keyboard.

Enable Atmosphere (checkbox) – Well, as Captain Obvious immediately states to us – it just enables or disables Atmosphere on a planet and nothing more.

Time of Day (slider) – Controls rotation of the Sun around a Planet. You’re given the Power to decide which time of day it is now. Cool isn’t it?

Pick Planet (Button) – In situations when you have more than one planet in your world, you may want to alter the settings of each planet’s atmosphere individually. So this button enables you to immediately pick the current atmosphere values of the planet you’re currently on. For example, fly to the Moon, press “Pick planet” button and you will get corresponding atmosphere values of that planet to play with. Fly back to Earth or any alien planet, and do the same to alter atmosphere settings of these planets. Yay!

Rayleigh Scattering R,G and B (sliders) – Group of three sliders which control the main, overall color of the Atmosphere. It’s that atmosphere color which is going to be seen from outer space and on the ground too! If you want to make your atmosphere alien green or purple – these are the correct set of sliders to play with. Each slider controls corresponding R,G or B (0-255) values. Pretty straightforward.

[[File:Atmosphere Settings.jpg|512px]]

Mie Scattering R, G and B (sliders) – Group of three sliders to control the color of the Sun glow. It would be weird to have Green atmosphere and Red sun glow right? You would normally want to set it to yellow or something light green or so. But it’s your choice you can make any color you want. But please note that in order to have noticeable results you have to actually HAVE that glow around your sun. This setting is called “Mie Height” and it has to be set to a fairly high value otherwise it wouldn’t be too prominent. We will talk about this “Mie Height” setting in a minute. No worries.

The following three sliders are complementary and play well together. It means you have to find a good balance setting them which is quite easy:

Rayleigh Height Surface (slider) – Controls the thickness of the atmospheric layer when you’re on or near planet’s Surface. For example. You normally want atmosphere layer to be fairly thick to cover high points of the planet’s surface like mountains and high hills while you’re on the ground because you have actual high picks in your surface geometry which you have to cover. Otherwise you would see black space when you’re on the high mountain. But technically, when you’re leaving the planet’s atmosphere all of these high peaks and mountains are starting to slowly collapse vertically forming a smooth spherical shape of the planet, if they wouldn’t - we would have planets looking like a spiky balls with mountain peaks sticking out in all directions. That’s why when all the high peaks are collapsed to the ground to form a perfect sphere - we are left with abnormally thick and wrong looking atmospheric layer thickness when observed from the outer space. How to fix this?! That’s where “Rayleigh Height Space” slider comes into play, as it controls the thickness of the atmospheric layer seen from outer space.

Rayleigh Height Space (slider) – Controls the thickness of atmospheric layer when you observing the planet from outer space. Like it was said earlier, settings for atmosphere thickness when you’re on the Surface and when you’re in an outer Space can’t be same and normally you want to make it much thinner when it is seen from outer space like it’s in real world. Refer to the following Pic to get better understanding.

Rayleigh Transition (slider) – Ok, so now that we have set the width of the planetary atmosphere for both - when we’re on the Surface and when we’re observing it from outer space, it is time to decide at which distance to switch between two, right? So that’s exactly what this slider does – sets the exact value at which distance that transition must happen. You can play around with this value to find the best setting, just remember that the main goal is to have this transition as smooth as possible, fortunately it’s super easy to achieve. Just make sure that while you’re on the ground and standing on a highest point you still see some atmosphere color (like Blue color in earthlike planets) ,and just about when you start to see the whole planet on your way to the outer space, switch it to the thinner (Rayleigh Height Space) version.

Mie Height (slider) – Controls the size of the outer glow effect of the Sun. Like it was said earlier, when you’re setting your color of the Glow effect via “Mie Scattering RGB” sliders, this particular setting (Mie Height) must be set to a fairly high value otherwise you won’t see it as there won’t be any glow. Look, you can’t change the color of a non-existing thing, soldier. Dismissed!

Sun size (slider) – Controls the size of the Sun.. What else did you expect from it?!

Sea Floor modifier (slider) – Defines the lowest (starting) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer starts. It depends on your planet’s relief, your lowest and highest peaks. Adjust individually for each planet. You’ll “feel” the right value immediately.

Atmosphere Top Modifier (slider) – Defines the highest (ending) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer stops. It depends on your planet’s relief. Adjust individually for each planet. You’ll “feel” the right value immediately. But normally you want this value to be set pretty high.

Intensity (slider) – Actually it should be called “Fog Intensity” as it’s exactly what it’s responsible for but I hope it will be changed by some coder guys eventually J. Controls the amount or intensity of the fog while you’re on or near the planet’s surface (doesn’t do anything when you’re in outer space).

Fog Intensity (slider) – And this, should be actually called “Fog Distance”. It controls the distance fog actually covers. The higher this value – more objects in front of view are covered with fog. (doesn’t do anything when you’re in outer space).

Restore (Button) – Ok, just in case you screw everything up, you always have a chance to revert all the changes you’ve made by clicking this Restore button, soldier! Very convenient isn’t it?!

==Atmosphere 2/2==
Ok, now that we got acquainted with all Atmosphere settings and know how they work, it is time for us to actually change a few settings to alter the look of our Atmosphere! Now the fun part begins. Let’s say that we want to change the color of Earthlike planet’s atmosphere from its natural Blue color to the Green one, so it looks more “alienish”. Please note, that all atmosphere settings are stored in “PlanetGeneratorDefinitions.sbc” file and they are NOT replaced even when you change these values in game and make a save. If you want to change those values you have to change them directly in the code of the “PlanetGeneratorDefinitions.sbc” file only! The system reads those atmosphere values from this file every time you’re loading your worlds.

But how for God’s sake would you know which values are correct and really desirable to put them in the code? This is really simple. You just adjust your atmosphere settings to your liking right in the game, and when you’re done and happy with it, you just copy those values into the code (you can screen grab the in-game view with Atmosphere Settings window or just write them down manually, not a big deal) But to paste those values in the code, you have to know WHERE to paste it, right? You don’t just randomly paste numbers into the code, do you? You may hurt yourself!

So please open “PlanetGeneratorDefinitions.sbc” file in any decent text editor and find the following line:
<pre>
<SubtypeId>EarthLike</SubtypeId>
</pre>
It’s a name or identifier of a planet, and since it’s named Earthlike, we know for sure that below are the definitions related to Earthlike planet. Cool! Now just scroll down to the part where you will see a commented (inactive) line of code which goes like:



Or alternatively, just Ctrl+F to find the following line. You must see something similar to this:

[[File:Atmosphere definition.jpg|512px]]

So here as you can see everything is pretty self-explanatory. Except a few lines that are just named differently in the code. If you want your atmosphere to “remember” the settings you have made you have to enter those values here to the corresponding lines. The following schematic pic shows dependencies between the code lines and the slider names in Atmosphere Settings window quite clearly:
(Click to enlarge)

[[File:In-game Atmosphere Debug Input.jpg|1024px]]

Now let’s just change the blue color of the atmosphere to orange. As you remember, group of three RGB sliders named “Rayleigh Scattering” are responsible for changing the main color of the Atmosphere. So why wait?

[[File:Mars-Like Atmosphere.jpg|1024px]]

Spectacular right? Now, let’s change the sun glow color “Mie Scattering RGB” to an orange tint too. It could stay the same yellow of course but let’s change it so you could have an idea. Remember to press “Alt” on your keyboard while you’re dragging those sliders.

[[File:Another Red Atmosphere.jpg|1024px]]

Ok, now it’s more orange but we have to increase the glow effect a bit to see it more prominently. And as we remember, the glow size control is “Mie Height” slider. Crank it up from 30 to 50.

Good, the glow effect became more prominent. Looking nice isn’t it? Of course, you can continue adjusting it and come up with really crazy results, but if you’re ok with what we already have, then just write down all the values that you currently have in your Atmosphere Settings window on the right or screenshot them and paste into any image editor for your reference. And back in the code editor, just enter those values into corresponding tags in the code and save it:

[[File:CloseUp Atmosphere definition.jpg|512px]]

That’s it! From now on, every time you load up your world with Earthlike planet in it, or spawn Earthlike planet, the atmosphere on it will be exactly the way you adjusted it via Atmosphere Settings! The God himself must have been using something like this we suppose..

[[File:Mars-like Atmosphere Final.jpg|1024px]]

==Clouds==
The first thing that should (probably) come in to your mind when you finally learn how to tweak Atmosphere settings, is probably how to change the look of the Clouds! Because, normally, when you change the color of the atmosphere you would like the clouds color to be relatively close to the Atmosphere color. In our Atmosphere guide (if you read it) we were sharing some knowledge about changing the look of the Atmosphere. We made it orange which is kind of cool all on its own, but what really draws our attention and not in a very good way – is the color of the clouds. As you can see they’re white which is looking wrong isn’t it? In an orange atmosphere environment you would expect orange or yellow clouds right? So that’s what we’ll be doing in a minute – changing the look of our cloud layer and getting to know their under-the-hoods.

Like with Atmosphere settings, the Clouds setting are stored in the same “PlanetGeneratorDefinitions.sbc” file located in KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Data and are individual for each planet. Usually we base our code lines so the Cloud definitions come right after Atmosphere definitions which makes it very convenient to search for. Just open your “PlanetGeneratorDefinitions.sbc” file in any decent advanced text editor and search for this commented (inactive) line of code:



Note: you can download the DDS files from here[mirror.keenswh.com]

[[File:Cloud Layers Definition.jpg|1024px]]

That’s where all the cloud settings for particular planet are stored. The following picture is a brief breakdown of cloud definitions:

Basically, the structure of placing clouds on any planet is as follows:
<pre>
<CloudLayers>
<CloudLayer>
Blah Blah Blah Beautiful Clouds Blah Blah Blah
</CloudLayer>
</CloudLayers>
</pre>
So, as you can see everything is super easy. Simply put, <CloudLayers> tags are meant for global separation of Cloud definitions from other code definitions and are here just to define where the code for the clouds start, while <CloudLayer> tags (again, don’t mistake with CloudLayers) are the actual cloud layers and each pair of these tags (<CloudLayer>…</CloudLayer>) define the look and behavior of each cloud layer. As Captain Obvious states - The more <CloudLayer> pairs you have.. umm - the more cloud layers you will have!

For example. You can have more than one Cloud layer, to simulate even more complex cloud patterns than you initially had in your texture file! And that’s when <InitialRotation> and <RotationAxis> tags come into play. You can assign values to these tags for each Cloud layer individually thus having the cloud spheres to be initially rotated and spinning on different angles creating more interesting and natural cloud patterns. So you basically just stack them this way:
<pre>
<CloudLayers>
<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>
</CloudLayers>
</pre>

That’s it! Now you have three Cloud Layers! And of course you can do it for the Far and the Near cloud layers as well.

Your main cloud color texture must be 4096x2048px RGB file saved in DDS format without alpha as “CloudName_cm.dds file” and it must contain only the color information of your clouds. For Alphamask file please create a separate file of the same 4096x2048px dimensions containing only Alpha mask, make it a greyscale file, save as DDS luminance format and name it “CloudName_Alphamask.dds”. Back in the code, in <texture> tags you just write “Cloudname.dds”, no worries - the engine will identify required “cm” and “alphamask” files itself, just make sure both files are in the correct folder. (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Models\Environment\Sky).

As you know, clouds that are seen from the outer space and the clouds that you see through your window don’t look the same because of the huge differences in scales in both cases. That’s why we have two types of clouds on each planet. First one (commented as “Far layer” in the code) – the clouds that you see from the outer space. They usually look like NASA satellite orbital photo shots.

[[File:Clouds.jpg|1024px]]

And the Second one (commented as “Near layer” in the code) – the clouds that are seen when you’re on the ground or close to it. These should look like a significantly zoomed version of the first ones - more detailed, wispy and more individual. Like the ones you used to see in the sky every day. Refer to the picture.

[[File:LargeClouds.jpg|1024px]]

Now, how to actually separate these two types of cloud layers and to make them come in layers – one after the other. This is very simple too. The maximum overall Altitude (height) of our atmosphere layer is 2. So we have to set up our cloud layers in a tricky way, so that when we’re in outer space - we would see the “Far layer” clouds ONLY, and as we’re getting lower (approaching the ground), on a particular altitude (height) smoothly switch to the “Near layer” clouds and have the “Far layer” clouds hidden. Sounds crazy but it will become clear if you look at the following pic:

[[File:CloudLayerDiagram.jpg|1024px]]

As you can see things are really self-explanatory here too. By setting the Start and End values in <FadeOutRelativeAltitude..> you basically create a vector, the starting point of which is infinity which means anything below this start point will be constant value, thus – making it possible to set the Far layer to be seen from outer space (values greater than 2), and preventing Near cloud layer from being seen - because it is set to fade out on 1.6. And vice versa – when you’re on the ground, you won’t see Far layer clouds layer because it faded out on much higher distance of 1.4. Not so hard right? Of course you can alter and tweak those values to your liking depending on the planets height maps/relief to get the desired transition between Far and Near cloud layers.

So now that we’re empowered with this knowledge, the only thing we’re left to do is to actually change the color of the clouds from white to yellow color so our clouds look more natural in an orange Atmosphere environment. As we remember, our clouds are consisting of two texture files – a file containing color information (usually just a plain color) and a file with an alpha mask only. We already know that the “Far layer” clouds (the ones seen from space) use “EarthFarClouds_cm.dds” texture file and the “Near layer” clouds use “Landsky_texture_cm.dds”. How we know that? It’s written in <texture> </texture> definitions, remember?

[[File:CloudTextureRoute.jpg|512px]]

Great! So now just open “EarthFarClouds_cm.dds” and the “Landsky_texture_cm.dds” and fill both files with plain yellow color and save them!

[[File:YellowCloud Texture.jpg|1024px]]

Start the game and spawn an Earthlike planet and voila! You got perfect yellow clouds!

[[File:Scenery With Yellow Clouds.jpg|1024px]]

==Planet ambient sounds modding - day/night biome sounds==

Sound rules are in the Content\Data\PlanetGeneratorDefinitions.sbc file. Here you can set different sounds based on player’s location or daytime on the planet.
<pre>
<SoundRule>
<Height Min="0" Max="0.5"/>
<Latitude Min="55" Max="80"/>
<SunAngleFromZenith Min="0" Max="180"/>
<EnvironmentSound>AmbIcelandDay</EnvironmentSound>
</SoundRule>
</pre>
Height stands for where you want the sound to play at the height of the heightmap (0-7200m). It is always +12% of the planet's diameter. 0 is from the the lowest start of the surface to 1.0 which is 100% of the surface (maximum height).
Latitude means angle from the equator. Therefore 0 to 20 will mean that this sound will mostly play in the desert area, 20-50 is mostly the green forest area, and so on.
SunAngleFromZenith NEEDS MORE INFO!!!
EnvironmentSound this is the name of the sound you want to use.

You can find all available sounds in Audio.sbc (location shown below) Here you will also put your own ambient sound with your own custom name.

How to implement custom ambient sound

All Ambient sounds are stored here:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Audio\ARC\AMB\

If you want your own sounds, they should be a loop sound, and on average should not be bigger than +-5 MB.
The supported format is: .xwm but .wav can also work, even though its file size is usually a lot bigger (not recommended).

Once your audio is done, implement it here in this file:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\Audio.sbc
<pre>
<Sound>
<Id>
<TypeId>MyObjectBuilder_AudioDefinition</TypeId>
<SubtypeId>AmbAlienForestDay</SubtypeId>
</Id>
<Category>AMB</Category>
<MaxDistance>100</MaxDistance>
<Volume>0.2</Volume>
<Loopable>true</Loopable>
<Waves>
<Wave Type="D2">
<Loop>ARC\AMB\AmbAlienForestDayLoop2d.xwm</Loop>
</Wave>
</Waves>
</Sound>
</pre>
Here edit only what is highlighted, otherwise I cannot guarantee that it will work properly!
<SubtypeId> This is how you will name your AMB sound, keeping in mind upper and lower case letters. Do not use _ or other special characters!
<Volume> This is self explanatory I hope.
<Loop> Here you just need to lead the definition to your file. ARC/AMB/ is the default location, so do not change that.
But if you want, you can make another folder in AMB for your custom ambient sounds for better organisation.

==In-game map modding==
Maps in Medieval Engineers are generated based on terrain and buildings on it. This means that they will work for any modded planet in their default form. That being said, the way map is generated is also fully moddable.

We definitions for map are located in Content\Data\Screens\MapDefinition.sbc. To mod maps you will have to alter/add definitions in this file, all vanilla textures for maps can be found in Content\Textures\GUI\Map. Feel free to use/alter any of them for creation of mods for Medieval Engineers.
Map content modding (Friend/foe display, tax notifications,...
In Medieval Engineers there are 2 view modes of map. Kingdom view which is showing entire kingdom and region view which is zoomed part of a kingdom map. Region is 1kmx1km large on 10 km diameter planet. Both views display different elements.
What is shown in these views depends on what layers it contains
<pre>
<Definition xsi:type="MyObjectBuilder_PlanetMapDefinition">
<Id Type="MyObjectBuilder_PlanetMapDefinition" Subtype="Main"/>
<BackgroundGenerator Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
<RegionView>
<Layers>...</Layers>
</RegionView>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</Definition>
</pre>
BackgroundGenerator refers to a definition of background texture that serves as a background on top of which all the map elements are placed.
<pre>
<RegionView>
<Layers>...</Layers>
</RegionView>
</pre>
The three dots in middle represent layers of elements that show in region view. List and description of all layers is in next section of this document.
<pre>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</pre>
The three dots in middle represent layers of elements that show in kingdom view. List and description of all layers is in next section of this document.
(I did not Kingdom view in its expanded form because it would take up too much space.)

===Layers description===
<pre><Layer xsi:type="MyObjectBuilder_MapBackgroundLayer" /></pre>
This layer draws the background. As generated based on chosen background definition.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaDevelopmentLayer">
<Threshold BlockCount="10" Sprite="Textures\GUI\Map\SmallGrid.png"/>
<Threshold BlockCount="30" Sprite="Textures\GUI\Map\MediumGrid.png"/>
<Threshold BlockCount="60" Sprite="Textures\GUI\Map\LargeGrid.png"/>
</Layer>
</pre>
This layer displays icons based on amount of blocks there is in an area. You can set the block thresholds, or mod the textures. It is also possible to add more thresholds. 80x80 px, png.

[[File:Smallest Settlement.png|150px|frameless]]
[[File:Medium Settlement.png|150px|frameless]]
[[File:LargestSettlement.png|150px|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_RegionFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for region, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaOwnershipLayer">
<AlliedBgColor Hex="#806464FF" />
<PlayerBgColor Hex="#8064FF64" />
<EnemyBgColor Hex="#80DC6415" />
</Layer>
</pre>
This layer defines color overlay over map areas based on ownership. You can mod which color is used for allies, your own areas or for enemies
<pre>
<Layer xsi:type="MyObjectBuilder_AreaUpkeepLayer">
<TaxIcon>Textures\GUI\Map\TaxIcon.png</TaxIcon>
</Layer>
</pre>
This layer displays tax icon on areas that belong to you and require tax payment soon. Texture is 80x80 pixels, png.
[[File:Taxes.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapPositionLayer">
<LocalPlayerImage>Textures\GUI\Map\PlayerPosition.png</LocalPlayerImage>
<OtherPlayersImage>Textures\GUI\Map\AllyPosition.png</OtherPlayersImage>
</Layer>
</pre>
PlanetMapPositionLayer displays player icon above area where they are.
[[File:Ally.png|frameless]]
[[File:Player.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_ActionTrackingLayer">
<ActionImage>Textures\GUI\Map\Action.png</ActionImage>
</Layer>
</pre>
Shows icon over an area on map with fighting / destruction.
[[File:AttackedArea.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_CurrentMapSelectionLayer">
<SelectionImage>Textures\GUI\Map\MapSelection.dds</SelectionImage>
</Layer>
</pre>
This is highlight of a region, that player selected with his mouse.
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapGridLayer">
<GridColor R="0" G="0" B="0" A="228"/>
</Layer>
</pre>
This layer sets which color is the grid drawn.
<pre>
<Layer xsi:type="MyObjectBuilder_KingdomFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for kingdom, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_RegionOwnershipLayer">
<PlayerIcon>Textures\GUI\Map\PlayerLandIcon.png</PlayerIcon>
<AllyIcon>Textures\GUI\Map\AllyLandIcon.png</AllyIcon>
<EnemyIcon>Textures\GUI\Map\EnemyLandIcon.png</EnemyIcon>
<PlayerAllyIcon>Textures\GUI\Map\PlayerAllyLandIcon.png</PlayerAllyIcon>
<PlayerEnemyIcon>Textures\GUI\Map\PlayerEnemyLandIcon.png</PlayerEnemyIcon>
<AllyEnemyIcon>Textures\GUI\Map\AllyEnemyLandIcon.png</AllyEnemyIcon>
<PlayerAllyEnemyIcon>Textures\GUI\Map\PlayerAllyEnemyLandIcon.png</PlayerAllyEnemyIcon>
</Layer>
</pre>
RegionOwnershipLayer generates textures used to express ownership on regional map.

===Background generator (trees, mountains, roads,...)===
Map background is where all the trees, mountains, hills are drawn. It is also capable of coloring map based on what is in planet’s material map (this is how we make roads for example).
All settings for map background are in MedievalMapBackgroundDefinition. The definition also in Content\Data\Screens\MapDefinition.sbc. I will go through various parts of the definition.

<pre><Id Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
Type of the definition says that this map background definition. Subtype is name of this specific background definition. If create your own background with unique subtype
Make sure you create your own background with unique subtype

<DrawHeightmap>false</DrawHeightmap>
When set on “true” planet’s heightmap is drawn under the map.
<Resolution>4096</Resolution><
Sets resolution of the generated in-game map.

<Features>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</Features>

<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</Definition>
</pre>
===Map Coloring===
You can use colors in material or biome map of a planet to appear on the game map. (roads for example). You define map coloring in a node called ”Features”. The coloring uses colors from planet material texture. You can learn more about material texture in biomes modding and surface material modding.
<pre>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
</pre>
This specific feature is used for painting roads on map with dark brown color. In Color you define which color will be the in-game map colored. Material=”67” decides where will be the color applied and refers to a red channel value on planet material texture.
<pre>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</pre>
This specific feature is used for painting forests on map with opaque brown. In Color you define which color will be the in-game map colored. Biome=”60” decides where will be the color applied and refers to a green channel value on planet material texture.

===Sprites===
Medieval Engineers map can also place sprites on map based on terrain shape. All the sprites are on one texture
<pre>
<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</pre>

[[File:AtlasCoordinateUsage.png|512px]]

Note: Illustrates how sprite is defined on our spritesheet. Example sprite:
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />

==Voxel color overlay modding==
We have a cool tech that enables us to color-shift color of almost any item in the game. Currently we are using it for trees(adds small color variations to the same model of a tree) and voxels above iron deposits.
==Fast travel settings modding==
In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around.
In this section of the guide we will show you how to mod which sectors are blocked.
There are 2 ways you can go about it:
===Generate automatically based on terrain shape===
Game is capable of creating fast travel map on its own based on height and terrain steepness. It is possible to mod thresholds for both height and steepness.
You will find the thresholds in Content\Data\Game\FastTravel.sbc. In a MyObjectBuilder_TerrainReachabilityProviderDefinition.
<RiseThreshold> - Sets min. terrain height change which will cause that area is unreachable.
<HeightThreshold> - Sets height of terrain after which area is unreachable, if it goes over this value. Range is 0 - 1.

If there are texture overrides in the definition, you have to erase them in order for the parameters to take effect. Texture overrides are nodes that are called in this fashion: <OverrideNAMEOFFACE>. You will learn more about these overrides in the next part of Fast travel modding.

===Creating fast travel texture override===
If you want to have full control over which areas are reachable and which are not regardless of terrain, you can create a simple texture on which you mark unreachable areas.

The texture is 80x80 pixels, RGB 8 bit. Black pixels forbid entrance.

When you have the texture, select route to it in the definition:
<pre><OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward></pre>
Reachability definition example:
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>
<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>
<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
</Definition>
</pre>
This definition would generate fast travel reachability everywhere, except for front planet face (Fareon kingdom) where fast travel reachability is created based on your texture.

===Development reachability===
Claimable area size, border highlight, contested timer modding
Size of the area and highlight properties are moddable as well.

===Area borders highlight===
<NeutralColor R="225" G="32" B="0" A="64" /> - Set color of an unowned territory
<SelfColor R="0" G="255" B="0" A="64" /> - Sets color of area border owned by you
<AliedColor R="65" G="105" B="225" A="64" /> - Sets color of area border that belongs to allies
<EnemyColor R="225" G="32" B="0" A="64" /> - Sets color of area border that is hostile
<WallSettings Depth="15" Rise="3" SegmentCount"71" End="115" /> - Changes shape of the border. Depth sets how deep is border submerged. Rise sets how tall is the border.
<Fade Start="71" End="115" /> - This sets at which point the border starts to fade.
Contested timer
When players claim area with claimblock, area goes to a “contested” phase for some amount of time, in this phase other players can still attempt to build their own claim block and claim the area. This time is moddable.
Content\Data\Game\SessionComponents.sbc contains definition called MyObjectBuilder_AreaOwnershipSystemDefinition. To mod this value, add this definition to your mod with changed value of <ContestedTimeInMinutes> parameter.

==Permissions modding - what is/isn’t allowed to do in claimed areas==
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.
Description of available actions to set permissions for:
Name=”Build” -> block placement permissions
Name=”Repair” -> Repairing/building already placed blocks
Name=”Deconstruct” -> Deconstructing
Name=”QuickDeconstruct” -> Faster deconstruction
Name=”VoxelEdit” -> Mining or shoveling
Name=”Destroy” -> Damage with hand weapons
Name=”Interaction” -> Chest opening, door opening
Name=”ClaimBlockInteraction” -> ClaimblockGui

===List of available Groupnames:===
Groupname: “Owner” -> Player who owns area
Groupname: “Allies” -> Mostly faction members of owner of the area
Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
Groupname: “Enemies” -> Players in factions that are hostile to your faction

==Compass modding==
It is possible to mod visual look of an in-game compass. All definitions of compass are stored in Content\Data\GUI\CompassDefinition.sbc. Our textures for compass are in Content\Textures\GUI\Compass folder if you want to check out how they look or use them in your mod.
===Creating compass texture atlas and setting coordinates for its elements===
Just like with map sprites, we save main compass elements on a single texture, then define parts of it using pixel coordinates. First setup origin point, then add width and height of the rectangle
Example texture coordinates for top part of the compass:
[[File:CompassTextureCoordinates.png|1024px]]
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>

===Explanation of compass definition line by line===
<pre><Texture>Textures/GUI/Compass/compass.png</Texture> </pre>
Route to a texture atlas.
<pre><KingdomIcon>Textures/GUI/Compass/Icon-Kingdom.png</KingdomIcon> </pre>
Route to icon symbolizing a kingdom.
<pre><Padding>7</Padding></pre>
Padding is added vertically between the top and bottom textures and the edges of the contents of the compass.
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>
Rectangle in the texture that contains the top part.
<pre><BottomCrop X="0" Y="0" Width="0" Height="0"/></pre>
Rectangle in the texture that contains the bottom part.
<pre><BackgroundCrop X="0" Y="64" Width="512" Height="64"/></pre>
Rectangle in the texture that contains the background.
<pre><ArrowCrop X="0" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the little marker used for elements that are drawn and have no icon.
<pre><MarkerCrop X="32" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the interval bars drawn every few degrees.
<pre><ShadowCrop X="64" Y="128" Width="80" Height="32" Left="8" Right="8"/></pre>
<pre><ShadowPadding Left="12" Top="8" Right="12" Bottom="8"/></pre>
Rectangle in the texture that contains the text shadows. Shadow is 3-Sliced, meaning the texture is split in three parts: [left|middle|right]
The sizes of left and right define the cropping lines that split the texture into three. The Sides are then always kep proportional as the texture is scaled.
<pre><VisibleRange>200</VisibleRange></pre>
Visible range in degrees.
<pre><Width>700</Width></pre>
Width in reference resolution pixels.
<pre><FontSize>1.1</FontSize></pre>
Scale of the font based on default.
<pre><VerticalOffset>0.065</VerticalOffset></pre>
Vertical offset from the top of the screen. 0 = top of the screen, 1 is the bottom. Compass is centered around this position.
<pre>
<TagStyles>
<TagStyle Tag="ClaimArea" Style="Bellow" MaxCharacters="15" Ellipsis="true"/>
<TagStyle Tag="Cardinal" Style="Above" MaxCharacters="1"/>
<TagStyle Tag="Kingdom" Style="Bellow"/>
</TagStyles>
</pre>
This section adds tags that are visible on compass and in which style. Currently we have 3 types of tags. Claim area - shows your claimed area on the compass, Kingdom tag shows kingdoms and Cardinal tag shows cardinal points (North, South,...). Each tag’s visual appearance is defined in tag/waypoint definition. Styles defines where should the text appear. Available styles: Center, IconOnly, NotShown, Bellow, Above.

===Explanation of Waypoint/Tag definition===
<pre>
<Definition xsi:type="MyObjectBuilder_WaypointDefinition">
<Id Type="MyObjectBuilder_WaypointDefinition" Subtype="Kingdom"/>
<IconPath>Textures/GUI/Compass/IconKeep.png</IconPath>
<Color R="255" G="255" B="255" A="255"/>
</Definition>
</pre>
IconPath contains path to the texture of kingdom icon. Color defines color of the text that is shown with the icon. (Example: Fareon, [[File:Kingdom Icon.png|thumb]])
===Compass texture vs in-game look comparison===
Texture:

[[File:Compas Texture with Zones.png|1024px]]

In-game look:

[[File:In-gameCompassZones.png|1024px]]
<NoWiki>*</NoWiki>note that background crop and bottom crop are not used in vanilla (empty opaque texture)

==Indestructible grids==
There is a way how to make some buildings in your save indestructible. We are using this feature for starting area buildings. Some you guys might make a good use of this feature in your pre-made worlds.

Currently, only way how to do this is to make edits to an existing save file. So you can only use it for world modding.

===Making indestructible cubegrids in existing safe===
Goal is to open world’s safe file in a text editor, find your cubegrid in it and add this tag to it: <DestructibleBlocks>true</DestructibleBlocks>.

#Find your save file. By default save files are stored in C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Saves
#Open folder with your save and find file called SANDBOX_0_0_0_.sbs. This file can be opened with any text editor you prefer.
#In the SANDBOX_0_0_0_.sbs search for the cubegrid name of the building you want to make indestructible. (use find/search function in your text editor, or you will grow old before you find it)
#Tip: To find out name of a cubegrid, create blueprint of the building. The name that the building saves as in your blueprint screen is the name of the cubegrid.
#You should find the name in tags called: <DisplayName>YOURCUBEGRIDNAME</DisplayName>
#Under the name, add following tag with setting set to false: <DestructibleBlocks>false</DestructibleBlocks>
#If you followed instruction, the indestructibility tag is now in node called <MyObjectBuilder_EntityBase> and not in any of its child nodes.
#Save the edited file.
#Load the save and test destructibility
#It worked! Enjoy
#It is still destructible. Go to point 1.

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding - Full Guide

2017-03-13T16:40:30Z

Lukas: /* Definition elements explained point by point: */

==Introduction==
Hello fellow Medieval Engineers!
I would like to present you with a guide that will help you understand how we created planets at Keen Software House and how to mod your own into the game.
Feel free to use/alter company owned files for your Medieval Engineers mods.

So let's get to modding!

==Recommended Software==
# Microsoft Visual Studio - or Notepad++ (Link[notepad-plus-plus.org]) - for opening files with .sbc extension where we have definitions for every feature in the game.
# Adobe Photoshop - for editing material and heightmap textures
# World Machine Professional - for heightmap easier creation (much more realistic looking terrain, without manual work)

(Basic Edition is also available, but the max resolution output is limited to 512x512 pixels)
http://www.world-machine.com

===Advice===
We would like to mention one thing before you get into modding planets:
For your own sake we recommend you to load either PlanetTemplate or EarthLikeModExample and test/edit all the things there, so you get to know the system and how everything works.

After that you can create your own from scratch. This is entirely up to you.

==General modding principles - how to make any mod==
I will explain again basic principles of how mods are applied.

All of our vanilla source files are all saved in a folder called content in your *game folder. If no mods are assigned to a world that you are loading, game uses only files from this content folder but if there are mods, game loads also files from mod adding more content or potentially rewriting vanilla content based on content of the mod’s folder. Mod is nothing else but a folder with another files.
Mod files are stored in mods folder on your computer , and if you are using them for the first time, they are downloaded from workshop first time you try to load/connect to a world with those mods.
Mod folder: C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Mods
===Opening mod and examining mods content===
When you open Mods folder, you will see mods as files with .sbm extension. But they are really just folders and to examine them, all you have to do is rewrite the extension from .sbm to .rar and then you can open them with rar and examine content.
Mods are not listed with their names, but with their steam id number. To find specific mod, you have to go to the mods workshop page

Examining other mods similar to your idea is a fast way to learn.
Example:

<NoWiki>*</NoWiki>By default this is SteamLibrary\steamapps\common\MedievalEngineers\Content. You can also get there if you go to steam library(same place where you start the game), right-click Medieval Engineers, select properties, local files and finally click on “browse local files”.
==Materials modding==
In case you are thinking about making your own trees and voxel materials, we have some good news for you!

There are two separate guides that you can follow to make your own stuff.

General modding guide - get started

===Voxel material modding===
http://steamcommunity.com/sharedfiles/filedetails/?id=568406623

==Planet Size==
Planet size is defined in a scenarios.sbc. Every time you click on create new world in the game it uses scenario definition to create a new safe file. Although this scenario definition is not moddable, you can still use it to create a world and share the world itself on the workshop.

First go to where you have Medieval Engineers source files and find Data folder (SteamLibrary\steamapps\common\MedievalEngineers\Content\Data\Scenarios.sbx)

==All planet related files overview and where to find them==
To summarize how planet modding in ME works, we can say this:
We use 2 types of textures and then we define how the game should interpret those textures in definitions. One texture is heightmap that is used just for generating terrain shape, another one is used to place everything else on the planet (ores, trees and plants, bots).
[[File:Diagram.png|1024px|center]]

==Material Texture modding==
Material texture is used to store information about location of various planet surface features. These features are surface materials, biomes (trees, bots, plants,..etc) and where you can find ore. Each one of these uses one color channel. Surface materials use red channel. Biomes use green. Ores are in blue channel.
We use 6 material textures (2048x2048) for each planet. You can find all our material textures here: Content\Data\PlanetDataFiles.
Each planet has its own folder. The folder has to have the same name as the planet.

[[File:MaterialMapBreakdown.jpg|512px]]

Illustration of how are the material textures connected to each other:

[[File:Planet Material Texture Order.jpg|512px]]

====The process of material texture creation is really simple. You have two options:====
=====Copy an existing map to your folder and overwrite the green channel and edit them to your liking=====
This is highly recommended to avoid errors!
=====Create a new: step by step in Photoshop=====
#Set both width and height to 2048 pixels
#(for smaller planets this can also be 1024 or less, but all textures need to have the same resolution! Even the heightmap)
#Set resolution - Pixels/Inch to 72.
#Set colour mode to RGB Colour - 8bit
#Now start painting with the pencil tool on each RGB Channel separately.
#Never on all three at once! (It will F. up everything - trust me).

===Surface voxel material definitions modding - grass, sand, snow===

[[File:RedChannel.jpg|22px|frameless]]

Surface “voxel materials” refers to what you know as grass, soil, stone.. We use red channel of the material texture to set where all the terrain appears. Then you need to write definitions in the Content\Data\PlanetGenerator.sbc to tell game which voxel should appear at specific red channel value.
Example of the definition of road:
<pre>
<ComplexMaterials>
<MaterialGroup Name="Road" Value="67">
<Rule>
<Layers>
<Layer Material="Soil" Depth="2"/>
</Layers>
<Slope Min="0" Max="90"/>
</Rule>
</MaterialGroup>
</ComplexMaterials>
</pre>
Example of corresponding material texture with road:

[[File:RoadMaterialTextureExample.png|512px]]

====Complex materials====
Complex materials definition allows to paint the map with a set of “voxel coloring rules”. Meaning that one color value in red channel can color terrain with different voxels based on rules like slope, longitude or latitude and height. (So with our road example)
<pre>
<MaterialGroup Name="Forest_Grass" Value="120">
<Rule>
<Layers>
<Layer Material="Woods_grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="0" Max="25"/>
<Latitude Min="-180" Max="180"/>
<Longitude Min="-180" Max="180"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="25" Max="45"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Rocks_grass" Depth="2"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="45" Max="55"/>
</Rule>
</MaterialGroup>
</pre>
This definition says what voxels should be generated in spots, that are painted with red channel value of 120.
The rules in this definition will lead to following:
Flat lands (up to 20 degrees slope) will have Wood grass 1 m thick, soil will be right under the WoodGrass up to 5 m depth and there will be stone underneath the soil.
In places with medium slope, there is Grass instead of WoodGrass. And in slopes from 45 to 55 there is rocks grass 2 m thick with stone right away under it.
With this technology, we can make the color react on its own to terrain bumps or even position on planet. This saves lots of meticulous painting with heightmap.

<Layer Material="Woods_grass" Depth="1"/>
Material refers to voxelmaterial definition. (You can find it in Content\Data\VoxelMaterials.sbc). Depth means how deep should the material go under ground.
<Slope Min="0" Max="25"/>
Slope of the terrain in degrees.
<Latitude Min="-180" Max="180"/>
Latitude in degrees. 0 degree is an equator.
<Longitude Min="-180" Max="180"/>
Longitude in degrees. 0 is in the middle of front planetary texture. (Fareon Kingdom)

===Biomes definitions modding - trees, plants and bots===
[[File:GreenChannel.jpg|frameless|22px]]

Biomes refers to everything that is spawned on top of the planet. We use green channel of the material texture to set where all the terrain features appear and definitions in the Content\Data\Environment\ProceduralEnvironments.sbc to tell game which environment item should appear at specific green channel value. Also you need to assign Environment to planet in the Content\Data\PlanetGenerator.sbc in case you are adding a brand new planet.

====First make/modify environment:====
Go to Content\Data\Environment\ProceduralEnvironments.sbc

=====Procedural World Environment definition=====
This definition defines where will the environmental items spawn and with which density. (note: bots are also considered environmental item). Best way to explain how procedural environment is working is to imagine that it puts spots on entire surface of a planet. And when you start defining trees, bots and bushes, the spots get “reserved” by these categories based on how many of those should appear in the world according to your mod.
Spots are always different for each single planet.
In order to mod the procedural environment, mod our “Earth Environment” definition. Or create your own but if you do, don’t forget to also mod PlanetGeneratorDefinition, so that planet has your new procedura environment assigned to it.

=====Definition elements explained point by point:=====
<pre>
<Definition xsi:type="MyObjectBuilder_ProceduralWorldEnvironment">
<Id>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>Earth Environment</SubtypeId>
</Id>
</pre>
This part of definition is called ID. It says what type of definition this is <TypeID> and unique name of that definition <SubtypeID>.

<pre>
<MaxSyncLod>1</MaxSyncLod>
</pre>
This line defines how far away from player are the environmental items updating. This is important feature for optimization.

<pre>
<SectorSize>40</SectorSize>
</pre>
This is size of the environmental sector. It is a different sector than the claimable areas by players. It sets size of one environmental sector.

<pre>
<ItemsPerSqMeter>0.17</ItemsPerSqMeter>
</pre>
The line sets overall maximum density of all environmental items. To return to analogy i used in the introduction, this number increases the amount of spots on the planet that are reserved for all environmental items.

<pre>
<ScanningMethod>Random</ScanningMethod>
</pre>

<pre>
<ItemTypes Type="MyObjectBuilder_EnvironmentItemTypesDefinition" Subtype="Default"/>
</pre>
This sets which types of environmental items are used in this procedural environment definition. This guide explains what are Environmental item types in the very next section.

<ItemGroup Density=".017" Name="Bots" LodStart="1" LodEnd="1">
<Mapping>
<Material>Woods</Material>
<Item Type="Bot" Subtype="Deer"/>
</Mapping>
<Mapping>
<Biome>60</Biome>
<Height Min="0" Max"1"/>
<Latitude Min="-180" Max"180"/>
<Longitude Min="-180" Max"180"/>
<Slope Min="0" Max"1"/>
<Item Type="Bot" Subtype="Deer" Density="0.9"/>
<Item Type="Bot" Subtype="Barbarian" Density="0.1"/>
</Mapping>
</ItemGroup>
Item group is used to organize and better manage mappings. Mappings are definitions that actually add the environment items in the world. It is important to set Density correctly. Density (Density=".017") sets how many of the procedurally generated spots on the planet will be assigned to environmental items from this group. The name (Name="Bots") is only for naming purposes within definition and has no impact on the game. LodStart="1" and LodEnd="1" control how far from the player will the items appear.
<Biome>60</Biome> This section means that Items within this mapping will only appear on spaces that are painted with green channel value 60 on the material map.
<Material>Woods</Material> This means that the environmental items will only appear in the woods.
<Height Min="0" Max"1"/> Sets in which altitude should these environmental items appear. If this parameter is missing, items spawn in full range (Min="0" Max"1")
<Latitude Min="-180" Max"180"/> Sets at which latitude do the environment items spawn. If this parameter is missing, items spawn in full range (Min="-180" Max"180")
<Longitude Min="-180" Max"180"/> Sets at which longitude the environment items spawn. If this parameter is missing, items spawn in full range (Min="-180" Max"180")
<Slope Min="0" Max"90"/> Sets at which slopes the environment items spawn. If this parameter is missing, items spawn in full range (Min="0" Max"90")

<ItemGroup Density=".085" Name="Trees" LodStart="-1" LodEnd="1">...</ItemGroup>
LodStart="-1" means that the items will be visible all the time. Will not go into settings of this Item Group, since it more of the same.
<ItemGroup Density=".36" Name="Small Items" LodStart="0" LodEnd="0">...</ItemGroup>
</Definition>

=====Environment items=====
We learned how to assign environments to planets and how to mod environments themselves by changing densities and environment items. But we still don't know how to make the environment items themselves. Guides for those can be found on following links.

If you want to mod trees:

If you want to mod bushes and plants:

If you want to mod bots:

=====EnvironmentItemTypesDefinition=====
Here you define various types of items. Currently we have these types: Tree, Gatherable, Farmable, Static and Bot. Before you add any item, you must make sure it fits within these types of environment items or you created a new type for them.
<Definition xsi:type="MyObjectBuilder_EnvironmentItemTypesDefinition">
<Id Type="MyObjectBuilder_EnvironmentItemTypesDefinition" Subtype="Default"/>
<Item Name="Tree">...</Item>
<Item Name="Gatherable">...</Item>
<Item Name="Farmable">... </Item>
<Item Name="Static">...</Item>
<Item Name="Bot">...</Item>
</Definition>

EnvironmentItemTypes
<Item Name="Tree">
<ProxyActivationLod>0</ProxyActivationLod>
<Provider Type="MyObjectBuilder_ProceduralEnvironmentModuleDefinition" Subtype="Growable"/>
<Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Gatherable" />
<Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Cuttable" />
</Item>
Available proxy and providers:
Proxy Subtype="Gatherable"
This line adds ability to all environmental items of this type to use action “Gatherable”. Keep in mind that the tree itself has to be setup properly in order for this to work.
Proxy Subtype="Cuttable" />
This line adds ability to all environmental items of this type to use action “Cuttable”. Keep in mind that the tree itself has to be setup properly in order for this to work.
<ProxyActivationLod>0</ProxyActivationLod>
This line says from which lod is the game logic attached to the environmental item. (when set on 0 only trees very close to you become “gatherable” and “cuttable”). This way we don’t use game logic on environmental items that couldn’t be used anyway and game is better optimized thanks to that.
Provider Subtype="Growable”
This line adds ability to all environmental items of this type to grow. Keep in mind that the tree itself has to be setup properly in order for this to work.
Provider Subtype="Farmable”
This line adds ability to all environmental items of this type to be farmable. Keep in mind that the tree itself has to be setup properly in order for this to work.
Provider Subtype="Static”
This line adds basically adds items that do nothing. They are just visual props. Like some of our fern bushes.
Provider Subtype="BotSpawner”
It is important that all environmental item types that will contain some bots have botspawner

====Assign environment to a planet====
Last thing is to assign your brand new procedural environment to a planet where it is supposed to appear. Go to Content\Data\PlanetGenerator.sbc and find definition of the planet you want your environment to be on. Then assign the environment to the planet by adding following line to the planet definition with name of your environment:
<pre>
<Environment>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>NAMEOFYOURENVIRONMENTDEFINITION</SubtypeId>
</Environment>
</pre>
SutypeId refers to the name of the environment from:
Content\Data\Environment\ProceduralEnvironments.sbc

''Note: This is not necessary if you just modded existing vanilla environment and have not changed its SubtypeID''

===Ores definitions modding===
[[File:BlueChannel.jpg|frameless|22px]]

Ores are placed using blue channel of the material texture to set where should ore deposits appear. When your ore deposits are painted on the material map, you need to define what ores will be there. Go to Content\Data\Environment\ProceduralEnvironments.sbc to tell game which ore should appear at specific blue channel value.

<pre>
<OreMappings>
<Ore Value="130" Type="IronOre_RichYield" Start="3" Depth="7" TargetColor="#b7340a" ColorInfluence="15 "/>
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
<Ore Value="110" Type="IronOre_PoorYield" Start="2" Depth="5" TargetColor="#a76a41" ColorInfluence="15" />
</OreMappings>
</pre>
The section you need to use is Ore Mappings.
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
Value refers to blue channel value on material texture.
Type refers to name of a voxel material from Content\Data\VoxelMaterials.sbc.
Start is depth at which the ore deposit starts. Depth is how deep under ground it goes.
TargetColor is color that will be used to color surface above the ore.
ColorInfluence sets strenght of coloring.

==Working with RGB==
Ok, Steam won't let me share that link to a small RGB Photoshop tutorial with you, so just go to photoshopessentials.com and search for RGB and it's the first link.

This is a simple tutorial to explain you what we mean when we say Grayscale ID, which can also be called the RGB values
(each channel only has one number per shade of that color ranging from 0 to 255).

Here I have loaded a Biome map texture front_mat texture which is used on the Vanilla EarthLike planet.

[[File:RGBChannels.jpg|frameless]]These are the RGB channels as you can see them in Photoshop.

NOTE: Edit each RGB channel separately!

Always use the pencil tool to paint pixels.
The brush tool has a falloff that has different values and you will not have control over those!
[[File:Color Picker.jpg|thumb]]

You can see if the numbers are correct on the top right of the screen if you have your workspace set to Essentials.

Here you will enter the values you want to paint.
Make sure you check them before saving, sometimes Photoshop can move the number +-1 (personal experience).

It doesn't matter if the numbers match, just as long as you have the correct value (ID) in the correct channel!

==Height-maps modding - terrain shape, roads==
As mentioned in 2. Required software, we used the program World Machine to create our heightmaps and then we did some minor tweaks by hand (like putting in lakes and desert areas)

First, to explain how our planet heightmaps work:
We have 6 textures that connect together (image below). Our standard resolution for a big 120km planet is 2048x2048. But you can use a lower one if you want to.

To create your own heightmap, the best action would be to find a heightmap here:
C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\PlanetDataFiles

Then you can open the texture and place yours/paint yours on a new layer, flatten the image and save it as a .PNG

There are other options for you also!
You can visit[terrain.party] this site and download a heightmap from a real place on Earth. You can even set the size of the map (maximum is 60 km). And then you can edit it further in Photoshop.
You can try painting it yourself in Photoshop (or any other similar software, like Gimp).
You can also just try Googling for heightmaps and try which one suits you the best (keep in mind the resolution must be 512,1024, 2048!)
However you get your heightmap, always keep in mind how each texture of the heightmap is connected, so the seams need to fit together. Bad texture connection is very visible in the game.
Here is an image of how the textures are connected:

[[File:Planet Material Texture Order.jpg|512px]]

===Roads===
We created roads using World Machine tools. You can find guide how to do that in between World Machine tutorials.

==Atmosphere==
[[File:View Image.jpg|1024px]]

Here, you will find everything you ever wanted to know about Atmosphere Settings in Space Engineers but were afraid to ask, my dear friend. So without any further ado. Let’s start with the “Atmosphere” settings window which you access in-game by hitting F12 -> Render Button -> Atmosphere checkbox. The new Atmosphere settings window opens immediately on the right side of the screen, showing a bunch of tricky sliders.

[[File:Cloud Layers Definition.jpg|1024px]]

If your pants are still dry, and if by any chance you’re still reading this, let us assure you that everything is pretty simple and not so scary as it may seem when you first open it. So let’s start with the brief and really quick explanation of what every slider or group of sliders are meant for. Lastly, remember that to alter any setting in this Window you have to hold “Alt” on your keyboard.

Enable Atmosphere (checkbox) – Well, as Captain Obvious immediately states to us – it just enables or disables Atmosphere on a planet and nothing more.

Time of Day (slider) – Controls rotation of the Sun around a Planet. You’re given the Power to decide which time of day it is now. Cool isn’t it?

Pick Planet (Button) – In situations when you have more than one planet in your world, you may want to alter the settings of each planet’s atmosphere individually. So this button enables you to immediately pick the current atmosphere values of the planet you’re currently on. For example, fly to the Moon, press “Pick planet” button and you will get corresponding atmosphere values of that planet to play with. Fly back to Earth or any alien planet, and do the same to alter atmosphere settings of these planets. Yay!

Rayleigh Scattering R,G and B (sliders) – Group of three sliders which control the main, overall color of the Atmosphere. It’s that atmosphere color which is going to be seen from outer space and on the ground too! If you want to make your atmosphere alien green or purple – these are the correct set of sliders to play with. Each slider controls corresponding R,G or B (0-255) values. Pretty straightforward.

[[File:Atmosphere Settings.jpg|512px]]

Mie Scattering R, G and B (sliders) – Group of three sliders to control the color of the Sun glow. It would be weird to have Green atmosphere and Red sun glow right? You would normally want to set it to yellow or something light green or so. But it’s your choice you can make any color you want. But please note that in order to have noticeable results you have to actually HAVE that glow around your sun. This setting is called “Mie Height” and it has to be set to a fairly high value otherwise it wouldn’t be too prominent. We will talk about this “Mie Height” setting in a minute. No worries.

The following three sliders are complementary and play well together. It means you have to find a good balance setting them which is quite easy:

Rayleigh Height Surface (slider) – Controls the thickness of the atmospheric layer when you’re on or near planet’s Surface. For example. You normally want atmosphere layer to be fairly thick to cover high points of the planet’s surface like mountains and high hills while you’re on the ground because you have actual high picks in your surface geometry which you have to cover. Otherwise you would see black space when you’re on the high mountain. But technically, when you’re leaving the planet’s atmosphere all of these high peaks and mountains are starting to slowly collapse vertically forming a smooth spherical shape of the planet, if they wouldn’t - we would have planets looking like a spiky balls with mountain peaks sticking out in all directions. That’s why when all the high peaks are collapsed to the ground to form a perfect sphere - we are left with abnormally thick and wrong looking atmospheric layer thickness when observed from the outer space. How to fix this?! That’s where “Rayleigh Height Space” slider comes into play, as it controls the thickness of the atmospheric layer seen from outer space.

Rayleigh Height Space (slider) – Controls the thickness of atmospheric layer when you observing the planet from outer space. Like it was said earlier, settings for atmosphere thickness when you’re on the Surface and when you’re in an outer Space can’t be same and normally you want to make it much thinner when it is seen from outer space like it’s in real world. Refer to the following Pic to get better understanding.

Rayleigh Transition (slider) – Ok, so now that we have set the width of the planetary atmosphere for both - when we’re on the Surface and when we’re observing it from outer space, it is time to decide at which distance to switch between two, right? So that’s exactly what this slider does – sets the exact value at which distance that transition must happen. You can play around with this value to find the best setting, just remember that the main goal is to have this transition as smooth as possible, fortunately it’s super easy to achieve. Just make sure that while you’re on the ground and standing on a highest point you still see some atmosphere color (like Blue color in earthlike planets) ,and just about when you start to see the whole planet on your way to the outer space, switch it to the thinner (Rayleigh Height Space) version.

Mie Height (slider) – Controls the size of the outer glow effect of the Sun. Like it was said earlier, when you’re setting your color of the Glow effect via “Mie Scattering RGB” sliders, this particular setting (Mie Height) must be set to a fairly high value otherwise you won’t see it as there won’t be any glow. Look, you can’t change the color of a non-existing thing, soldier. Dismissed!

Sun size (slider) – Controls the size of the Sun.. What else did you expect from it?!

Sea Floor modifier (slider) – Defines the lowest (starting) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer starts. It depends on your planet’s relief, your lowest and highest peaks. Adjust individually for each planet. You’ll “feel” the right value immediately.

Atmosphere Top Modifier (slider) – Defines the highest (ending) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer stops. It depends on your planet’s relief. Adjust individually for each planet. You’ll “feel” the right value immediately. But normally you want this value to be set pretty high.

Intensity (slider) – Actually it should be called “Fog Intensity” as it’s exactly what it’s responsible for but I hope it will be changed by some coder guys eventually J. Controls the amount or intensity of the fog while you’re on or near the planet’s surface (doesn’t do anything when you’re in outer space).

Fog Intensity (slider) – And this, should be actually called “Fog Distance”. It controls the distance fog actually covers. The higher this value – more objects in front of view are covered with fog. (doesn’t do anything when you’re in outer space).

Restore (Button) – Ok, just in case you screw everything up, you always have a chance to revert all the changes you’ve made by clicking this Restore button, soldier! Very convenient isn’t it?!

==Atmosphere 2/2==
Ok, now that we got acquainted with all Atmosphere settings and know how they work, it is time for us to actually change a few settings to alter the look of our Atmosphere! Now the fun part begins. Let’s say that we want to change the color of Earthlike planet’s atmosphere from its natural Blue color to the Green one, so it looks more “alienish”. Please note, that all atmosphere settings are stored in “PlanetGeneratorDefinitions.sbc” file and they are NOT replaced even when you change these values in game and make a save. If you want to change those values you have to change them directly in the code of the “PlanetGeneratorDefinitions.sbc” file only! The system reads those atmosphere values from this file every time you’re loading your worlds.

But how for God’s sake would you know which values are correct and really desirable to put them in the code? This is really simple. You just adjust your atmosphere settings to your liking right in the game, and when you’re done and happy with it, you just copy those values into the code (you can screen grab the in-game view with Atmosphere Settings window or just write them down manually, not a big deal) But to paste those values in the code, you have to know WHERE to paste it, right? You don’t just randomly paste numbers into the code, do you? You may hurt yourself!

So please open “PlanetGeneratorDefinitions.sbc” file in any decent text editor and find the following line:
<pre>
<SubtypeId>EarthLike</SubtypeId>
</pre>
It’s a name or identifier of a planet, and since it’s named Earthlike, we know for sure that below are the definitions related to Earthlike planet. Cool! Now just scroll down to the part where you will see a commented (inactive) line of code which goes like:



Or alternatively, just Ctrl+F to find the following line. You must see something similar to this:

[[File:Atmosphere definition.jpg|512px]]

So here as you can see everything is pretty self-explanatory. Except a few lines that are just named differently in the code. If you want your atmosphere to “remember” the settings you have made you have to enter those values here to the corresponding lines. The following schematic pic shows dependencies between the code lines and the slider names in Atmosphere Settings window quite clearly:
(Click to enlarge)

[[File:In-game Atmosphere Debug Input.jpg|1024px]]

Now let’s just change the blue color of the atmosphere to orange. As you remember, group of three RGB sliders named “Rayleigh Scattering” are responsible for changing the main color of the Atmosphere. So why wait?

[[File:Mars-Like Atmosphere.jpg|1024px]]

Spectacular right? Now, let’s change the sun glow color “Mie Scattering RGB” to an orange tint too. It could stay the same yellow of course but let’s change it so you could have an idea. Remember to press “Alt” on your keyboard while you’re dragging those sliders.

[[File:Another Red Atmosphere.jpg|1024px]]

Ok, now it’s more orange but we have to increase the glow effect a bit to see it more prominently. And as we remember, the glow size control is “Mie Height” slider. Crank it up from 30 to 50.

Good, the glow effect became more prominent. Looking nice isn’t it? Of course, you can continue adjusting it and come up with really crazy results, but if you’re ok with what we already have, then just write down all the values that you currently have in your Atmosphere Settings window on the right or screenshot them and paste into any image editor for your reference. And back in the code editor, just enter those values into corresponding tags in the code and save it:

[[File:CloseUp Atmosphere definition.jpg|512px]]

That’s it! From now on, every time you load up your world with Earthlike planet in it, or spawn Earthlike planet, the atmosphere on it will be exactly the way you adjusted it via Atmosphere Settings! The God himself must have been using something like this we suppose..

[[File:Mars-like Atmosphere Final.jpg|1024px]]

==Clouds==
The first thing that should (probably) come in to your mind when you finally learn how to tweak Atmosphere settings, is probably how to change the look of the Clouds! Because, normally, when you change the color of the atmosphere you would like the clouds color to be relatively close to the Atmosphere color. In our Atmosphere guide (if you read it) we were sharing some knowledge about changing the look of the Atmosphere. We made it orange which is kind of cool all on its own, but what really draws our attention and not in a very good way – is the color of the clouds. As you can see they’re white which is looking wrong isn’t it? In an orange atmosphere environment you would expect orange or yellow clouds right? So that’s what we’ll be doing in a minute – changing the look of our cloud layer and getting to know their under-the-hoods.

Like with Atmosphere settings, the Clouds setting are stored in the same “PlanetGeneratorDefinitions.sbc” file located in KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Data and are individual for each planet. Usually we base our code lines so the Cloud definitions come right after Atmosphere definitions which makes it very convenient to search for. Just open your “PlanetGeneratorDefinitions.sbc” file in any decent advanced text editor and search for this commented (inactive) line of code:



Note: you can download the DDS files from here[mirror.keenswh.com]

[[File:Cloud Layers Definition.jpg|1024px]]

That’s where all the cloud settings for particular planet are stored. The following picture is a brief breakdown of cloud definitions:

Basically, the structure of placing clouds on any planet is as follows:
<pre>
<CloudLayers>
<CloudLayer>
Blah Blah Blah Beautiful Clouds Blah Blah Blah
</CloudLayer>
</CloudLayers>
</pre>
So, as you can see everything is super easy. Simply put, <CloudLayers> tags are meant for global separation of Cloud definitions from other code definitions and are here just to define where the code for the clouds start, while <CloudLayer> tags (again, don’t mistake with CloudLayers) are the actual cloud layers and each pair of these tags (<CloudLayer>…</CloudLayer>) define the look and behavior of each cloud layer. As Captain Obvious states - The more <CloudLayer> pairs you have.. umm - the more cloud layers you will have!

For example. You can have more than one Cloud layer, to simulate even more complex cloud patterns than you initially had in your texture file! And that’s when <InitialRotation> and <RotationAxis> tags come into play. You can assign values to these tags for each Cloud layer individually thus having the cloud spheres to be initially rotated and spinning on different angles creating more interesting and natural cloud patterns. So you basically just stack them this way:
<pre>
<CloudLayers>
<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>
</CloudLayers>
</pre>

That’s it! Now you have three Cloud Layers! And of course you can do it for the Far and the Near cloud layers as well.

Your main cloud color texture must be 4096x2048px RGB file saved in DDS format without alpha as “CloudName_cm.dds file” and it must contain only the color information of your clouds. For Alphamask file please create a separate file of the same 4096x2048px dimensions containing only Alpha mask, make it a greyscale file, save as DDS luminance format and name it “CloudName_Alphamask.dds”. Back in the code, in <texture> tags you just write “Cloudname.dds”, no worries - the engine will identify required “cm” and “alphamask” files itself, just make sure both files are in the correct folder. (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Models\Environment\Sky).

As you know, clouds that are seen from the outer space and the clouds that you see through your window don’t look the same because of the huge differences in scales in both cases. That’s why we have two types of clouds on each planet. First one (commented as “Far layer” in the code) – the clouds that you see from the outer space. They usually look like NASA satellite orbital photo shots.

[[File:Clouds.jpg|1024px]]

And the Second one (commented as “Near layer” in the code) – the clouds that are seen when you’re on the ground or close to it. These should look like a significantly zoomed version of the first ones - more detailed, wispy and more individual. Like the ones you used to see in the sky every day. Refer to the picture.

[[File:LargeClouds.jpg|1024px]]

Now, how to actually separate these two types of cloud layers and to make them come in layers – one after the other. This is very simple too. The maximum overall Altitude (height) of our atmosphere layer is 2. So we have to set up our cloud layers in a tricky way, so that when we’re in outer space - we would see the “Far layer” clouds ONLY, and as we’re getting lower (approaching the ground), on a particular altitude (height) smoothly switch to the “Near layer” clouds and have the “Far layer” clouds hidden. Sounds crazy but it will become clear if you look at the following pic:

[[File:CloudLayerDiagram.jpg|1024px]]

As you can see things are really self-explanatory here too. By setting the Start and End values in <FadeOutRelativeAltitude..> you basically create a vector, the starting point of which is infinity which means anything below this start point will be constant value, thus – making it possible to set the Far layer to be seen from outer space (values greater than 2), and preventing Near cloud layer from being seen - because it is set to fade out on 1.6. And vice versa – when you’re on the ground, you won’t see Far layer clouds layer because it faded out on much higher distance of 1.4. Not so hard right? Of course you can alter and tweak those values to your liking depending on the planets height maps/relief to get the desired transition between Far and Near cloud layers.

So now that we’re empowered with this knowledge, the only thing we’re left to do is to actually change the color of the clouds from white to yellow color so our clouds look more natural in an orange Atmosphere environment. As we remember, our clouds are consisting of two texture files – a file containing color information (usually just a plain color) and a file with an alpha mask only. We already know that the “Far layer” clouds (the ones seen from space) use “EarthFarClouds_cm.dds” texture file and the “Near layer” clouds use “Landsky_texture_cm.dds”. How we know that? It’s written in <texture> </texture> definitions, remember?

[[File:CloudTextureRoute.jpg|512px]]

Great! So now just open “EarthFarClouds_cm.dds” and the “Landsky_texture_cm.dds” and fill both files with plain yellow color and save them!

[[File:YellowCloud Texture.jpg|1024px]]

Start the game and spawn an Earthlike planet and voila! You got perfect yellow clouds!

[[File:Scenery With Yellow Clouds.jpg|1024px]]

==Planet ambient sounds modding - day/night biome sounds==

Sound rules are in the Content\Data\PlanetGeneratorDefinitions.sbc file. Here you can set different sounds based on player’s location or daytime on the planet.
<pre>
<SoundRule>
<Height Min="0" Max="0.5"/>
<Latitude Min="55" Max="80"/>
<SunAngleFromZenith Min="0" Max="180"/>
<EnvironmentSound>AmbIcelandDay</EnvironmentSound>
</SoundRule>
</pre>
Height stands for where you want the sound to play at the height of the heightmap (0-7200m). It is always +12% of the planet's diameter. 0 is from the the lowest start of the surface to 1.0 which is 100% of the surface (maximum height).
Latitude means angle from the equator. Therefore 0 to 20 will mean that this sound will mostly play in the desert area, 20-50 is mostly the green forest area, and so on.
SunAngleFromZenith NEEDS MORE INFO!!!
EnvironmentSound this is the name of the sound you want to use.

You can find all available sounds in Audio.sbc (location shown below) Here you will also put your own ambient sound with your own custom name.

How to implement custom ambient sound

All Ambient sounds are stored here:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Audio\ARC\AMB\

If you want your own sounds, they should be a loop sound, and on average should not be bigger than +-5 MB.
The supported format is: .xwm but .wav can also work, even though its file size is usually a lot bigger (not recommended).

Once your audio is done, implement it here in this file:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\Audio.sbc
<pre>
<Sound>
<Id>
<TypeId>MyObjectBuilder_AudioDefinition</TypeId>
<SubtypeId>AmbAlienForestDay</SubtypeId>
</Id>
<Category>AMB</Category>
<MaxDistance>100</MaxDistance>
<Volume>0.2</Volume>
<Loopable>true</Loopable>
<Waves>
<Wave Type="D2">
<Loop>ARC\AMB\AmbAlienForestDayLoop2d.xwm</Loop>
</Wave>
</Waves>
</Sound>
</pre>
Here edit only what is highlighted, otherwise I cannot guarantee that it will work properly!
<SubtypeId> This is how you will name your AMB sound, keeping in mind upper and lower case letters. Do not use _ or other special characters!
<Volume> This is self explanatory I hope.
<Loop> Here you just need to lead the definition to your file. ARC/AMB/ is the default location, so do not change that.
But if you want, you can make another folder in AMB for your custom ambient sounds for better organisation.

==In-game map modding==
Maps in Medieval Engineers are generated based on terrain and buildings on it. This means that they will work for any modded planet in their default form. That being said, the way map is generated is also fully moddable.

We definitions for map are located in Content\Data\Screens\MapDefinition.sbc. To mod maps you will have to alter/add definitions in this file, all vanilla textures for maps can be found in Content\Textures\GUI\Map. Feel free to use/alter any of them for creation of mods for Medieval Engineers.
Map content modding (Friend/foe display, tax notifications,...
In Medieval Engineers there are 2 view modes of map. Kingdom view which is showing entire kingdom and region view which is zoomed part of a kingdom map. Region is 1kmx1km large on 10 km diameter planet. Both views display different elements.
What is shown in these views depends on what layers it contains
<pre>
<Definition xsi:type="MyObjectBuilder_PlanetMapDefinition">
<Id Type="MyObjectBuilder_PlanetMapDefinition" Subtype="Main"/>
<BackgroundGenerator Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
<RegionView>
<Layers>...</Layers>
</RegionView>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</Definition>
</pre>
BackgroundGenerator refers to a definition of background texture that serves as a background on top of which all the map elements are placed.
<pre>
<RegionView>
<Layers>...</Layers>
</RegionView>
</pre>
The three dots in middle represent layers of elements that show in region view. List and description of all layers is in next section of this document.
<pre>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</pre>
The three dots in middle represent layers of elements that show in kingdom view. List and description of all layers is in next section of this document.
(I did not Kingdom view in its expanded form because it would take up too much space.)

===Layers description===
<pre><Layer xsi:type="MyObjectBuilder_MapBackgroundLayer" /></pre>
This layer draws the background. As generated based on chosen background definition.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaDevelopmentLayer">
<Threshold BlockCount="10" Sprite="Textures\GUI\Map\SmallGrid.png"/>
<Threshold BlockCount="30" Sprite="Textures\GUI\Map\MediumGrid.png"/>
<Threshold BlockCount="60" Sprite="Textures\GUI\Map\LargeGrid.png"/>
</Layer>
</pre>
This layer displays icons based on amount of blocks there is in an area. You can set the block thresholds, or mod the textures. It is also possible to add more thresholds. 80x80 px, png.

[[File:Smallest Settlement.png|150px|frameless]]
[[File:Medium Settlement.png|150px|frameless]]
[[File:LargestSettlement.png|150px|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_RegionFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for region, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaOwnershipLayer">
<AlliedBgColor Hex="#806464FF" />
<PlayerBgColor Hex="#8064FF64" />
<EnemyBgColor Hex="#80DC6415" />
</Layer>
</pre>
This layer defines color overlay over map areas based on ownership. You can mod which color is used for allies, your own areas or for enemies
<pre>
<Layer xsi:type="MyObjectBuilder_AreaUpkeepLayer">
<TaxIcon>Textures\GUI\Map\TaxIcon.png</TaxIcon>
</Layer>
</pre>
This layer displays tax icon on areas that belong to you and require tax payment soon. Texture is 80x80 pixels, png.
[[File:Taxes.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapPositionLayer">
<LocalPlayerImage>Textures\GUI\Map\PlayerPosition.png</LocalPlayerImage>
<OtherPlayersImage>Textures\GUI\Map\AllyPosition.png</OtherPlayersImage>
</Layer>
</pre>
PlanetMapPositionLayer displays player icon above area where they are.
[[File:Ally.png|frameless]]
[[File:Player.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_ActionTrackingLayer">
<ActionImage>Textures\GUI\Map\Action.png</ActionImage>
</Layer>
</pre>
Shows icon over an area on map with fighting / destruction.
[[File:AttackedArea.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_CurrentMapSelectionLayer">
<SelectionImage>Textures\GUI\Map\MapSelection.dds</SelectionImage>
</Layer>
</pre>
This is highlight of a region, that player selected with his mouse.
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapGridLayer">
<GridColor R="0" G="0" B="0" A="228"/>
</Layer>
</pre>
This layer sets which color is the grid drawn.
<pre>
<Layer xsi:type="MyObjectBuilder_KingdomFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for kingdom, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_RegionOwnershipLayer">
<PlayerIcon>Textures\GUI\Map\PlayerLandIcon.png</PlayerIcon>
<AllyIcon>Textures\GUI\Map\AllyLandIcon.png</AllyIcon>
<EnemyIcon>Textures\GUI\Map\EnemyLandIcon.png</EnemyIcon>
<PlayerAllyIcon>Textures\GUI\Map\PlayerAllyLandIcon.png</PlayerAllyIcon>
<PlayerEnemyIcon>Textures\GUI\Map\PlayerEnemyLandIcon.png</PlayerEnemyIcon>
<AllyEnemyIcon>Textures\GUI\Map\AllyEnemyLandIcon.png</AllyEnemyIcon>
<PlayerAllyEnemyIcon>Textures\GUI\Map\PlayerAllyEnemyLandIcon.png</PlayerAllyEnemyIcon>
</Layer>
</pre>
RegionOwnershipLayer generates textures used to express ownership on regional map.

===Background generator (trees, mountains, roads,...)===
Map background is where all the trees, mountains, hills are drawn. It is also capable of coloring map based on what is in planet’s material map (this is how we make roads for example).
All settings for map background are in MedievalMapBackgroundDefinition. The definition also in Content\Data\Screens\MapDefinition.sbc. I will go through various parts of the definition.

<pre><Id Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
Type of the definition says that this map background definition. Subtype is name of this specific background definition. If create your own background with unique subtype
Make sure you create your own background with unique subtype

<DrawHeightmap>false</DrawHeightmap>
When set on “true” planet’s heightmap is drawn under the map.
<Resolution>4096</Resolution><
Sets resolution of the generated in-game map.

<Features>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</Features>

<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</Definition>
</pre>
===Map Coloring===
You can use colors in material or biome map of a planet to appear on the game map. (roads for example). You define map coloring in a node called ”Features”. The coloring uses colors from planet material texture. You can learn more about material texture in biomes modding and surface material modding.
<pre>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
</pre>
This specific feature is used for painting roads on map with dark brown color. In Color you define which color will be the in-game map colored. Material=”67” decides where will be the color applied and refers to a red channel value on planet material texture.
<pre>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</pre>
This specific feature is used for painting forests on map with opaque brown. In Color you define which color will be the in-game map colored. Biome=”60” decides where will be the color applied and refers to a green channel value on planet material texture.

===Sprites===
Medieval Engineers map can also place sprites on map based on terrain shape. All the sprites are on one texture
<pre>
<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</pre>

[[File:AtlasCoordinateUsage.png|512px]]

Note: Illustrates how sprite is defined on our spritesheet. Example sprite:
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />

==Voxel color overlay modding==
We have a cool tech that enables us to color-shift color of almost any item in the game. Currently we are using it for trees(adds small color variations to the same model of a tree) and voxels above iron deposits.
==Fast travel settings modding==
In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around.
In this section of the guide we will show you how to mod which sectors are blocked.
There are 2 ways you can go about it:
===Generate automatically based on terrain shape===
Game is capable of creating fast travel map on its own based on height and terrain steepness. It is possible to mod thresholds for both height and steepness.
You will find the thresholds in Content\Data\Game\FastTravel.sbc. In a MyObjectBuilder_TerrainReachabilityProviderDefinition.
<RiseThreshold> - Sets min. terrain height change which will cause that area is unreachable.
<HeightThreshold> - Sets height of terrain after which area is unreachable, if it goes over this value. Range is 0 - 1.

If there are texture overrides in the definition, you have to erase them in order for the parameters to take effect. Texture overrides are nodes that are called in this fashion: <OverrideNAMEOFFACE>. You will learn more about these overrides in the next part of Fast travel modding.

===Creating fast travel texture override===
If you want to have full control over which areas are reachable and which are not regardless of terrain, you can create a simple texture on which you mark unreachable areas.

The texture is 80x80 pixels, RGB 8 bit. Black pixels forbid entrance.

When you have the texture, select route to it in the definition:
<pre><OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward></pre>
Reachability definition example:
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>
<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>
<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
</Definition>
</pre>
This definition would generate fast travel reachability everywhere, except for front planet face (Fareon kingdom) where fast travel reachability is created based on your texture.

===Development reachability===
Claimable area size, border highlight, contested timer modding
Size of the area and highlight properties are moddable as well.

===Area borders highlight===
<NeutralColor R="225" G="32" B="0" A="64" /> - Set color of an unowned territory
<SelfColor R="0" G="255" B="0" A="64" /> - Sets color of area border owned by you
<AliedColor R="65" G="105" B="225" A="64" /> - Sets color of area border that belongs to allies
<EnemyColor R="225" G="32" B="0" A="64" /> - Sets color of area border that is hostile
<WallSettings Depth="15" Rise="3" SegmentCount"71" End="115" /> - Changes shape of the border. Depth sets how deep is border submerged. Rise sets how tall is the border.
<Fade Start="71" End="115" /> - This sets at which point the border starts to fade.
Contested timer
When players claim area with claimblock, area goes to a “contested” phase for some amount of time, in this phase other players can still attempt to build their own claim block and claim the area. This time is moddable.
Content\Data\Game\SessionComponents.sbc contains definition called MyObjectBuilder_AreaOwnershipSystemDefinition. To mod this value, add this definition to your mod with changed value of <ContestedTimeInMinutes> parameter.

==Permissions modding - what is/isn’t allowed to do in claimed areas==
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.
Description of available actions to set permissions for:
Name=”Build” -> block placement permissions
Name=”Repair” -> Repairing/building already placed blocks
Name=”Deconstruct” -> Deconstructing
Name=”QuickDeconstruct” -> Faster deconstruction
Name=”VoxelEdit” -> Mining or shoveling
Name=”Destroy” -> Damage with hand weapons
Name=”Interaction” -> Chest opening, door opening
Name=”ClaimBlockInteraction” -> ClaimblockGui

===List of available Groupnames:===
Groupname: “Owner” -> Player who owns area
Groupname: “Allies” -> Mostly faction members of owner of the area
Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
Groupname: “Enemies” -> Players in factions that are hostile to your faction

==Compass modding==
It is possible to mod visual look of an in-game compass. All definitions of compass are stored in Content\Data\GUI\CompassDefinition.sbc. Our textures for compass are in Content\Textures\GUI\Compass folder if you want to check out how they look or use them in your mod.
===Creating compass texture atlas and setting coordinates for its elements===
Just like with map sprites, we save main compass elements on a single texture, then define parts of it using pixel coordinates. First setup origin point, then add width and height of the rectangle
Example texture coordinates for top part of the compass:
[[File:CompassTextureCoordinates.png|1024px]]
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>

===Explanation of compass definition line by line===
<pre><Texture>Textures/GUI/Compass/compass.png</Texture> </pre>
Route to a texture atlas.
<pre><KingdomIcon>Textures/GUI/Compass/Icon-Kingdom.png</KingdomIcon> </pre>
Route to icon symbolizing a kingdom.
<pre><Padding>7</Padding></pre>
Padding is added vertically between the top and bottom textures and the edges of the contents of the compass.
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>
Rectangle in the texture that contains the top part.
<pre><BottomCrop X="0" Y="0" Width="0" Height="0"/></pre>
Rectangle in the texture that contains the bottom part.
<pre><BackgroundCrop X="0" Y="64" Width="512" Height="64"/></pre>
Rectangle in the texture that contains the background.
<pre><ArrowCrop X="0" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the little marker used for elements that are drawn and have no icon.
<pre><MarkerCrop X="32" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the interval bars drawn every few degrees.
<pre><ShadowCrop X="64" Y="128" Width="80" Height="32" Left="8" Right="8"/></pre>
<pre><ShadowPadding Left="12" Top="8" Right="12" Bottom="8"/></pre>
Rectangle in the texture that contains the text shadows. Shadow is 3-Sliced, meaning the texture is split in three parts: [left|middle|right]
The sizes of left and right define the cropping lines that split the texture into three. The Sides are then always kep proportional as the texture is scaled.
<pre><VisibleRange>200</VisibleRange></pre>
Visible range in degrees.
<pre><Width>700</Width></pre>
Width in reference resolution pixels.
<pre><FontSize>1.1</FontSize></pre>
Scale of the font based on default.
<pre><VerticalOffset>0.065</VerticalOffset></pre>
Vertical offset from the top of the screen. 0 = top of the screen, 1 is the bottom. Compass is centered around this position.
<pre>
<TagStyles>
<TagStyle Tag="ClaimArea" Style="Bellow" MaxCharacters="15" Ellipsis="true"/>
<TagStyle Tag="Cardinal" Style="Above" MaxCharacters="1"/>
<TagStyle Tag="Kingdom" Style="Bellow"/>
</TagStyles>
</pre>
This section adds tags that are visible on compass and in which style. Currently we have 3 types of tags. Claim area - shows your claimed area on the compass, Kingdom tag shows kingdoms and Cardinal tag shows cardinal points (North, South,...). Each tag’s visual appearance is defined in tag/waypoint definition. Styles defines where should the text appear. Available styles: Center, IconOnly, NotShown, Bellow, Above.

===Explanation of Waypoint/Tag definition===
<pre>
<Definition xsi:type="MyObjectBuilder_WaypointDefinition">
<Id Type="MyObjectBuilder_WaypointDefinition" Subtype="Kingdom"/>
<IconPath>Textures/GUI/Compass/IconKeep.png</IconPath>
<Color R="255" G="255" B="255" A="255"/>
</Definition>
</pre>
IconPath contains path to the texture of kingdom icon. Color defines color of the text that is shown with the icon. (Example: Fareon, [[File:Kingdom Icon.png|thumb]])
===Compass texture vs in-game look comparison===
Texture:

[[File:Compas Texture with Zones.png|1024px]]

In-game look:

[[File:In-gameCompassZones.png|1024px]]
<NoWiki>*</NoWiki>note that background crop and bottom crop are not used in vanilla (empty opaque texture)

==Indestructible grids==
There is a way how to make some buildings in your save indestructible. We are using this feature for starting area buildings. Some you guys might make a good use of this feature in your pre-made worlds.

Currently, only way how to do this is to make edits to an existing save file. So you can only use it for world modding.

===Making indestructible cubegrids in existing safe===
Goal is to open world’s safe file in a text editor, find your cubegrid in it and add this tag to it: <DestructibleBlocks>true</DestructibleBlocks>.

#Find your save file. By default save files are stored in C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Saves
#Open folder with your save and find file called SANDBOX_0_0_0_.sbs. This file can be opened with any text editor you prefer.
#In the SANDBOX_0_0_0_.sbs search for the cubegrid name of the building you want to make indestructible. (use find/search function in your text editor, or you will grow old before you find it)
#Tip: To find out name of a cubegrid, create blueprint of the building. The name that the building saves as in your blueprint screen is the name of the cubegrid.
#You should find the name in tags called: <DisplayName>YOURCUBEGRIDNAME</DisplayName>
#Under the name, add following tag with setting set to false: <DestructibleBlocks>false</DestructibleBlocks>
#If you followed instruction, the indestructibility tag is now in node called <MyObjectBuilder_EntityBase> and not in any of its child nodes.
#Save the edited file.
#Load the save and test destructibility
#It worked! Enjoy
#It is still destructible. Go to point 1.

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding - Full Guide

2017-03-13T16:34:50Z

Lukas: /* Assign environment to a planet */

==Introduction==
Hello fellow Medieval Engineers!
I would like to present you with a guide that will help you understand how we created planets at Keen Software House and how to mod your own into the game.
Feel free to use/alter company owned files for your Medieval Engineers mods.

So let's get to modding!

==Recommended Software==
# Microsoft Visual Studio - or Notepad++ (Link[notepad-plus-plus.org]) - for opening files with .sbc extension where we have definitions for every feature in the game.
# Adobe Photoshop - for editing material and heightmap textures
# World Machine Professional - for heightmap easier creation (much more realistic looking terrain, without manual work)

(Basic Edition is also available, but the max resolution output is limited to 512x512 pixels)
http://www.world-machine.com

===Advice===
We would like to mention one thing before you get into modding planets:
For your own sake we recommend you to load either PlanetTemplate or EarthLikeModExample and test/edit all the things there, so you get to know the system and how everything works.

After that you can create your own from scratch. This is entirely up to you.

==General modding principles - how to make any mod==
I will explain again basic principles of how mods are applied.

All of our vanilla source files are all saved in a folder called content in your *game folder. If no mods are assigned to a world that you are loading, game uses only files from this content folder but if there are mods, game loads also files from mod adding more content or potentially rewriting vanilla content based on content of the mod’s folder. Mod is nothing else but a folder with another files.
Mod files are stored in mods folder on your computer , and if you are using them for the first time, they are downloaded from workshop first time you try to load/connect to a world with those mods.
Mod folder: C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Mods
===Opening mod and examining mods content===
When you open Mods folder, you will see mods as files with .sbm extension. But they are really just folders and to examine them, all you have to do is rewrite the extension from .sbm to .rar and then you can open them with rar and examine content.
Mods are not listed with their names, but with their steam id number. To find specific mod, you have to go to the mods workshop page

Examining other mods similar to your idea is a fast way to learn.
Example:

<NoWiki>*</NoWiki>By default this is SteamLibrary\steamapps\common\MedievalEngineers\Content. You can also get there if you go to steam library(same place where you start the game), right-click Medieval Engineers, select properties, local files and finally click on “browse local files”.
==Materials modding==
In case you are thinking about making your own trees and voxel materials, we have some good news for you!

There are two separate guides that you can follow to make your own stuff.

General modding guide - get started

===Voxel material modding===
http://steamcommunity.com/sharedfiles/filedetails/?id=568406623

==Planet Size==
Planet size is defined in a scenarios.sbc. Every time you click on create new world in the game it uses scenario definition to create a new safe file. Although this scenario definition is not moddable, you can still use it to create a world and share the world itself on the workshop.

First go to where you have Medieval Engineers source files and find Data folder (SteamLibrary\steamapps\common\MedievalEngineers\Content\Data\Scenarios.sbx)

==All planet related files overview and where to find them==
To summarize how planet modding in ME works, we can say this:
We use 2 types of textures and then we define how the game should interpret those textures in definitions. One texture is heightmap that is used just for generating terrain shape, another one is used to place everything else on the planet (ores, trees and plants, bots).
[[File:Diagram.png|1024px|center]]

==Material Texture modding==
Material texture is used to store information about location of various planet surface features. These features are surface materials, biomes (trees, bots, plants,..etc) and where you can find ore. Each one of these uses one color channel. Surface materials use red channel. Biomes use green. Ores are in blue channel.
We use 6 material textures (2048x2048) for each planet. You can find all our material textures here: Content\Data\PlanetDataFiles.
Each planet has its own folder. The folder has to have the same name as the planet.

[[File:MaterialMapBreakdown.jpg|512px]]

Illustration of how are the material textures connected to each other:

[[File:Planet Material Texture Order.jpg|512px]]

====The process of material texture creation is really simple. You have two options:====
=====Copy an existing map to your folder and overwrite the green channel and edit them to your liking=====
This is highly recommended to avoid errors!
=====Create a new: step by step in Photoshop=====
#Set both width and height to 2048 pixels
#(for smaller planets this can also be 1024 or less, but all textures need to have the same resolution! Even the heightmap)
#Set resolution - Pixels/Inch to 72.
#Set colour mode to RGB Colour - 8bit
#Now start painting with the pencil tool on each RGB Channel separately.
#Never on all three at once! (It will F. up everything - trust me).

===Surface voxel material definitions modding - grass, sand, snow===

[[File:RedChannel.jpg|22px|frameless]]

Surface “voxel materials” refers to what you know as grass, soil, stone.. We use red channel of the material texture to set where all the terrain appears. Then you need to write definitions in the Content\Data\PlanetGenerator.sbc to tell game which voxel should appear at specific red channel value.
Example of the definition of road:
<pre>
<ComplexMaterials>
<MaterialGroup Name="Road" Value="67">
<Rule>
<Layers>
<Layer Material="Soil" Depth="2"/>
</Layers>
<Slope Min="0" Max="90"/>
</Rule>
</MaterialGroup>
</ComplexMaterials>
</pre>
Example of corresponding material texture with road:

[[File:RoadMaterialTextureExample.png|512px]]

====Complex materials====
Complex materials definition allows to paint the map with a set of “voxel coloring rules”. Meaning that one color value in red channel can color terrain with different voxels based on rules like slope, longitude or latitude and height. (So with our road example)
<pre>
<MaterialGroup Name="Forest_Grass" Value="120">
<Rule>
<Layers>
<Layer Material="Woods_grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="0" Max="25"/>
<Latitude Min="-180" Max="180"/>
<Longitude Min="-180" Max="180"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="25" Max="45"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Rocks_grass" Depth="2"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="45" Max="55"/>
</Rule>
</MaterialGroup>
</pre>
This definition says what voxels should be generated in spots, that are painted with red channel value of 120.
The rules in this definition will lead to following:
Flat lands (up to 20 degrees slope) will have Wood grass 1 m thick, soil will be right under the WoodGrass up to 5 m depth and there will be stone underneath the soil.
In places with medium slope, there is Grass instead of WoodGrass. And in slopes from 45 to 55 there is rocks grass 2 m thick with stone right away under it.
With this technology, we can make the color react on its own to terrain bumps or even position on planet. This saves lots of meticulous painting with heightmap.

<Layer Material="Woods_grass" Depth="1"/>
Material refers to voxelmaterial definition. (You can find it in Content\Data\VoxelMaterials.sbc). Depth means how deep should the material go under ground.
<Slope Min="0" Max="25"/>
Slope of the terrain in degrees.
<Latitude Min="-180" Max="180"/>
Latitude in degrees. 0 degree is an equator.
<Longitude Min="-180" Max="180"/>
Longitude in degrees. 0 is in the middle of front planetary texture. (Fareon Kingdom)

===Biomes definitions modding - trees, plants and bots===
[[File:GreenChannel.jpg|frameless|22px]]

Biomes refers to everything that is spawned on top of the planet. We use green channel of the material texture to set where all the terrain features appear and definitions in the Content\Data\Environment\ProceduralEnvironments.sbc to tell game which environment item should appear at specific green channel value. Also you need to assign Environment to planet in the Content\Data\PlanetGenerator.sbc in case you are adding a brand new planet.

====First make/modify environment:====
Go to Content\Data\Environment\ProceduralEnvironments.sbc

=====Procedural World Environment definition=====
This definition defines where will the environmental items spawn and with which density. (note: bots are also considered environmental item). Best way to explain how procedural environment is working is to imagine that it puts spots on entire surface of a planet. And when you start defining trees, bots and bushes, the spots get “reserved” by these categories based on how many of those should appear in the world according to your mod.
Spots are always different for each single planet.
In order to mod the procedural environment, mod our “Earth Environment” definition. Or create your own but if you do, don’t forget to also mod PlanetGeneratorDefinition, so that planet has your new procedura environment assigned to it.

=====Definition elements explained point by point:=====
<pre>
<Definition xsi:type="MyObjectBuilder_ProceduralWorldEnvironment">
<Id>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>Earth Environment</SubtypeId>
</Id>
</pre>
This part of definition is called ID. It says what type of definition this is <TypeID> and unique name of that definition <SubtypeID>.

<pre>
<MaxSyncLod>1</MaxSyncLod>
</pre>
This line defines how far away from player are the environmental items updating. This is important feature for optimization.

<pre>
<SectorSize>40</SectorSize>
</pre>
This is size of the environmental sector. It is a different sector than the claimable areas by players. It sets size of one environmental sector.

<pre>
<ItemsPerSqMeter>0.17</ItemsPerSqMeter>
</pre>
The line sets overall maximum density of all environmental items. To return to analogy i used in the introduction, this number increases the amount of spots on the planet that are reserved for all environmental items.

<pre>
<ScanningMethod>Random</ScanningMethod>
</pre>

<pre>
<ItemTypes Type="MyObjectBuilder_EnvironmentItemTypesDefinition" Subtype="Default"/>
</pre>
This sets which types of environmental items are used in this procedural environment definition. This guide explains what are Environmental item types in the very next section.

<ItemGroup Density=".017" Name="Bots" LodStart="1" LodEnd="1">
<Mapping>
<Material>Woods</Material>
<Item Type="Bot" Subtype="Deer"/>
</Mapping>
<Mapping>
<Biome>60</Biome>
<Height Min="0" Max"1"/>
<Latitude Min="-180" Max"180"/>
<Longitude Min="-180" Max"180"/>
<Slope Min="0" Max"1"/>
<Item Type="Bot" Subtype="Deer" Density="0.9"/>
<Item Type="Bot" Subtype="Barbarian" Density="0.1"/>
</Mapping>
</ItemGroup>
Item group is used to organize and better manage mappings. Mappings are definitions that actually add the environment items in the world. It is important to set Density correctly. Density (Density=".017") sets how many of the procedurally generated spots on the planet will be assigned to environmental items from this group. The name (Name="Bots") is only for naming purposes within definition and has no impact on the game. LodStart="1" and LodEnd="1" control how far from the player will the items appear.
<Biome>60</Biome> This section means that Items within this mapping will only appear on spaces that are painted with green channel value 60 on the material map.
<Material>Woods</Material> This means that the environmental items will only appear in the woods.
<Height Min="0" Max"1"/> Sets in which altitude should these environmental items appear. If this parameter is missing, items spawn in full range (Min="0" Max"1")
<Latitude Min="-180" Max"180"/> Sets at which latitude do the environment items spawn. If this parameter is missing, items spawn in full range (Min="-180" Max"180")
<Longitude Min="-180" Max"180"/> Sets at which longitude the environment items spawn. If this parameter is missing, items spawn in full range (Min="-180" Max"180")
<Slope Min="0" Max"90"/> Sets at which slopes the environment items spawn. If this parameter is missing, items spawn in full range (Min="0" Max"90")

<ItemGroup Density=".085" Name="Trees" LodStart="-1" LodEnd="1">...</ItemGroup>
<ItemGroup Density=".36" Name="Small Items" LodStart="0" LodEnd="0">...</ItemGroup>
There are 2 more item Groups. I will not go into details, since it is not
</Definition>

=====Environment items=====
We learned how to assign environments to planets and how to mod environments themselves by changing densities and environment items. But we still don't know how to make the environment items themselves. Guides for those can be found on following links.

If you want to mod trees:

If you want to mod bushes and plants:

If you want to mod bots:

=====EnvironmentItemTypesDefinition=====
Here you define various types of items. Currently we have these types: Tree, Gatherable, Farmable, Static and Bot. Before you add any item, you must make sure it fits within these types of environment items or you created a new type for them.
<Definition xsi:type="MyObjectBuilder_EnvironmentItemTypesDefinition">
<Id Type="MyObjectBuilder_EnvironmentItemTypesDefinition" Subtype="Default"/>
<Item Name="Tree">...</Item>
<Item Name="Gatherable">...</Item>
<Item Name="Farmable">... </Item>
<Item Name="Static">...</Item>
<Item Name="Bot">...</Item>
</Definition>

EnvironmentItemTypes
<Item Name="Tree">
<ProxyActivationLod>0</ProxyActivationLod>
<Provider Type="MyObjectBuilder_ProceduralEnvironmentModuleDefinition" Subtype="Growable"/>
<Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Gatherable" />
<Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Cuttable" />
</Item>
Available proxy and providers:
Proxy Subtype="Gatherable"
This line adds ability to all environmental items of this type to use action “Gatherable”. Keep in mind that the tree itself has to be setup properly in order for this to work.
Proxy Subtype="Cuttable" />
This line adds ability to all environmental items of this type to use action “Cuttable”. Keep in mind that the tree itself has to be setup properly in order for this to work.
<ProxyActivationLod>0</ProxyActivationLod>
This line says from which lod is the game logic attached to the environmental item. (when set on 0 only trees very close to you become “gatherable” and “cuttable”). This way we don’t use game logic on environmental items that couldn’t be used anyway and game is better optimized thanks to that.
Provider Subtype="Growable”
This line adds ability to all environmental items of this type to grow. Keep in mind that the tree itself has to be setup properly in order for this to work.
Provider Subtype="Farmable”
This line adds ability to all environmental items of this type to be farmable. Keep in mind that the tree itself has to be setup properly in order for this to work.
Provider Subtype="Static”
This line adds basically adds items that do nothing. They are just visual props. Like some of our fern bushes.
Provider Subtype="BotSpawner”
It is important that all environmental item types that will contain some bots have botspawner

====Assign environment to a planet====
Last thing is to assign your brand new procedural environment to a planet where it is supposed to appear. Go to Content\Data\PlanetGenerator.sbc and find definition of the planet you want your environment to be on. Then assign the environment to the planet by adding following line to the planet definition with name of your environment:
<pre>
<Environment>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>NAMEOFYOURENVIRONMENTDEFINITION</SubtypeId>
</Environment>
</pre>
SutypeId refers to the name of the environment from:
Content\Data\Environment\ProceduralEnvironments.sbc

''Note: This is not necessary if you just modded existing vanilla environment and have not changed its SubtypeID''

===Ores definitions modding===
[[File:BlueChannel.jpg|frameless|22px]]

Ores are placed using blue channel of the material texture to set where should ore deposits appear. When your ore deposits are painted on the material map, you need to define what ores will be there. Go to Content\Data\Environment\ProceduralEnvironments.sbc to tell game which ore should appear at specific blue channel value.

<pre>
<OreMappings>
<Ore Value="130" Type="IronOre_RichYield" Start="3" Depth="7" TargetColor="#b7340a" ColorInfluence="15 "/>
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
<Ore Value="110" Type="IronOre_PoorYield" Start="2" Depth="5" TargetColor="#a76a41" ColorInfluence="15" />
</OreMappings>
</pre>
The section you need to use is Ore Mappings.
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
Value refers to blue channel value on material texture.
Type refers to name of a voxel material from Content\Data\VoxelMaterials.sbc.
Start is depth at which the ore deposit starts. Depth is how deep under ground it goes.
TargetColor is color that will be used to color surface above the ore.
ColorInfluence sets strenght of coloring.

==Working with RGB==
Ok, Steam won't let me share that link to a small RGB Photoshop tutorial with you, so just go to photoshopessentials.com and search for RGB and it's the first link.

This is a simple tutorial to explain you what we mean when we say Grayscale ID, which can also be called the RGB values
(each channel only has one number per shade of that color ranging from 0 to 255).

Here I have loaded a Biome map texture front_mat texture which is used on the Vanilla EarthLike planet.

[[File:RGBChannels.jpg|frameless]]These are the RGB channels as you can see them in Photoshop.

NOTE: Edit each RGB channel separately!

Always use the pencil tool to paint pixels.
The brush tool has a falloff that has different values and you will not have control over those!
[[File:Color Picker.jpg|thumb]]

You can see if the numbers are correct on the top right of the screen if you have your workspace set to Essentials.

Here you will enter the values you want to paint.
Make sure you check them before saving, sometimes Photoshop can move the number +-1 (personal experience).

It doesn't matter if the numbers match, just as long as you have the correct value (ID) in the correct channel!

==Height-maps modding - terrain shape, roads==
As mentioned in 2. Required software, we used the program World Machine to create our heightmaps and then we did some minor tweaks by hand (like putting in lakes and desert areas)

First, to explain how our planet heightmaps work:
We have 6 textures that connect together (image below). Our standard resolution for a big 120km planet is 2048x2048. But you can use a lower one if you want to.

To create your own heightmap, the best action would be to find a heightmap here:
C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\PlanetDataFiles

Then you can open the texture and place yours/paint yours on a new layer, flatten the image and save it as a .PNG

There are other options for you also!
You can visit[terrain.party] this site and download a heightmap from a real place on Earth. You can even set the size of the map (maximum is 60 km). And then you can edit it further in Photoshop.
You can try painting it yourself in Photoshop (or any other similar software, like Gimp).
You can also just try Googling for heightmaps and try which one suits you the best (keep in mind the resolution must be 512,1024, 2048!)
However you get your heightmap, always keep in mind how each texture of the heightmap is connected, so the seams need to fit together. Bad texture connection is very visible in the game.
Here is an image of how the textures are connected:

[[File:Planet Material Texture Order.jpg|512px]]

===Roads===
We created roads using World Machine tools. You can find guide how to do that in between World Machine tutorials.

==Atmosphere==
[[File:View Image.jpg|1024px]]

Here, you will find everything you ever wanted to know about Atmosphere Settings in Space Engineers but were afraid to ask, my dear friend. So without any further ado. Let’s start with the “Atmosphere” settings window which you access in-game by hitting F12 -> Render Button -> Atmosphere checkbox. The new Atmosphere settings window opens immediately on the right side of the screen, showing a bunch of tricky sliders.

[[File:Cloud Layers Definition.jpg|1024px]]

If your pants are still dry, and if by any chance you’re still reading this, let us assure you that everything is pretty simple and not so scary as it may seem when you first open it. So let’s start with the brief and really quick explanation of what every slider or group of sliders are meant for. Lastly, remember that to alter any setting in this Window you have to hold “Alt” on your keyboard.

Enable Atmosphere (checkbox) – Well, as Captain Obvious immediately states to us – it just enables or disables Atmosphere on a planet and nothing more.

Time of Day (slider) – Controls rotation of the Sun around a Planet. You’re given the Power to decide which time of day it is now. Cool isn’t it?

Pick Planet (Button) – In situations when you have more than one planet in your world, you may want to alter the settings of each planet’s atmosphere individually. So this button enables you to immediately pick the current atmosphere values of the planet you’re currently on. For example, fly to the Moon, press “Pick planet” button and you will get corresponding atmosphere values of that planet to play with. Fly back to Earth or any alien planet, and do the same to alter atmosphere settings of these planets. Yay!

Rayleigh Scattering R,G and B (sliders) – Group of three sliders which control the main, overall color of the Atmosphere. It’s that atmosphere color which is going to be seen from outer space and on the ground too! If you want to make your atmosphere alien green or purple – these are the correct set of sliders to play with. Each slider controls corresponding R,G or B (0-255) values. Pretty straightforward.

[[File:Atmosphere Settings.jpg|512px]]

Mie Scattering R, G and B (sliders) – Group of three sliders to control the color of the Sun glow. It would be weird to have Green atmosphere and Red sun glow right? You would normally want to set it to yellow or something light green or so. But it’s your choice you can make any color you want. But please note that in order to have noticeable results you have to actually HAVE that glow around your sun. This setting is called “Mie Height” and it has to be set to a fairly high value otherwise it wouldn’t be too prominent. We will talk about this “Mie Height” setting in a minute. No worries.

The following three sliders are complementary and play well together. It means you have to find a good balance setting them which is quite easy:

Rayleigh Height Surface (slider) – Controls the thickness of the atmospheric layer when you’re on or near planet’s Surface. For example. You normally want atmosphere layer to be fairly thick to cover high points of the planet’s surface like mountains and high hills while you’re on the ground because you have actual high picks in your surface geometry which you have to cover. Otherwise you would see black space when you’re on the high mountain. But technically, when you’re leaving the planet’s atmosphere all of these high peaks and mountains are starting to slowly collapse vertically forming a smooth spherical shape of the planet, if they wouldn’t - we would have planets looking like a spiky balls with mountain peaks sticking out in all directions. That’s why when all the high peaks are collapsed to the ground to form a perfect sphere - we are left with abnormally thick and wrong looking atmospheric layer thickness when observed from the outer space. How to fix this?! That’s where “Rayleigh Height Space” slider comes into play, as it controls the thickness of the atmospheric layer seen from outer space.

Rayleigh Height Space (slider) – Controls the thickness of atmospheric layer when you observing the planet from outer space. Like it was said earlier, settings for atmosphere thickness when you’re on the Surface and when you’re in an outer Space can’t be same and normally you want to make it much thinner when it is seen from outer space like it’s in real world. Refer to the following Pic to get better understanding.

Rayleigh Transition (slider) – Ok, so now that we have set the width of the planetary atmosphere for both - when we’re on the Surface and when we’re observing it from outer space, it is time to decide at which distance to switch between two, right? So that’s exactly what this slider does – sets the exact value at which distance that transition must happen. You can play around with this value to find the best setting, just remember that the main goal is to have this transition as smooth as possible, fortunately it’s super easy to achieve. Just make sure that while you’re on the ground and standing on a highest point you still see some atmosphere color (like Blue color in earthlike planets) ,and just about when you start to see the whole planet on your way to the outer space, switch it to the thinner (Rayleigh Height Space) version.

Mie Height (slider) – Controls the size of the outer glow effect of the Sun. Like it was said earlier, when you’re setting your color of the Glow effect via “Mie Scattering RGB” sliders, this particular setting (Mie Height) must be set to a fairly high value otherwise you won’t see it as there won’t be any glow. Look, you can’t change the color of a non-existing thing, soldier. Dismissed!

Sun size (slider) – Controls the size of the Sun.. What else did you expect from it?!

Sea Floor modifier (slider) – Defines the lowest (starting) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer starts. It depends on your planet’s relief, your lowest and highest peaks. Adjust individually for each planet. You’ll “feel” the right value immediately.

Atmosphere Top Modifier (slider) – Defines the highest (ending) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer stops. It depends on your planet’s relief. Adjust individually for each planet. You’ll “feel” the right value immediately. But normally you want this value to be set pretty high.

Intensity (slider) – Actually it should be called “Fog Intensity” as it’s exactly what it’s responsible for but I hope it will be changed by some coder guys eventually J. Controls the amount or intensity of the fog while you’re on or near the planet’s surface (doesn’t do anything when you’re in outer space).

Fog Intensity (slider) – And this, should be actually called “Fog Distance”. It controls the distance fog actually covers. The higher this value – more objects in front of view are covered with fog. (doesn’t do anything when you’re in outer space).

Restore (Button) – Ok, just in case you screw everything up, you always have a chance to revert all the changes you’ve made by clicking this Restore button, soldier! Very convenient isn’t it?!

==Atmosphere 2/2==
Ok, now that we got acquainted with all Atmosphere settings and know how they work, it is time for us to actually change a few settings to alter the look of our Atmosphere! Now the fun part begins. Let’s say that we want to change the color of Earthlike planet’s atmosphere from its natural Blue color to the Green one, so it looks more “alienish”. Please note, that all atmosphere settings are stored in “PlanetGeneratorDefinitions.sbc” file and they are NOT replaced even when you change these values in game and make a save. If you want to change those values you have to change them directly in the code of the “PlanetGeneratorDefinitions.sbc” file only! The system reads those atmosphere values from this file every time you’re loading your worlds.

But how for God’s sake would you know which values are correct and really desirable to put them in the code? This is really simple. You just adjust your atmosphere settings to your liking right in the game, and when you’re done and happy with it, you just copy those values into the code (you can screen grab the in-game view with Atmosphere Settings window or just write them down manually, not a big deal) But to paste those values in the code, you have to know WHERE to paste it, right? You don’t just randomly paste numbers into the code, do you? You may hurt yourself!

So please open “PlanetGeneratorDefinitions.sbc” file in any decent text editor and find the following line:
<pre>
<SubtypeId>EarthLike</SubtypeId>
</pre>
It’s a name or identifier of a planet, and since it’s named Earthlike, we know for sure that below are the definitions related to Earthlike planet. Cool! Now just scroll down to the part where you will see a commented (inactive) line of code which goes like:



Or alternatively, just Ctrl+F to find the following line. You must see something similar to this:

[[File:Atmosphere definition.jpg|512px]]

So here as you can see everything is pretty self-explanatory. Except a few lines that are just named differently in the code. If you want your atmosphere to “remember” the settings you have made you have to enter those values here to the corresponding lines. The following schematic pic shows dependencies between the code lines and the slider names in Atmosphere Settings window quite clearly:
(Click to enlarge)

[[File:In-game Atmosphere Debug Input.jpg|1024px]]

Now let’s just change the blue color of the atmosphere to orange. As you remember, group of three RGB sliders named “Rayleigh Scattering” are responsible for changing the main color of the Atmosphere. So why wait?

[[File:Mars-Like Atmosphere.jpg|1024px]]

Spectacular right? Now, let’s change the sun glow color “Mie Scattering RGB” to an orange tint too. It could stay the same yellow of course but let’s change it so you could have an idea. Remember to press “Alt” on your keyboard while you’re dragging those sliders.

[[File:Another Red Atmosphere.jpg|1024px]]

Ok, now it’s more orange but we have to increase the glow effect a bit to see it more prominently. And as we remember, the glow size control is “Mie Height” slider. Crank it up from 30 to 50.

Good, the glow effect became more prominent. Looking nice isn’t it? Of course, you can continue adjusting it and come up with really crazy results, but if you’re ok with what we already have, then just write down all the values that you currently have in your Atmosphere Settings window on the right or screenshot them and paste into any image editor for your reference. And back in the code editor, just enter those values into corresponding tags in the code and save it:

[[File:CloseUp Atmosphere definition.jpg|512px]]

That’s it! From now on, every time you load up your world with Earthlike planet in it, or spawn Earthlike planet, the atmosphere on it will be exactly the way you adjusted it via Atmosphere Settings! The God himself must have been using something like this we suppose..

[[File:Mars-like Atmosphere Final.jpg|1024px]]

==Clouds==
The first thing that should (probably) come in to your mind when you finally learn how to tweak Atmosphere settings, is probably how to change the look of the Clouds! Because, normally, when you change the color of the atmosphere you would like the clouds color to be relatively close to the Atmosphere color. In our Atmosphere guide (if you read it) we were sharing some knowledge about changing the look of the Atmosphere. We made it orange which is kind of cool all on its own, but what really draws our attention and not in a very good way – is the color of the clouds. As you can see they’re white which is looking wrong isn’t it? In an orange atmosphere environment you would expect orange or yellow clouds right? So that’s what we’ll be doing in a minute – changing the look of our cloud layer and getting to know their under-the-hoods.

Like with Atmosphere settings, the Clouds setting are stored in the same “PlanetGeneratorDefinitions.sbc” file located in KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Data and are individual for each planet. Usually we base our code lines so the Cloud definitions come right after Atmosphere definitions which makes it very convenient to search for. Just open your “PlanetGeneratorDefinitions.sbc” file in any decent advanced text editor and search for this commented (inactive) line of code:



Note: you can download the DDS files from here[mirror.keenswh.com]

[[File:Cloud Layers Definition.jpg|1024px]]

That’s where all the cloud settings for particular planet are stored. The following picture is a brief breakdown of cloud definitions:

Basically, the structure of placing clouds on any planet is as follows:
<pre>
<CloudLayers>
<CloudLayer>
Blah Blah Blah Beautiful Clouds Blah Blah Blah
</CloudLayer>
</CloudLayers>
</pre>
So, as you can see everything is super easy. Simply put, <CloudLayers> tags are meant for global separation of Cloud definitions from other code definitions and are here just to define where the code for the clouds start, while <CloudLayer> tags (again, don’t mistake with CloudLayers) are the actual cloud layers and each pair of these tags (<CloudLayer>…</CloudLayer>) define the look and behavior of each cloud layer. As Captain Obvious states - The more <CloudLayer> pairs you have.. umm - the more cloud layers you will have!

For example. You can have more than one Cloud layer, to simulate even more complex cloud patterns than you initially had in your texture file! And that’s when <InitialRotation> and <RotationAxis> tags come into play. You can assign values to these tags for each Cloud layer individually thus having the cloud spheres to be initially rotated and spinning on different angles creating more interesting and natural cloud patterns. So you basically just stack them this way:
<pre>
<CloudLayers>
<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>
</CloudLayers>
</pre>

That’s it! Now you have three Cloud Layers! And of course you can do it for the Far and the Near cloud layers as well.

Your main cloud color texture must be 4096x2048px RGB file saved in DDS format without alpha as “CloudName_cm.dds file” and it must contain only the color information of your clouds. For Alphamask file please create a separate file of the same 4096x2048px dimensions containing only Alpha mask, make it a greyscale file, save as DDS luminance format and name it “CloudName_Alphamask.dds”. Back in the code, in <texture> tags you just write “Cloudname.dds”, no worries - the engine will identify required “cm” and “alphamask” files itself, just make sure both files are in the correct folder. (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Models\Environment\Sky).

As you know, clouds that are seen from the outer space and the clouds that you see through your window don’t look the same because of the huge differences in scales in both cases. That’s why we have two types of clouds on each planet. First one (commented as “Far layer” in the code) – the clouds that you see from the outer space. They usually look like NASA satellite orbital photo shots.

[[File:Clouds.jpg|1024px]]

And the Second one (commented as “Near layer” in the code) – the clouds that are seen when you’re on the ground or close to it. These should look like a significantly zoomed version of the first ones - more detailed, wispy and more individual. Like the ones you used to see in the sky every day. Refer to the picture.

[[File:LargeClouds.jpg|1024px]]

Now, how to actually separate these two types of cloud layers and to make them come in layers – one after the other. This is very simple too. The maximum overall Altitude (height) of our atmosphere layer is 2. So we have to set up our cloud layers in a tricky way, so that when we’re in outer space - we would see the “Far layer” clouds ONLY, and as we’re getting lower (approaching the ground), on a particular altitude (height) smoothly switch to the “Near layer” clouds and have the “Far layer” clouds hidden. Sounds crazy but it will become clear if you look at the following pic:

[[File:CloudLayerDiagram.jpg|1024px]]

As you can see things are really self-explanatory here too. By setting the Start and End values in <FadeOutRelativeAltitude..> you basically create a vector, the starting point of which is infinity which means anything below this start point will be constant value, thus – making it possible to set the Far layer to be seen from outer space (values greater than 2), and preventing Near cloud layer from being seen - because it is set to fade out on 1.6. And vice versa – when you’re on the ground, you won’t see Far layer clouds layer because it faded out on much higher distance of 1.4. Not so hard right? Of course you can alter and tweak those values to your liking depending on the planets height maps/relief to get the desired transition between Far and Near cloud layers.

So now that we’re empowered with this knowledge, the only thing we’re left to do is to actually change the color of the clouds from white to yellow color so our clouds look more natural in an orange Atmosphere environment. As we remember, our clouds are consisting of two texture files – a file containing color information (usually just a plain color) and a file with an alpha mask only. We already know that the “Far layer” clouds (the ones seen from space) use “EarthFarClouds_cm.dds” texture file and the “Near layer” clouds use “Landsky_texture_cm.dds”. How we know that? It’s written in <texture> </texture> definitions, remember?

[[File:CloudTextureRoute.jpg|512px]]

Great! So now just open “EarthFarClouds_cm.dds” and the “Landsky_texture_cm.dds” and fill both files with plain yellow color and save them!

[[File:YellowCloud Texture.jpg|1024px]]

Start the game and spawn an Earthlike planet and voila! You got perfect yellow clouds!

[[File:Scenery With Yellow Clouds.jpg|1024px]]

==Planet ambient sounds modding - day/night biome sounds==

Sound rules are in the Content\Data\PlanetGeneratorDefinitions.sbc file. Here you can set different sounds based on player’s location or daytime on the planet.
<pre>
<SoundRule>
<Height Min="0" Max="0.5"/>
<Latitude Min="55" Max="80"/>
<SunAngleFromZenith Min="0" Max="180"/>
<EnvironmentSound>AmbIcelandDay</EnvironmentSound>
</SoundRule>
</pre>
Height stands for where you want the sound to play at the height of the heightmap (0-7200m). It is always +12% of the planet's diameter. 0 is from the the lowest start of the surface to 1.0 which is 100% of the surface (maximum height).
Latitude means angle from the equator. Therefore 0 to 20 will mean that this sound will mostly play in the desert area, 20-50 is mostly the green forest area, and so on.
SunAngleFromZenith NEEDS MORE INFO!!!
EnvironmentSound this is the name of the sound you want to use.

You can find all available sounds in Audio.sbc (location shown below) Here you will also put your own ambient sound with your own custom name.

How to implement custom ambient sound

All Ambient sounds are stored here:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Audio\ARC\AMB\

If you want your own sounds, they should be a loop sound, and on average should not be bigger than +-5 MB.
The supported format is: .xwm but .wav can also work, even though its file size is usually a lot bigger (not recommended).

Once your audio is done, implement it here in this file:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\Audio.sbc
<pre>
<Sound>
<Id>
<TypeId>MyObjectBuilder_AudioDefinition</TypeId>
<SubtypeId>AmbAlienForestDay</SubtypeId>
</Id>
<Category>AMB</Category>
<MaxDistance>100</MaxDistance>
<Volume>0.2</Volume>
<Loopable>true</Loopable>
<Waves>
<Wave Type="D2">
<Loop>ARC\AMB\AmbAlienForestDayLoop2d.xwm</Loop>
</Wave>
</Waves>
</Sound>
</pre>
Here edit only what is highlighted, otherwise I cannot guarantee that it will work properly!
<SubtypeId> This is how you will name your AMB sound, keeping in mind upper and lower case letters. Do not use _ or other special characters!
<Volume> This is self explanatory I hope.
<Loop> Here you just need to lead the definition to your file. ARC/AMB/ is the default location, so do not change that.
But if you want, you can make another folder in AMB for your custom ambient sounds for better organisation.

==In-game map modding==
Maps in Medieval Engineers are generated based on terrain and buildings on it. This means that they will work for any modded planet in their default form. That being said, the way map is generated is also fully moddable.

We definitions for map are located in Content\Data\Screens\MapDefinition.sbc. To mod maps you will have to alter/add definitions in this file, all vanilla textures for maps can be found in Content\Textures\GUI\Map. Feel free to use/alter any of them for creation of mods for Medieval Engineers.
Map content modding (Friend/foe display, tax notifications,...
In Medieval Engineers there are 2 view modes of map. Kingdom view which is showing entire kingdom and region view which is zoomed part of a kingdom map. Region is 1kmx1km large on 10 km diameter planet. Both views display different elements.
What is shown in these views depends on what layers it contains
<pre>
<Definition xsi:type="MyObjectBuilder_PlanetMapDefinition">
<Id Type="MyObjectBuilder_PlanetMapDefinition" Subtype="Main"/>
<BackgroundGenerator Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
<RegionView>
<Layers>...</Layers>
</RegionView>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</Definition>
</pre>
BackgroundGenerator refers to a definition of background texture that serves as a background on top of which all the map elements are placed.
<pre>
<RegionView>
<Layers>...</Layers>
</RegionView>
</pre>
The three dots in middle represent layers of elements that show in region view. List and description of all layers is in next section of this document.
<pre>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</pre>
The three dots in middle represent layers of elements that show in kingdom view. List and description of all layers is in next section of this document.
(I did not Kingdom view in its expanded form because it would take up too much space.)

===Layers description===
<pre><Layer xsi:type="MyObjectBuilder_MapBackgroundLayer" /></pre>
This layer draws the background. As generated based on chosen background definition.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaDevelopmentLayer">
<Threshold BlockCount="10" Sprite="Textures\GUI\Map\SmallGrid.png"/>
<Threshold BlockCount="30" Sprite="Textures\GUI\Map\MediumGrid.png"/>
<Threshold BlockCount="60" Sprite="Textures\GUI\Map\LargeGrid.png"/>
</Layer>
</pre>
This layer displays icons based on amount of blocks there is in an area. You can set the block thresholds, or mod the textures. It is also possible to add more thresholds. 80x80 px, png.

[[File:Smallest Settlement.png|150px|frameless]]
[[File:Medium Settlement.png|150px|frameless]]
[[File:LargestSettlement.png|150px|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_RegionFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for region, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaOwnershipLayer">
<AlliedBgColor Hex="#806464FF" />
<PlayerBgColor Hex="#8064FF64" />
<EnemyBgColor Hex="#80DC6415" />
</Layer>
</pre>
This layer defines color overlay over map areas based on ownership. You can mod which color is used for allies, your own areas or for enemies
<pre>
<Layer xsi:type="MyObjectBuilder_AreaUpkeepLayer">
<TaxIcon>Textures\GUI\Map\TaxIcon.png</TaxIcon>
</Layer>
</pre>
This layer displays tax icon on areas that belong to you and require tax payment soon. Texture is 80x80 pixels, png.
[[File:Taxes.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapPositionLayer">
<LocalPlayerImage>Textures\GUI\Map\PlayerPosition.png</LocalPlayerImage>
<OtherPlayersImage>Textures\GUI\Map\AllyPosition.png</OtherPlayersImage>
</Layer>
</pre>
PlanetMapPositionLayer displays player icon above area where they are.
[[File:Ally.png|frameless]]
[[File:Player.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_ActionTrackingLayer">
<ActionImage>Textures\GUI\Map\Action.png</ActionImage>
</Layer>
</pre>
Shows icon over an area on map with fighting / destruction.
[[File:AttackedArea.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_CurrentMapSelectionLayer">
<SelectionImage>Textures\GUI\Map\MapSelection.dds</SelectionImage>
</Layer>
</pre>
This is highlight of a region, that player selected with his mouse.
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapGridLayer">
<GridColor R="0" G="0" B="0" A="228"/>
</Layer>
</pre>
This layer sets which color is the grid drawn.
<pre>
<Layer xsi:type="MyObjectBuilder_KingdomFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for kingdom, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_RegionOwnershipLayer">
<PlayerIcon>Textures\GUI\Map\PlayerLandIcon.png</PlayerIcon>
<AllyIcon>Textures\GUI\Map\AllyLandIcon.png</AllyIcon>
<EnemyIcon>Textures\GUI\Map\EnemyLandIcon.png</EnemyIcon>
<PlayerAllyIcon>Textures\GUI\Map\PlayerAllyLandIcon.png</PlayerAllyIcon>
<PlayerEnemyIcon>Textures\GUI\Map\PlayerEnemyLandIcon.png</PlayerEnemyIcon>
<AllyEnemyIcon>Textures\GUI\Map\AllyEnemyLandIcon.png</AllyEnemyIcon>
<PlayerAllyEnemyIcon>Textures\GUI\Map\PlayerAllyEnemyLandIcon.png</PlayerAllyEnemyIcon>
</Layer>
</pre>
RegionOwnershipLayer generates textures used to express ownership on regional map.

===Background generator (trees, mountains, roads,...)===
Map background is where all the trees, mountains, hills are drawn. It is also capable of coloring map based on what is in planet’s material map (this is how we make roads for example).
All settings for map background are in MedievalMapBackgroundDefinition. The definition also in Content\Data\Screens\MapDefinition.sbc. I will go through various parts of the definition.

<pre><Id Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
Type of the definition says that this map background definition. Subtype is name of this specific background definition. If create your own background with unique subtype
Make sure you create your own background with unique subtype

<DrawHeightmap>false</DrawHeightmap>
When set on “true” planet’s heightmap is drawn under the map.
<Resolution>4096</Resolution><
Sets resolution of the generated in-game map.

<Features>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</Features>

<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</Definition>
</pre>
===Map Coloring===
You can use colors in material or biome map of a planet to appear on the game map. (roads for example). You define map coloring in a node called ”Features”. The coloring uses colors from planet material texture. You can learn more about material texture in biomes modding and surface material modding.
<pre>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
</pre>
This specific feature is used for painting roads on map with dark brown color. In Color you define which color will be the in-game map colored. Material=”67” decides where will be the color applied and refers to a red channel value on planet material texture.
<pre>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</pre>
This specific feature is used for painting forests on map with opaque brown. In Color you define which color will be the in-game map colored. Biome=”60” decides where will be the color applied and refers to a green channel value on planet material texture.

===Sprites===
Medieval Engineers map can also place sprites on map based on terrain shape. All the sprites are on one texture
<pre>
<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</pre>

[[File:AtlasCoordinateUsage.png|512px]]

Note: Illustrates how sprite is defined on our spritesheet. Example sprite:
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />

==Voxel color overlay modding==
We have a cool tech that enables us to color-shift color of almost any item in the game. Currently we are using it for trees(adds small color variations to the same model of a tree) and voxels above iron deposits.
==Fast travel settings modding==
In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around.
In this section of the guide we will show you how to mod which sectors are blocked.
There are 2 ways you can go about it:
===Generate automatically based on terrain shape===
Game is capable of creating fast travel map on its own based on height and terrain steepness. It is possible to mod thresholds for both height and steepness.
You will find the thresholds in Content\Data\Game\FastTravel.sbc. In a MyObjectBuilder_TerrainReachabilityProviderDefinition.
<RiseThreshold> - Sets min. terrain height change which will cause that area is unreachable.
<HeightThreshold> - Sets height of terrain after which area is unreachable, if it goes over this value. Range is 0 - 1.

If there are texture overrides in the definition, you have to erase them in order for the parameters to take effect. Texture overrides are nodes that are called in this fashion: <OverrideNAMEOFFACE>. You will learn more about these overrides in the next part of Fast travel modding.

===Creating fast travel texture override===
If you want to have full control over which areas are reachable and which are not regardless of terrain, you can create a simple texture on which you mark unreachable areas.

The texture is 80x80 pixels, RGB 8 bit. Black pixels forbid entrance.

When you have the texture, select route to it in the definition:
<pre><OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward></pre>
Reachability definition example:
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>
<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>
<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
</Definition>
</pre>
This definition would generate fast travel reachability everywhere, except for front planet face (Fareon kingdom) where fast travel reachability is created based on your texture.

===Development reachability===
Claimable area size, border highlight, contested timer modding
Size of the area and highlight properties are moddable as well.

===Area borders highlight===
<NeutralColor R="225" G="32" B="0" A="64" /> - Set color of an unowned territory
<SelfColor R="0" G="255" B="0" A="64" /> - Sets color of area border owned by you
<AliedColor R="65" G="105" B="225" A="64" /> - Sets color of area border that belongs to allies
<EnemyColor R="225" G="32" B="0" A="64" /> - Sets color of area border that is hostile
<WallSettings Depth="15" Rise="3" SegmentCount"71" End="115" /> - Changes shape of the border. Depth sets how deep is border submerged. Rise sets how tall is the border.
<Fade Start="71" End="115" /> - This sets at which point the border starts to fade.
Contested timer
When players claim area with claimblock, area goes to a “contested” phase for some amount of time, in this phase other players can still attempt to build their own claim block and claim the area. This time is moddable.
Content\Data\Game\SessionComponents.sbc contains definition called MyObjectBuilder_AreaOwnershipSystemDefinition. To mod this value, add this definition to your mod with changed value of <ContestedTimeInMinutes> parameter.

==Permissions modding - what is/isn’t allowed to do in claimed areas==
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.
Description of available actions to set permissions for:
Name=”Build” -> block placement permissions
Name=”Repair” -> Repairing/building already placed blocks
Name=”Deconstruct” -> Deconstructing
Name=”QuickDeconstruct” -> Faster deconstruction
Name=”VoxelEdit” -> Mining or shoveling
Name=”Destroy” -> Damage with hand weapons
Name=”Interaction” -> Chest opening, door opening
Name=”ClaimBlockInteraction” -> ClaimblockGui

===List of available Groupnames:===
Groupname: “Owner” -> Player who owns area
Groupname: “Allies” -> Mostly faction members of owner of the area
Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
Groupname: “Enemies” -> Players in factions that are hostile to your faction

==Compass modding==
It is possible to mod visual look of an in-game compass. All definitions of compass are stored in Content\Data\GUI\CompassDefinition.sbc. Our textures for compass are in Content\Textures\GUI\Compass folder if you want to check out how they look or use them in your mod.
===Creating compass texture atlas and setting coordinates for its elements===
Just like with map sprites, we save main compass elements on a single texture, then define parts of it using pixel coordinates. First setup origin point, then add width and height of the rectangle
Example texture coordinates for top part of the compass:
[[File:CompassTextureCoordinates.png|1024px]]
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>

===Explanation of compass definition line by line===
<pre><Texture>Textures/GUI/Compass/compass.png</Texture> </pre>
Route to a texture atlas.
<pre><KingdomIcon>Textures/GUI/Compass/Icon-Kingdom.png</KingdomIcon> </pre>
Route to icon symbolizing a kingdom.
<pre><Padding>7</Padding></pre>
Padding is added vertically between the top and bottom textures and the edges of the contents of the compass.
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>
Rectangle in the texture that contains the top part.
<pre><BottomCrop X="0" Y="0" Width="0" Height="0"/></pre>
Rectangle in the texture that contains the bottom part.
<pre><BackgroundCrop X="0" Y="64" Width="512" Height="64"/></pre>
Rectangle in the texture that contains the background.
<pre><ArrowCrop X="0" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the little marker used for elements that are drawn and have no icon.
<pre><MarkerCrop X="32" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the interval bars drawn every few degrees.
<pre><ShadowCrop X="64" Y="128" Width="80" Height="32" Left="8" Right="8"/></pre>
<pre><ShadowPadding Left="12" Top="8" Right="12" Bottom="8"/></pre>
Rectangle in the texture that contains the text shadows. Shadow is 3-Sliced, meaning the texture is split in three parts: [left|middle|right]
The sizes of left and right define the cropping lines that split the texture into three. The Sides are then always kep proportional as the texture is scaled.
<pre><VisibleRange>200</VisibleRange></pre>
Visible range in degrees.
<pre><Width>700</Width></pre>
Width in reference resolution pixels.
<pre><FontSize>1.1</FontSize></pre>
Scale of the font based on default.
<pre><VerticalOffset>0.065</VerticalOffset></pre>
Vertical offset from the top of the screen. 0 = top of the screen, 1 is the bottom. Compass is centered around this position.
<pre>
<TagStyles>
<TagStyle Tag="ClaimArea" Style="Bellow" MaxCharacters="15" Ellipsis="true"/>
<TagStyle Tag="Cardinal" Style="Above" MaxCharacters="1"/>
<TagStyle Tag="Kingdom" Style="Bellow"/>
</TagStyles>
</pre>
This section adds tags that are visible on compass and in which style. Currently we have 3 types of tags. Claim area - shows your claimed area on the compass, Kingdom tag shows kingdoms and Cardinal tag shows cardinal points (North, South,...). Each tag’s visual appearance is defined in tag/waypoint definition. Styles defines where should the text appear. Available styles: Center, IconOnly, NotShown, Bellow, Above.

===Explanation of Waypoint/Tag definition===
<pre>
<Definition xsi:type="MyObjectBuilder_WaypointDefinition">
<Id Type="MyObjectBuilder_WaypointDefinition" Subtype="Kingdom"/>
<IconPath>Textures/GUI/Compass/IconKeep.png</IconPath>
<Color R="255" G="255" B="255" A="255"/>
</Definition>
</pre>
IconPath contains path to the texture of kingdom icon. Color defines color of the text that is shown with the icon. (Example: Fareon, [[File:Kingdom Icon.png|thumb]])
===Compass texture vs in-game look comparison===
Texture:

[[File:Compas Texture with Zones.png|1024px]]

In-game look:

[[File:In-gameCompassZones.png|1024px]]
<NoWiki>*</NoWiki>note that background crop and bottom crop are not used in vanilla (empty opaque texture)

==Indestructible grids==
There is a way how to make some buildings in your save indestructible. We are using this feature for starting area buildings. Some you guys might make a good use of this feature in your pre-made worlds.

Currently, only way how to do this is to make edits to an existing save file. So you can only use it for world modding.

===Making indestructible cubegrids in existing safe===
Goal is to open world’s safe file in a text editor, find your cubegrid in it and add this tag to it: <DestructibleBlocks>true</DestructibleBlocks>.

#Find your save file. By default save files are stored in C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Saves
#Open folder with your save and find file called SANDBOX_0_0_0_.sbs. This file can be opened with any text editor you prefer.
#In the SANDBOX_0_0_0_.sbs search for the cubegrid name of the building you want to make indestructible. (use find/search function in your text editor, or you will grow old before you find it)
#Tip: To find out name of a cubegrid, create blueprint of the building. The name that the building saves as in your blueprint screen is the name of the cubegrid.
#You should find the name in tags called: <DisplayName>YOURCUBEGRIDNAME</DisplayName>
#Under the name, add following tag with setting set to false: <DestructibleBlocks>false</DestructibleBlocks>
#If you followed instruction, the indestructibility tag is now in node called <MyObjectBuilder_EntityBase> and not in any of its child nodes.
#Save the edited file.
#Load the save and test destructibility
#It worked! Enjoy
#It is still destructible. Go to point 1.

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding - Full Guide

2017-03-13T16:34:29Z

Lukas: /* Assign environment to a planet */

==Introduction==
Hello fellow Medieval Engineers!
I would like to present you with a guide that will help you understand how we created planets at Keen Software House and how to mod your own into the game.
Feel free to use/alter company owned files for your Medieval Engineers mods.

So let's get to modding!

==Recommended Software==
# Microsoft Visual Studio - or Notepad++ (Link[notepad-plus-plus.org]) - for opening files with .sbc extension where we have definitions for every feature in the game.
# Adobe Photoshop - for editing material and heightmap textures
# World Machine Professional - for heightmap easier creation (much more realistic looking terrain, without manual work)

(Basic Edition is also available, but the max resolution output is limited to 512x512 pixels)
http://www.world-machine.com

===Advice===
We would like to mention one thing before you get into modding planets:
For your own sake we recommend you to load either PlanetTemplate or EarthLikeModExample and test/edit all the things there, so you get to know the system and how everything works.

After that you can create your own from scratch. This is entirely up to you.

==General modding principles - how to make any mod==
I will explain again basic principles of how mods are applied.

All of our vanilla source files are all saved in a folder called content in your *game folder. If no mods are assigned to a world that you are loading, game uses only files from this content folder but if there are mods, game loads also files from mod adding more content or potentially rewriting vanilla content based on content of the mod’s folder. Mod is nothing else but a folder with another files.
Mod files are stored in mods folder on your computer , and if you are using them for the first time, they are downloaded from workshop first time you try to load/connect to a world with those mods.
Mod folder: C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Mods
===Opening mod and examining mods content===
When you open Mods folder, you will see mods as files with .sbm extension. But they are really just folders and to examine them, all you have to do is rewrite the extension from .sbm to .rar and then you can open them with rar and examine content.
Mods are not listed with their names, but with their steam id number. To find specific mod, you have to go to the mods workshop page

Examining other mods similar to your idea is a fast way to learn.
Example:

<NoWiki>*</NoWiki>By default this is SteamLibrary\steamapps\common\MedievalEngineers\Content. You can also get there if you go to steam library(same place where you start the game), right-click Medieval Engineers, select properties, local files and finally click on “browse local files”.
==Materials modding==
In case you are thinking about making your own trees and voxel materials, we have some good news for you!

There are two separate guides that you can follow to make your own stuff.

General modding guide - get started

===Voxel material modding===
http://steamcommunity.com/sharedfiles/filedetails/?id=568406623

==Planet Size==
Planet size is defined in a scenarios.sbc. Every time you click on create new world in the game it uses scenario definition to create a new safe file. Although this scenario definition is not moddable, you can still use it to create a world and share the world itself on the workshop.

First go to where you have Medieval Engineers source files and find Data folder (SteamLibrary\steamapps\common\MedievalEngineers\Content\Data\Scenarios.sbx)

==All planet related files overview and where to find them==
To summarize how planet modding in ME works, we can say this:
We use 2 types of textures and then we define how the game should interpret those textures in definitions. One texture is heightmap that is used just for generating terrain shape, another one is used to place everything else on the planet (ores, trees and plants, bots).
[[File:Diagram.png|1024px|center]]

==Material Texture modding==
Material texture is used to store information about location of various planet surface features. These features are surface materials, biomes (trees, bots, plants,..etc) and where you can find ore. Each one of these uses one color channel. Surface materials use red channel. Biomes use green. Ores are in blue channel.
We use 6 material textures (2048x2048) for each planet. You can find all our material textures here: Content\Data\PlanetDataFiles.
Each planet has its own folder. The folder has to have the same name as the planet.

[[File:MaterialMapBreakdown.jpg|512px]]

Illustration of how are the material textures connected to each other:

[[File:Planet Material Texture Order.jpg|512px]]

====The process of material texture creation is really simple. You have two options:====
=====Copy an existing map to your folder and overwrite the green channel and edit them to your liking=====
This is highly recommended to avoid errors!
=====Create a new: step by step in Photoshop=====
#Set both width and height to 2048 pixels
#(for smaller planets this can also be 1024 or less, but all textures need to have the same resolution! Even the heightmap)
#Set resolution - Pixels/Inch to 72.
#Set colour mode to RGB Colour - 8bit
#Now start painting with the pencil tool on each RGB Channel separately.
#Never on all three at once! (It will F. up everything - trust me).

===Surface voxel material definitions modding - grass, sand, snow===

[[File:RedChannel.jpg|22px|frameless]]

Surface “voxel materials” refers to what you know as grass, soil, stone.. We use red channel of the material texture to set where all the terrain appears. Then you need to write definitions in the Content\Data\PlanetGenerator.sbc to tell game which voxel should appear at specific red channel value.
Example of the definition of road:
<pre>
<ComplexMaterials>
<MaterialGroup Name="Road" Value="67">
<Rule>
<Layers>
<Layer Material="Soil" Depth="2"/>
</Layers>
<Slope Min="0" Max="90"/>
</Rule>
</MaterialGroup>
</ComplexMaterials>
</pre>
Example of corresponding material texture with road:

[[File:RoadMaterialTextureExample.png|512px]]

====Complex materials====
Complex materials definition allows to paint the map with a set of “voxel coloring rules”. Meaning that one color value in red channel can color terrain with different voxels based on rules like slope, longitude or latitude and height. (So with our road example)
<pre>
<MaterialGroup Name="Forest_Grass" Value="120">
<Rule>
<Layers>
<Layer Material="Woods_grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="0" Max="25"/>
<Latitude Min="-180" Max="180"/>
<Longitude Min="-180" Max="180"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="25" Max="45"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Rocks_grass" Depth="2"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="45" Max="55"/>
</Rule>
</MaterialGroup>
</pre>
This definition says what voxels should be generated in spots, that are painted with red channel value of 120.
The rules in this definition will lead to following:
Flat lands (up to 20 degrees slope) will have Wood grass 1 m thick, soil will be right under the WoodGrass up to 5 m depth and there will be stone underneath the soil.
In places with medium slope, there is Grass instead of WoodGrass. And in slopes from 45 to 55 there is rocks grass 2 m thick with stone right away under it.
With this technology, we can make the color react on its own to terrain bumps or even position on planet. This saves lots of meticulous painting with heightmap.

<Layer Material="Woods_grass" Depth="1"/>
Material refers to voxelmaterial definition. (You can find it in Content\Data\VoxelMaterials.sbc). Depth means how deep should the material go under ground.
<Slope Min="0" Max="25"/>
Slope of the terrain in degrees.
<Latitude Min="-180" Max="180"/>
Latitude in degrees. 0 degree is an equator.
<Longitude Min="-180" Max="180"/>
Longitude in degrees. 0 is in the middle of front planetary texture. (Fareon Kingdom)

===Biomes definitions modding - trees, plants and bots===
[[File:GreenChannel.jpg|frameless|22px]]

Biomes refers to everything that is spawned on top of the planet. We use green channel of the material texture to set where all the terrain features appear and definitions in the Content\Data\Environment\ProceduralEnvironments.sbc to tell game which environment item should appear at specific green channel value. Also you need to assign Environment to planet in the Content\Data\PlanetGenerator.sbc in case you are adding a brand new planet.

====First make/modify environment:====
Go to Content\Data\Environment\ProceduralEnvironments.sbc

=====Procedural World Environment definition=====
This definition defines where will the environmental items spawn and with which density. (note: bots are also considered environmental item). Best way to explain how procedural environment is working is to imagine that it puts spots on entire surface of a planet. And when you start defining trees, bots and bushes, the spots get “reserved” by these categories based on how many of those should appear in the world according to your mod.
Spots are always different for each single planet.
In order to mod the procedural environment, mod our “Earth Environment” definition. Or create your own but if you do, don’t forget to also mod PlanetGeneratorDefinition, so that planet has your new procedura environment assigned to it.

=====Definition elements explained point by point:=====
<pre>
<Definition xsi:type="MyObjectBuilder_ProceduralWorldEnvironment">
<Id>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>Earth Environment</SubtypeId>
</Id>
</pre>
This part of definition is called ID. It says what type of definition this is <TypeID> and unique name of that definition <SubtypeID>.

<pre>
<MaxSyncLod>1</MaxSyncLod>
</pre>
This line defines how far away from player are the environmental items updating. This is important feature for optimization.

<pre>
<SectorSize>40</SectorSize>
</pre>
This is size of the environmental sector. It is a different sector than the claimable areas by players. It sets size of one environmental sector.

<pre>
<ItemsPerSqMeter>0.17</ItemsPerSqMeter>
</pre>
The line sets overall maximum density of all environmental items. To return to analogy i used in the introduction, this number increases the amount of spots on the planet that are reserved for all environmental items.

<pre>
<ScanningMethod>Random</ScanningMethod>
</pre>

<pre>
<ItemTypes Type="MyObjectBuilder_EnvironmentItemTypesDefinition" Subtype="Default"/>
</pre>
This sets which types of environmental items are used in this procedural environment definition. This guide explains what are Environmental item types in the very next section.

<ItemGroup Density=".017" Name="Bots" LodStart="1" LodEnd="1">
<Mapping>
<Material>Woods</Material>
<Item Type="Bot" Subtype="Deer"/>
</Mapping>
<Mapping>
<Biome>60</Biome>
<Height Min="0" Max"1"/>
<Latitude Min="-180" Max"180"/>
<Longitude Min="-180" Max"180"/>
<Slope Min="0" Max"1"/>
<Item Type="Bot" Subtype="Deer" Density="0.9"/>
<Item Type="Bot" Subtype="Barbarian" Density="0.1"/>
</Mapping>
</ItemGroup>
Item group is used to organize and better manage mappings. Mappings are definitions that actually add the environment items in the world. It is important to set Density correctly. Density (Density=".017") sets how many of the procedurally generated spots on the planet will be assigned to environmental items from this group. The name (Name="Bots") is only for naming purposes within definition and has no impact on the game. LodStart="1" and LodEnd="1" control how far from the player will the items appear.
<Biome>60</Biome> This section means that Items within this mapping will only appear on spaces that are painted with green channel value 60 on the material map.
<Material>Woods</Material> This means that the environmental items will only appear in the woods.
<Height Min="0" Max"1"/> Sets in which altitude should these environmental items appear. If this parameter is missing, items spawn in full range (Min="0" Max"1")
<Latitude Min="-180" Max"180"/> Sets at which latitude do the environment items spawn. If this parameter is missing, items spawn in full range (Min="-180" Max"180")
<Longitude Min="-180" Max"180"/> Sets at which longitude the environment items spawn. If this parameter is missing, items spawn in full range (Min="-180" Max"180")
<Slope Min="0" Max"90"/> Sets at which slopes the environment items spawn. If this parameter is missing, items spawn in full range (Min="0" Max"90")

<ItemGroup Density=".085" Name="Trees" LodStart="-1" LodEnd="1">...</ItemGroup>
<ItemGroup Density=".36" Name="Small Items" LodStart="0" LodEnd="0">...</ItemGroup>
There are 2 more item Groups. I will not go into details, since it is not
</Definition>

=====Environment items=====
We learned how to assign environments to planets and how to mod environments themselves by changing densities and environment items. But we still don't know how to make the environment items themselves. Guides for those can be found on following links.

If you want to mod trees:

If you want to mod bushes and plants:

If you want to mod bots:

=====EnvironmentItemTypesDefinition=====
Here you define various types of items. Currently we have these types: Tree, Gatherable, Farmable, Static and Bot. Before you add any item, you must make sure it fits within these types of environment items or you created a new type for them.
<Definition xsi:type="MyObjectBuilder_EnvironmentItemTypesDefinition">
<Id Type="MyObjectBuilder_EnvironmentItemTypesDefinition" Subtype="Default"/>
<Item Name="Tree">...</Item>
<Item Name="Gatherable">...</Item>
<Item Name="Farmable">... </Item>
<Item Name="Static">...</Item>
<Item Name="Bot">...</Item>
</Definition>

EnvironmentItemTypes
<Item Name="Tree">
<ProxyActivationLod>0</ProxyActivationLod>
<Provider Type="MyObjectBuilder_ProceduralEnvironmentModuleDefinition" Subtype="Growable"/>
<Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Gatherable" />
<Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Cuttable" />
</Item>
Available proxy and providers:
Proxy Subtype="Gatherable"
This line adds ability to all environmental items of this type to use action “Gatherable”. Keep in mind that the tree itself has to be setup properly in order for this to work.
Proxy Subtype="Cuttable" />
This line adds ability to all environmental items of this type to use action “Cuttable”. Keep in mind that the tree itself has to be setup properly in order for this to work.
<ProxyActivationLod>0</ProxyActivationLod>
This line says from which lod is the game logic attached to the environmental item. (when set on 0 only trees very close to you become “gatherable” and “cuttable”). This way we don’t use game logic on environmental items that couldn’t be used anyway and game is better optimized thanks to that.
Provider Subtype="Growable”
This line adds ability to all environmental items of this type to grow. Keep in mind that the tree itself has to be setup properly in order for this to work.
Provider Subtype="Farmable”
This line adds ability to all environmental items of this type to be farmable. Keep in mind that the tree itself has to be setup properly in order for this to work.
Provider Subtype="Static”
This line adds basically adds items that do nothing. They are just visual props. Like some of our fern bushes.
Provider Subtype="BotSpawner”
It is important that all environmental item types that will contain some bots have botspawner

====Assign environment to a planet====
Last thing is to assign your brand new procedural environment to a planet where it is supposed to appear. Go to Content\Data\PlanetGenerator.sbc and find definition of the planet you want your environment to be on. Then assign the environment to the planet by adding following line to the planet definition with name of your environment:
<pre>
<Environment>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>NAMEOFYOURENVIRONMENTDEFINITION</SubtypeId>
</Environment>
</pre>
SutypeId refers to the name of the environment from:
Content\Data\Environment\ProceduralEnvironments.sbc

Note: This is not necessary if you just modded existing vanilla environment and have not changed its SubtypeID

===Ores definitions modding===
[[File:BlueChannel.jpg|frameless|22px]]

Ores are placed using blue channel of the material texture to set where should ore deposits appear. When your ore deposits are painted on the material map, you need to define what ores will be there. Go to Content\Data\Environment\ProceduralEnvironments.sbc to tell game which ore should appear at specific blue channel value.

<pre>
<OreMappings>
<Ore Value="130" Type="IronOre_RichYield" Start="3" Depth="7" TargetColor="#b7340a" ColorInfluence="15 "/>
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
<Ore Value="110" Type="IronOre_PoorYield" Start="2" Depth="5" TargetColor="#a76a41" ColorInfluence="15" />
</OreMappings>
</pre>
The section you need to use is Ore Mappings.
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
Value refers to blue channel value on material texture.
Type refers to name of a voxel material from Content\Data\VoxelMaterials.sbc.
Start is depth at which the ore deposit starts. Depth is how deep under ground it goes.
TargetColor is color that will be used to color surface above the ore.
ColorInfluence sets strenght of coloring.

==Working with RGB==
Ok, Steam won't let me share that link to a small RGB Photoshop tutorial with you, so just go to photoshopessentials.com and search for RGB and it's the first link.

This is a simple tutorial to explain you what we mean when we say Grayscale ID, which can also be called the RGB values
(each channel only has one number per shade of that color ranging from 0 to 255).

Here I have loaded a Biome map texture front_mat texture which is used on the Vanilla EarthLike planet.

[[File:RGBChannels.jpg|frameless]]These are the RGB channels as you can see them in Photoshop.

NOTE: Edit each RGB channel separately!

Always use the pencil tool to paint pixels.
The brush tool has a falloff that has different values and you will not have control over those!
[[File:Color Picker.jpg|thumb]]

You can see if the numbers are correct on the top right of the screen if you have your workspace set to Essentials.

Here you will enter the values you want to paint.
Make sure you check them before saving, sometimes Photoshop can move the number +-1 (personal experience).

It doesn't matter if the numbers match, just as long as you have the correct value (ID) in the correct channel!

==Height-maps modding - terrain shape, roads==
As mentioned in 2. Required software, we used the program World Machine to create our heightmaps and then we did some minor tweaks by hand (like putting in lakes and desert areas)

First, to explain how our planet heightmaps work:
We have 6 textures that connect together (image below). Our standard resolution for a big 120km planet is 2048x2048. But you can use a lower one if you want to.

To create your own heightmap, the best action would be to find a heightmap here:
C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\PlanetDataFiles

Then you can open the texture and place yours/paint yours on a new layer, flatten the image and save it as a .PNG

There are other options for you also!
You can visit[terrain.party] this site and download a heightmap from a real place on Earth. You can even set the size of the map (maximum is 60 km). And then you can edit it further in Photoshop.
You can try painting it yourself in Photoshop (or any other similar software, like Gimp).
You can also just try Googling for heightmaps and try which one suits you the best (keep in mind the resolution must be 512,1024, 2048!)
However you get your heightmap, always keep in mind how each texture of the heightmap is connected, so the seams need to fit together. Bad texture connection is very visible in the game.
Here is an image of how the textures are connected:

[[File:Planet Material Texture Order.jpg|512px]]

===Roads===
We created roads using World Machine tools. You can find guide how to do that in between World Machine tutorials.

==Atmosphere==
[[File:View Image.jpg|1024px]]

Here, you will find everything you ever wanted to know about Atmosphere Settings in Space Engineers but were afraid to ask, my dear friend. So without any further ado. Let’s start with the “Atmosphere” settings window which you access in-game by hitting F12 -> Render Button -> Atmosphere checkbox. The new Atmosphere settings window opens immediately on the right side of the screen, showing a bunch of tricky sliders.

[[File:Cloud Layers Definition.jpg|1024px]]

If your pants are still dry, and if by any chance you’re still reading this, let us assure you that everything is pretty simple and not so scary as it may seem when you first open it. So let’s start with the brief and really quick explanation of what every slider or group of sliders are meant for. Lastly, remember that to alter any setting in this Window you have to hold “Alt” on your keyboard.

Enable Atmosphere (checkbox) – Well, as Captain Obvious immediately states to us – it just enables or disables Atmosphere on a planet and nothing more.

Time of Day (slider) – Controls rotation of the Sun around a Planet. You’re given the Power to decide which time of day it is now. Cool isn’t it?

Pick Planet (Button) – In situations when you have more than one planet in your world, you may want to alter the settings of each planet’s atmosphere individually. So this button enables you to immediately pick the current atmosphere values of the planet you’re currently on. For example, fly to the Moon, press “Pick planet” button and you will get corresponding atmosphere values of that planet to play with. Fly back to Earth or any alien planet, and do the same to alter atmosphere settings of these planets. Yay!

Rayleigh Scattering R,G and B (sliders) – Group of three sliders which control the main, overall color of the Atmosphere. It’s that atmosphere color which is going to be seen from outer space and on the ground too! If you want to make your atmosphere alien green or purple – these are the correct set of sliders to play with. Each slider controls corresponding R,G or B (0-255) values. Pretty straightforward.

[[File:Atmosphere Settings.jpg|512px]]

Mie Scattering R, G and B (sliders) – Group of three sliders to control the color of the Sun glow. It would be weird to have Green atmosphere and Red sun glow right? You would normally want to set it to yellow or something light green or so. But it’s your choice you can make any color you want. But please note that in order to have noticeable results you have to actually HAVE that glow around your sun. This setting is called “Mie Height” and it has to be set to a fairly high value otherwise it wouldn’t be too prominent. We will talk about this “Mie Height” setting in a minute. No worries.

The following three sliders are complementary and play well together. It means you have to find a good balance setting them which is quite easy:

Rayleigh Height Surface (slider) – Controls the thickness of the atmospheric layer when you’re on or near planet’s Surface. For example. You normally want atmosphere layer to be fairly thick to cover high points of the planet’s surface like mountains and high hills while you’re on the ground because you have actual high picks in your surface geometry which you have to cover. Otherwise you would see black space when you’re on the high mountain. But technically, when you’re leaving the planet’s atmosphere all of these high peaks and mountains are starting to slowly collapse vertically forming a smooth spherical shape of the planet, if they wouldn’t - we would have planets looking like a spiky balls with mountain peaks sticking out in all directions. That’s why when all the high peaks are collapsed to the ground to form a perfect sphere - we are left with abnormally thick and wrong looking atmospheric layer thickness when observed from the outer space. How to fix this?! That’s where “Rayleigh Height Space” slider comes into play, as it controls the thickness of the atmospheric layer seen from outer space.

Rayleigh Height Space (slider) – Controls the thickness of atmospheric layer when you observing the planet from outer space. Like it was said earlier, settings for atmosphere thickness when you’re on the Surface and when you’re in an outer Space can’t be same and normally you want to make it much thinner when it is seen from outer space like it’s in real world. Refer to the following Pic to get better understanding.

Rayleigh Transition (slider) – Ok, so now that we have set the width of the planetary atmosphere for both - when we’re on the Surface and when we’re observing it from outer space, it is time to decide at which distance to switch between two, right? So that’s exactly what this slider does – sets the exact value at which distance that transition must happen. You can play around with this value to find the best setting, just remember that the main goal is to have this transition as smooth as possible, fortunately it’s super easy to achieve. Just make sure that while you’re on the ground and standing on a highest point you still see some atmosphere color (like Blue color in earthlike planets) ,and just about when you start to see the whole planet on your way to the outer space, switch it to the thinner (Rayleigh Height Space) version.

Mie Height (slider) – Controls the size of the outer glow effect of the Sun. Like it was said earlier, when you’re setting your color of the Glow effect via “Mie Scattering RGB” sliders, this particular setting (Mie Height) must be set to a fairly high value otherwise you won’t see it as there won’t be any glow. Look, you can’t change the color of a non-existing thing, soldier. Dismissed!

Sun size (slider) – Controls the size of the Sun.. What else did you expect from it?!

Sea Floor modifier (slider) – Defines the lowest (starting) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer starts. It depends on your planet’s relief, your lowest and highest peaks. Adjust individually for each planet. You’ll “feel” the right value immediately.

Atmosphere Top Modifier (slider) – Defines the highest (ending) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer stops. It depends on your planet’s relief. Adjust individually for each planet. You’ll “feel” the right value immediately. But normally you want this value to be set pretty high.

Intensity (slider) – Actually it should be called “Fog Intensity” as it’s exactly what it’s responsible for but I hope it will be changed by some coder guys eventually J. Controls the amount or intensity of the fog while you’re on or near the planet’s surface (doesn’t do anything when you’re in outer space).

Fog Intensity (slider) – And this, should be actually called “Fog Distance”. It controls the distance fog actually covers. The higher this value – more objects in front of view are covered with fog. (doesn’t do anything when you’re in outer space).

Restore (Button) – Ok, just in case you screw everything up, you always have a chance to revert all the changes you’ve made by clicking this Restore button, soldier! Very convenient isn’t it?!

==Atmosphere 2/2==
Ok, now that we got acquainted with all Atmosphere settings and know how they work, it is time for us to actually change a few settings to alter the look of our Atmosphere! Now the fun part begins. Let’s say that we want to change the color of Earthlike planet’s atmosphere from its natural Blue color to the Green one, so it looks more “alienish”. Please note, that all atmosphere settings are stored in “PlanetGeneratorDefinitions.sbc” file and they are NOT replaced even when you change these values in game and make a save. If you want to change those values you have to change them directly in the code of the “PlanetGeneratorDefinitions.sbc” file only! The system reads those atmosphere values from this file every time you’re loading your worlds.

But how for God’s sake would you know which values are correct and really desirable to put them in the code? This is really simple. You just adjust your atmosphere settings to your liking right in the game, and when you’re done and happy with it, you just copy those values into the code (you can screen grab the in-game view with Atmosphere Settings window or just write them down manually, not a big deal) But to paste those values in the code, you have to know WHERE to paste it, right? You don’t just randomly paste numbers into the code, do you? You may hurt yourself!

So please open “PlanetGeneratorDefinitions.sbc” file in any decent text editor and find the following line:
<pre>
<SubtypeId>EarthLike</SubtypeId>
</pre>
It’s a name or identifier of a planet, and since it’s named Earthlike, we know for sure that below are the definitions related to Earthlike planet. Cool! Now just scroll down to the part where you will see a commented (inactive) line of code which goes like:



Or alternatively, just Ctrl+F to find the following line. You must see something similar to this:

[[File:Atmosphere definition.jpg|512px]]

So here as you can see everything is pretty self-explanatory. Except a few lines that are just named differently in the code. If you want your atmosphere to “remember” the settings you have made you have to enter those values here to the corresponding lines. The following schematic pic shows dependencies between the code lines and the slider names in Atmosphere Settings window quite clearly:
(Click to enlarge)

[[File:In-game Atmosphere Debug Input.jpg|1024px]]

Now let’s just change the blue color of the atmosphere to orange. As you remember, group of three RGB sliders named “Rayleigh Scattering” are responsible for changing the main color of the Atmosphere. So why wait?

[[File:Mars-Like Atmosphere.jpg|1024px]]

Spectacular right? Now, let’s change the sun glow color “Mie Scattering RGB” to an orange tint too. It could stay the same yellow of course but let’s change it so you could have an idea. Remember to press “Alt” on your keyboard while you’re dragging those sliders.

[[File:Another Red Atmosphere.jpg|1024px]]

Ok, now it’s more orange but we have to increase the glow effect a bit to see it more prominently. And as we remember, the glow size control is “Mie Height” slider. Crank it up from 30 to 50.

Good, the glow effect became more prominent. Looking nice isn’t it? Of course, you can continue adjusting it and come up with really crazy results, but if you’re ok with what we already have, then just write down all the values that you currently have in your Atmosphere Settings window on the right or screenshot them and paste into any image editor for your reference. And back in the code editor, just enter those values into corresponding tags in the code and save it:

[[File:CloseUp Atmosphere definition.jpg|512px]]

That’s it! From now on, every time you load up your world with Earthlike planet in it, or spawn Earthlike planet, the atmosphere on it will be exactly the way you adjusted it via Atmosphere Settings! The God himself must have been using something like this we suppose..

[[File:Mars-like Atmosphere Final.jpg|1024px]]

==Clouds==
The first thing that should (probably) come in to your mind when you finally learn how to tweak Atmosphere settings, is probably how to change the look of the Clouds! Because, normally, when you change the color of the atmosphere you would like the clouds color to be relatively close to the Atmosphere color. In our Atmosphere guide (if you read it) we were sharing some knowledge about changing the look of the Atmosphere. We made it orange which is kind of cool all on its own, but what really draws our attention and not in a very good way – is the color of the clouds. As you can see they’re white which is looking wrong isn’t it? In an orange atmosphere environment you would expect orange or yellow clouds right? So that’s what we’ll be doing in a minute – changing the look of our cloud layer and getting to know their under-the-hoods.

Like with Atmosphere settings, the Clouds setting are stored in the same “PlanetGeneratorDefinitions.sbc” file located in KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Data and are individual for each planet. Usually we base our code lines so the Cloud definitions come right after Atmosphere definitions which makes it very convenient to search for. Just open your “PlanetGeneratorDefinitions.sbc” file in any decent advanced text editor and search for this commented (inactive) line of code:



Note: you can download the DDS files from here[mirror.keenswh.com]

[[File:Cloud Layers Definition.jpg|1024px]]

That’s where all the cloud settings for particular planet are stored. The following picture is a brief breakdown of cloud definitions:

Basically, the structure of placing clouds on any planet is as follows:
<pre>
<CloudLayers>
<CloudLayer>
Blah Blah Blah Beautiful Clouds Blah Blah Blah
</CloudLayer>
</CloudLayers>
</pre>
So, as you can see everything is super easy. Simply put, <CloudLayers> tags are meant for global separation of Cloud definitions from other code definitions and are here just to define where the code for the clouds start, while <CloudLayer> tags (again, don’t mistake with CloudLayers) are the actual cloud layers and each pair of these tags (<CloudLayer>…</CloudLayer>) define the look and behavior of each cloud layer. As Captain Obvious states - The more <CloudLayer> pairs you have.. umm - the more cloud layers you will have!

For example. You can have more than one Cloud layer, to simulate even more complex cloud patterns than you initially had in your texture file! And that’s when <InitialRotation> and <RotationAxis> tags come into play. You can assign values to these tags for each Cloud layer individually thus having the cloud spheres to be initially rotated and spinning on different angles creating more interesting and natural cloud patterns. So you basically just stack them this way:
<pre>
<CloudLayers>
<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>
</CloudLayers>
</pre>

That’s it! Now you have three Cloud Layers! And of course you can do it for the Far and the Near cloud layers as well.

Your main cloud color texture must be 4096x2048px RGB file saved in DDS format without alpha as “CloudName_cm.dds file” and it must contain only the color information of your clouds. For Alphamask file please create a separate file of the same 4096x2048px dimensions containing only Alpha mask, make it a greyscale file, save as DDS luminance format and name it “CloudName_Alphamask.dds”. Back in the code, in <texture> tags you just write “Cloudname.dds”, no worries - the engine will identify required “cm” and “alphamask” files itself, just make sure both files are in the correct folder. (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Models\Environment\Sky).

As you know, clouds that are seen from the outer space and the clouds that you see through your window don’t look the same because of the huge differences in scales in both cases. That’s why we have two types of clouds on each planet. First one (commented as “Far layer” in the code) – the clouds that you see from the outer space. They usually look like NASA satellite orbital photo shots.

[[File:Clouds.jpg|1024px]]

And the Second one (commented as “Near layer” in the code) – the clouds that are seen when you’re on the ground or close to it. These should look like a significantly zoomed version of the first ones - more detailed, wispy and more individual. Like the ones you used to see in the sky every day. Refer to the picture.

[[File:LargeClouds.jpg|1024px]]

Now, how to actually separate these two types of cloud layers and to make them come in layers – one after the other. This is very simple too. The maximum overall Altitude (height) of our atmosphere layer is 2. So we have to set up our cloud layers in a tricky way, so that when we’re in outer space - we would see the “Far layer” clouds ONLY, and as we’re getting lower (approaching the ground), on a particular altitude (height) smoothly switch to the “Near layer” clouds and have the “Far layer” clouds hidden. Sounds crazy but it will become clear if you look at the following pic:

[[File:CloudLayerDiagram.jpg|1024px]]

As you can see things are really self-explanatory here too. By setting the Start and End values in <FadeOutRelativeAltitude..> you basically create a vector, the starting point of which is infinity which means anything below this start point will be constant value, thus – making it possible to set the Far layer to be seen from outer space (values greater than 2), and preventing Near cloud layer from being seen - because it is set to fade out on 1.6. And vice versa – when you’re on the ground, you won’t see Far layer clouds layer because it faded out on much higher distance of 1.4. Not so hard right? Of course you can alter and tweak those values to your liking depending on the planets height maps/relief to get the desired transition between Far and Near cloud layers.

So now that we’re empowered with this knowledge, the only thing we’re left to do is to actually change the color of the clouds from white to yellow color so our clouds look more natural in an orange Atmosphere environment. As we remember, our clouds are consisting of two texture files – a file containing color information (usually just a plain color) and a file with an alpha mask only. We already know that the “Far layer” clouds (the ones seen from space) use “EarthFarClouds_cm.dds” texture file and the “Near layer” clouds use “Landsky_texture_cm.dds”. How we know that? It’s written in <texture> </texture> definitions, remember?

[[File:CloudTextureRoute.jpg|512px]]

Great! So now just open “EarthFarClouds_cm.dds” and the “Landsky_texture_cm.dds” and fill both files with plain yellow color and save them!

[[File:YellowCloud Texture.jpg|1024px]]

Start the game and spawn an Earthlike planet and voila! You got perfect yellow clouds!

[[File:Scenery With Yellow Clouds.jpg|1024px]]

==Planet ambient sounds modding - day/night biome sounds==

Sound rules are in the Content\Data\PlanetGeneratorDefinitions.sbc file. Here you can set different sounds based on player’s location or daytime on the planet.
<pre>
<SoundRule>
<Height Min="0" Max="0.5"/>
<Latitude Min="55" Max="80"/>
<SunAngleFromZenith Min="0" Max="180"/>
<EnvironmentSound>AmbIcelandDay</EnvironmentSound>
</SoundRule>
</pre>
Height stands for where you want the sound to play at the height of the heightmap (0-7200m). It is always +12% of the planet's diameter. 0 is from the the lowest start of the surface to 1.0 which is 100% of the surface (maximum height).
Latitude means angle from the equator. Therefore 0 to 20 will mean that this sound will mostly play in the desert area, 20-50 is mostly the green forest area, and so on.
SunAngleFromZenith NEEDS MORE INFO!!!
EnvironmentSound this is the name of the sound you want to use.

You can find all available sounds in Audio.sbc (location shown below) Here you will also put your own ambient sound with your own custom name.

How to implement custom ambient sound

All Ambient sounds are stored here:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Audio\ARC\AMB\

If you want your own sounds, they should be a loop sound, and on average should not be bigger than +-5 MB.
The supported format is: .xwm but .wav can also work, even though its file size is usually a lot bigger (not recommended).

Once your audio is done, implement it here in this file:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\Audio.sbc
<pre>
<Sound>
<Id>
<TypeId>MyObjectBuilder_AudioDefinition</TypeId>
<SubtypeId>AmbAlienForestDay</SubtypeId>
</Id>
<Category>AMB</Category>
<MaxDistance>100</MaxDistance>
<Volume>0.2</Volume>
<Loopable>true</Loopable>
<Waves>
<Wave Type="D2">
<Loop>ARC\AMB\AmbAlienForestDayLoop2d.xwm</Loop>
</Wave>
</Waves>
</Sound>
</pre>
Here edit only what is highlighted, otherwise I cannot guarantee that it will work properly!
<SubtypeId> This is how you will name your AMB sound, keeping in mind upper and lower case letters. Do not use _ or other special characters!
<Volume> This is self explanatory I hope.
<Loop> Here you just need to lead the definition to your file. ARC/AMB/ is the default location, so do not change that.
But if you want, you can make another folder in AMB for your custom ambient sounds for better organisation.

==In-game map modding==
Maps in Medieval Engineers are generated based on terrain and buildings on it. This means that they will work for any modded planet in their default form. That being said, the way map is generated is also fully moddable.

We definitions for map are located in Content\Data\Screens\MapDefinition.sbc. To mod maps you will have to alter/add definitions in this file, all vanilla textures for maps can be found in Content\Textures\GUI\Map. Feel free to use/alter any of them for creation of mods for Medieval Engineers.
Map content modding (Friend/foe display, tax notifications,...
In Medieval Engineers there are 2 view modes of map. Kingdom view which is showing entire kingdom and region view which is zoomed part of a kingdom map. Region is 1kmx1km large on 10 km diameter planet. Both views display different elements.
What is shown in these views depends on what layers it contains
<pre>
<Definition xsi:type="MyObjectBuilder_PlanetMapDefinition">
<Id Type="MyObjectBuilder_PlanetMapDefinition" Subtype="Main"/>
<BackgroundGenerator Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
<RegionView>
<Layers>...</Layers>
</RegionView>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</Definition>
</pre>
BackgroundGenerator refers to a definition of background texture that serves as a background on top of which all the map elements are placed.
<pre>
<RegionView>
<Layers>...</Layers>
</RegionView>
</pre>
The three dots in middle represent layers of elements that show in region view. List and description of all layers is in next section of this document.
<pre>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</pre>
The three dots in middle represent layers of elements that show in kingdom view. List and description of all layers is in next section of this document.
(I did not Kingdom view in its expanded form because it would take up too much space.)

===Layers description===
<pre><Layer xsi:type="MyObjectBuilder_MapBackgroundLayer" /></pre>
This layer draws the background. As generated based on chosen background definition.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaDevelopmentLayer">
<Threshold BlockCount="10" Sprite="Textures\GUI\Map\SmallGrid.png"/>
<Threshold BlockCount="30" Sprite="Textures\GUI\Map\MediumGrid.png"/>
<Threshold BlockCount="60" Sprite="Textures\GUI\Map\LargeGrid.png"/>
</Layer>
</pre>
This layer displays icons based on amount of blocks there is in an area. You can set the block thresholds, or mod the textures. It is also possible to add more thresholds. 80x80 px, png.

[[File:Smallest Settlement.png|150px|frameless]]
[[File:Medium Settlement.png|150px|frameless]]
[[File:LargestSettlement.png|150px|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_RegionFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for region, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaOwnershipLayer">
<AlliedBgColor Hex="#806464FF" />
<PlayerBgColor Hex="#8064FF64" />
<EnemyBgColor Hex="#80DC6415" />
</Layer>
</pre>
This layer defines color overlay over map areas based on ownership. You can mod which color is used for allies, your own areas or for enemies
<pre>
<Layer xsi:type="MyObjectBuilder_AreaUpkeepLayer">
<TaxIcon>Textures\GUI\Map\TaxIcon.png</TaxIcon>
</Layer>
</pre>
This layer displays tax icon on areas that belong to you and require tax payment soon. Texture is 80x80 pixels, png.
[[File:Taxes.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapPositionLayer">
<LocalPlayerImage>Textures\GUI\Map\PlayerPosition.png</LocalPlayerImage>
<OtherPlayersImage>Textures\GUI\Map\AllyPosition.png</OtherPlayersImage>
</Layer>
</pre>
PlanetMapPositionLayer displays player icon above area where they are.
[[File:Ally.png|frameless]]
[[File:Player.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_ActionTrackingLayer">
<ActionImage>Textures\GUI\Map\Action.png</ActionImage>
</Layer>
</pre>
Shows icon over an area on map with fighting / destruction.
[[File:AttackedArea.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_CurrentMapSelectionLayer">
<SelectionImage>Textures\GUI\Map\MapSelection.dds</SelectionImage>
</Layer>
</pre>
This is highlight of a region, that player selected with his mouse.
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapGridLayer">
<GridColor R="0" G="0" B="0" A="228"/>
</Layer>
</pre>
This layer sets which color is the grid drawn.
<pre>
<Layer xsi:type="MyObjectBuilder_KingdomFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for kingdom, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_RegionOwnershipLayer">
<PlayerIcon>Textures\GUI\Map\PlayerLandIcon.png</PlayerIcon>
<AllyIcon>Textures\GUI\Map\AllyLandIcon.png</AllyIcon>
<EnemyIcon>Textures\GUI\Map\EnemyLandIcon.png</EnemyIcon>
<PlayerAllyIcon>Textures\GUI\Map\PlayerAllyLandIcon.png</PlayerAllyIcon>
<PlayerEnemyIcon>Textures\GUI\Map\PlayerEnemyLandIcon.png</PlayerEnemyIcon>
<AllyEnemyIcon>Textures\GUI\Map\AllyEnemyLandIcon.png</AllyEnemyIcon>
<PlayerAllyEnemyIcon>Textures\GUI\Map\PlayerAllyEnemyLandIcon.png</PlayerAllyEnemyIcon>
</Layer>
</pre>
RegionOwnershipLayer generates textures used to express ownership on regional map.

===Background generator (trees, mountains, roads,...)===
Map background is where all the trees, mountains, hills are drawn. It is also capable of coloring map based on what is in planet’s material map (this is how we make roads for example).
All settings for map background are in MedievalMapBackgroundDefinition. The definition also in Content\Data\Screens\MapDefinition.sbc. I will go through various parts of the definition.

<pre><Id Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
Type of the definition says that this map background definition. Subtype is name of this specific background definition. If create your own background with unique subtype
Make sure you create your own background with unique subtype

<DrawHeightmap>false</DrawHeightmap>
When set on “true” planet’s heightmap is drawn under the map.
<Resolution>4096</Resolution><
Sets resolution of the generated in-game map.

<Features>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</Features>

<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</Definition>
</pre>
===Map Coloring===
You can use colors in material or biome map of a planet to appear on the game map. (roads for example). You define map coloring in a node called ”Features”. The coloring uses colors from planet material texture. You can learn more about material texture in biomes modding and surface material modding.
<pre>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
</pre>
This specific feature is used for painting roads on map with dark brown color. In Color you define which color will be the in-game map colored. Material=”67” decides where will be the color applied and refers to a red channel value on planet material texture.
<pre>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</pre>
This specific feature is used for painting forests on map with opaque brown. In Color you define which color will be the in-game map colored. Biome=”60” decides where will be the color applied and refers to a green channel value on planet material texture.

===Sprites===
Medieval Engineers map can also place sprites on map based on terrain shape. All the sprites are on one texture
<pre>
<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</pre>

[[File:AtlasCoordinateUsage.png|512px]]

Note: Illustrates how sprite is defined on our spritesheet. Example sprite:
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />

==Voxel color overlay modding==
We have a cool tech that enables us to color-shift color of almost any item in the game. Currently we are using it for trees(adds small color variations to the same model of a tree) and voxels above iron deposits.
==Fast travel settings modding==
In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around.
In this section of the guide we will show you how to mod which sectors are blocked.
There are 2 ways you can go about it:
===Generate automatically based on terrain shape===
Game is capable of creating fast travel map on its own based on height and terrain steepness. It is possible to mod thresholds for both height and steepness.
You will find the thresholds in Content\Data\Game\FastTravel.sbc. In a MyObjectBuilder_TerrainReachabilityProviderDefinition.
<RiseThreshold> - Sets min. terrain height change which will cause that area is unreachable.
<HeightThreshold> - Sets height of terrain after which area is unreachable, if it goes over this value. Range is 0 - 1.

If there are texture overrides in the definition, you have to erase them in order for the parameters to take effect. Texture overrides are nodes that are called in this fashion: <OverrideNAMEOFFACE>. You will learn more about these overrides in the next part of Fast travel modding.

===Creating fast travel texture override===
If you want to have full control over which areas are reachable and which are not regardless of terrain, you can create a simple texture on which you mark unreachable areas.

The texture is 80x80 pixels, RGB 8 bit. Black pixels forbid entrance.

When you have the texture, select route to it in the definition:
<pre><OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward></pre>
Reachability definition example:
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>
<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>
<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
</Definition>
</pre>
This definition would generate fast travel reachability everywhere, except for front planet face (Fareon kingdom) where fast travel reachability is created based on your texture.

===Development reachability===
Claimable area size, border highlight, contested timer modding
Size of the area and highlight properties are moddable as well.

===Area borders highlight===
<NeutralColor R="225" G="32" B="0" A="64" /> - Set color of an unowned territory
<SelfColor R="0" G="255" B="0" A="64" /> - Sets color of area border owned by you
<AliedColor R="65" G="105" B="225" A="64" /> - Sets color of area border that belongs to allies
<EnemyColor R="225" G="32" B="0" A="64" /> - Sets color of area border that is hostile
<WallSettings Depth="15" Rise="3" SegmentCount"71" End="115" /> - Changes shape of the border. Depth sets how deep is border submerged. Rise sets how tall is the border.
<Fade Start="71" End="115" /> - This sets at which point the border starts to fade.
Contested timer
When players claim area with claimblock, area goes to a “contested” phase for some amount of time, in this phase other players can still attempt to build their own claim block and claim the area. This time is moddable.
Content\Data\Game\SessionComponents.sbc contains definition called MyObjectBuilder_AreaOwnershipSystemDefinition. To mod this value, add this definition to your mod with changed value of <ContestedTimeInMinutes> parameter.

==Permissions modding - what is/isn’t allowed to do in claimed areas==
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.
Description of available actions to set permissions for:
Name=”Build” -> block placement permissions
Name=”Repair” -> Repairing/building already placed blocks
Name=”Deconstruct” -> Deconstructing
Name=”QuickDeconstruct” -> Faster deconstruction
Name=”VoxelEdit” -> Mining or shoveling
Name=”Destroy” -> Damage with hand weapons
Name=”Interaction” -> Chest opening, door opening
Name=”ClaimBlockInteraction” -> ClaimblockGui

===List of available Groupnames:===
Groupname: “Owner” -> Player who owns area
Groupname: “Allies” -> Mostly faction members of owner of the area
Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
Groupname: “Enemies” -> Players in factions that are hostile to your faction

==Compass modding==
It is possible to mod visual look of an in-game compass. All definitions of compass are stored in Content\Data\GUI\CompassDefinition.sbc. Our textures for compass are in Content\Textures\GUI\Compass folder if you want to check out how they look or use them in your mod.
===Creating compass texture atlas and setting coordinates for its elements===
Just like with map sprites, we save main compass elements on a single texture, then define parts of it using pixel coordinates. First setup origin point, then add width and height of the rectangle
Example texture coordinates for top part of the compass:
[[File:CompassTextureCoordinates.png|1024px]]
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>

===Explanation of compass definition line by line===
<pre><Texture>Textures/GUI/Compass/compass.png</Texture> </pre>
Route to a texture atlas.
<pre><KingdomIcon>Textures/GUI/Compass/Icon-Kingdom.png</KingdomIcon> </pre>
Route to icon symbolizing a kingdom.
<pre><Padding>7</Padding></pre>
Padding is added vertically between the top and bottom textures and the edges of the contents of the compass.
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>
Rectangle in the texture that contains the top part.
<pre><BottomCrop X="0" Y="0" Width="0" Height="0"/></pre>
Rectangle in the texture that contains the bottom part.
<pre><BackgroundCrop X="0" Y="64" Width="512" Height="64"/></pre>
Rectangle in the texture that contains the background.
<pre><ArrowCrop X="0" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the little marker used for elements that are drawn and have no icon.
<pre><MarkerCrop X="32" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the interval bars drawn every few degrees.
<pre><ShadowCrop X="64" Y="128" Width="80" Height="32" Left="8" Right="8"/></pre>
<pre><ShadowPadding Left="12" Top="8" Right="12" Bottom="8"/></pre>
Rectangle in the texture that contains the text shadows. Shadow is 3-Sliced, meaning the texture is split in three parts: [left|middle|right]
The sizes of left and right define the cropping lines that split the texture into three. The Sides are then always kep proportional as the texture is scaled.
<pre><VisibleRange>200</VisibleRange></pre>
Visible range in degrees.
<pre><Width>700</Width></pre>
Width in reference resolution pixels.
<pre><FontSize>1.1</FontSize></pre>
Scale of the font based on default.
<pre><VerticalOffset>0.065</VerticalOffset></pre>
Vertical offset from the top of the screen. 0 = top of the screen, 1 is the bottom. Compass is centered around this position.
<pre>
<TagStyles>
<TagStyle Tag="ClaimArea" Style="Bellow" MaxCharacters="15" Ellipsis="true"/>
<TagStyle Tag="Cardinal" Style="Above" MaxCharacters="1"/>
<TagStyle Tag="Kingdom" Style="Bellow"/>
</TagStyles>
</pre>
This section adds tags that are visible on compass and in which style. Currently we have 3 types of tags. Claim area - shows your claimed area on the compass, Kingdom tag shows kingdoms and Cardinal tag shows cardinal points (North, South,...). Each tag’s visual appearance is defined in tag/waypoint definition. Styles defines where should the text appear. Available styles: Center, IconOnly, NotShown, Bellow, Above.

===Explanation of Waypoint/Tag definition===
<pre>
<Definition xsi:type="MyObjectBuilder_WaypointDefinition">
<Id Type="MyObjectBuilder_WaypointDefinition" Subtype="Kingdom"/>
<IconPath>Textures/GUI/Compass/IconKeep.png</IconPath>
<Color R="255" G="255" B="255" A="255"/>
</Definition>
</pre>
IconPath contains path to the texture of kingdom icon. Color defines color of the text that is shown with the icon. (Example: Fareon, [[File:Kingdom Icon.png|thumb]])
===Compass texture vs in-game look comparison===
Texture:

[[File:Compas Texture with Zones.png|1024px]]

In-game look:

[[File:In-gameCompassZones.png|1024px]]
<NoWiki>*</NoWiki>note that background crop and bottom crop are not used in vanilla (empty opaque texture)

==Indestructible grids==
There is a way how to make some buildings in your save indestructible. We are using this feature for starting area buildings. Some you guys might make a good use of this feature in your pre-made worlds.

Currently, only way how to do this is to make edits to an existing save file. So you can only use it for world modding.

===Making indestructible cubegrids in existing safe===
Goal is to open world’s safe file in a text editor, find your cubegrid in it and add this tag to it: <DestructibleBlocks>true</DestructibleBlocks>.

#Find your save file. By default save files are stored in C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Saves
#Open folder with your save and find file called SANDBOX_0_0_0_.sbs. This file can be opened with any text editor you prefer.
#In the SANDBOX_0_0_0_.sbs search for the cubegrid name of the building you want to make indestructible. (use find/search function in your text editor, or you will grow old before you find it)
#Tip: To find out name of a cubegrid, create blueprint of the building. The name that the building saves as in your blueprint screen is the name of the cubegrid.
#You should find the name in tags called: <DisplayName>YOURCUBEGRIDNAME</DisplayName>
#Under the name, add following tag with setting set to false: <DestructibleBlocks>false</DestructibleBlocks>
#If you followed instruction, the indestructibility tag is now in node called <MyObjectBuilder_EntityBase> and not in any of its child nodes.
#Save the edited file.
#Load the save and test destructibility
#It worked! Enjoy
#It is still destructible. Go to point 1.

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding - Full Guide

2017-03-13T16:33:12Z

Lukas: /* Assign environment to a planet */

==Introduction==
Hello fellow Medieval Engineers!
I would like to present you with a guide that will help you understand how we created planets at Keen Software House and how to mod your own into the game.
Feel free to use/alter company owned files for your Medieval Engineers mods.

So let's get to modding!

==Recommended Software==
# Microsoft Visual Studio - or Notepad++ (Link[notepad-plus-plus.org]) - for opening files with .sbc extension where we have definitions for every feature in the game.
# Adobe Photoshop - for editing material and heightmap textures
# World Machine Professional - for heightmap easier creation (much more realistic looking terrain, without manual work)

(Basic Edition is also available, but the max resolution output is limited to 512x512 pixels)
http://www.world-machine.com

===Advice===
We would like to mention one thing before you get into modding planets:
For your own sake we recommend you to load either PlanetTemplate or EarthLikeModExample and test/edit all the things there, so you get to know the system and how everything works.

After that you can create your own from scratch. This is entirely up to you.

==General modding principles - how to make any mod==
I will explain again basic principles of how mods are applied.

All of our vanilla source files are all saved in a folder called content in your *game folder. If no mods are assigned to a world that you are loading, game uses only files from this content folder but if there are mods, game loads also files from mod adding more content or potentially rewriting vanilla content based on content of the mod’s folder. Mod is nothing else but a folder with another files.
Mod files are stored in mods folder on your computer , and if you are using them for the first time, they are downloaded from workshop first time you try to load/connect to a world with those mods.
Mod folder: C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Mods
===Opening mod and examining mods content===
When you open Mods folder, you will see mods as files with .sbm extension. But they are really just folders and to examine them, all you have to do is rewrite the extension from .sbm to .rar and then you can open them with rar and examine content.
Mods are not listed with their names, but with their steam id number. To find specific mod, you have to go to the mods workshop page

Examining other mods similar to your idea is a fast way to learn.
Example:

<NoWiki>*</NoWiki>By default this is SteamLibrary\steamapps\common\MedievalEngineers\Content. You can also get there if you go to steam library(same place where you start the game), right-click Medieval Engineers, select properties, local files and finally click on “browse local files”.
==Materials modding==
In case you are thinking about making your own trees and voxel materials, we have some good news for you!

There are two separate guides that you can follow to make your own stuff.

General modding guide - get started

===Voxel material modding===
http://steamcommunity.com/sharedfiles/filedetails/?id=568406623

==Planet Size==
Planet size is defined in a scenarios.sbc. Every time you click on create new world in the game it uses scenario definition to create a new safe file. Although this scenario definition is not moddable, you can still use it to create a world and share the world itself on the workshop.

First go to where you have Medieval Engineers source files and find Data folder (SteamLibrary\steamapps\common\MedievalEngineers\Content\Data\Scenarios.sbx)

==All planet related files overview and where to find them==
To summarize how planet modding in ME works, we can say this:
We use 2 types of textures and then we define how the game should interpret those textures in definitions. One texture is heightmap that is used just for generating terrain shape, another one is used to place everything else on the planet (ores, trees and plants, bots).
[[File:Diagram.png|1024px|center]]

==Material Texture modding==
Material texture is used to store information about location of various planet surface features. These features are surface materials, biomes (trees, bots, plants,..etc) and where you can find ore. Each one of these uses one color channel. Surface materials use red channel. Biomes use green. Ores are in blue channel.
We use 6 material textures (2048x2048) for each planet. You can find all our material textures here: Content\Data\PlanetDataFiles.
Each planet has its own folder. The folder has to have the same name as the planet.

[[File:MaterialMapBreakdown.jpg|512px]]

Illustration of how are the material textures connected to each other:

[[File:Planet Material Texture Order.jpg|512px]]

====The process of material texture creation is really simple. You have two options:====
=====Copy an existing map to your folder and overwrite the green channel and edit them to your liking=====
This is highly recommended to avoid errors!
=====Create a new: step by step in Photoshop=====
#Set both width and height to 2048 pixels
#(for smaller planets this can also be 1024 or less, but all textures need to have the same resolution! Even the heightmap)
#Set resolution - Pixels/Inch to 72.
#Set colour mode to RGB Colour - 8bit
#Now start painting with the pencil tool on each RGB Channel separately.
#Never on all three at once! (It will F. up everything - trust me).

===Surface voxel material definitions modding - grass, sand, snow===

[[File:RedChannel.jpg|22px|frameless]]

Surface “voxel materials” refers to what you know as grass, soil, stone.. We use red channel of the material texture to set where all the terrain appears. Then you need to write definitions in the Content\Data\PlanetGenerator.sbc to tell game which voxel should appear at specific red channel value.
Example of the definition of road:
<pre>
<ComplexMaterials>
<MaterialGroup Name="Road" Value="67">
<Rule>
<Layers>
<Layer Material="Soil" Depth="2"/>
</Layers>
<Slope Min="0" Max="90"/>
</Rule>
</MaterialGroup>
</ComplexMaterials>
</pre>
Example of corresponding material texture with road:

[[File:RoadMaterialTextureExample.png|512px]]

====Complex materials====
Complex materials definition allows to paint the map with a set of “voxel coloring rules”. Meaning that one color value in red channel can color terrain with different voxels based on rules like slope, longitude or latitude and height. (So with our road example)
<pre>
<MaterialGroup Name="Forest_Grass" Value="120">
<Rule>
<Layers>
<Layer Material="Woods_grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="0" Max="25"/>
<Latitude Min="-180" Max="180"/>
<Longitude Min="-180" Max="180"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="25" Max="45"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Rocks_grass" Depth="2"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="45" Max="55"/>
</Rule>
</MaterialGroup>
</pre>
This definition says what voxels should be generated in spots, that are painted with red channel value of 120.
The rules in this definition will lead to following:
Flat lands (up to 20 degrees slope) will have Wood grass 1 m thick, soil will be right under the WoodGrass up to 5 m depth and there will be stone underneath the soil.
In places with medium slope, there is Grass instead of WoodGrass. And in slopes from 45 to 55 there is rocks grass 2 m thick with stone right away under it.
With this technology, we can make the color react on its own to terrain bumps or even position on planet. This saves lots of meticulous painting with heightmap.

<Layer Material="Woods_grass" Depth="1"/>
Material refers to voxelmaterial definition. (You can find it in Content\Data\VoxelMaterials.sbc). Depth means how deep should the material go under ground.
<Slope Min="0" Max="25"/>
Slope of the terrain in degrees.
<Latitude Min="-180" Max="180"/>
Latitude in degrees. 0 degree is an equator.
<Longitude Min="-180" Max="180"/>
Longitude in degrees. 0 is in the middle of front planetary texture. (Fareon Kingdom)

===Biomes definitions modding - trees, plants and bots===
[[File:GreenChannel.jpg|frameless|22px]]

Biomes refers to everything that is spawned on top of the planet. We use green channel of the material texture to set where all the terrain features appear and definitions in the Content\Data\Environment\ProceduralEnvironments.sbc to tell game which environment item should appear at specific green channel value. Also you need to assign Environment to planet in the Content\Data\PlanetGenerator.sbc in case you are adding a brand new planet.

====First make/modify environment:====
Go to Content\Data\Environment\ProceduralEnvironments.sbc

=====Procedural World Environment definition=====
This definition defines where will the environmental items spawn and with which density. (note: bots are also considered environmental item). Best way to explain how procedural environment is working is to imagine that it puts spots on entire surface of a planet. And when you start defining trees, bots and bushes, the spots get “reserved” by these categories based on how many of those should appear in the world according to your mod.
Spots are always different for each single planet.
In order to mod the procedural environment, mod our “Earth Environment” definition. Or create your own but if you do, don’t forget to also mod PlanetGeneratorDefinition, so that planet has your new procedura environment assigned to it.

=====Definition elements explained point by point:=====
<pre>
<Definition xsi:type="MyObjectBuilder_ProceduralWorldEnvironment">
<Id>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>Earth Environment</SubtypeId>
</Id>
</pre>
This part of definition is called ID. It says what type of definition this is <TypeID> and unique name of that definition <SubtypeID>.

<pre>
<MaxSyncLod>1</MaxSyncLod>
</pre>
This line defines how far away from player are the environmental items updating. This is important feature for optimization.

<pre>
<SectorSize>40</SectorSize>
</pre>
This is size of the environmental sector. It is a different sector than the claimable areas by players. It sets size of one environmental sector.

<pre>
<ItemsPerSqMeter>0.17</ItemsPerSqMeter>
</pre>
The line sets overall maximum density of all environmental items. To return to analogy i used in the introduction, this number increases the amount of spots on the planet that are reserved for all environmental items.

<pre>
<ScanningMethod>Random</ScanningMethod>
</pre>

<pre>
<ItemTypes Type="MyObjectBuilder_EnvironmentItemTypesDefinition" Subtype="Default"/>
</pre>
This sets which types of environmental items are used in this procedural environment definition. This guide explains what are Environmental item types in the very next section.

<ItemGroup Density=".017" Name="Bots" LodStart="1" LodEnd="1">
<Mapping>
<Material>Woods</Material>
<Item Type="Bot" Subtype="Deer"/>
</Mapping>
<Mapping>
<Biome>60</Biome>
<Height Min="0" Max"1"/>
<Latitude Min="-180" Max"180"/>
<Longitude Min="-180" Max"180"/>
<Slope Min="0" Max"1"/>
<Item Type="Bot" Subtype="Deer" Density="0.9"/>
<Item Type="Bot" Subtype="Barbarian" Density="0.1"/>
</Mapping>
</ItemGroup>
Item group is used to organize and better manage mappings. Mappings are definitions that actually add the environment items in the world. It is important to set Density correctly. Density (Density=".017") sets how many of the procedurally generated spots on the planet will be assigned to environmental items from this group. The name (Name="Bots") is only for naming purposes within definition and has no impact on the game. LodStart="1" and LodEnd="1" control how far from the player will the items appear.
<Biome>60</Biome> This section means that Items within this mapping will only appear on spaces that are painted with green channel value 60 on the material map.
<Material>Woods</Material> This means that the environmental items will only appear in the woods.
<Height Min="0" Max"1"/> Sets in which altitude should these environmental items appear. If this parameter is missing, items spawn in full range (Min="0" Max"1")
<Latitude Min="-180" Max"180"/> Sets at which latitude do the environment items spawn. If this parameter is missing, items spawn in full range (Min="-180" Max"180")
<Longitude Min="-180" Max"180"/> Sets at which longitude the environment items spawn. If this parameter is missing, items spawn in full range (Min="-180" Max"180")
<Slope Min="0" Max"90"/> Sets at which slopes the environment items spawn. If this parameter is missing, items spawn in full range (Min="0" Max"90")

<ItemGroup Density=".085" Name="Trees" LodStart="-1" LodEnd="1">...</ItemGroup>
<ItemGroup Density=".36" Name="Small Items" LodStart="0" LodEnd="0">...</ItemGroup>
There are 2 more item Groups. I will not go into details, since it is not
</Definition>

=====Environment items=====
We learned how to assign environments to planets and how to mod environments themselves by changing densities and environment items. But we still don't know how to make the environment items themselves. Guides for those can be found on following links.

If you want to mod trees:

If you want to mod bushes and plants:

If you want to mod bots:

=====EnvironmentItemTypesDefinition=====
Here you define various types of items. Currently we have these types: Tree, Gatherable, Farmable, Static and Bot. Before you add any item, you must make sure it fits within these types of environment items or you created a new type for them.
<Definition xsi:type="MyObjectBuilder_EnvironmentItemTypesDefinition">
<Id Type="MyObjectBuilder_EnvironmentItemTypesDefinition" Subtype="Default"/>
<Item Name="Tree">...</Item>
<Item Name="Gatherable">...</Item>
<Item Name="Farmable">... </Item>
<Item Name="Static">...</Item>
<Item Name="Bot">...</Item>
</Definition>

EnvironmentItemTypes
<Item Name="Tree">
<ProxyActivationLod>0</ProxyActivationLod>
<Provider Type="MyObjectBuilder_ProceduralEnvironmentModuleDefinition" Subtype="Growable"/>
<Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Gatherable" />
<Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Cuttable" />
</Item>
Available proxy and providers:
Proxy Subtype="Gatherable"
This line adds ability to all environmental items of this type to use action “Gatherable”. Keep in mind that the tree itself has to be setup properly in order for this to work.
Proxy Subtype="Cuttable" />
This line adds ability to all environmental items of this type to use action “Cuttable”. Keep in mind that the tree itself has to be setup properly in order for this to work.
<ProxyActivationLod>0</ProxyActivationLod>
This line says from which lod is the game logic attached to the environmental item. (when set on 0 only trees very close to you become “gatherable” and “cuttable”). This way we don’t use game logic on environmental items that couldn’t be used anyway and game is better optimized thanks to that.
Provider Subtype="Growable”
This line adds ability to all environmental items of this type to grow. Keep in mind that the tree itself has to be setup properly in order for this to work.
Provider Subtype="Farmable”
This line adds ability to all environmental items of this type to be farmable. Keep in mind that the tree itself has to be setup properly in order for this to work.
Provider Subtype="Static”
This line adds basically adds items that do nothing. They are just visual props. Like some of our fern bushes.
Provider Subtype="BotSpawner”
It is important that all environmental item types that will contain some bots have botspawner

====Assign environment to a planet====
Last thing is to assign your brand new procedural environment to a planet where it is supposed to appear. Go to Content\Data\PlanetGenerator.sbc and find definition of the planet you want your environment to be on. Then assign the environment to the planet by adding following line to the planet definition with name of your environment:
<pre>
<Environment>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>NAMEOFYOURENVIRONMENTDEFINITION</SubtypeId>
</Environment>
</pre>
SutypeId refers to the name of the environment from:
Content\Data\Environment\ProceduralEnvironments.sbc

===Ores definitions modding===
[[File:BlueChannel.jpg|frameless|22px]]

Ores are placed using blue channel of the material texture to set where should ore deposits appear. When your ore deposits are painted on the material map, you need to define what ores will be there. Go to Content\Data\Environment\ProceduralEnvironments.sbc to tell game which ore should appear at specific blue channel value.

<pre>
<OreMappings>
<Ore Value="130" Type="IronOre_RichYield" Start="3" Depth="7" TargetColor="#b7340a" ColorInfluence="15 "/>
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
<Ore Value="110" Type="IronOre_PoorYield" Start="2" Depth="5" TargetColor="#a76a41" ColorInfluence="15" />
</OreMappings>
</pre>
The section you need to use is Ore Mappings.
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
Value refers to blue channel value on material texture.
Type refers to name of a voxel material from Content\Data\VoxelMaterials.sbc.
Start is depth at which the ore deposit starts. Depth is how deep under ground it goes.
TargetColor is color that will be used to color surface above the ore.
ColorInfluence sets strenght of coloring.

==Working with RGB==
Ok, Steam won't let me share that link to a small RGB Photoshop tutorial with you, so just go to photoshopessentials.com and search for RGB and it's the first link.

This is a simple tutorial to explain you what we mean when we say Grayscale ID, which can also be called the RGB values
(each channel only has one number per shade of that color ranging from 0 to 255).

Here I have loaded a Biome map texture front_mat texture which is used on the Vanilla EarthLike planet.

[[File:RGBChannels.jpg|frameless]]These are the RGB channels as you can see them in Photoshop.

NOTE: Edit each RGB channel separately!

Always use the pencil tool to paint pixels.
The brush tool has a falloff that has different values and you will not have control over those!
[[File:Color Picker.jpg|thumb]]

You can see if the numbers are correct on the top right of the screen if you have your workspace set to Essentials.

Here you will enter the values you want to paint.
Make sure you check them before saving, sometimes Photoshop can move the number +-1 (personal experience).

It doesn't matter if the numbers match, just as long as you have the correct value (ID) in the correct channel!

==Height-maps modding - terrain shape, roads==
As mentioned in 2. Required software, we used the program World Machine to create our heightmaps and then we did some minor tweaks by hand (like putting in lakes and desert areas)

First, to explain how our planet heightmaps work:
We have 6 textures that connect together (image below). Our standard resolution for a big 120km planet is 2048x2048. But you can use a lower one if you want to.

To create your own heightmap, the best action would be to find a heightmap here:
C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\PlanetDataFiles

Then you can open the texture and place yours/paint yours on a new layer, flatten the image and save it as a .PNG

There are other options for you also!
You can visit[terrain.party] this site and download a heightmap from a real place on Earth. You can even set the size of the map (maximum is 60 km). And then you can edit it further in Photoshop.
You can try painting it yourself in Photoshop (or any other similar software, like Gimp).
You can also just try Googling for heightmaps and try which one suits you the best (keep in mind the resolution must be 512,1024, 2048!)
However you get your heightmap, always keep in mind how each texture of the heightmap is connected, so the seams need to fit together. Bad texture connection is very visible in the game.
Here is an image of how the textures are connected:

[[File:Planet Material Texture Order.jpg|512px]]

===Roads===
We created roads using World Machine tools. You can find guide how to do that in between World Machine tutorials.

==Atmosphere==
[[File:View Image.jpg|1024px]]

Here, you will find everything you ever wanted to know about Atmosphere Settings in Space Engineers but were afraid to ask, my dear friend. So without any further ado. Let’s start with the “Atmosphere” settings window which you access in-game by hitting F12 -> Render Button -> Atmosphere checkbox. The new Atmosphere settings window opens immediately on the right side of the screen, showing a bunch of tricky sliders.

[[File:Cloud Layers Definition.jpg|1024px]]

If your pants are still dry, and if by any chance you’re still reading this, let us assure you that everything is pretty simple and not so scary as it may seem when you first open it. So let’s start with the brief and really quick explanation of what every slider or group of sliders are meant for. Lastly, remember that to alter any setting in this Window you have to hold “Alt” on your keyboard.

Enable Atmosphere (checkbox) – Well, as Captain Obvious immediately states to us – it just enables or disables Atmosphere on a planet and nothing more.

Time of Day (slider) – Controls rotation of the Sun around a Planet. You’re given the Power to decide which time of day it is now. Cool isn’t it?

Pick Planet (Button) – In situations when you have more than one planet in your world, you may want to alter the settings of each planet’s atmosphere individually. So this button enables you to immediately pick the current atmosphere values of the planet you’re currently on. For example, fly to the Moon, press “Pick planet” button and you will get corresponding atmosphere values of that planet to play with. Fly back to Earth or any alien planet, and do the same to alter atmosphere settings of these planets. Yay!

Rayleigh Scattering R,G and B (sliders) – Group of three sliders which control the main, overall color of the Atmosphere. It’s that atmosphere color which is going to be seen from outer space and on the ground too! If you want to make your atmosphere alien green or purple – these are the correct set of sliders to play with. Each slider controls corresponding R,G or B (0-255) values. Pretty straightforward.

[[File:Atmosphere Settings.jpg|512px]]

Mie Scattering R, G and B (sliders) – Group of three sliders to control the color of the Sun glow. It would be weird to have Green atmosphere and Red sun glow right? You would normally want to set it to yellow or something light green or so. But it’s your choice you can make any color you want. But please note that in order to have noticeable results you have to actually HAVE that glow around your sun. This setting is called “Mie Height” and it has to be set to a fairly high value otherwise it wouldn’t be too prominent. We will talk about this “Mie Height” setting in a minute. No worries.

The following three sliders are complementary and play well together. It means you have to find a good balance setting them which is quite easy:

Rayleigh Height Surface (slider) – Controls the thickness of the atmospheric layer when you’re on or near planet’s Surface. For example. You normally want atmosphere layer to be fairly thick to cover high points of the planet’s surface like mountains and high hills while you’re on the ground because you have actual high picks in your surface geometry which you have to cover. Otherwise you would see black space when you’re on the high mountain. But technically, when you’re leaving the planet’s atmosphere all of these high peaks and mountains are starting to slowly collapse vertically forming a smooth spherical shape of the planet, if they wouldn’t - we would have planets looking like a spiky balls with mountain peaks sticking out in all directions. That’s why when all the high peaks are collapsed to the ground to form a perfect sphere - we are left with abnormally thick and wrong looking atmospheric layer thickness when observed from the outer space. How to fix this?! That’s where “Rayleigh Height Space” slider comes into play, as it controls the thickness of the atmospheric layer seen from outer space.

Rayleigh Height Space (slider) – Controls the thickness of atmospheric layer when you observing the planet from outer space. Like it was said earlier, settings for atmosphere thickness when you’re on the Surface and when you’re in an outer Space can’t be same and normally you want to make it much thinner when it is seen from outer space like it’s in real world. Refer to the following Pic to get better understanding.

Rayleigh Transition (slider) – Ok, so now that we have set the width of the planetary atmosphere for both - when we’re on the Surface and when we’re observing it from outer space, it is time to decide at which distance to switch between two, right? So that’s exactly what this slider does – sets the exact value at which distance that transition must happen. You can play around with this value to find the best setting, just remember that the main goal is to have this transition as smooth as possible, fortunately it’s super easy to achieve. Just make sure that while you’re on the ground and standing on a highest point you still see some atmosphere color (like Blue color in earthlike planets) ,and just about when you start to see the whole planet on your way to the outer space, switch it to the thinner (Rayleigh Height Space) version.

Mie Height (slider) – Controls the size of the outer glow effect of the Sun. Like it was said earlier, when you’re setting your color of the Glow effect via “Mie Scattering RGB” sliders, this particular setting (Mie Height) must be set to a fairly high value otherwise you won’t see it as there won’t be any glow. Look, you can’t change the color of a non-existing thing, soldier. Dismissed!

Sun size (slider) – Controls the size of the Sun.. What else did you expect from it?!

Sea Floor modifier (slider) – Defines the lowest (starting) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer starts. It depends on your planet’s relief, your lowest and highest peaks. Adjust individually for each planet. You’ll “feel” the right value immediately.

Atmosphere Top Modifier (slider) – Defines the highest (ending) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer stops. It depends on your planet’s relief. Adjust individually for each planet. You’ll “feel” the right value immediately. But normally you want this value to be set pretty high.

Intensity (slider) – Actually it should be called “Fog Intensity” as it’s exactly what it’s responsible for but I hope it will be changed by some coder guys eventually J. Controls the amount or intensity of the fog while you’re on or near the planet’s surface (doesn’t do anything when you’re in outer space).

Fog Intensity (slider) – And this, should be actually called “Fog Distance”. It controls the distance fog actually covers. The higher this value – more objects in front of view are covered with fog. (doesn’t do anything when you’re in outer space).

Restore (Button) – Ok, just in case you screw everything up, you always have a chance to revert all the changes you’ve made by clicking this Restore button, soldier! Very convenient isn’t it?!

==Atmosphere 2/2==
Ok, now that we got acquainted with all Atmosphere settings and know how they work, it is time for us to actually change a few settings to alter the look of our Atmosphere! Now the fun part begins. Let’s say that we want to change the color of Earthlike planet’s atmosphere from its natural Blue color to the Green one, so it looks more “alienish”. Please note, that all atmosphere settings are stored in “PlanetGeneratorDefinitions.sbc” file and they are NOT replaced even when you change these values in game and make a save. If you want to change those values you have to change them directly in the code of the “PlanetGeneratorDefinitions.sbc” file only! The system reads those atmosphere values from this file every time you’re loading your worlds.

But how for God’s sake would you know which values are correct and really desirable to put them in the code? This is really simple. You just adjust your atmosphere settings to your liking right in the game, and when you’re done and happy with it, you just copy those values into the code (you can screen grab the in-game view with Atmosphere Settings window or just write them down manually, not a big deal) But to paste those values in the code, you have to know WHERE to paste it, right? You don’t just randomly paste numbers into the code, do you? You may hurt yourself!

So please open “PlanetGeneratorDefinitions.sbc” file in any decent text editor and find the following line:
<pre>
<SubtypeId>EarthLike</SubtypeId>
</pre>
It’s a name or identifier of a planet, and since it’s named Earthlike, we know for sure that below are the definitions related to Earthlike planet. Cool! Now just scroll down to the part where you will see a commented (inactive) line of code which goes like:



Or alternatively, just Ctrl+F to find the following line. You must see something similar to this:

[[File:Atmosphere definition.jpg|512px]]

So here as you can see everything is pretty self-explanatory. Except a few lines that are just named differently in the code. If you want your atmosphere to “remember” the settings you have made you have to enter those values here to the corresponding lines. The following schematic pic shows dependencies between the code lines and the slider names in Atmosphere Settings window quite clearly:
(Click to enlarge)

[[File:In-game Atmosphere Debug Input.jpg|1024px]]

Now let’s just change the blue color of the atmosphere to orange. As you remember, group of three RGB sliders named “Rayleigh Scattering” are responsible for changing the main color of the Atmosphere. So why wait?

[[File:Mars-Like Atmosphere.jpg|1024px]]

Spectacular right? Now, let’s change the sun glow color “Mie Scattering RGB” to an orange tint too. It could stay the same yellow of course but let’s change it so you could have an idea. Remember to press “Alt” on your keyboard while you’re dragging those sliders.

[[File:Another Red Atmosphere.jpg|1024px]]

Ok, now it’s more orange but we have to increase the glow effect a bit to see it more prominently. And as we remember, the glow size control is “Mie Height” slider. Crank it up from 30 to 50.

Good, the glow effect became more prominent. Looking nice isn’t it? Of course, you can continue adjusting it and come up with really crazy results, but if you’re ok with what we already have, then just write down all the values that you currently have in your Atmosphere Settings window on the right or screenshot them and paste into any image editor for your reference. And back in the code editor, just enter those values into corresponding tags in the code and save it:

[[File:CloseUp Atmosphere definition.jpg|512px]]

That’s it! From now on, every time you load up your world with Earthlike planet in it, or spawn Earthlike planet, the atmosphere on it will be exactly the way you adjusted it via Atmosphere Settings! The God himself must have been using something like this we suppose..

[[File:Mars-like Atmosphere Final.jpg|1024px]]

==Clouds==
The first thing that should (probably) come in to your mind when you finally learn how to tweak Atmosphere settings, is probably how to change the look of the Clouds! Because, normally, when you change the color of the atmosphere you would like the clouds color to be relatively close to the Atmosphere color. In our Atmosphere guide (if you read it) we were sharing some knowledge about changing the look of the Atmosphere. We made it orange which is kind of cool all on its own, but what really draws our attention and not in a very good way – is the color of the clouds. As you can see they’re white which is looking wrong isn’t it? In an orange atmosphere environment you would expect orange or yellow clouds right? So that’s what we’ll be doing in a minute – changing the look of our cloud layer and getting to know their under-the-hoods.

Like with Atmosphere settings, the Clouds setting are stored in the same “PlanetGeneratorDefinitions.sbc” file located in KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Data and are individual for each planet. Usually we base our code lines so the Cloud definitions come right after Atmosphere definitions which makes it very convenient to search for. Just open your “PlanetGeneratorDefinitions.sbc” file in any decent advanced text editor and search for this commented (inactive) line of code:



Note: you can download the DDS files from here[mirror.keenswh.com]

[[File:Cloud Layers Definition.jpg|1024px]]

That’s where all the cloud settings for particular planet are stored. The following picture is a brief breakdown of cloud definitions:

Basically, the structure of placing clouds on any planet is as follows:
<pre>
<CloudLayers>
<CloudLayer>
Blah Blah Blah Beautiful Clouds Blah Blah Blah
</CloudLayer>
</CloudLayers>
</pre>
So, as you can see everything is super easy. Simply put, <CloudLayers> tags are meant for global separation of Cloud definitions from other code definitions and are here just to define where the code for the clouds start, while <CloudLayer> tags (again, don’t mistake with CloudLayers) are the actual cloud layers and each pair of these tags (<CloudLayer>…</CloudLayer>) define the look and behavior of each cloud layer. As Captain Obvious states - The more <CloudLayer> pairs you have.. umm - the more cloud layers you will have!

For example. You can have more than one Cloud layer, to simulate even more complex cloud patterns than you initially had in your texture file! And that’s when <InitialRotation> and <RotationAxis> tags come into play. You can assign values to these tags for each Cloud layer individually thus having the cloud spheres to be initially rotated and spinning on different angles creating more interesting and natural cloud patterns. So you basically just stack them this way:
<pre>
<CloudLayers>
<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>
</CloudLayers>
</pre>

That’s it! Now you have three Cloud Layers! And of course you can do it for the Far and the Near cloud layers as well.

Your main cloud color texture must be 4096x2048px RGB file saved in DDS format without alpha as “CloudName_cm.dds file” and it must contain only the color information of your clouds. For Alphamask file please create a separate file of the same 4096x2048px dimensions containing only Alpha mask, make it a greyscale file, save as DDS luminance format and name it “CloudName_Alphamask.dds”. Back in the code, in <texture> tags you just write “Cloudname.dds”, no worries - the engine will identify required “cm” and “alphamask” files itself, just make sure both files are in the correct folder. (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Models\Environment\Sky).

As you know, clouds that are seen from the outer space and the clouds that you see through your window don’t look the same because of the huge differences in scales in both cases. That’s why we have two types of clouds on each planet. First one (commented as “Far layer” in the code) – the clouds that you see from the outer space. They usually look like NASA satellite orbital photo shots.

[[File:Clouds.jpg|1024px]]

And the Second one (commented as “Near layer” in the code) – the clouds that are seen when you’re on the ground or close to it. These should look like a significantly zoomed version of the first ones - more detailed, wispy and more individual. Like the ones you used to see in the sky every day. Refer to the picture.

[[File:LargeClouds.jpg|1024px]]

Now, how to actually separate these two types of cloud layers and to make them come in layers – one after the other. This is very simple too. The maximum overall Altitude (height) of our atmosphere layer is 2. So we have to set up our cloud layers in a tricky way, so that when we’re in outer space - we would see the “Far layer” clouds ONLY, and as we’re getting lower (approaching the ground), on a particular altitude (height) smoothly switch to the “Near layer” clouds and have the “Far layer” clouds hidden. Sounds crazy but it will become clear if you look at the following pic:

[[File:CloudLayerDiagram.jpg|1024px]]

As you can see things are really self-explanatory here too. By setting the Start and End values in <FadeOutRelativeAltitude..> you basically create a vector, the starting point of which is infinity which means anything below this start point will be constant value, thus – making it possible to set the Far layer to be seen from outer space (values greater than 2), and preventing Near cloud layer from being seen - because it is set to fade out on 1.6. And vice versa – when you’re on the ground, you won’t see Far layer clouds layer because it faded out on much higher distance of 1.4. Not so hard right? Of course you can alter and tweak those values to your liking depending on the planets height maps/relief to get the desired transition between Far and Near cloud layers.

So now that we’re empowered with this knowledge, the only thing we’re left to do is to actually change the color of the clouds from white to yellow color so our clouds look more natural in an orange Atmosphere environment. As we remember, our clouds are consisting of two texture files – a file containing color information (usually just a plain color) and a file with an alpha mask only. We already know that the “Far layer” clouds (the ones seen from space) use “EarthFarClouds_cm.dds” texture file and the “Near layer” clouds use “Landsky_texture_cm.dds”. How we know that? It’s written in <texture> </texture> definitions, remember?

[[File:CloudTextureRoute.jpg|512px]]

Great! So now just open “EarthFarClouds_cm.dds” and the “Landsky_texture_cm.dds” and fill both files with plain yellow color and save them!

[[File:YellowCloud Texture.jpg|1024px]]

Start the game and spawn an Earthlike planet and voila! You got perfect yellow clouds!

[[File:Scenery With Yellow Clouds.jpg|1024px]]

==Planet ambient sounds modding - day/night biome sounds==

Sound rules are in the Content\Data\PlanetGeneratorDefinitions.sbc file. Here you can set different sounds based on player’s location or daytime on the planet.
<pre>
<SoundRule>
<Height Min="0" Max="0.5"/>
<Latitude Min="55" Max="80"/>
<SunAngleFromZenith Min="0" Max="180"/>
<EnvironmentSound>AmbIcelandDay</EnvironmentSound>
</SoundRule>
</pre>
Height stands for where you want the sound to play at the height of the heightmap (0-7200m). It is always +12% of the planet's diameter. 0 is from the the lowest start of the surface to 1.0 which is 100% of the surface (maximum height).
Latitude means angle from the equator. Therefore 0 to 20 will mean that this sound will mostly play in the desert area, 20-50 is mostly the green forest area, and so on.
SunAngleFromZenith NEEDS MORE INFO!!!
EnvironmentSound this is the name of the sound you want to use.

You can find all available sounds in Audio.sbc (location shown below) Here you will also put your own ambient sound with your own custom name.

How to implement custom ambient sound

All Ambient sounds are stored here:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Audio\ARC\AMB\

If you want your own sounds, they should be a loop sound, and on average should not be bigger than +-5 MB.
The supported format is: .xwm but .wav can also work, even though its file size is usually a lot bigger (not recommended).

Once your audio is done, implement it here in this file:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\Audio.sbc
<pre>
<Sound>
<Id>
<TypeId>MyObjectBuilder_AudioDefinition</TypeId>
<SubtypeId>AmbAlienForestDay</SubtypeId>
</Id>
<Category>AMB</Category>
<MaxDistance>100</MaxDistance>
<Volume>0.2</Volume>
<Loopable>true</Loopable>
<Waves>
<Wave Type="D2">
<Loop>ARC\AMB\AmbAlienForestDayLoop2d.xwm</Loop>
</Wave>
</Waves>
</Sound>
</pre>
Here edit only what is highlighted, otherwise I cannot guarantee that it will work properly!
<SubtypeId> This is how you will name your AMB sound, keeping in mind upper and lower case letters. Do not use _ or other special characters!
<Volume> This is self explanatory I hope.
<Loop> Here you just need to lead the definition to your file. ARC/AMB/ is the default location, so do not change that.
But if you want, you can make another folder in AMB for your custom ambient sounds for better organisation.

==In-game map modding==
Maps in Medieval Engineers are generated based on terrain and buildings on it. This means that they will work for any modded planet in their default form. That being said, the way map is generated is also fully moddable.

We definitions for map are located in Content\Data\Screens\MapDefinition.sbc. To mod maps you will have to alter/add definitions in this file, all vanilla textures for maps can be found in Content\Textures\GUI\Map. Feel free to use/alter any of them for creation of mods for Medieval Engineers.
Map content modding (Friend/foe display, tax notifications,...
In Medieval Engineers there are 2 view modes of map. Kingdom view which is showing entire kingdom and region view which is zoomed part of a kingdom map. Region is 1kmx1km large on 10 km diameter planet. Both views display different elements.
What is shown in these views depends on what layers it contains
<pre>
<Definition xsi:type="MyObjectBuilder_PlanetMapDefinition">
<Id Type="MyObjectBuilder_PlanetMapDefinition" Subtype="Main"/>
<BackgroundGenerator Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
<RegionView>
<Layers>...</Layers>
</RegionView>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</Definition>
</pre>
BackgroundGenerator refers to a definition of background texture that serves as a background on top of which all the map elements are placed.
<pre>
<RegionView>
<Layers>...</Layers>
</RegionView>
</pre>
The three dots in middle represent layers of elements that show in region view. List and description of all layers is in next section of this document.
<pre>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</pre>
The three dots in middle represent layers of elements that show in kingdom view. List and description of all layers is in next section of this document.
(I did not Kingdom view in its expanded form because it would take up too much space.)

===Layers description===
<pre><Layer xsi:type="MyObjectBuilder_MapBackgroundLayer" /></pre>
This layer draws the background. As generated based on chosen background definition.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaDevelopmentLayer">
<Threshold BlockCount="10" Sprite="Textures\GUI\Map\SmallGrid.png"/>
<Threshold BlockCount="30" Sprite="Textures\GUI\Map\MediumGrid.png"/>
<Threshold BlockCount="60" Sprite="Textures\GUI\Map\LargeGrid.png"/>
</Layer>
</pre>
This layer displays icons based on amount of blocks there is in an area. You can set the block thresholds, or mod the textures. It is also possible to add more thresholds. 80x80 px, png.

[[File:Smallest Settlement.png|150px|frameless]]
[[File:Medium Settlement.png|150px|frameless]]
[[File:LargestSettlement.png|150px|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_RegionFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for region, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaOwnershipLayer">
<AlliedBgColor Hex="#806464FF" />
<PlayerBgColor Hex="#8064FF64" />
<EnemyBgColor Hex="#80DC6415" />
</Layer>
</pre>
This layer defines color overlay over map areas based on ownership. You can mod which color is used for allies, your own areas or for enemies
<pre>
<Layer xsi:type="MyObjectBuilder_AreaUpkeepLayer">
<TaxIcon>Textures\GUI\Map\TaxIcon.png</TaxIcon>
</Layer>
</pre>
This layer displays tax icon on areas that belong to you and require tax payment soon. Texture is 80x80 pixels, png.
[[File:Taxes.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapPositionLayer">
<LocalPlayerImage>Textures\GUI\Map\PlayerPosition.png</LocalPlayerImage>
<OtherPlayersImage>Textures\GUI\Map\AllyPosition.png</OtherPlayersImage>
</Layer>
</pre>
PlanetMapPositionLayer displays player icon above area where they are.
[[File:Ally.png|frameless]]
[[File:Player.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_ActionTrackingLayer">
<ActionImage>Textures\GUI\Map\Action.png</ActionImage>
</Layer>
</pre>
Shows icon over an area on map with fighting / destruction.
[[File:AttackedArea.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_CurrentMapSelectionLayer">
<SelectionImage>Textures\GUI\Map\MapSelection.dds</SelectionImage>
</Layer>
</pre>
This is highlight of a region, that player selected with his mouse.
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapGridLayer">
<GridColor R="0" G="0" B="0" A="228"/>
</Layer>
</pre>
This layer sets which color is the grid drawn.
<pre>
<Layer xsi:type="MyObjectBuilder_KingdomFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for kingdom, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_RegionOwnershipLayer">
<PlayerIcon>Textures\GUI\Map\PlayerLandIcon.png</PlayerIcon>
<AllyIcon>Textures\GUI\Map\AllyLandIcon.png</AllyIcon>
<EnemyIcon>Textures\GUI\Map\EnemyLandIcon.png</EnemyIcon>
<PlayerAllyIcon>Textures\GUI\Map\PlayerAllyLandIcon.png</PlayerAllyIcon>
<PlayerEnemyIcon>Textures\GUI\Map\PlayerEnemyLandIcon.png</PlayerEnemyIcon>
<AllyEnemyIcon>Textures\GUI\Map\AllyEnemyLandIcon.png</AllyEnemyIcon>
<PlayerAllyEnemyIcon>Textures\GUI\Map\PlayerAllyEnemyLandIcon.png</PlayerAllyEnemyIcon>
</Layer>
</pre>
RegionOwnershipLayer generates textures used to express ownership on regional map.

===Background generator (trees, mountains, roads,...)===
Map background is where all the trees, mountains, hills are drawn. It is also capable of coloring map based on what is in planet’s material map (this is how we make roads for example).
All settings for map background are in MedievalMapBackgroundDefinition. The definition also in Content\Data\Screens\MapDefinition.sbc. I will go through various parts of the definition.

<pre><Id Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
Type of the definition says that this map background definition. Subtype is name of this specific background definition. If create your own background with unique subtype
Make sure you create your own background with unique subtype

<DrawHeightmap>false</DrawHeightmap>
When set on “true” planet’s heightmap is drawn under the map.
<Resolution>4096</Resolution><
Sets resolution of the generated in-game map.

<Features>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</Features>

<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</Definition>
</pre>
===Map Coloring===
You can use colors in material or biome map of a planet to appear on the game map. (roads for example). You define map coloring in a node called ”Features”. The coloring uses colors from planet material texture. You can learn more about material texture in biomes modding and surface material modding.
<pre>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
</pre>
This specific feature is used for painting roads on map with dark brown color. In Color you define which color will be the in-game map colored. Material=”67” decides where will be the color applied and refers to a red channel value on planet material texture.
<pre>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</pre>
This specific feature is used for painting forests on map with opaque brown. In Color you define which color will be the in-game map colored. Biome=”60” decides where will be the color applied and refers to a green channel value on planet material texture.

===Sprites===
Medieval Engineers map can also place sprites on map based on terrain shape. All the sprites are on one texture
<pre>
<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</pre>

[[File:AtlasCoordinateUsage.png|512px]]

Note: Illustrates how sprite is defined on our spritesheet. Example sprite:
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />

==Voxel color overlay modding==
We have a cool tech that enables us to color-shift color of almost any item in the game. Currently we are using it for trees(adds small color variations to the same model of a tree) and voxels above iron deposits.
==Fast travel settings modding==
In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around.
In this section of the guide we will show you how to mod which sectors are blocked.
There are 2 ways you can go about it:
===Generate automatically based on terrain shape===
Game is capable of creating fast travel map on its own based on height and terrain steepness. It is possible to mod thresholds for both height and steepness.
You will find the thresholds in Content\Data\Game\FastTravel.sbc. In a MyObjectBuilder_TerrainReachabilityProviderDefinition.
<RiseThreshold> - Sets min. terrain height change which will cause that area is unreachable.
<HeightThreshold> - Sets height of terrain after which area is unreachable, if it goes over this value. Range is 0 - 1.

If there are texture overrides in the definition, you have to erase them in order for the parameters to take effect. Texture overrides are nodes that are called in this fashion: <OverrideNAMEOFFACE>. You will learn more about these overrides in the next part of Fast travel modding.

===Creating fast travel texture override===
If you want to have full control over which areas are reachable and which are not regardless of terrain, you can create a simple texture on which you mark unreachable areas.

The texture is 80x80 pixels, RGB 8 bit. Black pixels forbid entrance.

When you have the texture, select route to it in the definition:
<pre><OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward></pre>
Reachability definition example:
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>
<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>
<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
</Definition>
</pre>
This definition would generate fast travel reachability everywhere, except for front planet face (Fareon kingdom) where fast travel reachability is created based on your texture.

===Development reachability===
Claimable area size, border highlight, contested timer modding
Size of the area and highlight properties are moddable as well.

===Area borders highlight===
<NeutralColor R="225" G="32" B="0" A="64" /> - Set color of an unowned territory
<SelfColor R="0" G="255" B="0" A="64" /> - Sets color of area border owned by you
<AliedColor R="65" G="105" B="225" A="64" /> - Sets color of area border that belongs to allies
<EnemyColor R="225" G="32" B="0" A="64" /> - Sets color of area border that is hostile
<WallSettings Depth="15" Rise="3" SegmentCount"71" End="115" /> - Changes shape of the border. Depth sets how deep is border submerged. Rise sets how tall is the border.
<Fade Start="71" End="115" /> - This sets at which point the border starts to fade.
Contested timer
When players claim area with claimblock, area goes to a “contested” phase for some amount of time, in this phase other players can still attempt to build their own claim block and claim the area. This time is moddable.
Content\Data\Game\SessionComponents.sbc contains definition called MyObjectBuilder_AreaOwnershipSystemDefinition. To mod this value, add this definition to your mod with changed value of <ContestedTimeInMinutes> parameter.

==Permissions modding - what is/isn’t allowed to do in claimed areas==
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.
Description of available actions to set permissions for:
Name=”Build” -> block placement permissions
Name=”Repair” -> Repairing/building already placed blocks
Name=”Deconstruct” -> Deconstructing
Name=”QuickDeconstruct” -> Faster deconstruction
Name=”VoxelEdit” -> Mining or shoveling
Name=”Destroy” -> Damage with hand weapons
Name=”Interaction” -> Chest opening, door opening
Name=”ClaimBlockInteraction” -> ClaimblockGui

===List of available Groupnames:===
Groupname: “Owner” -> Player who owns area
Groupname: “Allies” -> Mostly faction members of owner of the area
Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
Groupname: “Enemies” -> Players in factions that are hostile to your faction

==Compass modding==
It is possible to mod visual look of an in-game compass. All definitions of compass are stored in Content\Data\GUI\CompassDefinition.sbc. Our textures for compass are in Content\Textures\GUI\Compass folder if you want to check out how they look or use them in your mod.
===Creating compass texture atlas and setting coordinates for its elements===
Just like with map sprites, we save main compass elements on a single texture, then define parts of it using pixel coordinates. First setup origin point, then add width and height of the rectangle
Example texture coordinates for top part of the compass:
[[File:CompassTextureCoordinates.png|1024px]]
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>

===Explanation of compass definition line by line===
<pre><Texture>Textures/GUI/Compass/compass.png</Texture> </pre>
Route to a texture atlas.
<pre><KingdomIcon>Textures/GUI/Compass/Icon-Kingdom.png</KingdomIcon> </pre>
Route to icon symbolizing a kingdom.
<pre><Padding>7</Padding></pre>
Padding is added vertically between the top and bottom textures and the edges of the contents of the compass.
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>
Rectangle in the texture that contains the top part.
<pre><BottomCrop X="0" Y="0" Width="0" Height="0"/></pre>
Rectangle in the texture that contains the bottom part.
<pre><BackgroundCrop X="0" Y="64" Width="512" Height="64"/></pre>
Rectangle in the texture that contains the background.
<pre><ArrowCrop X="0" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the little marker used for elements that are drawn and have no icon.
<pre><MarkerCrop X="32" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the interval bars drawn every few degrees.
<pre><ShadowCrop X="64" Y="128" Width="80" Height="32" Left="8" Right="8"/></pre>
<pre><ShadowPadding Left="12" Top="8" Right="12" Bottom="8"/></pre>
Rectangle in the texture that contains the text shadows. Shadow is 3-Sliced, meaning the texture is split in three parts: [left|middle|right]
The sizes of left and right define the cropping lines that split the texture into three. The Sides are then always kep proportional as the texture is scaled.
<pre><VisibleRange>200</VisibleRange></pre>
Visible range in degrees.
<pre><Width>700</Width></pre>
Width in reference resolution pixels.
<pre><FontSize>1.1</FontSize></pre>
Scale of the font based on default.
<pre><VerticalOffset>0.065</VerticalOffset></pre>
Vertical offset from the top of the screen. 0 = top of the screen, 1 is the bottom. Compass is centered around this position.
<pre>
<TagStyles>
<TagStyle Tag="ClaimArea" Style="Bellow" MaxCharacters="15" Ellipsis="true"/>
<TagStyle Tag="Cardinal" Style="Above" MaxCharacters="1"/>
<TagStyle Tag="Kingdom" Style="Bellow"/>
</TagStyles>
</pre>
This section adds tags that are visible on compass and in which style. Currently we have 3 types of tags. Claim area - shows your claimed area on the compass, Kingdom tag shows kingdoms and Cardinal tag shows cardinal points (North, South,...). Each tag’s visual appearance is defined in tag/waypoint definition. Styles defines where should the text appear. Available styles: Center, IconOnly, NotShown, Bellow, Above.

===Explanation of Waypoint/Tag definition===
<pre>
<Definition xsi:type="MyObjectBuilder_WaypointDefinition">
<Id Type="MyObjectBuilder_WaypointDefinition" Subtype="Kingdom"/>
<IconPath>Textures/GUI/Compass/IconKeep.png</IconPath>
<Color R="255" G="255" B="255" A="255"/>
</Definition>
</pre>
IconPath contains path to the texture of kingdom icon. Color defines color of the text that is shown with the icon. (Example: Fareon, [[File:Kingdom Icon.png|thumb]])
===Compass texture vs in-game look comparison===
Texture:

[[File:Compas Texture with Zones.png|1024px]]

In-game look:

[[File:In-gameCompassZones.png|1024px]]
<NoWiki>*</NoWiki>note that background crop and bottom crop are not used in vanilla (empty opaque texture)

==Indestructible grids==
There is a way how to make some buildings in your save indestructible. We are using this feature for starting area buildings. Some you guys might make a good use of this feature in your pre-made worlds.

Currently, only way how to do this is to make edits to an existing save file. So you can only use it for world modding.

===Making indestructible cubegrids in existing safe===
Goal is to open world’s safe file in a text editor, find your cubegrid in it and add this tag to it: <DestructibleBlocks>true</DestructibleBlocks>.

#Find your save file. By default save files are stored in C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Saves
#Open folder with your save and find file called SANDBOX_0_0_0_.sbs. This file can be opened with any text editor you prefer.
#In the SANDBOX_0_0_0_.sbs search for the cubegrid name of the building you want to make indestructible. (use find/search function in your text editor, or you will grow old before you find it)
#Tip: To find out name of a cubegrid, create blueprint of the building. The name that the building saves as in your blueprint screen is the name of the cubegrid.
#You should find the name in tags called: <DisplayName>YOURCUBEGRIDNAME</DisplayName>
#Under the name, add following tag with setting set to false: <DestructibleBlocks>false</DestructibleBlocks>
#If you followed instruction, the indestructibility tag is now in node called <MyObjectBuilder_EntityBase> and not in any of its child nodes.
#Save the edited file.
#Load the save and test destructibility
#It worked! Enjoy
#It is still destructible. Go to point 1.

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding - Full Guide

2017-03-13T16:30:24Z

Lukas: /* Biomes definitions modding - trees, plants and bots */

==Introduction==
Hello fellow Medieval Engineers!
I would like to present you with a guide that will help you understand how we created planets at Keen Software House and how to mod your own into the game.
Feel free to use/alter company owned files for your Medieval Engineers mods.

So let's get to modding!

==Recommended Software==
# Microsoft Visual Studio - or Notepad++ (Link[notepad-plus-plus.org]) - for opening files with .sbc extension where we have definitions for every feature in the game.
# Adobe Photoshop - for editing material and heightmap textures
# World Machine Professional - for heightmap easier creation (much more realistic looking terrain, without manual work)

(Basic Edition is also available, but the max resolution output is limited to 512x512 pixels)
http://www.world-machine.com

===Advice===
We would like to mention one thing before you get into modding planets:
For your own sake we recommend you to load either PlanetTemplate or EarthLikeModExample and test/edit all the things there, so you get to know the system and how everything works.

After that you can create your own from scratch. This is entirely up to you.

==General modding principles - how to make any mod==
I will explain again basic principles of how mods are applied.

All of our vanilla source files are all saved in a folder called content in your *game folder. If no mods are assigned to a world that you are loading, game uses only files from this content folder but if there are mods, game loads also files from mod adding more content or potentially rewriting vanilla content based on content of the mod’s folder. Mod is nothing else but a folder with another files.
Mod files are stored in mods folder on your computer , and if you are using them for the first time, they are downloaded from workshop first time you try to load/connect to a world with those mods.
Mod folder: C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Mods
===Opening mod and examining mods content===
When you open Mods folder, you will see mods as files with .sbm extension. But they are really just folders and to examine them, all you have to do is rewrite the extension from .sbm to .rar and then you can open them with rar and examine content.
Mods are not listed with their names, but with their steam id number. To find specific mod, you have to go to the mods workshop page

Examining other mods similar to your idea is a fast way to learn.
Example:

<NoWiki>*</NoWiki>By default this is SteamLibrary\steamapps\common\MedievalEngineers\Content. You can also get there if you go to steam library(same place where you start the game), right-click Medieval Engineers, select properties, local files and finally click on “browse local files”.
==Materials modding==
In case you are thinking about making your own trees and voxel materials, we have some good news for you!

There are two separate guides that you can follow to make your own stuff.

General modding guide - get started

===Voxel material modding===
http://steamcommunity.com/sharedfiles/filedetails/?id=568406623

==Planet Size==
Planet size is defined in a scenarios.sbc. Every time you click on create new world in the game it uses scenario definition to create a new safe file. Although this scenario definition is not moddable, you can still use it to create a world and share the world itself on the workshop.

First go to where you have Medieval Engineers source files and find Data folder (SteamLibrary\steamapps\common\MedievalEngineers\Content\Data\Scenarios.sbx)

==All planet related files overview and where to find them==
To summarize how planet modding in ME works, we can say this:
We use 2 types of textures and then we define how the game should interpret those textures in definitions. One texture is heightmap that is used just for generating terrain shape, another one is used to place everything else on the planet (ores, trees and plants, bots).
[[File:Diagram.png|1024px|center]]

==Material Texture modding==
Material texture is used to store information about location of various planet surface features. These features are surface materials, biomes (trees, bots, plants,..etc) and where you can find ore. Each one of these uses one color channel. Surface materials use red channel. Biomes use green. Ores are in blue channel.
We use 6 material textures (2048x2048) for each planet. You can find all our material textures here: Content\Data\PlanetDataFiles.
Each planet has its own folder. The folder has to have the same name as the planet.

[[File:MaterialMapBreakdown.jpg|512px]]

Illustration of how are the material textures connected to each other:

[[File:Planet Material Texture Order.jpg|512px]]

====The process of material texture creation is really simple. You have two options:====
=====Copy an existing map to your folder and overwrite the green channel and edit them to your liking=====
This is highly recommended to avoid errors!
=====Create a new: step by step in Photoshop=====
#Set both width and height to 2048 pixels
#(for smaller planets this can also be 1024 or less, but all textures need to have the same resolution! Even the heightmap)
#Set resolution - Pixels/Inch to 72.
#Set colour mode to RGB Colour - 8bit
#Now start painting with the pencil tool on each RGB Channel separately.
#Never on all three at once! (It will F. up everything - trust me).

===Surface voxel material definitions modding - grass, sand, snow===

[[File:RedChannel.jpg|22px|frameless]]

Surface “voxel materials” refers to what you know as grass, soil, stone.. We use red channel of the material texture to set where all the terrain appears. Then you need to write definitions in the Content\Data\PlanetGenerator.sbc to tell game which voxel should appear at specific red channel value.
Example of the definition of road:
<pre>
<ComplexMaterials>
<MaterialGroup Name="Road" Value="67">
<Rule>
<Layers>
<Layer Material="Soil" Depth="2"/>
</Layers>
<Slope Min="0" Max="90"/>
</Rule>
</MaterialGroup>
</ComplexMaterials>
</pre>
Example of corresponding material texture with road:

[[File:RoadMaterialTextureExample.png|512px]]

====Complex materials====
Complex materials definition allows to paint the map with a set of “voxel coloring rules”. Meaning that one color value in red channel can color terrain with different voxels based on rules like slope, longitude or latitude and height. (So with our road example)
<pre>
<MaterialGroup Name="Forest_Grass" Value="120">
<Rule>
<Layers>
<Layer Material="Woods_grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="0" Max="25"/>
<Latitude Min="-180" Max="180"/>
<Longitude Min="-180" Max="180"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="25" Max="45"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Rocks_grass" Depth="2"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="45" Max="55"/>
</Rule>
</MaterialGroup>
</pre>
This definition says what voxels should be generated in spots, that are painted with red channel value of 120.
The rules in this definition will lead to following:
Flat lands (up to 20 degrees slope) will have Wood grass 1 m thick, soil will be right under the WoodGrass up to 5 m depth and there will be stone underneath the soil.
In places with medium slope, there is Grass instead of WoodGrass. And in slopes from 45 to 55 there is rocks grass 2 m thick with stone right away under it.
With this technology, we can make the color react on its own to terrain bumps or even position on planet. This saves lots of meticulous painting with heightmap.

<Layer Material="Woods_grass" Depth="1"/>
Material refers to voxelmaterial definition. (You can find it in Content\Data\VoxelMaterials.sbc). Depth means how deep should the material go under ground.
<Slope Min="0" Max="25"/>
Slope of the terrain in degrees.
<Latitude Min="-180" Max="180"/>
Latitude in degrees. 0 degree is an equator.
<Longitude Min="-180" Max="180"/>
Longitude in degrees. 0 is in the middle of front planetary texture. (Fareon Kingdom)

===Biomes definitions modding - trees, plants and bots===
[[File:GreenChannel.jpg|frameless|22px]]

Biomes refers to everything that is spawned on top of the planet. We use green channel of the material texture to set where all the terrain features appear and definitions in the Content\Data\Environment\ProceduralEnvironments.sbc to tell game which environment item should appear at specific green channel value. Also you need to assign Environment to planet in the Content\Data\PlanetGenerator.sbc in case you are adding a brand new planet.

====First make/modify environment:====
Go to Content\Data\Environment\ProceduralEnvironments.sbc

=====Procedural World Environment definition=====
This definition defines where will the environmental items spawn and with which density. (note: bots are also considered environmental item). Best way to explain how procedural environment is working is to imagine that it puts spots on entire surface of a planet. And when you start defining trees, bots and bushes, the spots get “reserved” by these categories based on how many of those should appear in the world according to your mod.
Spots are always different for each single planet.
In order to mod the procedural environment, mod our “Earth Environment” definition. Or create your own but if you do, don’t forget to also mod PlanetGeneratorDefinition, so that planet has your new procedura environment assigned to it.

=====Definition elements explained point by point:=====
<pre>
<Definition xsi:type="MyObjectBuilder_ProceduralWorldEnvironment">
<Id>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>Earth Environment</SubtypeId>
</Id>
</pre>
This part of definition is called ID. It says what type of definition this is <TypeID> and unique name of that definition <SubtypeID>.

<pre>
<MaxSyncLod>1</MaxSyncLod>
</pre>
This line defines how far away from player are the environmental items updating. This is important feature for optimization.

<pre>
<SectorSize>40</SectorSize>
</pre>
This is size of the environmental sector. It is a different sector than the claimable areas by players. It sets size of one environmental sector.

<pre>
<ItemsPerSqMeter>0.17</ItemsPerSqMeter>
</pre>
The line sets overall maximum density of all environmental items. To return to analogy i used in the introduction, this number increases the amount of spots on the planet that are reserved for all environmental items.

<pre>
<ScanningMethod>Random</ScanningMethod>
</pre>

<pre>
<ItemTypes Type="MyObjectBuilder_EnvironmentItemTypesDefinition" Subtype="Default"/>
</pre>
This sets which types of environmental items are used in this procedural environment definition. This guide explains what are Environmental item types in the very next section.

<ItemGroup Density=".017" Name="Bots" LodStart="1" LodEnd="1">
<Mapping>
<Material>Woods</Material>
<Item Type="Bot" Subtype="Deer"/>
</Mapping>
<Mapping>
<Biome>60</Biome>
<Height Min="0" Max"1"/>
<Latitude Min="-180" Max"180"/>
<Longitude Min="-180" Max"180"/>
<Slope Min="0" Max"1"/>
<Item Type="Bot" Subtype="Deer" Density="0.9"/>
<Item Type="Bot" Subtype="Barbarian" Density="0.1"/>
</Mapping>
</ItemGroup>
Item group is used to organize and better manage mappings. Mappings are definitions that actually add the environment items in the world. It is important to set Density correctly. Density (Density=".017") sets how many of the procedurally generated spots on the planet will be assigned to environmental items from this group. The name (Name="Bots") is only for naming purposes within definition and has no impact on the game. LodStart="1" and LodEnd="1" control how far from the player will the items appear.
<Biome>60</Biome> This section means that Items within this mapping will only appear on spaces that are painted with green channel value 60 on the material map.
<Material>Woods</Material> This means that the environmental items will only appear in the woods.
<Height Min="0" Max"1"/> Sets in which altitude should these environmental items appear. If this parameter is missing, items spawn in full range (Min="0" Max"1")
<Latitude Min="-180" Max"180"/> Sets at which latitude do the environment items spawn. If this parameter is missing, items spawn in full range (Min="-180" Max"180")
<Longitude Min="-180" Max"180"/> Sets at which longitude the environment items spawn. If this parameter is missing, items spawn in full range (Min="-180" Max"180")
<Slope Min="0" Max"90"/> Sets at which slopes the environment items spawn. If this parameter is missing, items spawn in full range (Min="0" Max"90")

<ItemGroup Density=".085" Name="Trees" LodStart="-1" LodEnd="1">...</ItemGroup>
<ItemGroup Density=".36" Name="Small Items" LodStart="0" LodEnd="0">...</ItemGroup>
There are 2 more item Groups. I will not go into details, since it is not
</Definition>

=====Environment items=====
We learned how to assign environments to planets and how to mod environments themselves by changing densities and environment items. But we still don't know how to make the environment items themselves. Guides for those can be found on following links.

If you want to mod trees:

If you want to mod bushes and plants:

If you want to mod bots:

=====EnvironmentItemTypesDefinition=====
Here you define various types of items. Currently we have these types: Tree, Gatherable, Farmable, Static and Bot. Before you add any item, you must make sure it fits within these types of environment items or you created a new type for them.
<Definition xsi:type="MyObjectBuilder_EnvironmentItemTypesDefinition">
<Id Type="MyObjectBuilder_EnvironmentItemTypesDefinition" Subtype="Default"/>
<Item Name="Tree">...</Item>
<Item Name="Gatherable">...</Item>
<Item Name="Farmable">... </Item>
<Item Name="Static">...</Item>
<Item Name="Bot">...</Item>
</Definition>

EnvironmentItemTypes
<Item Name="Tree">
<ProxyActivationLod>0</ProxyActivationLod>
<Provider Type="MyObjectBuilder_ProceduralEnvironmentModuleDefinition" Subtype="Growable"/>
<Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Gatherable" />
<Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Cuttable" />
</Item>
Available proxy and providers:
Proxy Subtype="Gatherable"
This line adds ability to all environmental items of this type to use action “Gatherable”. Keep in mind that the tree itself has to be setup properly in order for this to work.
Proxy Subtype="Cuttable" />
This line adds ability to all environmental items of this type to use action “Cuttable”. Keep in mind that the tree itself has to be setup properly in order for this to work.
<ProxyActivationLod>0</ProxyActivationLod>
This line says from which lod is the game logic attached to the environmental item. (when set on 0 only trees very close to you become “gatherable” and “cuttable”). This way we don’t use game logic on environmental items that couldn’t be used anyway and game is better optimized thanks to that.
Provider Subtype="Growable”
This line adds ability to all environmental items of this type to grow. Keep in mind that the tree itself has to be setup properly in order for this to work.
Provider Subtype="Farmable”
This line adds ability to all environmental items of this type to be farmable. Keep in mind that the tree itself has to be setup properly in order for this to work.
Provider Subtype="Static”
This line adds basically adds items that do nothing. They are just visual props. Like some of our fern bushes.
Provider Subtype="BotSpawner”
It is important that all environmental item types that will contain some bots have botspawner

====Assign environment to a planet====
Go to Content\Data\PlanetGenerator.sbc and find definition of the planet you want your environment to be on. Then assign the environment to the planet this way:
<pre>
<Environment>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>Earth Environment</SubtypeId>
</Environment>
</pre>
SutypeId refers to the name of the environment from:
Content\Data\Environment\ProceduralEnvironments.sbc

===Ores definitions modding===
[[File:BlueChannel.jpg|frameless|22px]]

Ores are placed using blue channel of the material texture to set where should ore deposits appear. When your ore deposits are painted on the material map, you need to define what ores will be there. Go to Content\Data\Environment\ProceduralEnvironments.sbc to tell game which ore should appear at specific blue channel value.

<pre>
<OreMappings>
<Ore Value="130" Type="IronOre_RichYield" Start="3" Depth="7" TargetColor="#b7340a" ColorInfluence="15 "/>
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
<Ore Value="110" Type="IronOre_PoorYield" Start="2" Depth="5" TargetColor="#a76a41" ColorInfluence="15" />
</OreMappings>
</pre>
The section you need to use is Ore Mappings.
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
Value refers to blue channel value on material texture.
Type refers to name of a voxel material from Content\Data\VoxelMaterials.sbc.
Start is depth at which the ore deposit starts. Depth is how deep under ground it goes.
TargetColor is color that will be used to color surface above the ore.
ColorInfluence sets strenght of coloring.

==Working with RGB==
Ok, Steam won't let me share that link to a small RGB Photoshop tutorial with you, so just go to photoshopessentials.com and search for RGB and it's the first link.

This is a simple tutorial to explain you what we mean when we say Grayscale ID, which can also be called the RGB values
(each channel only has one number per shade of that color ranging from 0 to 255).

Here I have loaded a Biome map texture front_mat texture which is used on the Vanilla EarthLike planet.

[[File:RGBChannels.jpg|frameless]]These are the RGB channels as you can see them in Photoshop.

NOTE: Edit each RGB channel separately!

Always use the pencil tool to paint pixels.
The brush tool has a falloff that has different values and you will not have control over those!
[[File:Color Picker.jpg|thumb]]

You can see if the numbers are correct on the top right of the screen if you have your workspace set to Essentials.

Here you will enter the values you want to paint.
Make sure you check them before saving, sometimes Photoshop can move the number +-1 (personal experience).

It doesn't matter if the numbers match, just as long as you have the correct value (ID) in the correct channel!

==Height-maps modding - terrain shape, roads==
As mentioned in 2. Required software, we used the program World Machine to create our heightmaps and then we did some minor tweaks by hand (like putting in lakes and desert areas)

First, to explain how our planet heightmaps work:
We have 6 textures that connect together (image below). Our standard resolution for a big 120km planet is 2048x2048. But you can use a lower one if you want to.

To create your own heightmap, the best action would be to find a heightmap here:
C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\PlanetDataFiles

Then you can open the texture and place yours/paint yours on a new layer, flatten the image and save it as a .PNG

There are other options for you also!
You can visit[terrain.party] this site and download a heightmap from a real place on Earth. You can even set the size of the map (maximum is 60 km). And then you can edit it further in Photoshop.
You can try painting it yourself in Photoshop (or any other similar software, like Gimp).
You can also just try Googling for heightmaps and try which one suits you the best (keep in mind the resolution must be 512,1024, 2048!)
However you get your heightmap, always keep in mind how each texture of the heightmap is connected, so the seams need to fit together. Bad texture connection is very visible in the game.
Here is an image of how the textures are connected:

[[File:Planet Material Texture Order.jpg|512px]]

===Roads===
We created roads using World Machine tools. You can find guide how to do that in between World Machine tutorials.

==Atmosphere==
[[File:View Image.jpg|1024px]]

Here, you will find everything you ever wanted to know about Atmosphere Settings in Space Engineers but were afraid to ask, my dear friend. So without any further ado. Let’s start with the “Atmosphere” settings window which you access in-game by hitting F12 -> Render Button -> Atmosphere checkbox. The new Atmosphere settings window opens immediately on the right side of the screen, showing a bunch of tricky sliders.

[[File:Cloud Layers Definition.jpg|1024px]]

If your pants are still dry, and if by any chance you’re still reading this, let us assure you that everything is pretty simple and not so scary as it may seem when you first open it. So let’s start with the brief and really quick explanation of what every slider or group of sliders are meant for. Lastly, remember that to alter any setting in this Window you have to hold “Alt” on your keyboard.

Enable Atmosphere (checkbox) – Well, as Captain Obvious immediately states to us – it just enables or disables Atmosphere on a planet and nothing more.

Time of Day (slider) – Controls rotation of the Sun around a Planet. You’re given the Power to decide which time of day it is now. Cool isn’t it?

Pick Planet (Button) – In situations when you have more than one planet in your world, you may want to alter the settings of each planet’s atmosphere individually. So this button enables you to immediately pick the current atmosphere values of the planet you’re currently on. For example, fly to the Moon, press “Pick planet” button and you will get corresponding atmosphere values of that planet to play with. Fly back to Earth or any alien planet, and do the same to alter atmosphere settings of these planets. Yay!

Rayleigh Scattering R,G and B (sliders) – Group of three sliders which control the main, overall color of the Atmosphere. It’s that atmosphere color which is going to be seen from outer space and on the ground too! If you want to make your atmosphere alien green or purple – these are the correct set of sliders to play with. Each slider controls corresponding R,G or B (0-255) values. Pretty straightforward.

[[File:Atmosphere Settings.jpg|512px]]

Mie Scattering R, G and B (sliders) – Group of three sliders to control the color of the Sun glow. It would be weird to have Green atmosphere and Red sun glow right? You would normally want to set it to yellow or something light green or so. But it’s your choice you can make any color you want. But please note that in order to have noticeable results you have to actually HAVE that glow around your sun. This setting is called “Mie Height” and it has to be set to a fairly high value otherwise it wouldn’t be too prominent. We will talk about this “Mie Height” setting in a minute. No worries.

The following three sliders are complementary and play well together. It means you have to find a good balance setting them which is quite easy:

Rayleigh Height Surface (slider) – Controls the thickness of the atmospheric layer when you’re on or near planet’s Surface. For example. You normally want atmosphere layer to be fairly thick to cover high points of the planet’s surface like mountains and high hills while you’re on the ground because you have actual high picks in your surface geometry which you have to cover. Otherwise you would see black space when you’re on the high mountain. But technically, when you’re leaving the planet’s atmosphere all of these high peaks and mountains are starting to slowly collapse vertically forming a smooth spherical shape of the planet, if they wouldn’t - we would have planets looking like a spiky balls with mountain peaks sticking out in all directions. That’s why when all the high peaks are collapsed to the ground to form a perfect sphere - we are left with abnormally thick and wrong looking atmospheric layer thickness when observed from the outer space. How to fix this?! That’s where “Rayleigh Height Space” slider comes into play, as it controls the thickness of the atmospheric layer seen from outer space.

Rayleigh Height Space (slider) – Controls the thickness of atmospheric layer when you observing the planet from outer space. Like it was said earlier, settings for atmosphere thickness when you’re on the Surface and when you’re in an outer Space can’t be same and normally you want to make it much thinner when it is seen from outer space like it’s in real world. Refer to the following Pic to get better understanding.

Rayleigh Transition (slider) – Ok, so now that we have set the width of the planetary atmosphere for both - when we’re on the Surface and when we’re observing it from outer space, it is time to decide at which distance to switch between two, right? So that’s exactly what this slider does – sets the exact value at which distance that transition must happen. You can play around with this value to find the best setting, just remember that the main goal is to have this transition as smooth as possible, fortunately it’s super easy to achieve. Just make sure that while you’re on the ground and standing on a highest point you still see some atmosphere color (like Blue color in earthlike planets) ,and just about when you start to see the whole planet on your way to the outer space, switch it to the thinner (Rayleigh Height Space) version.

Mie Height (slider) – Controls the size of the outer glow effect of the Sun. Like it was said earlier, when you’re setting your color of the Glow effect via “Mie Scattering RGB” sliders, this particular setting (Mie Height) must be set to a fairly high value otherwise you won’t see it as there won’t be any glow. Look, you can’t change the color of a non-existing thing, soldier. Dismissed!

Sun size (slider) – Controls the size of the Sun.. What else did you expect from it?!

Sea Floor modifier (slider) – Defines the lowest (starting) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer starts. It depends on your planet’s relief, your lowest and highest peaks. Adjust individually for each planet. You’ll “feel” the right value immediately.

Atmosphere Top Modifier (slider) – Defines the highest (ending) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer stops. It depends on your planet’s relief. Adjust individually for each planet. You’ll “feel” the right value immediately. But normally you want this value to be set pretty high.

Intensity (slider) – Actually it should be called “Fog Intensity” as it’s exactly what it’s responsible for but I hope it will be changed by some coder guys eventually J. Controls the amount or intensity of the fog while you’re on or near the planet’s surface (doesn’t do anything when you’re in outer space).

Fog Intensity (slider) – And this, should be actually called “Fog Distance”. It controls the distance fog actually covers. The higher this value – more objects in front of view are covered with fog. (doesn’t do anything when you’re in outer space).

Restore (Button) – Ok, just in case you screw everything up, you always have a chance to revert all the changes you’ve made by clicking this Restore button, soldier! Very convenient isn’t it?!

==Atmosphere 2/2==
Ok, now that we got acquainted with all Atmosphere settings and know how they work, it is time for us to actually change a few settings to alter the look of our Atmosphere! Now the fun part begins. Let’s say that we want to change the color of Earthlike planet’s atmosphere from its natural Blue color to the Green one, so it looks more “alienish”. Please note, that all atmosphere settings are stored in “PlanetGeneratorDefinitions.sbc” file and they are NOT replaced even when you change these values in game and make a save. If you want to change those values you have to change them directly in the code of the “PlanetGeneratorDefinitions.sbc” file only! The system reads those atmosphere values from this file every time you’re loading your worlds.

But how for God’s sake would you know which values are correct and really desirable to put them in the code? This is really simple. You just adjust your atmosphere settings to your liking right in the game, and when you’re done and happy with it, you just copy those values into the code (you can screen grab the in-game view with Atmosphere Settings window or just write them down manually, not a big deal) But to paste those values in the code, you have to know WHERE to paste it, right? You don’t just randomly paste numbers into the code, do you? You may hurt yourself!

So please open “PlanetGeneratorDefinitions.sbc” file in any decent text editor and find the following line:
<pre>
<SubtypeId>EarthLike</SubtypeId>
</pre>
It’s a name or identifier of a planet, and since it’s named Earthlike, we know for sure that below are the definitions related to Earthlike planet. Cool! Now just scroll down to the part where you will see a commented (inactive) line of code which goes like:



Or alternatively, just Ctrl+F to find the following line. You must see something similar to this:

[[File:Atmosphere definition.jpg|512px]]

So here as you can see everything is pretty self-explanatory. Except a few lines that are just named differently in the code. If you want your atmosphere to “remember” the settings you have made you have to enter those values here to the corresponding lines. The following schematic pic shows dependencies between the code lines and the slider names in Atmosphere Settings window quite clearly:
(Click to enlarge)

[[File:In-game Atmosphere Debug Input.jpg|1024px]]

Now let’s just change the blue color of the atmosphere to orange. As you remember, group of three RGB sliders named “Rayleigh Scattering” are responsible for changing the main color of the Atmosphere. So why wait?

[[File:Mars-Like Atmosphere.jpg|1024px]]

Spectacular right? Now, let’s change the sun glow color “Mie Scattering RGB” to an orange tint too. It could stay the same yellow of course but let’s change it so you could have an idea. Remember to press “Alt” on your keyboard while you’re dragging those sliders.

[[File:Another Red Atmosphere.jpg|1024px]]

Ok, now it’s more orange but we have to increase the glow effect a bit to see it more prominently. And as we remember, the glow size control is “Mie Height” slider. Crank it up from 30 to 50.

Good, the glow effect became more prominent. Looking nice isn’t it? Of course, you can continue adjusting it and come up with really crazy results, but if you’re ok with what we already have, then just write down all the values that you currently have in your Atmosphere Settings window on the right or screenshot them and paste into any image editor for your reference. And back in the code editor, just enter those values into corresponding tags in the code and save it:

[[File:CloseUp Atmosphere definition.jpg|512px]]

That’s it! From now on, every time you load up your world with Earthlike planet in it, or spawn Earthlike planet, the atmosphere on it will be exactly the way you adjusted it via Atmosphere Settings! The God himself must have been using something like this we suppose..

[[File:Mars-like Atmosphere Final.jpg|1024px]]

==Clouds==
The first thing that should (probably) come in to your mind when you finally learn how to tweak Atmosphere settings, is probably how to change the look of the Clouds! Because, normally, when you change the color of the atmosphere you would like the clouds color to be relatively close to the Atmosphere color. In our Atmosphere guide (if you read it) we were sharing some knowledge about changing the look of the Atmosphere. We made it orange which is kind of cool all on its own, but what really draws our attention and not in a very good way – is the color of the clouds. As you can see they’re white which is looking wrong isn’t it? In an orange atmosphere environment you would expect orange or yellow clouds right? So that’s what we’ll be doing in a minute – changing the look of our cloud layer and getting to know their under-the-hoods.

Like with Atmosphere settings, the Clouds setting are stored in the same “PlanetGeneratorDefinitions.sbc” file located in KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Data and are individual for each planet. Usually we base our code lines so the Cloud definitions come right after Atmosphere definitions which makes it very convenient to search for. Just open your “PlanetGeneratorDefinitions.sbc” file in any decent advanced text editor and search for this commented (inactive) line of code:



Note: you can download the DDS files from here[mirror.keenswh.com]

[[File:Cloud Layers Definition.jpg|1024px]]

That’s where all the cloud settings for particular planet are stored. The following picture is a brief breakdown of cloud definitions:

Basically, the structure of placing clouds on any planet is as follows:
<pre>
<CloudLayers>
<CloudLayer>
Blah Blah Blah Beautiful Clouds Blah Blah Blah
</CloudLayer>
</CloudLayers>
</pre>
So, as you can see everything is super easy. Simply put, <CloudLayers> tags are meant for global separation of Cloud definitions from other code definitions and are here just to define where the code for the clouds start, while <CloudLayer> tags (again, don’t mistake with CloudLayers) are the actual cloud layers and each pair of these tags (<CloudLayer>…</CloudLayer>) define the look and behavior of each cloud layer. As Captain Obvious states - The more <CloudLayer> pairs you have.. umm - the more cloud layers you will have!

For example. You can have more than one Cloud layer, to simulate even more complex cloud patterns than you initially had in your texture file! And that’s when <InitialRotation> and <RotationAxis> tags come into play. You can assign values to these tags for each Cloud layer individually thus having the cloud spheres to be initially rotated and spinning on different angles creating more interesting and natural cloud patterns. So you basically just stack them this way:
<pre>
<CloudLayers>
<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>
</CloudLayers>
</pre>

That’s it! Now you have three Cloud Layers! And of course you can do it for the Far and the Near cloud layers as well.

Your main cloud color texture must be 4096x2048px RGB file saved in DDS format without alpha as “CloudName_cm.dds file” and it must contain only the color information of your clouds. For Alphamask file please create a separate file of the same 4096x2048px dimensions containing only Alpha mask, make it a greyscale file, save as DDS luminance format and name it “CloudName_Alphamask.dds”. Back in the code, in <texture> tags you just write “Cloudname.dds”, no worries - the engine will identify required “cm” and “alphamask” files itself, just make sure both files are in the correct folder. (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Models\Environment\Sky).

As you know, clouds that are seen from the outer space and the clouds that you see through your window don’t look the same because of the huge differences in scales in both cases. That’s why we have two types of clouds on each planet. First one (commented as “Far layer” in the code) – the clouds that you see from the outer space. They usually look like NASA satellite orbital photo shots.

[[File:Clouds.jpg|1024px]]

And the Second one (commented as “Near layer” in the code) – the clouds that are seen when you’re on the ground or close to it. These should look like a significantly zoomed version of the first ones - more detailed, wispy and more individual. Like the ones you used to see in the sky every day. Refer to the picture.

[[File:LargeClouds.jpg|1024px]]

Now, how to actually separate these two types of cloud layers and to make them come in layers – one after the other. This is very simple too. The maximum overall Altitude (height) of our atmosphere layer is 2. So we have to set up our cloud layers in a tricky way, so that when we’re in outer space - we would see the “Far layer” clouds ONLY, and as we’re getting lower (approaching the ground), on a particular altitude (height) smoothly switch to the “Near layer” clouds and have the “Far layer” clouds hidden. Sounds crazy but it will become clear if you look at the following pic:

[[File:CloudLayerDiagram.jpg|1024px]]

As you can see things are really self-explanatory here too. By setting the Start and End values in <FadeOutRelativeAltitude..> you basically create a vector, the starting point of which is infinity which means anything below this start point will be constant value, thus – making it possible to set the Far layer to be seen from outer space (values greater than 2), and preventing Near cloud layer from being seen - because it is set to fade out on 1.6. And vice versa – when you’re on the ground, you won’t see Far layer clouds layer because it faded out on much higher distance of 1.4. Not so hard right? Of course you can alter and tweak those values to your liking depending on the planets height maps/relief to get the desired transition between Far and Near cloud layers.

So now that we’re empowered with this knowledge, the only thing we’re left to do is to actually change the color of the clouds from white to yellow color so our clouds look more natural in an orange Atmosphere environment. As we remember, our clouds are consisting of two texture files – a file containing color information (usually just a plain color) and a file with an alpha mask only. We already know that the “Far layer” clouds (the ones seen from space) use “EarthFarClouds_cm.dds” texture file and the “Near layer” clouds use “Landsky_texture_cm.dds”. How we know that? It’s written in <texture> </texture> definitions, remember?

[[File:CloudTextureRoute.jpg|512px]]

Great! So now just open “EarthFarClouds_cm.dds” and the “Landsky_texture_cm.dds” and fill both files with plain yellow color and save them!

[[File:YellowCloud Texture.jpg|1024px]]

Start the game and spawn an Earthlike planet and voila! You got perfect yellow clouds!

[[File:Scenery With Yellow Clouds.jpg|1024px]]

==Planet ambient sounds modding - day/night biome sounds==

Sound rules are in the Content\Data\PlanetGeneratorDefinitions.sbc file. Here you can set different sounds based on player’s location or daytime on the planet.
<pre>
<SoundRule>
<Height Min="0" Max="0.5"/>
<Latitude Min="55" Max="80"/>
<SunAngleFromZenith Min="0" Max="180"/>
<EnvironmentSound>AmbIcelandDay</EnvironmentSound>
</SoundRule>
</pre>
Height stands for where you want the sound to play at the height of the heightmap (0-7200m). It is always +12% of the planet's diameter. 0 is from the the lowest start of the surface to 1.0 which is 100% of the surface (maximum height).
Latitude means angle from the equator. Therefore 0 to 20 will mean that this sound will mostly play in the desert area, 20-50 is mostly the green forest area, and so on.
SunAngleFromZenith NEEDS MORE INFO!!!
EnvironmentSound this is the name of the sound you want to use.

You can find all available sounds in Audio.sbc (location shown below) Here you will also put your own ambient sound with your own custom name.

How to implement custom ambient sound

All Ambient sounds are stored here:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Audio\ARC\AMB\

If you want your own sounds, they should be a loop sound, and on average should not be bigger than +-5 MB.
The supported format is: .xwm but .wav can also work, even though its file size is usually a lot bigger (not recommended).

Once your audio is done, implement it here in this file:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\Audio.sbc
<pre>
<Sound>
<Id>
<TypeId>MyObjectBuilder_AudioDefinition</TypeId>
<SubtypeId>AmbAlienForestDay</SubtypeId>
</Id>
<Category>AMB</Category>
<MaxDistance>100</MaxDistance>
<Volume>0.2</Volume>
<Loopable>true</Loopable>
<Waves>
<Wave Type="D2">
<Loop>ARC\AMB\AmbAlienForestDayLoop2d.xwm</Loop>
</Wave>
</Waves>
</Sound>
</pre>
Here edit only what is highlighted, otherwise I cannot guarantee that it will work properly!
<SubtypeId> This is how you will name your AMB sound, keeping in mind upper and lower case letters. Do not use _ or other special characters!
<Volume> This is self explanatory I hope.
<Loop> Here you just need to lead the definition to your file. ARC/AMB/ is the default location, so do not change that.
But if you want, you can make another folder in AMB for your custom ambient sounds for better organisation.

==In-game map modding==
Maps in Medieval Engineers are generated based on terrain and buildings on it. This means that they will work for any modded planet in their default form. That being said, the way map is generated is also fully moddable.

We definitions for map are located in Content\Data\Screens\MapDefinition.sbc. To mod maps you will have to alter/add definitions in this file, all vanilla textures for maps can be found in Content\Textures\GUI\Map. Feel free to use/alter any of them for creation of mods for Medieval Engineers.
Map content modding (Friend/foe display, tax notifications,...
In Medieval Engineers there are 2 view modes of map. Kingdom view which is showing entire kingdom and region view which is zoomed part of a kingdom map. Region is 1kmx1km large on 10 km diameter planet. Both views display different elements.
What is shown in these views depends on what layers it contains
<pre>
<Definition xsi:type="MyObjectBuilder_PlanetMapDefinition">
<Id Type="MyObjectBuilder_PlanetMapDefinition" Subtype="Main"/>
<BackgroundGenerator Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
<RegionView>
<Layers>...</Layers>
</RegionView>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</Definition>
</pre>
BackgroundGenerator refers to a definition of background texture that serves as a background on top of which all the map elements are placed.
<pre>
<RegionView>
<Layers>...</Layers>
</RegionView>
</pre>
The three dots in middle represent layers of elements that show in region view. List and description of all layers is in next section of this document.
<pre>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</pre>
The three dots in middle represent layers of elements that show in kingdom view. List and description of all layers is in next section of this document.
(I did not Kingdom view in its expanded form because it would take up too much space.)

===Layers description===
<pre><Layer xsi:type="MyObjectBuilder_MapBackgroundLayer" /></pre>
This layer draws the background. As generated based on chosen background definition.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaDevelopmentLayer">
<Threshold BlockCount="10" Sprite="Textures\GUI\Map\SmallGrid.png"/>
<Threshold BlockCount="30" Sprite="Textures\GUI\Map\MediumGrid.png"/>
<Threshold BlockCount="60" Sprite="Textures\GUI\Map\LargeGrid.png"/>
</Layer>
</pre>
This layer displays icons based on amount of blocks there is in an area. You can set the block thresholds, or mod the textures. It is also possible to add more thresholds. 80x80 px, png.

[[File:Smallest Settlement.png|150px|frameless]]
[[File:Medium Settlement.png|150px|frameless]]
[[File:LargestSettlement.png|150px|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_RegionFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for region, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaOwnershipLayer">
<AlliedBgColor Hex="#806464FF" />
<PlayerBgColor Hex="#8064FF64" />
<EnemyBgColor Hex="#80DC6415" />
</Layer>
</pre>
This layer defines color overlay over map areas based on ownership. You can mod which color is used for allies, your own areas or for enemies
<pre>
<Layer xsi:type="MyObjectBuilder_AreaUpkeepLayer">
<TaxIcon>Textures\GUI\Map\TaxIcon.png</TaxIcon>
</Layer>
</pre>
This layer displays tax icon on areas that belong to you and require tax payment soon. Texture is 80x80 pixels, png.
[[File:Taxes.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapPositionLayer">
<LocalPlayerImage>Textures\GUI\Map\PlayerPosition.png</LocalPlayerImage>
<OtherPlayersImage>Textures\GUI\Map\AllyPosition.png</OtherPlayersImage>
</Layer>
</pre>
PlanetMapPositionLayer displays player icon above area where they are.
[[File:Ally.png|frameless]]
[[File:Player.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_ActionTrackingLayer">
<ActionImage>Textures\GUI\Map\Action.png</ActionImage>
</Layer>
</pre>
Shows icon over an area on map with fighting / destruction.
[[File:AttackedArea.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_CurrentMapSelectionLayer">
<SelectionImage>Textures\GUI\Map\MapSelection.dds</SelectionImage>
</Layer>
</pre>
This is highlight of a region, that player selected with his mouse.
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapGridLayer">
<GridColor R="0" G="0" B="0" A="228"/>
</Layer>
</pre>
This layer sets which color is the grid drawn.
<pre>
<Layer xsi:type="MyObjectBuilder_KingdomFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for kingdom, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_RegionOwnershipLayer">
<PlayerIcon>Textures\GUI\Map\PlayerLandIcon.png</PlayerIcon>
<AllyIcon>Textures\GUI\Map\AllyLandIcon.png</AllyIcon>
<EnemyIcon>Textures\GUI\Map\EnemyLandIcon.png</EnemyIcon>
<PlayerAllyIcon>Textures\GUI\Map\PlayerAllyLandIcon.png</PlayerAllyIcon>
<PlayerEnemyIcon>Textures\GUI\Map\PlayerEnemyLandIcon.png</PlayerEnemyIcon>
<AllyEnemyIcon>Textures\GUI\Map\AllyEnemyLandIcon.png</AllyEnemyIcon>
<PlayerAllyEnemyIcon>Textures\GUI\Map\PlayerAllyEnemyLandIcon.png</PlayerAllyEnemyIcon>
</Layer>
</pre>
RegionOwnershipLayer generates textures used to express ownership on regional map.

===Background generator (trees, mountains, roads,...)===
Map background is where all the trees, mountains, hills are drawn. It is also capable of coloring map based on what is in planet’s material map (this is how we make roads for example).
All settings for map background are in MedievalMapBackgroundDefinition. The definition also in Content\Data\Screens\MapDefinition.sbc. I will go through various parts of the definition.

<pre><Id Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
Type of the definition says that this map background definition. Subtype is name of this specific background definition. If create your own background with unique subtype
Make sure you create your own background with unique subtype

<DrawHeightmap>false</DrawHeightmap>
When set on “true” planet’s heightmap is drawn under the map.
<Resolution>4096</Resolution><
Sets resolution of the generated in-game map.

<Features>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</Features>

<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</Definition>
</pre>
===Map Coloring===
You can use colors in material or biome map of a planet to appear on the game map. (roads for example). You define map coloring in a node called ”Features”. The coloring uses colors from planet material texture. You can learn more about material texture in biomes modding and surface material modding.
<pre>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
</pre>
This specific feature is used for painting roads on map with dark brown color. In Color you define which color will be the in-game map colored. Material=”67” decides where will be the color applied and refers to a red channel value on planet material texture.
<pre>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</pre>
This specific feature is used for painting forests on map with opaque brown. In Color you define which color will be the in-game map colored. Biome=”60” decides where will be the color applied and refers to a green channel value on planet material texture.

===Sprites===
Medieval Engineers map can also place sprites on map based on terrain shape. All the sprites are on one texture
<pre>
<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</pre>

[[File:AtlasCoordinateUsage.png|512px]]

Note: Illustrates how sprite is defined on our spritesheet. Example sprite:
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />

==Voxel color overlay modding==
We have a cool tech that enables us to color-shift color of almost any item in the game. Currently we are using it for trees(adds small color variations to the same model of a tree) and voxels above iron deposits.
==Fast travel settings modding==
In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around.
In this section of the guide we will show you how to mod which sectors are blocked.
There are 2 ways you can go about it:
===Generate automatically based on terrain shape===
Game is capable of creating fast travel map on its own based on height and terrain steepness. It is possible to mod thresholds for both height and steepness.
You will find the thresholds in Content\Data\Game\FastTravel.sbc. In a MyObjectBuilder_TerrainReachabilityProviderDefinition.
<RiseThreshold> - Sets min. terrain height change which will cause that area is unreachable.
<HeightThreshold> - Sets height of terrain after which area is unreachable, if it goes over this value. Range is 0 - 1.

If there are texture overrides in the definition, you have to erase them in order for the parameters to take effect. Texture overrides are nodes that are called in this fashion: <OverrideNAMEOFFACE>. You will learn more about these overrides in the next part of Fast travel modding.

===Creating fast travel texture override===
If you want to have full control over which areas are reachable and which are not regardless of terrain, you can create a simple texture on which you mark unreachable areas.

The texture is 80x80 pixels, RGB 8 bit. Black pixels forbid entrance.

When you have the texture, select route to it in the definition:
<pre><OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward></pre>
Reachability definition example:
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>
<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>
<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
</Definition>
</pre>
This definition would generate fast travel reachability everywhere, except for front planet face (Fareon kingdom) where fast travel reachability is created based on your texture.

===Development reachability===
Claimable area size, border highlight, contested timer modding
Size of the area and highlight properties are moddable as well.

===Area borders highlight===
<NeutralColor R="225" G="32" B="0" A="64" /> - Set color of an unowned territory
<SelfColor R="0" G="255" B="0" A="64" /> - Sets color of area border owned by you
<AliedColor R="65" G="105" B="225" A="64" /> - Sets color of area border that belongs to allies
<EnemyColor R="225" G="32" B="0" A="64" /> - Sets color of area border that is hostile
<WallSettings Depth="15" Rise="3" SegmentCount"71" End="115" /> - Changes shape of the border. Depth sets how deep is border submerged. Rise sets how tall is the border.
<Fade Start="71" End="115" /> - This sets at which point the border starts to fade.
Contested timer
When players claim area with claimblock, area goes to a “contested” phase for some amount of time, in this phase other players can still attempt to build their own claim block and claim the area. This time is moddable.
Content\Data\Game\SessionComponents.sbc contains definition called MyObjectBuilder_AreaOwnershipSystemDefinition. To mod this value, add this definition to your mod with changed value of <ContestedTimeInMinutes> parameter.

==Permissions modding - what is/isn’t allowed to do in claimed areas==
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.
Description of available actions to set permissions for:
Name=”Build” -> block placement permissions
Name=”Repair” -> Repairing/building already placed blocks
Name=”Deconstruct” -> Deconstructing
Name=”QuickDeconstruct” -> Faster deconstruction
Name=”VoxelEdit” -> Mining or shoveling
Name=”Destroy” -> Damage with hand weapons
Name=”Interaction” -> Chest opening, door opening
Name=”ClaimBlockInteraction” -> ClaimblockGui

===List of available Groupnames:===
Groupname: “Owner” -> Player who owns area
Groupname: “Allies” -> Mostly faction members of owner of the area
Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
Groupname: “Enemies” -> Players in factions that are hostile to your faction

==Compass modding==
It is possible to mod visual look of an in-game compass. All definitions of compass are stored in Content\Data\GUI\CompassDefinition.sbc. Our textures for compass are in Content\Textures\GUI\Compass folder if you want to check out how they look or use them in your mod.
===Creating compass texture atlas and setting coordinates for its elements===
Just like with map sprites, we save main compass elements on a single texture, then define parts of it using pixel coordinates. First setup origin point, then add width and height of the rectangle
Example texture coordinates for top part of the compass:
[[File:CompassTextureCoordinates.png|1024px]]
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>

===Explanation of compass definition line by line===
<pre><Texture>Textures/GUI/Compass/compass.png</Texture> </pre>
Route to a texture atlas.
<pre><KingdomIcon>Textures/GUI/Compass/Icon-Kingdom.png</KingdomIcon> </pre>
Route to icon symbolizing a kingdom.
<pre><Padding>7</Padding></pre>
Padding is added vertically between the top and bottom textures and the edges of the contents of the compass.
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>
Rectangle in the texture that contains the top part.
<pre><BottomCrop X="0" Y="0" Width="0" Height="0"/></pre>
Rectangle in the texture that contains the bottom part.
<pre><BackgroundCrop X="0" Y="64" Width="512" Height="64"/></pre>
Rectangle in the texture that contains the background.
<pre><ArrowCrop X="0" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the little marker used for elements that are drawn and have no icon.
<pre><MarkerCrop X="32" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the interval bars drawn every few degrees.
<pre><ShadowCrop X="64" Y="128" Width="80" Height="32" Left="8" Right="8"/></pre>
<pre><ShadowPadding Left="12" Top="8" Right="12" Bottom="8"/></pre>
Rectangle in the texture that contains the text shadows. Shadow is 3-Sliced, meaning the texture is split in three parts: [left|middle|right]
The sizes of left and right define the cropping lines that split the texture into three. The Sides are then always kep proportional as the texture is scaled.
<pre><VisibleRange>200</VisibleRange></pre>
Visible range in degrees.
<pre><Width>700</Width></pre>
Width in reference resolution pixels.
<pre><FontSize>1.1</FontSize></pre>
Scale of the font based on default.
<pre><VerticalOffset>0.065</VerticalOffset></pre>
Vertical offset from the top of the screen. 0 = top of the screen, 1 is the bottom. Compass is centered around this position.
<pre>
<TagStyles>
<TagStyle Tag="ClaimArea" Style="Bellow" MaxCharacters="15" Ellipsis="true"/>
<TagStyle Tag="Cardinal" Style="Above" MaxCharacters="1"/>
<TagStyle Tag="Kingdom" Style="Bellow"/>
</TagStyles>
</pre>
This section adds tags that are visible on compass and in which style. Currently we have 3 types of tags. Claim area - shows your claimed area on the compass, Kingdom tag shows kingdoms and Cardinal tag shows cardinal points (North, South,...). Each tag’s visual appearance is defined in tag/waypoint definition. Styles defines where should the text appear. Available styles: Center, IconOnly, NotShown, Bellow, Above.

===Explanation of Waypoint/Tag definition===
<pre>
<Definition xsi:type="MyObjectBuilder_WaypointDefinition">
<Id Type="MyObjectBuilder_WaypointDefinition" Subtype="Kingdom"/>
<IconPath>Textures/GUI/Compass/IconKeep.png</IconPath>
<Color R="255" G="255" B="255" A="255"/>
</Definition>
</pre>
IconPath contains path to the texture of kingdom icon. Color defines color of the text that is shown with the icon. (Example: Fareon, [[File:Kingdom Icon.png|thumb]])
===Compass texture vs in-game look comparison===
Texture:

[[File:Compas Texture with Zones.png|1024px]]

In-game look:

[[File:In-gameCompassZones.png|1024px]]
<NoWiki>*</NoWiki>note that background crop and bottom crop are not used in vanilla (empty opaque texture)

==Indestructible grids==
There is a way how to make some buildings in your save indestructible. We are using this feature for starting area buildings. Some you guys might make a good use of this feature in your pre-made worlds.

Currently, only way how to do this is to make edits to an existing save file. So you can only use it for world modding.

===Making indestructible cubegrids in existing safe===
Goal is to open world’s safe file in a text editor, find your cubegrid in it and add this tag to it: <DestructibleBlocks>true</DestructibleBlocks>.

#Find your save file. By default save files are stored in C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Saves
#Open folder with your save and find file called SANDBOX_0_0_0_.sbs. This file can be opened with any text editor you prefer.
#In the SANDBOX_0_0_0_.sbs search for the cubegrid name of the building you want to make indestructible. (use find/search function in your text editor, or you will grow old before you find it)
#Tip: To find out name of a cubegrid, create blueprint of the building. The name that the building saves as in your blueprint screen is the name of the cubegrid.
#You should find the name in tags called: <DisplayName>YOURCUBEGRIDNAME</DisplayName>
#Under the name, add following tag with setting set to false: <DestructibleBlocks>false</DestructibleBlocks>
#If you followed instruction, the indestructibility tag is now in node called <MyObjectBuilder_EntityBase> and not in any of its child nodes.
#Save the edited file.
#Load the save and test destructibility
#It worked! Enjoy
#It is still destructible. Go to point 1.

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding/Voxel Materials

2017-03-13T16:23:08Z

Lukas: Lukas moved page Official Content/Modding of Voxel Materials to Official Content/Voxel Materials modding without leaving a redirect

Hello and welcome to the Modding of Voxel Materials guide for young Padawans. Feeling creative about changing the look of voxel materials? You think you’re really good, huh? Well, you’re in the right place, then. Be prepared for a great journey saving the world by changing the look of the voxel worlds around you. Let’s just assume that you want to change the color of this beautiful green grass which grows on every EarthLike planet in the SE Universe! And let’s assume you want to change it to a crazy blue color. Why? Because we CAN, and you Can too! Call NOW and get your free training program PLUS an amazing set of kitchen knives... wait... I meant something completely different...

[[File:Voxels 1-1.jpg|center|1200px]]

==Source Files==
Various files will be used as examples in this guide.<br/>
They can be downloaded here: http://www.medievalengineerswiki.com/uploaded_files/Voxel_material_modding_files.zip

==Voxel material definitions==
Ok, so to start - all voxel materials definitions are stored in the VoxelMaterials.sbc file. Find it and open it in MS Visual Studio or any other advanced text editor. Search for the following line in the code:

<pre><SubtypeId>Grass</SubtypeId></pre>

That’s where all the fun begins! So “Grass” is the name of the voxel material we’re looking for. It’s exactly how it is called in the game, and it’s exactly that green grass you see on the screenshot. Now let’s just make a quick overview of those code lines that define how particular voxel materials look and behave so you can brag about your programming skills to your girlfriend.

Every voxel material starts with the <VoxelMaterial> tag and ends with </VoxelMaterial> tag. You can refer to the “Understanding voxel material definitions” picture for a brief breakdown of the most important code definitions describing the look of a voxel material.

[[File:Voxels 2-1.jpg|center]]

So first things first, you have to know that the grass you see in a screenshot consists of the Grass Voxel Material (Ground) and a set of different Grass Textures “growing” out of it and scattered randomly on it. So you will be creating/tweaking the textures for the both, because normally you don’t want blue grass to grow on a green surface, right? You do? Shut up, marine! You’re in the army now, son. Just do what you’ve been told to do, and we’ll do the thinking! Let’s start with the Surface definitions first and then continue on to the Grass itself.

==Understanding what Voxel Material (ground) is made of==
Basically, the following three lines define how our base Voxel Material’s surface will look, or to be more precise - which textures it will use to define this look.

[[File:Voxels 3-1.jpg|center]]

Here’s what these code lines do:
<pre><ColorMetalXZnY>Textures\Voxels\Grass_cm.dds</ColorMetalXZnY></pre>
: Your Color+Metalness texture goes here. The letters “cm” in the “Grass_cm.dds” file stand for Color and Metalness. Color (or a diffuse/albedo map) is a standard RGB channel and Metalness is placed in the Alpha channel. You can go completely crazy in RGB colors. Do whatever you want. Metalness is a Black and White map only (normally NO grey halftones) which represents areas that are Metal only. You wouldn’t want to have metalness in your grass, would you? So that’s why it’s empty now (black).

[[File:Voxels 3-2.jpg|center]]

<pre><NormalGlossXZnY>Textures\Voxels\Grass_ng.dds</NormalGlossXZnY></pre>
: Your Normals+Glossiness texture goes here. The letters “ng” in the “Grass_ng.dds” file stand for Normal and Glossiness. Normal map is a standard RGB channels and the Glossiness map is placed in Alpha channel. As you can see here, the normal map resides on all RGB channels and we have subtle glossy areas (Black means NO Glossiness. White: 100% glossiness) scattered all around the grass surface.

[[File:Voxels 3-3.jpg|center]]

<pre><ExtXZnY>Textures\Voxels\Green_add.dds</ExtXZnY></pre>
: Your AO+ Emissivity+Dirt texture goes here. The letters “add” in the ”Grass_add.dds” file stand for Ambient Occlusion map, Emissivity map and Dirt map. Everything’s simple: AO goes to the Red channel, Emissivity goes in the Green channel and Dirt map goes to the Blue channel. In this particular example we see that currently we have a very subtle AO map (White areas mean no AO), no emissivity at all - because we don’t want our grass to glow in the dark (Black means no emissivity) and it has no dirt (White means NO Dirt).

[[File:Voxels 3-4.jpg|center]]

Now just open the first “Grass_cm.dds” texture in Photoshop and add a Hue/Saturation adjustment layer on top. Tick Colorize and make the color crazy Blue.

[[File:Voxels 3-5.jpg|center]]

Now just re-save this file as “GrassBlue_cm.dds” in the correct folder: (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Voxels). And of course we have to change the name in the VoxelMaterials.sbc file’s definitions, too, so the Engine knows which file to use instead of the old (green) one:

[[File:Voxels 3-6.jpg|center]]

Important note:
All textures must be saved in DDS format, DXT5, Interpolated Alpha format with “Generate MIP maps” ON.

[[File:Voxels 3-7.jpg|center]]

If you load the game now to see what happened to the grass, you will see that we’ve changed the color of the Grass Voxel Material (surface) only, while the Grass Plates which grow on it remain green. What the..?

[[File:Voxels 3-8.jpg|center|1200px]]

That’s because we didn’t change the Grass textures yet. We’ll do this in a minute, no worries.

Also, you may notice that if you move far enough from the surface, suddenly, instead of blue color – the old green starts to fade in. But didn’t we change it?! Time to panic right?

[[File:Voxels 3-9.jpg|center|1200px]]

Wrong! Those green textures that you see in the far distance are actually Far1 and Far2 textures, with Far3 Color at its farthest end. I said calm down, son, this is an order! We will talk about it in a minute! Don’t worry, we got you covered!

==Far textures==
Now that we got acquainted with “cm”, “ng” and “add” files, and know what they’re doing, it is time to speak of Far textures and their meaning in our lives. Briefly - the beautiful green grass field seen from the height of human eyes and the same field seen from the outer space will not look the same, obviously. While standing on it, you’re able to see all the details, even individual grass blades and flowers here and there, but when you’re in outer space and looking down on it from orbit - the base green color will mostly remain, but it’s color pattern and relief will change significantly. So it’s apparent that we have to substitute the base grass material seen from eye-height for one that might look like it's seen from outer space. Also, we have to “tell” the render engine at which particular distances it should load our Far Textures, and how big in scale they should be to represent the desired look. Here’s a picture so you can have an idea of how it currently looks.

[[File:Voxels 4-1.jpg|center|1200px]]

As you can see, Far1 and Far2 textures are represented by the same naming convention - “cm”, “ng” and “add” files. The Far3 Color, as Captain Obvious states, is defined by the RGB Color values only. It’s because when you too far away from the surface - having a simple color is more than enough.

[[File:Voxels 4-2.jpg|center]]

So please open the Far1 color+metalness texture file “EarthGreenGrass_Far1_cm.dds” in Photoshop, and add a simple Hue/Saturation adjustment layer on top. Change the Hue/ Saturation values so it looks bluish enough (or any other color you like). Do the same with Far2 color+metalness texture file “EarthGreenGrass_Far2_cm.dds”. Now you have completely blue Far1 and Farf2 textures. That’s exactly what we want. Finally, it’s time to change the Far3 Color which will be loaded at extremely far distances and which is still green. But we will change it in a sec.

[[File:Voxels 4-3.jpg|center|1200px]]

To choose the correct Far3 color to seamlessly blend with the Far2 Texture, you must first get rid of anything like fog or normal map effects that might get in the way and reduce the accuracy of color adjustments. So it’s better to choose your Far3 color with only the Base Color channel turned on (see the picture). To do so, hit F12 -> Render button –> tick the Render Debug checkbox –> tick the Base color in a newly opened Render Debug window.

Then hit F12 and then click the “Game” button. Tick the “Voxel Materials” checkbox and the Voxel Materials debug window will pop up on the right side with the drop down list where you can select any existing voxel materials in your world and adjust them.

[[File:Voxels 4-4.jpg|center|1200px]]

Holding “Alt” (you need to keep holding “Alt” while you operate in this window), select “Grass” material from the dropdown list and start adjusting the color with these three RGB sliders. We can get a good result with R-0, G-5 and B-25, as this color blends perfectly with other Far textures. But first we have to convert these RGB values to XYZ values before we paste them into the code.

[[File:Voxels 4-5.jpg|center]]

To find your X,Y and Z values simply divide each of your RGB values by 255. By dividing 0/255, 5/255 and 25/255 you get X-0, Y-0.02 and Z-0.10 respectively. Cool! Now just update the old XYZ values with these new ones in the code and load the game! You should see something similar to this.

[[File:Voxels 4-6.jpg|center|1200px]]

Also, the Voxel Materials debug window is convenient for interactive in-game adjustment of Far Textures’ Distance and Scale values. You can adjust the corresponding Far1 and Far2 Distance and Scale sliders, and you can set Far 3 RGB colors and see changes immediately, which is a lot better than guessing the correct numbers in the code. After you find the desired values for everything related to Far textures, you just copy those values to the definitions in the code. Very convenient, isn’t it?

Now about Distance and Scale definitions in the code. So, the following lines in the code:
<pre>
<Far1Distance>30</Far1Distance>
<Far2Distance>500</Far2Distance>
<Far3Distance>5000</Far2Distance>
</pre>
literally mean that the Far1 texture is seen at distances greater than 30 meters, the Far2 texture is seen on a distances greater than 500 meters, and finally the Far3 color is seen at distances greater than 5000 meters. It’s that simple. The following lines:
<pre>
<Far1Scale>200</Far1Scale>
<Far2Scale>1000</Far2Scale>
</pre>
define the scale (in meters) for the Far 1 and Far2 textures.

==Understanding what Grass is made of (Grass Plates)==
Below you can see all the grass textures our green grass consists of. It consists of 7 (seven) different grass plates (each with it’s own set of “cm” and “ng” files). Note that <Color></Color> tags are for “cm” files, and <Normal></Normal> tags are for “ng” files. Here they are:

[[File:Voxels 5-1.jpg|center]]

And that’s how their channels look in Photoshop:

[[File:Voxels 5-2.jpg|center]]

[[File:Voxels 5-3.jpg|center]]

[[File:Voxels 5-4.jpg|center]]

[[File:Voxels 5-5.jpg|center]]

[[File:Voxels 5-6.jpg|center]]

[[File:Voxels 5-7.jpg|center]]

[[File:Voxels 5-8.jpg|center]]

Why there are so many of them? More grass plates mean more variation in the overall feel and color of the grass, and thus it looks more real, which is exactly what we’re after (unless you really want to make an awful type of graphics intentionally of course!) If the whole field were made up of only one type of grass texture it would be way too repetitive, boring and too uniform of course.
Now you can say, hey, but didn’t we use the Alpha channel for Metalness in all “cm” type files?! Don’t worry, your grass won’t be metallic. Yes, though the “CM” abbreviation stands for Color and Metalness in the above files, remember that for Grass Plates only (ONLY), we use Alpha channel NOT for Metalness but for Alpha Mask, to cut out th Grass’ silhouette. Pretty simple right? But for all “NG” (normal/metalness) type of files everything stays the same – you have RGB channels for Normals and Alpha channel for Glossiness.

==Changing the Grass color==
Now that we know how our Grass is made, let’s make a simple color change again - from Green to Blue. So open all 7 (seven) Grass Plate files (“Grass_01_cm.dds”, “Grass_02_cm.dds”.. etc) in Photoshop, and for each of the files, add a simple Hue/Saturation adjustment layer on top. Change the Hue/ Saturation values so it looks bluish enough (or any other color you like)

[[File:Voxels 6-1.jpg|center]]

and then let’s re-save it as “GrassBlue_01_cm.dds” in the same folder (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Models\Environment\Grass). Please note that it’s different from the folder where you put your textures for the Voxel Surface materials. Repeat the same procedure for the rest of the "cm" textures (“GrassBlue_02_cm.dds” etc.) Then we go back into the code of VoxelMaterials.sbc and change the names of all 7 grass textures “Grass_01_cm.dds” etc. to “GrassBlue_01_cm.dds” which we’ve just created. You should end up with the following:

[[File:Voxels 6-2.jpg|center]]

Restart the game, or just reload the save and Voila. You have this crazy blue-colored grass. I wouldn’t step on it barefoot, to be honest. You never know who may live in the blue grass. You never know :)
[[File:Voxels 6-3.jpg|center|1200px]]

[[Category:Keen_Modding_Guides]]

Keen:AI Bots

2017-03-13T16:20:38Z

Lukas: /* Creating definition */

==Creating behavior==

===Introduction===
This tutorial presents how to create simple behavior for barbarian step by step. The only requirement for this tutorial is to get Medieval Engineers mod SDK which can be found in Steam library under Tool section. For curious readers, tutorial about behavior trees and the behavior tree tool can be found under this address.

===Jumping barbarian behavior===
In order to create a new behavior, we will need to open the behavior tree tool. It can be accessed from ME mod SDK which you can find in the Tool section on Steam.

[[File:ModSDK.png]]

When you double click Medieval Engineers - Mod SDK, it will open the root folder with tools. In order to open behavior tree tool you need to go to Tools folder and then to VRageEditor folder. In VRageEditor folder, start '''BehaviorTree.bat''' which will open the behavior tree tool.

[[File:BehaviorTreeBat.png]]

The first step is to create a new behavior tree. To do this, click the "New tree" button in the upper left corner of the application. A new window with two fields will pop up in which you can specify the name and the kind of behavior you want to create. In this tutorial we are going to make jumping barbarian behavior, so let's call our new behavior '''JumpingBarbarianBehavior''' and set the ''Behavior'' field to '''Barbarian'''.

[[File:CreateNewTree.png]]

When you click the ''"Create"'' button, the window will be closed and the behavior tree graph area control with the grey background will appear in the behavior tree tool. In this control we will add new nodes and create our AI. On the creation, the control automatically adds the Root node which is the main node of a behavior tree. The orange color of the node signalizes that the node is selected. You can select node by clicking on it with the left mouse button.

[[File:Selection.png]]

Our first and only child of the root node will be selector node. To do it, let's select the root node and click on the "Add node" button in the upper menu. From the pop-up menu pick Selector value and click the Ok button. If you did the steps correctly, a selector node should be added next to the root node. There should be also connection (a black arrow) between two nodes. If it is not a case, you can create a new connection between nodes by clicking and dragging a mouse cursor from a node's black dot to the another node's black dot. If you want to remove a connection between two nodes, you can double click the arrow.

[[File:NodeConnecting.png]]

The root node can only have one child node (in our case selector node). A selector node can have any number of child nodes. We decided to pick selector as the first node because of its property of finishing the run on the first child which returns '''SUCCESS''' or '''RUNNING''' states. You can find more about it in the tutorial mentioned at the beginning of this tutorial.
Let's add two new nodes to the selector node. The first one will be a sequence node and the latter will be an action node. You can tell the application to automatically reorganize the layout of the nodes by clicking the "Refresh layout" button in the upper menu.

[[File:SelectorNode.png]]

Let's change the action of our newly added action node. Double click the first value field in the action node (by default, in barbarian behavior, it has "Attack" value set), and in the pop-up window change the value of the field to "Idle". At this point it would be great to change names of selector and sequence nodes to more meaningful ones. Let's call them '''MainSelector''' and '''JumpingSequence''' respectively. You can change the name of these nodes by double clicking their value fields (by default they have values '''Selector''' and '''Sequence'''). Changing names of selectors and sequences does not affect how a behavior works. It is simply a cosmetic change that increases the readability of a behavior.

[[File:JumpingSequence.png]]

The next step is to design our jumping sequence. What we want our bot to achieve is to find a player character in some radius, get to the found character and jump next to him. Barbarian behavior exposes a set of actions that can help us with making it happen. The very first action that we are going to add to the jumping sequence is going to be ''"FindCharacterInRadius"''. It has two parameters:
#''radius'' - which specifies in what radius the action should look for a player character,
#''output'' player character - in this field you can specify under what name the found player character will be stored in the memory. This name can be used in different actions as an input parameter (if type is supported of course).
In our case we want to look for a player in radius of 30 meters and we will save it under "Player" name in the memory.
The second node in the jumping sequence is going to be ''"SetTarget"'' action node. ''"SetTarget"'' has input parameter which is the name of some target stored in the memory. In our case it is found character from ''"FindCharacterInRadius"'' action. Therefore, provide it with the "Player" value.

[[File:JumpSequenceActions.png]]

After setting the target, we have to get to the character. To do this, we will add a selector node with two child action nodes to the jumping sequence. Let's name the selector node '''GetToTarget'''. The first action of the '''GetToTarge''' selector should be ''"IsAtTargetPosition"'' action that takes as a parameter the tolerable area radius around the target. The second action is ''"GotoTarget"'' which makes the character move towards the target. GetToTarget selector ensures that we will get to our target.
The last child node of the jumping sequence is a decorator node. There can be two types of decorators: a timer decorator (it activates after the specified amount of time passes) and a counter decorator (it activates after the specified call count has been reached). We are going to pick the timer decorator node by changing first value of a decorator node to ''"TimerLogic"''. In the second value, let's choose '''RUNNING''' which stands for the default value that decorator returns. The last one specifies value dependent on the decorator type. In the case of a timer decorator, it is time in milliseconds after which the decorator will run its child node. Let's provide it with the value of 1500 ms. You can find more about decorators and related concepts under this link. As a decorator can only have one child, we are going attach "Jump" action node to it.
As the final modification to our behavior tree, let's mark the '''JumpingSequence''' node as a memorable (by clicking on the ''"Is memorable"'' box). It means that while doing the jumping sequence we want to focus only on the node that was processed last time. Below you can see the final state of the behavior tree:

[[File:EntireTreeView.png]]

Now you can safely export the behavior tree to a file. Click the ''"Export tree"'' button in the upper menu and select which behavior you want to export. The next step is to specify a file to which you want to save selected behaviors. In the next tutorial I will present you how to create a mod with our jumping barbarian!

==Creating bot==
===Introduction===
In the previous tutorial we have created jumping barbarian behavior. Now we are going add it to the game. The bot will appear in the g-screen menu under Bots tab, so you will be able to spawn him at any location.

===Creating definition===
In order to make our bot available in the game, we have to define a bot definition. Let's create a new file ''MyBots.sbc'' in which we will define our previously created behavior.

<pre>
<?xml version="1.0"?>
<Definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Bots>
<Bot xsi:type="MyObjectBuilder_HumanoidBotDefinition">
<Id>
<TypeId>MyObjectBuilder_HumanoidBot</TypeId>
<SubtypeId>JumpingBarbarian</SubtypeId>
</Id>
<DisplayName>Jumping Barbarian</DisplayName>
<Icon>Textures\GUI\Icons\SpawnBarbarian.dds</Icon>
<BotModel>Medieval_barbarian</BotModel>
<BotBehaviorTree Subtype="JumpingBarbarianBehavior" />
<BehaviorType>Barbarian</BehaviorType>
<TargetType>Humanoid</TargetType>
<StartingItem Subtype="Mace" />
<Public>true</Public>
<AvailableInSurvival>false</AvailableInSurvival>
<InventoryContentGenerated>true</InventoryContentGenerated>
<InventoryContainerTypeId>
<TypeId>ContainerTypeDefinition</TypeId>
<SubtypeId>BarbarianBagContent</SubtypeId>
</InventoryContainerTypeId>
<FactionTag>BARB</FactionTag>
</Bot>
</Bots>
</Definitions>
</pre>

The definition above will tell the game what kind of bot we want to create. The bot is going to use jumping behavior. The next step is to a create toolbar item for the g-screen menu.

<pre>
<?xml version="1.0" encoding="utf-8"?>
<Definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<CategoryClasses>
<Category>
<Id>
<TypeId>GuiBlockCategoryDefinition</TypeId>
<SubtypeId/>
</Id>
<DisplayName>DisplayName_Category_Bots</DisplayName>
<Name>Bots</Name>
<Public>true</Public>
<ItemIds>
<string>BotDefinition/JumpingBarbarian</string>
</ItemIds>
</Category>
</CategoryClasses>
</Definitions>
</pre>

Now let's create a new folder '''JumpingBehavior''' and create '''Data''' subfolder inside of it. Then, move all three files (''JumpingBehavior.sbc'', ''MyBots.sbc'' and ''Categories.sbc'') to '''Data''' folder. Another step is to copy our JumpingBehavior folder to ''Roaming/MedievalEngineers/Mods'' folder. Now you can open the game and add our mod. As stated before, you will find the jumping barbarian under '''Bots''' tab in g-screen menu. Enjoy!

Link:
http://steamcommunity.com/sharedfiles/filedetails/?id=413831474

Keen:AI Bots

2017-03-13T16:18:58Z

Lukas: /* Creating definition */

==Creating behavior==

===Introduction===
This tutorial presents how to create simple behavior for barbarian step by step. The only requirement for this tutorial is to get Medieval Engineers mod SDK which can be found in Steam library under Tool section. For curious readers, tutorial about behavior trees and the behavior tree tool can be found under this address.

===Jumping barbarian behavior===
In order to create a new behavior, we will need to open the behavior tree tool. It can be accessed from ME mod SDK which you can find in the Tool section on Steam.

[[File:ModSDK.png]]

When you double click Medieval Engineers - Mod SDK, it will open the root folder with tools. In order to open behavior tree tool you need to go to Tools folder and then to VRageEditor folder. In VRageEditor folder, start '''BehaviorTree.bat''' which will open the behavior tree tool.

[[File:BehaviorTreeBat.png]]

The first step is to create a new behavior tree. To do this, click the "New tree" button in the upper left corner of the application. A new window with two fields will pop up in which you can specify the name and the kind of behavior you want to create. In this tutorial we are going to make jumping barbarian behavior, so let's call our new behavior '''JumpingBarbarianBehavior''' and set the ''Behavior'' field to '''Barbarian'''.

[[File:CreateNewTree.png]]

When you click the ''"Create"'' button, the window will be closed and the behavior tree graph area control with the grey background will appear in the behavior tree tool. In this control we will add new nodes and create our AI. On the creation, the control automatically adds the Root node which is the main node of a behavior tree. The orange color of the node signalizes that the node is selected. You can select node by clicking on it with the left mouse button.

[[File:Selection.png]]

Our first and only child of the root node will be selector node. To do it, let's select the root node and click on the "Add node" button in the upper menu. From the pop-up menu pick Selector value and click the Ok button. If you did the steps correctly, a selector node should be added next to the root node. There should be also connection (a black arrow) between two nodes. If it is not a case, you can create a new connection between nodes by clicking and dragging a mouse cursor from a node's black dot to the another node's black dot. If you want to remove a connection between two nodes, you can double click the arrow.

[[File:NodeConnecting.png]]

The root node can only have one child node (in our case selector node). A selector node can have any number of child nodes. We decided to pick selector as the first node because of its property of finishing the run on the first child which returns '''SUCCESS''' or '''RUNNING''' states. You can find more about it in the tutorial mentioned at the beginning of this tutorial.
Let's add two new nodes to the selector node. The first one will be a sequence node and the latter will be an action node. You can tell the application to automatically reorganize the layout of the nodes by clicking the "Refresh layout" button in the upper menu.

[[File:SelectorNode.png]]

Let's change the action of our newly added action node. Double click the first value field in the action node (by default, in barbarian behavior, it has "Attack" value set), and in the pop-up window change the value of the field to "Idle". At this point it would be great to change names of selector and sequence nodes to more meaningful ones. Let's call them '''MainSelector''' and '''JumpingSequence''' respectively. You can change the name of these nodes by double clicking their value fields (by default they have values '''Selector''' and '''Sequence'''). Changing names of selectors and sequences does not affect how a behavior works. It is simply a cosmetic change that increases the readability of a behavior.

[[File:JumpingSequence.png]]

The next step is to design our jumping sequence. What we want our bot to achieve is to find a player character in some radius, get to the found character and jump next to him. Barbarian behavior exposes a set of actions that can help us with making it happen. The very first action that we are going to add to the jumping sequence is going to be ''"FindCharacterInRadius"''. It has two parameters:
#''radius'' - which specifies in what radius the action should look for a player character,
#''output'' player character - in this field you can specify under what name the found player character will be stored in the memory. This name can be used in different actions as an input parameter (if type is supported of course).
In our case we want to look for a player in radius of 30 meters and we will save it under "Player" name in the memory.
The second node in the jumping sequence is going to be ''"SetTarget"'' action node. ''"SetTarget"'' has input parameter which is the name of some target stored in the memory. In our case it is found character from ''"FindCharacterInRadius"'' action. Therefore, provide it with the "Player" value.

[[File:JumpSequenceActions.png]]

After setting the target, we have to get to the character. To do this, we will add a selector node with two child action nodes to the jumping sequence. Let's name the selector node '''GetToTarget'''. The first action of the '''GetToTarge''' selector should be ''"IsAtTargetPosition"'' action that takes as a parameter the tolerable area radius around the target. The second action is ''"GotoTarget"'' which makes the character move towards the target. GetToTarget selector ensures that we will get to our target.
The last child node of the jumping sequence is a decorator node. There can be two types of decorators: a timer decorator (it activates after the specified amount of time passes) and a counter decorator (it activates after the specified call count has been reached). We are going to pick the timer decorator node by changing first value of a decorator node to ''"TimerLogic"''. In the second value, let's choose '''RUNNING''' which stands for the default value that decorator returns. The last one specifies value dependent on the decorator type. In the case of a timer decorator, it is time in milliseconds after which the decorator will run its child node. Let's provide it with the value of 1500 ms. You can find more about decorators and related concepts under this link. As a decorator can only have one child, we are going attach "Jump" action node to it.
As the final modification to our behavior tree, let's mark the '''JumpingSequence''' node as a memorable (by clicking on the ''"Is memorable"'' box). It means that while doing the jumping sequence we want to focus only on the node that was processed last time. Below you can see the final state of the behavior tree:

[[File:EntireTreeView.png]]

Now you can safely export the behavior tree to a file. Click the ''"Export tree"'' button in the upper menu and select which behavior you want to export. The next step is to specify a file to which you want to save selected behaviors. In the next tutorial I will present you how to create a mod with our jumping barbarian!

==Creating bot==
===Introduction===
In the previous tutorial we have created jumping barbarian behavior. Now we are going add it to the game. The bot will appear in the g-screen menu under Bots tab, so you will be able to spawn him at any location.

===Creating definition===
In order to make our bot available in the game, we have to define a bot definition. Let's create a new file ''MyBots.sbc'' in which we will define our previously created behavior.

<pre>
<?xml version="1.0"?>
<Definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Bots>
<Bot xsi:type="MyObjectBuilder_HumanoidBotDefinition">
<Id>
<TypeId>MyObjectBuilder_HumanoidBot</TypeId>
<SubtypeId>NormalBarbarian</SubtypeId>
</Id>
<DisplayName>DisplayName_Bots_Barbarian</DisplayName>
<Icon>Textures\GUI\Icons\SpawnBarbarian.dds</Icon>
<BotModel>Medieval_barbarian</BotModel>
<BotBehaviorTree Subtype="BarbarianBehavior" />
<BehaviorType>Barbarian</BehaviorType>
<TargetType>Humanoid</TargetType>
<StartingItem Subtype="Mace" />
<Public>true</Public>
<AvailableInSurvival>false</AvailableInSurvival>
<InventoryContentGenerated>true</InventoryContentGenerated>
<InventoryContainerTypeId>
<TypeId>ContainerTypeDefinition</TypeId>
<SubtypeId>BarbarianBagContent</SubtypeId>
</InventoryContainerTypeId>
<FactionTag>BARB</FactionTag>
</Bot>
</Bots>
</Definitions>
</pre>

The definition above will tell the game what kind of bot we want to create. The bot is going to use jumping behavior. The next step is to a create toolbar item for the g-screen menu.

<pre>
<?xml version="1.0" encoding="utf-8"?>
<Definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<CategoryClasses>
<Category>
<Id>
<TypeId>GuiBlockCategoryDefinition</TypeId>
<SubtypeId/>
</Id>
<DisplayName>DisplayName_Category_Bots</DisplayName>
<Name>Bots</Name>
<Public>true</Public>
<ItemIds>
<string>BotDefinition/JumpingBarbarian</string>
</ItemIds>
</Category>
</CategoryClasses>
</Definitions>
</pre>

Now let's create a new folder '''JumpingBehavior''' and create '''Data''' subfolder inside of it. Then, move all three files (''JumpingBehavior.sbc'', ''MyBots.sbc'' and ''Categories.sbc'') to '''Data''' folder. Another step is to copy our JumpingBehavior folder to ''Roaming/MedievalEngineers/Mods'' folder. Now you can open the game and add our mod. As stated before, you will find the jumping barbarian under '''Bots''' tab in g-screen menu. Enjoy!

Link:
http://steamcommunity.com/sharedfiles/filedetails/?id=413831474

Keen:AI Bots

2017-03-13T16:17:30Z

Lukas:

==Creating behavior==

===Introduction===
This tutorial presents how to create simple behavior for barbarian step by step. The only requirement for this tutorial is to get Medieval Engineers mod SDK which can be found in Steam library under Tool section. For curious readers, tutorial about behavior trees and the behavior tree tool can be found under this address.

===Jumping barbarian behavior===
In order to create a new behavior, we will need to open the behavior tree tool. It can be accessed from ME mod SDK which you can find in the Tool section on Steam.

[[File:ModSDK.png]]

When you double click Medieval Engineers - Mod SDK, it will open the root folder with tools. In order to open behavior tree tool you need to go to Tools folder and then to VRageEditor folder. In VRageEditor folder, start '''BehaviorTree.bat''' which will open the behavior tree tool.

[[File:BehaviorTreeBat.png]]

The first step is to create a new behavior tree. To do this, click the "New tree" button in the upper left corner of the application. A new window with two fields will pop up in which you can specify the name and the kind of behavior you want to create. In this tutorial we are going to make jumping barbarian behavior, so let's call our new behavior '''JumpingBarbarianBehavior''' and set the ''Behavior'' field to '''Barbarian'''.

[[File:CreateNewTree.png]]

When you click the ''"Create"'' button, the window will be closed and the behavior tree graph area control with the grey background will appear in the behavior tree tool. In this control we will add new nodes and create our AI. On the creation, the control automatically adds the Root node which is the main node of a behavior tree. The orange color of the node signalizes that the node is selected. You can select node by clicking on it with the left mouse button.

[[File:Selection.png]]

Our first and only child of the root node will be selector node. To do it, let's select the root node and click on the "Add node" button in the upper menu. From the pop-up menu pick Selector value and click the Ok button. If you did the steps correctly, a selector node should be added next to the root node. There should be also connection (a black arrow) between two nodes. If it is not a case, you can create a new connection between nodes by clicking and dragging a mouse cursor from a node's black dot to the another node's black dot. If you want to remove a connection between two nodes, you can double click the arrow.

[[File:NodeConnecting.png]]

The root node can only have one child node (in our case selector node). A selector node can have any number of child nodes. We decided to pick selector as the first node because of its property of finishing the run on the first child which returns '''SUCCESS''' or '''RUNNING''' states. You can find more about it in the tutorial mentioned at the beginning of this tutorial.
Let's add two new nodes to the selector node. The first one will be a sequence node and the latter will be an action node. You can tell the application to automatically reorganize the layout of the nodes by clicking the "Refresh layout" button in the upper menu.

[[File:SelectorNode.png]]

Let's change the action of our newly added action node. Double click the first value field in the action node (by default, in barbarian behavior, it has "Attack" value set), and in the pop-up window change the value of the field to "Idle". At this point it would be great to change names of selector and sequence nodes to more meaningful ones. Let's call them '''MainSelector''' and '''JumpingSequence''' respectively. You can change the name of these nodes by double clicking their value fields (by default they have values '''Selector''' and '''Sequence'''). Changing names of selectors and sequences does not affect how a behavior works. It is simply a cosmetic change that increases the readability of a behavior.

[[File:JumpingSequence.png]]

The next step is to design our jumping sequence. What we want our bot to achieve is to find a player character in some radius, get to the found character and jump next to him. Barbarian behavior exposes a set of actions that can help us with making it happen. The very first action that we are going to add to the jumping sequence is going to be ''"FindCharacterInRadius"''. It has two parameters:
#''radius'' - which specifies in what radius the action should look for a player character,
#''output'' player character - in this field you can specify under what name the found player character will be stored in the memory. This name can be used in different actions as an input parameter (if type is supported of course).
In our case we want to look for a player in radius of 30 meters and we will save it under "Player" name in the memory.
The second node in the jumping sequence is going to be ''"SetTarget"'' action node. ''"SetTarget"'' has input parameter which is the name of some target stored in the memory. In our case it is found character from ''"FindCharacterInRadius"'' action. Therefore, provide it with the "Player" value.

[[File:JumpSequenceActions.png]]

After setting the target, we have to get to the character. To do this, we will add a selector node with two child action nodes to the jumping sequence. Let's name the selector node '''GetToTarget'''. The first action of the '''GetToTarge''' selector should be ''"IsAtTargetPosition"'' action that takes as a parameter the tolerable area radius around the target. The second action is ''"GotoTarget"'' which makes the character move towards the target. GetToTarget selector ensures that we will get to our target.
The last child node of the jumping sequence is a decorator node. There can be two types of decorators: a timer decorator (it activates after the specified amount of time passes) and a counter decorator (it activates after the specified call count has been reached). We are going to pick the timer decorator node by changing first value of a decorator node to ''"TimerLogic"''. In the second value, let's choose '''RUNNING''' which stands for the default value that decorator returns. The last one specifies value dependent on the decorator type. In the case of a timer decorator, it is time in milliseconds after which the decorator will run its child node. Let's provide it with the value of 1500 ms. You can find more about decorators and related concepts under this link. As a decorator can only have one child, we are going attach "Jump" action node to it.
As the final modification to our behavior tree, let's mark the '''JumpingSequence''' node as a memorable (by clicking on the ''"Is memorable"'' box). It means that while doing the jumping sequence we want to focus only on the node that was processed last time. Below you can see the final state of the behavior tree:

[[File:EntireTreeView.png]]

Now you can safely export the behavior tree to a file. Click the ''"Export tree"'' button in the upper menu and select which behavior you want to export. The next step is to specify a file to which you want to save selected behaviors. In the next tutorial I will present you how to create a mod with our jumping barbarian!

==Creating bot==
===Introduction===
In the previous tutorial we have created jumping barbarian behavior. Now we are going add it to the game. The bot will appear in the g-screen menu under Bots tab, so you will be able to spawn him at any location.

===Creating definition===
In order to make our bot available in the game, we have to define a bot definition. Let's create a new file ''MyBots.sbc'' in which we will define our previously created behavior.

<pre>
<?xml version="1.0"?>
<Definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Bots>
<Bot xsi:type="MyObjectBuilder_HumanoidBotDefinition">
<Id>
<TypeId>MyObjectBuilder_HumanoidBot</TypeId>
<SubtypeId>NormalBarbarian</SubtypeId>
</Id>
<DisplayName>DisplayName_Bots_Barbarian</DisplayName>
<Icon>Textures\GUI\Icons\SpawnBarbarian.dds</Icon>
<BotModel>Medieval_barbarian</BotModel>
<BotBehaviorTree Subtype="BarbarianBehavior" />
<BehaviorType>Barbarian</BehaviorType>
<TargetType>Humanoid</TargetType>
<StartingItem Subtype="Mace" />
<Public>true</Public>
<AvailableInSurvival>false</AvailableInSurvival>
<InventoryContentGenerated>true</InventoryContentGenerated>
<InventoryContainerTypeId>
<TypeId>ContainerTypeDefinition</TypeId>
<SubtypeId>BarbarianBagContent</SubtypeId>
</InventoryContainerTypeId>
<FactionTag>BARB</FactionTag>
</Bot>
</Bots>
</Definitions>
</pre>

The definition above will tell the game what kind of bot we want to create. The bot is going to use jumping behavior. The next step is to a create toolbar item for the g-screen menu.

<pre>
<?xml version="1.0" encoding="utf-8"?>
<Definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<CategoryClasses>
<Category>
<Id>
<TypeId>GuiBlockCategoryDefinition</TypeId>
<SubtypeId/>
</Id>
<DisplayName>DisplayName_Category_Bots</DisplayName>
<Name>Bots</Name>
<Public>true</Public>
<ItemIds>
<string>BotDefinition/JumpingBarbarian</string>
</ItemIds>
</Category>
</CategoryClasses>
</Definitions>
</pre>

Now let's create a new folder '''JumpingBehavior''' and create '''Data''' subfolder inside of it. Then, move all three files (''JumpingBehavior.sbc'', ''MyBots.sbc'' and ''Categories.sbc'') to '''Data''' folder. Another step is to copy our JumpingBehavior folder to ''Roaming/MedievalEngineers/Mods'' folder. Now you can open the game and add our mod. As stated before, you will find the jumping barbarian under '''Bots''' tab in g-screen menu. Enjoy!

Keen:AI Bots

2017-03-13T15:59:00Z

Lukas: Created page with "==Creating behavior== ===Introduction=== This tutorial presents how to create simple behavior for barbarian step by step. The only requirement for this tutorial is to get Med..."

File:EntireTreeView.png

2017-03-13T15:58:36Z

Lukas:

Tree View

File:JumpSequenceActions.png

2017-03-13T15:56:41Z

Lukas:

Actions of the jumping sequence

File:JumpingSequence.png

2017-03-13T15:55:01Z

Lukas:

Adding a jumping sequence

File:SelectorNode.png

2017-03-13T15:53:19Z

Lukas:

Selector Node

File:NodeConnecting.png

2017-03-13T15:52:25Z

Lukas:

How to connect nodes

File:Selection.png

2017-03-13T15:51:37Z

Lukas:

How Selection highlight works

File:CreateNewTree.png

2017-03-13T15:44:08Z

Lukas:

Shows how to create a new behavior tree

File:BehaviorTreeBat.png

2017-03-13T15:40:57Z

Lukas:

Shows what to start to activate behavior tool

File:ModSDK.png

2017-03-13T15:38:52Z

Lukas:

Shows where to find ME mod SDK

Keen:Planet Modding - Full Guide

2017-03-13T15:33:55Z

Lukas: /* Biomes definitions modding - trees, plants and bots */

==Introduction==
Hello fellow Medieval Engineers!
I would like to present you with a guide that will help you understand how we created planets at Keen Software House and how to mod your own into the game.
Feel free to use/alter company owned files for your Medieval Engineers mods.

So let's get to modding!

==Recommended Software==
# Microsoft Visual Studio - or Notepad++ (Link[notepad-plus-plus.org]) - for opening files with .sbc extension where we have definitions for every feature in the game.
# Adobe Photoshop - for editing material and heightmap textures
# World Machine Professional - for heightmap easier creation (much more realistic looking terrain, without manual work)

(Basic Edition is also available, but the max resolution output is limited to 512x512 pixels)
http://www.world-machine.com

===Advice===
We would like to mention one thing before you get into modding planets:
For your own sake we recommend you to load either PlanetTemplate or EarthLikeModExample and test/edit all the things there, so you get to know the system and how everything works.

After that you can create your own from scratch. This is entirely up to you.

==General modding principles - how to make any mod==
I will explain again basic principles of how mods are applied.

All of our vanilla source files are all saved in a folder called content in your *game folder. If no mods are assigned to a world that you are loading, game uses only files from this content folder but if there are mods, game loads also files from mod adding more content or potentially rewriting vanilla content based on content of the mod’s folder. Mod is nothing else but a folder with another files.
Mod files are stored in mods folder on your computer , and if you are using them for the first time, they are downloaded from workshop first time you try to load/connect to a world with those mods.
Mod folder: C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Mods
===Opening mod and examining mods content===
When you open Mods folder, you will see mods as files with .sbm extension. But they are really just folders and to examine them, all you have to do is rewrite the extension from .sbm to .rar and then you can open them with rar and examine content.
Mods are not listed with their names, but with their steam id number. To find specific mod, you have to go to the mods workshop page

Examining other mods similar to your idea is a fast way to learn.
Example:

<NoWiki>*</NoWiki>By default this is SteamLibrary\steamapps\common\MedievalEngineers\Content. You can also get there if you go to steam library(same place where you start the game), right-click Medieval Engineers, select properties, local files and finally click on “browse local files”.
==Materials modding==
In case you are thinking about making your own trees and voxel materials, we have some good news for you!

There are two separate guides that you can follow to make your own stuff.

General modding guide - get started

===Voxel material modding===
http://steamcommunity.com/sharedfiles/filedetails/?id=568406623

==Planet Size==
Planet size is defined in a scenarios.sbc. Every time you click on create new world in the game it uses scenario definition to create a new safe file. Although this scenario definition is not moddable, you can still use it to create a world and share the world itself on the workshop.

First go to where you have Medieval Engineers source files and find Data folder (SteamLibrary\steamapps\common\MedievalEngineers\Content\Data\Scenarios.sbx)

==All planet related files overview and where to find them==
To summarize how planet modding in ME works, we can say this:
We use 2 types of textures and then we define how the game should interpret those textures in definitions. One texture is heightmap that is used just for generating terrain shape, another one is used to place everything else on the planet (ores, trees and plants, bots).
[[File:Diagram.png|1024px|center]]

==Material Texture modding==
Material texture is used to store information about location of various planet surface features. These features are surface materials, biomes (trees, bots, plants,..etc) and where you can find ore. Each one of these uses one color channel. Surface materials use red channel. Biomes use green. Ores are in blue channel.
We use 6 material textures (2048x2048) for each planet. You can find all our material textures here: Content\Data\PlanetDataFiles.
Each planet has its own folder. The folder has to have the same name as the planet.

[[File:MaterialMapBreakdown.jpg|512px]]

Illustration of how are the material textures connected to each other:

[[File:Planet Material Texture Order.jpg|512px]]

====The process of material texture creation is really simple. You have two options:====
=====Copy an existing map to your folder and overwrite the green channel and edit them to your liking=====
This is highly recommended to avoid errors!
=====Create a new: step by step in Photoshop=====
#Set both width and height to 2048 pixels
#(for smaller planets this can also be 1024 or less, but all textures need to have the same resolution! Even the heightmap)
#Set resolution - Pixels/Inch to 72.
#Set colour mode to RGB Colour - 8bit
#Now start painting with the pencil tool on each RGB Channel separately.
#Never on all three at once! (It will F. up everything - trust me).

===Surface voxel material definitions modding - grass, sand, snow===

[[File:RedChannel.jpg|22px|frameless]]

Surface “voxel materials” refers to what you know as grass, soil, stone.. We use red channel of the material texture to set where all the terrain appears. Then you need to write definitions in the Content\Data\PlanetGenerator.sbc to tell game which voxel should appear at specific red channel value.
Example of the definition of road:
<pre>
<ComplexMaterials>
<MaterialGroup Name="Road" Value="67">
<Rule>
<Layers>
<Layer Material="Soil" Depth="2"/>
</Layers>
<Slope Min="0" Max="90"/>
</Rule>
</MaterialGroup>
</ComplexMaterials>
</pre>
Example of corresponding material texture with road:

[[File:RoadMaterialTextureExample.png|512px]]

====Complex materials====
Complex materials definition allows to paint the map with a set of “voxel coloring rules”. Meaning that one color value in red channel can color terrain with different voxels based on rules like slope, longitude or latitude and height. (So with our road example)
<pre>
<MaterialGroup Name="Forest_Grass" Value="120">
<Rule>
<Layers>
<Layer Material="Woods_grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="0" Max="25"/>
<Latitude Min="-180" Max="180"/>
<Longitude Min="-180" Max="180"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="25" Max="45"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Rocks_grass" Depth="2"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="45" Max="55"/>
</Rule>
</MaterialGroup>
</pre>
This definition says what voxels should be generated in spots, that are painted with red channel value of 120.
The rules in this definition will lead to following:
Flat lands (up to 20 degrees slope) will have Wood grass 1 m thick, soil will be right under the WoodGrass up to 5 m depth and there will be stone underneath the soil.
In places with medium slope, there is Grass instead of WoodGrass. And in slopes from 45 to 55 there is rocks grass 2 m thick with stone right away under it.
With this technology, we can make the color react on its own to terrain bumps or even position on planet. This saves lots of meticulous painting with heightmap.

<Layer Material="Woods_grass" Depth="1"/>
Material refers to voxelmaterial definition. (You can find it in Content\Data\VoxelMaterials.sbc). Depth means how deep should the material go under ground.
<Slope Min="0" Max="25"/>
Slope of the terrain in degrees.
<Latitude Min="-180" Max="180"/>
Latitude in degrees. 0 degree is an equator.
<Longitude Min="-180" Max="180"/>
Longitude in degrees. 0 is in the middle of front planetary texture. (Fareon Kingdom)

===Biomes definitions modding - trees, plants and bots===
[[File:GreenChannel.jpg|frameless|22px]]

Biomes refers to everything that is spawned on top of the planet. We use green channel of the material texture to set where all the terrain features appear. Then you need to write definitions in the Content\Data\Environment\ProceduralEnvironments.sbc to tell game which environment item should appear at specific green channel value. Also you need to assign Environment to planet in the Content\Data\PlanetGenerator.sbc
First make/modify environment:
Go to Content\Data\Environment\ProceduralEnvironments.sbc
Assign environment to a planet
Go to Content\Data\PlanetGenerator.sbc and find definition of the planet you want your environment to be on. Then assign the environment to the planet this way:
<pre>
<Environment>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>Earth Environment</SubtypeId>
</Environment>
</pre>
SutypeId refers to the name of the environment from:
Content\Data\Environment\ProceduralEnvironments.sbc

====Procedural World Environment definition====
This definition defines where will the environmental items spawn and with which density. (note: bots are also considered environmental item). Best way to explain how procedural environment is working is to imagine that it puts spots on entire surface of a planet. And when you start defining trees, bots and bushes, the spots get “reserved” by these categories based on how many of those should appear in the world according to your mod.
Spots are always different for each single planet.
In order to mod the procedural environment, mod our “Earth Environment” definition. Or create your own but if you do, don’t forget to also mod PlanetGeneratorDefinition, so that planet has your new procedura environment assigned to it.

====Definition elements explained point by point:====
<pre>
<Definition xsi:type="MyObjectBuilder_ProceduralWorldEnvironment">
<Id>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>Earth Environment</SubtypeId>
</Id>
</pre>
This part of definition is called ID. It says what type of definition this is <TypeID> and unique name of that definition <SubtypeID>.

<pre>
<MaxSyncLod>1</MaxSyncLod>
</pre>
This line defines how far away from player are the environmental items updating. This is important feature for optimization.

<pre>
<SectorSize>40</SectorSize>
</pre>
This is size of the environmental sector. It is a different sector than the claimable areas by players. It sets size of one environmental sector.

<pre>
<ItemsPerSqMeter>0.17</ItemsPerSqMeter>
</pre>
The line sets overall maximum density of all environmental items. To return to analogy i used in the introduction, this number increases the amount of spots on the planet that are reserved for all environmental items.

<pre>
<ScanningMethod>Random</ScanningMethod>
</pre>

<pre>
<ItemTypes Type="MyObjectBuilder_EnvironmentItemTypesDefinition" Subtype="Default"/>
</pre>
This sets which types of environmental items are used in this procedural environment definition. This guide explains what are Environmental item types in the very next section.

<ItemGroup Density=".017" Name="Bots" LodStart="1" LodEnd="1">
<Mapping>
<Material>Woods</Material>
<Item Type="Bot" Subtype="Deer"/>
</Mapping>
<Mapping>
<Biome>60</Biome>
<Height Min="0" Max"1"/>
<Latitude Min="-180" Max"180"/>
<Longitude Min="-180" Max"180"/>
<Slope Min="0" Max"1"/>
<Item Type="Bot" Subtype="Deer" Density="0.9"/>
<Item Type="Bot" Subtype="Barbarian" Density="0.1"/>
</Mapping>
</ItemGroup>
Item group is used to organize and better manage mappings. Mappings are definitions that actually add the environment items in the world. It is important to set Density correctly. Density (Density=".017") sets how many of the procedurally generated spots on the planet will be assigned to environmental items from this group. The name (Name="Bots") is only for naming purposes within definition and has no impact on the game. LodStart="1" and LodEnd="1" control how far from the player will the items appear.
<Biome>60</Biome> This section means that Items within this mapping will only appear on spaces that are painted with green channel value 60 on the material map.
<Material>Woods</Material> This means that the environmental items will only appear in the woods.
<Height Min="0" Max"1"/> Sets in which altitude should these environmental items appear. If this parameter is missing, items spawn in full range (Min="0" Max"1")
<Latitude Min="-180" Max"180"/> Sets at which latitude do the environment items spawn. If this parameter is missing, items spawn in full range (Min="-180" Max"180")
<Longitude Min="-180" Max"180"/> Sets at which longitude the environment items spawn. If this parameter is missing, items spawn in full range (Min="-180" Max"180")
<Slope Min="0" Max"90"/> Sets at which slopes the environment items spawn. If this parameter is missing, items spawn in full range (Min="0" Max"90")

<ItemGroup Density=".085" Name="Trees" LodStart="-1" LodEnd="1">...</ItemGroup>
<ItemGroup Density=".36" Name="Small Items" LodStart="0" LodEnd="0">...</ItemGroup>
There are 2 more item Groups. I will not go into details, since it is not
</Definition>

====Environment items====
We learned how to assign environments to planets and how to mod environments themselves by changing densities and environment items. But we still don't know how to make the environment items themselves. Guides for those can be found on following links.

If you want to mod trees:

If you want to mod bushes and plants:

If you want to mod bots:

====EnvironmentItemTypesDefinition====
Here you define various types of items. Currently we have these types: Tree, Gatherable, Farmable, Static and Bot. Before you add any item, you must make sure it fits within these types of environment items or you created a new type for them.
<Definition xsi:type="MyObjectBuilder_EnvironmentItemTypesDefinition">
<Id Type="MyObjectBuilder_EnvironmentItemTypesDefinition" Subtype="Default"/>
<Item Name="Tree">...</Item>
<Item Name="Gatherable">...</Item>
<Item Name="Farmable">... </Item>
<Item Name="Static">...</Item>
<Item Name="Bot">...</Item>
</Definition>

EnvironmentItemTypes
<Item Name="Tree">
<ProxyActivationLod>0</ProxyActivationLod>
<Provider Type="MyObjectBuilder_ProceduralEnvironmentModuleDefinition" Subtype="Growable"/>
<Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Gatherable" />
<Proxy Type="MyObjectBuilder_EnvironmentModuleProxyDefinition" Subtype="Cuttable" />
</Item>
Available proxy and providers:
Proxy Subtype="Gatherable"
This line adds ability to all environmental items of this type to use action “Gatherable”. Keep in mind that the tree itself has to be setup properly in order for this to work.
Proxy Subtype="Cuttable" />
This line adds ability to all environmental items of this type to use action “Cuttable”. Keep in mind that the tree itself has to be setup properly in order for this to work.
<ProxyActivationLod>0</ProxyActivationLod>
This line says from which lod is the game logic attached to the environmental item. (when set on 0 only trees very close to you become “gatherable” and “cuttable”). This way we don’t use game logic on environmental items that couldn’t be used anyway and game is better optimized thanks to that.
Provider Subtype="Growable”
This line adds ability to all environmental items of this type to grow. Keep in mind that the tree itself has to be setup properly in order for this to work.
Provider Subtype="Farmable”
This line adds ability to all environmental items of this type to be farmable. Keep in mind that the tree itself has to be setup properly in order for this to work.
Provider Subtype="Static”
This line adds basically adds items that do nothing. They are just visual props. Like some of our fern bushes.
Provider Subtype="BotSpawner”
It is important that all environmental item types that will contain some bots have botspawner

===Ores definitions modding===
[[File:BlueChannel.jpg|frameless|22px]]

Ores are placed using blue channel of the material texture to set where should ore deposits appear. When your ore deposits are painted on the material map, you need to define what ores will be there. Go to Content\Data\Environment\ProceduralEnvironments.sbc to tell game which ore should appear at specific blue channel value.

<pre>
<OreMappings>
<Ore Value="130" Type="IronOre_RichYield" Start="3" Depth="7" TargetColor="#b7340a" ColorInfluence="15 "/>
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
<Ore Value="110" Type="IronOre_PoorYield" Start="2" Depth="5" TargetColor="#a76a41" ColorInfluence="15" />
</OreMappings>
</pre>
The section you need to use is Ore Mappings.
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
Value refers to blue channel value on material texture.
Type refers to name of a voxel material from Content\Data\VoxelMaterials.sbc.
Start is depth at which the ore deposit starts. Depth is how deep under ground it goes.
TargetColor is color that will be used to color surface above the ore.
ColorInfluence sets strenght of coloring.

==Working with RGB==
Ok, Steam won't let me share that link to a small RGB Photoshop tutorial with you, so just go to photoshopessentials.com and search for RGB and it's the first link.

This is a simple tutorial to explain you what we mean when we say Grayscale ID, which can also be called the RGB values
(each channel only has one number per shade of that color ranging from 0 to 255).

Here I have loaded a Biome map texture front_mat texture which is used on the Vanilla EarthLike planet.

[[File:RGBChannels.jpg|frameless]]These are the RGB channels as you can see them in Photoshop.

NOTE: Edit each RGB channel separately!

Always use the pencil tool to paint pixels.
The brush tool has a falloff that has different values and you will not have control over those!
[[File:Color Picker.jpg|thumb]]

You can see if the numbers are correct on the top right of the screen if you have your workspace set to Essentials.

Here you will enter the values you want to paint.
Make sure you check them before saving, sometimes Photoshop can move the number +-1 (personal experience).

It doesn't matter if the numbers match, just as long as you have the correct value (ID) in the correct channel!

==Height-maps modding - terrain shape, roads==
As mentioned in 2. Required software, we used the program World Machine to create our heightmaps and then we did some minor tweaks by hand (like putting in lakes and desert areas)

First, to explain how our planet heightmaps work:
We have 6 textures that connect together (image below). Our standard resolution for a big 120km planet is 2048x2048. But you can use a lower one if you want to.

To create your own heightmap, the best action would be to find a heightmap here:
C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\PlanetDataFiles

Then you can open the texture and place yours/paint yours on a new layer, flatten the image and save it as a .PNG

There are other options for you also!
You can visit[terrain.party] this site and download a heightmap from a real place on Earth. You can even set the size of the map (maximum is 60 km). And then you can edit it further in Photoshop.
You can try painting it yourself in Photoshop (or any other similar software, like Gimp).
You can also just try Googling for heightmaps and try which one suits you the best (keep in mind the resolution must be 512,1024, 2048!)
However you get your heightmap, always keep in mind how each texture of the heightmap is connected, so the seams need to fit together. Bad texture connection is very visible in the game.
Here is an image of how the textures are connected:

[[File:Planet Material Texture Order.jpg|512px]]

===Roads===
We created roads using World Machine tools. You can find guide how to do that in between World Machine tutorials.

==Atmosphere==
[[File:View Image.jpg|1024px]]

Here, you will find everything you ever wanted to know about Atmosphere Settings in Space Engineers but were afraid to ask, my dear friend. So without any further ado. Let’s start with the “Atmosphere” settings window which you access in-game by hitting F12 -> Render Button -> Atmosphere checkbox. The new Atmosphere settings window opens immediately on the right side of the screen, showing a bunch of tricky sliders.

[[File:Cloud Layers Definition.jpg|1024px]]

If your pants are still dry, and if by any chance you’re still reading this, let us assure you that everything is pretty simple and not so scary as it may seem when you first open it. So let’s start with the brief and really quick explanation of what every slider or group of sliders are meant for. Lastly, remember that to alter any setting in this Window you have to hold “Alt” on your keyboard.

Enable Atmosphere (checkbox) – Well, as Captain Obvious immediately states to us – it just enables or disables Atmosphere on a planet and nothing more.

Time of Day (slider) – Controls rotation of the Sun around a Planet. You’re given the Power to decide which time of day it is now. Cool isn’t it?

Pick Planet (Button) – In situations when you have more than one planet in your world, you may want to alter the settings of each planet’s atmosphere individually. So this button enables you to immediately pick the current atmosphere values of the planet you’re currently on. For example, fly to the Moon, press “Pick planet” button and you will get corresponding atmosphere values of that planet to play with. Fly back to Earth or any alien planet, and do the same to alter atmosphere settings of these planets. Yay!

Rayleigh Scattering R,G and B (sliders) – Group of three sliders which control the main, overall color of the Atmosphere. It’s that atmosphere color which is going to be seen from outer space and on the ground too! If you want to make your atmosphere alien green or purple – these are the correct set of sliders to play with. Each slider controls corresponding R,G or B (0-255) values. Pretty straightforward.

[[File:Atmosphere Settings.jpg|512px]]

Mie Scattering R, G and B (sliders) – Group of three sliders to control the color of the Sun glow. It would be weird to have Green atmosphere and Red sun glow right? You would normally want to set it to yellow or something light green or so. But it’s your choice you can make any color you want. But please note that in order to have noticeable results you have to actually HAVE that glow around your sun. This setting is called “Mie Height” and it has to be set to a fairly high value otherwise it wouldn’t be too prominent. We will talk about this “Mie Height” setting in a minute. No worries.

The following three sliders are complementary and play well together. It means you have to find a good balance setting them which is quite easy:

Rayleigh Height Surface (slider) – Controls the thickness of the atmospheric layer when you’re on or near planet’s Surface. For example. You normally want atmosphere layer to be fairly thick to cover high points of the planet’s surface like mountains and high hills while you’re on the ground because you have actual high picks in your surface geometry which you have to cover. Otherwise you would see black space when you’re on the high mountain. But technically, when you’re leaving the planet’s atmosphere all of these high peaks and mountains are starting to slowly collapse vertically forming a smooth spherical shape of the planet, if they wouldn’t - we would have planets looking like a spiky balls with mountain peaks sticking out in all directions. That’s why when all the high peaks are collapsed to the ground to form a perfect sphere - we are left with abnormally thick and wrong looking atmospheric layer thickness when observed from the outer space. How to fix this?! That’s where “Rayleigh Height Space” slider comes into play, as it controls the thickness of the atmospheric layer seen from outer space.

Rayleigh Height Space (slider) – Controls the thickness of atmospheric layer when you observing the planet from outer space. Like it was said earlier, settings for atmosphere thickness when you’re on the Surface and when you’re in an outer Space can’t be same and normally you want to make it much thinner when it is seen from outer space like it’s in real world. Refer to the following Pic to get better understanding.

Rayleigh Transition (slider) – Ok, so now that we have set the width of the planetary atmosphere for both - when we’re on the Surface and when we’re observing it from outer space, it is time to decide at which distance to switch between two, right? So that’s exactly what this slider does – sets the exact value at which distance that transition must happen. You can play around with this value to find the best setting, just remember that the main goal is to have this transition as smooth as possible, fortunately it’s super easy to achieve. Just make sure that while you’re on the ground and standing on a highest point you still see some atmosphere color (like Blue color in earthlike planets) ,and just about when you start to see the whole planet on your way to the outer space, switch it to the thinner (Rayleigh Height Space) version.

Mie Height (slider) – Controls the size of the outer glow effect of the Sun. Like it was said earlier, when you’re setting your color of the Glow effect via “Mie Scattering RGB” sliders, this particular setting (Mie Height) must be set to a fairly high value otherwise you won’t see it as there won’t be any glow. Look, you can’t change the color of a non-existing thing, soldier. Dismissed!

Sun size (slider) – Controls the size of the Sun.. What else did you expect from it?!

Sea Floor modifier (slider) – Defines the lowest (starting) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer starts. It depends on your planet’s relief, your lowest and highest peaks. Adjust individually for each planet. You’ll “feel” the right value immediately.

Atmosphere Top Modifier (slider) – Defines the highest (ending) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer stops. It depends on your planet’s relief. Adjust individually for each planet. You’ll “feel” the right value immediately. But normally you want this value to be set pretty high.

Intensity (slider) – Actually it should be called “Fog Intensity” as it’s exactly what it’s responsible for but I hope it will be changed by some coder guys eventually J. Controls the amount or intensity of the fog while you’re on or near the planet’s surface (doesn’t do anything when you’re in outer space).

Fog Intensity (slider) – And this, should be actually called “Fog Distance”. It controls the distance fog actually covers. The higher this value – more objects in front of view are covered with fog. (doesn’t do anything when you’re in outer space).

Restore (Button) – Ok, just in case you screw everything up, you always have a chance to revert all the changes you’ve made by clicking this Restore button, soldier! Very convenient isn’t it?!

==Atmosphere 2/2==
Ok, now that we got acquainted with all Atmosphere settings and know how they work, it is time for us to actually change a few settings to alter the look of our Atmosphere! Now the fun part begins. Let’s say that we want to change the color of Earthlike planet’s atmosphere from its natural Blue color to the Green one, so it looks more “alienish”. Please note, that all atmosphere settings are stored in “PlanetGeneratorDefinitions.sbc” file and they are NOT replaced even when you change these values in game and make a save. If you want to change those values you have to change them directly in the code of the “PlanetGeneratorDefinitions.sbc” file only! The system reads those atmosphere values from this file every time you’re loading your worlds.

But how for God’s sake would you know which values are correct and really desirable to put them in the code? This is really simple. You just adjust your atmosphere settings to your liking right in the game, and when you’re done and happy with it, you just copy those values into the code (you can screen grab the in-game view with Atmosphere Settings window or just write them down manually, not a big deal) But to paste those values in the code, you have to know WHERE to paste it, right? You don’t just randomly paste numbers into the code, do you? You may hurt yourself!

So please open “PlanetGeneratorDefinitions.sbc” file in any decent text editor and find the following line:
<pre>
<SubtypeId>EarthLike</SubtypeId>
</pre>
It’s a name or identifier of a planet, and since it’s named Earthlike, we know for sure that below are the definitions related to Earthlike planet. Cool! Now just scroll down to the part where you will see a commented (inactive) line of code which goes like:



Or alternatively, just Ctrl+F to find the following line. You must see something similar to this:

[[File:Atmosphere definition.jpg|512px]]

So here as you can see everything is pretty self-explanatory. Except a few lines that are just named differently in the code. If you want your atmosphere to “remember” the settings you have made you have to enter those values here to the corresponding lines. The following schematic pic shows dependencies between the code lines and the slider names in Atmosphere Settings window quite clearly:
(Click to enlarge)

[[File:In-game Atmosphere Debug Input.jpg|1024px]]

Now let’s just change the blue color of the atmosphere to orange. As you remember, group of three RGB sliders named “Rayleigh Scattering” are responsible for changing the main color of the Atmosphere. So why wait?

[[File:Mars-Like Atmosphere.jpg|1024px]]

Spectacular right? Now, let’s change the sun glow color “Mie Scattering RGB” to an orange tint too. It could stay the same yellow of course but let’s change it so you could have an idea. Remember to press “Alt” on your keyboard while you’re dragging those sliders.

[[File:Another Red Atmosphere.jpg|1024px]]

Ok, now it’s more orange but we have to increase the glow effect a bit to see it more prominently. And as we remember, the glow size control is “Mie Height” slider. Crank it up from 30 to 50.

Good, the glow effect became more prominent. Looking nice isn’t it? Of course, you can continue adjusting it and come up with really crazy results, but if you’re ok with what we already have, then just write down all the values that you currently have in your Atmosphere Settings window on the right or screenshot them and paste into any image editor for your reference. And back in the code editor, just enter those values into corresponding tags in the code and save it:

[[File:CloseUp Atmosphere definition.jpg|512px]]

That’s it! From now on, every time you load up your world with Earthlike planet in it, or spawn Earthlike planet, the atmosphere on it will be exactly the way you adjusted it via Atmosphere Settings! The God himself must have been using something like this we suppose..

[[File:Mars-like Atmosphere Final.jpg|1024px]]

==Clouds==
The first thing that should (probably) come in to your mind when you finally learn how to tweak Atmosphere settings, is probably how to change the look of the Clouds! Because, normally, when you change the color of the atmosphere you would like the clouds color to be relatively close to the Atmosphere color. In our Atmosphere guide (if you read it) we were sharing some knowledge about changing the look of the Atmosphere. We made it orange which is kind of cool all on its own, but what really draws our attention and not in a very good way – is the color of the clouds. As you can see they’re white which is looking wrong isn’t it? In an orange atmosphere environment you would expect orange or yellow clouds right? So that’s what we’ll be doing in a minute – changing the look of our cloud layer and getting to know their under-the-hoods.

Like with Atmosphere settings, the Clouds setting are stored in the same “PlanetGeneratorDefinitions.sbc” file located in KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Data and are individual for each planet. Usually we base our code lines so the Cloud definitions come right after Atmosphere definitions which makes it very convenient to search for. Just open your “PlanetGeneratorDefinitions.sbc” file in any decent advanced text editor and search for this commented (inactive) line of code:



Note: you can download the DDS files from here[mirror.keenswh.com]

[[File:Cloud Layers Definition.jpg|1024px]]

That’s where all the cloud settings for particular planet are stored. The following picture is a brief breakdown of cloud definitions:

Basically, the structure of placing clouds on any planet is as follows:
<pre>
<CloudLayers>
<CloudLayer>
Blah Blah Blah Beautiful Clouds Blah Blah Blah
</CloudLayer>
</CloudLayers>
</pre>
So, as you can see everything is super easy. Simply put, <CloudLayers> tags are meant for global separation of Cloud definitions from other code definitions and are here just to define where the code for the clouds start, while <CloudLayer> tags (again, don’t mistake with CloudLayers) are the actual cloud layers and each pair of these tags (<CloudLayer>…</CloudLayer>) define the look and behavior of each cloud layer. As Captain Obvious states - The more <CloudLayer> pairs you have.. umm - the more cloud layers you will have!

For example. You can have more than one Cloud layer, to simulate even more complex cloud patterns than you initially had in your texture file! And that’s when <InitialRotation> and <RotationAxis> tags come into play. You can assign values to these tags for each Cloud layer individually thus having the cloud spheres to be initially rotated and spinning on different angles creating more interesting and natural cloud patterns. So you basically just stack them this way:
<pre>
<CloudLayers>
<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>
</CloudLayers>
</pre>

That’s it! Now you have three Cloud Layers! And of course you can do it for the Far and the Near cloud layers as well.

Your main cloud color texture must be 4096x2048px RGB file saved in DDS format without alpha as “CloudName_cm.dds file” and it must contain only the color information of your clouds. For Alphamask file please create a separate file of the same 4096x2048px dimensions containing only Alpha mask, make it a greyscale file, save as DDS luminance format and name it “CloudName_Alphamask.dds”. Back in the code, in <texture> tags you just write “Cloudname.dds”, no worries - the engine will identify required “cm” and “alphamask” files itself, just make sure both files are in the correct folder. (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Models\Environment\Sky).

As you know, clouds that are seen from the outer space and the clouds that you see through your window don’t look the same because of the huge differences in scales in both cases. That’s why we have two types of clouds on each planet. First one (commented as “Far layer” in the code) – the clouds that you see from the outer space. They usually look like NASA satellite orbital photo shots.

[[File:Clouds.jpg|1024px]]

And the Second one (commented as “Near layer” in the code) – the clouds that are seen when you’re on the ground or close to it. These should look like a significantly zoomed version of the first ones - more detailed, wispy and more individual. Like the ones you used to see in the sky every day. Refer to the picture.

[[File:LargeClouds.jpg|1024px]]

Now, how to actually separate these two types of cloud layers and to make them come in layers – one after the other. This is very simple too. The maximum overall Altitude (height) of our atmosphere layer is 2. So we have to set up our cloud layers in a tricky way, so that when we’re in outer space - we would see the “Far layer” clouds ONLY, and as we’re getting lower (approaching the ground), on a particular altitude (height) smoothly switch to the “Near layer” clouds and have the “Far layer” clouds hidden. Sounds crazy but it will become clear if you look at the following pic:

[[File:CloudLayerDiagram.jpg|1024px]]

As you can see things are really self-explanatory here too. By setting the Start and End values in <FadeOutRelativeAltitude..> you basically create a vector, the starting point of which is infinity which means anything below this start point will be constant value, thus – making it possible to set the Far layer to be seen from outer space (values greater than 2), and preventing Near cloud layer from being seen - because it is set to fade out on 1.6. And vice versa – when you’re on the ground, you won’t see Far layer clouds layer because it faded out on much higher distance of 1.4. Not so hard right? Of course you can alter and tweak those values to your liking depending on the planets height maps/relief to get the desired transition between Far and Near cloud layers.

So now that we’re empowered with this knowledge, the only thing we’re left to do is to actually change the color of the clouds from white to yellow color so our clouds look more natural in an orange Atmosphere environment. As we remember, our clouds are consisting of two texture files – a file containing color information (usually just a plain color) and a file with an alpha mask only. We already know that the “Far layer” clouds (the ones seen from space) use “EarthFarClouds_cm.dds” texture file and the “Near layer” clouds use “Landsky_texture_cm.dds”. How we know that? It’s written in <texture> </texture> definitions, remember?

[[File:CloudTextureRoute.jpg|512px]]

Great! So now just open “EarthFarClouds_cm.dds” and the “Landsky_texture_cm.dds” and fill both files with plain yellow color and save them!

[[File:YellowCloud Texture.jpg|1024px]]

Start the game and spawn an Earthlike planet and voila! You got perfect yellow clouds!

[[File:Scenery With Yellow Clouds.jpg|1024px]]

==Planet ambient sounds modding - day/night biome sounds==

Sound rules are in the Content\Data\PlanetGeneratorDefinitions.sbc file. Here you can set different sounds based on player’s location or daytime on the planet.
<pre>
<SoundRule>
<Height Min="0" Max="0.5"/>
<Latitude Min="55" Max="80"/>
<SunAngleFromZenith Min="0" Max="180"/>
<EnvironmentSound>AmbIcelandDay</EnvironmentSound>
</SoundRule>
</pre>
Height stands for where you want the sound to play at the height of the heightmap (0-7200m). It is always +12% of the planet's diameter. 0 is from the the lowest start of the surface to 1.0 which is 100% of the surface (maximum height).
Latitude means angle from the equator. Therefore 0 to 20 will mean that this sound will mostly play in the desert area, 20-50 is mostly the green forest area, and so on.
SunAngleFromZenith NEEDS MORE INFO!!!
EnvironmentSound this is the name of the sound you want to use.

You can find all available sounds in Audio.sbc (location shown below) Here you will also put your own ambient sound with your own custom name.

How to implement custom ambient sound

All Ambient sounds are stored here:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Audio\ARC\AMB\

If you want your own sounds, they should be a loop sound, and on average should not be bigger than +-5 MB.
The supported format is: .xwm but .wav can also work, even though its file size is usually a lot bigger (not recommended).

Once your audio is done, implement it here in this file:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\Audio.sbc
<pre>
<Sound>
<Id>
<TypeId>MyObjectBuilder_AudioDefinition</TypeId>
<SubtypeId>AmbAlienForestDay</SubtypeId>
</Id>
<Category>AMB</Category>
<MaxDistance>100</MaxDistance>
<Volume>0.2</Volume>
<Loopable>true</Loopable>
<Waves>
<Wave Type="D2">
<Loop>ARC\AMB\AmbAlienForestDayLoop2d.xwm</Loop>
</Wave>
</Waves>
</Sound>
</pre>
Here edit only what is highlighted, otherwise I cannot guarantee that it will work properly!
<SubtypeId> This is how you will name your AMB sound, keeping in mind upper and lower case letters. Do not use _ or other special characters!
<Volume> This is self explanatory I hope.
<Loop> Here you just need to lead the definition to your file. ARC/AMB/ is the default location, so do not change that.
But if you want, you can make another folder in AMB for your custom ambient sounds for better organisation.

==In-game map modding==
Maps in Medieval Engineers are generated based on terrain and buildings on it. This means that they will work for any modded planet in their default form. That being said, the way map is generated is also fully moddable.

We definitions for map are located in Content\Data\Screens\MapDefinition.sbc. To mod maps you will have to alter/add definitions in this file, all vanilla textures for maps can be found in Content\Textures\GUI\Map. Feel free to use/alter any of them for creation of mods for Medieval Engineers.
Map content modding (Friend/foe display, tax notifications,...
In Medieval Engineers there are 2 view modes of map. Kingdom view which is showing entire kingdom and region view which is zoomed part of a kingdom map. Region is 1kmx1km large on 10 km diameter planet. Both views display different elements.
What is shown in these views depends on what layers it contains
<pre>
<Definition xsi:type="MyObjectBuilder_PlanetMapDefinition">
<Id Type="MyObjectBuilder_PlanetMapDefinition" Subtype="Main"/>
<BackgroundGenerator Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
<RegionView>
<Layers>...</Layers>
</RegionView>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</Definition>
</pre>
BackgroundGenerator refers to a definition of background texture that serves as a background on top of which all the map elements are placed.
<pre>
<RegionView>
<Layers>...</Layers>
</RegionView>
</pre>
The three dots in middle represent layers of elements that show in region view. List and description of all layers is in next section of this document.
<pre>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</pre>
The three dots in middle represent layers of elements that show in kingdom view. List and description of all layers is in next section of this document.
(I did not Kingdom view in its expanded form because it would take up too much space.)

===Layers description===
<pre><Layer xsi:type="MyObjectBuilder_MapBackgroundLayer" /></pre>
This layer draws the background. As generated based on chosen background definition.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaDevelopmentLayer">
<Threshold BlockCount="10" Sprite="Textures\GUI\Map\SmallGrid.png"/>
<Threshold BlockCount="30" Sprite="Textures\GUI\Map\MediumGrid.png"/>
<Threshold BlockCount="60" Sprite="Textures\GUI\Map\LargeGrid.png"/>
</Layer>
</pre>
This layer displays icons based on amount of blocks there is in an area. You can set the block thresholds, or mod the textures. It is also possible to add more thresholds. 80x80 px, png.

[[File:Smallest Settlement.png|150px|frameless]]
[[File:Medium Settlement.png|150px|frameless]]
[[File:LargestSettlement.png|150px|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_RegionFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for region, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaOwnershipLayer">
<AlliedBgColor Hex="#806464FF" />
<PlayerBgColor Hex="#8064FF64" />
<EnemyBgColor Hex="#80DC6415" />
</Layer>
</pre>
This layer defines color overlay over map areas based on ownership. You can mod which color is used for allies, your own areas or for enemies
<pre>
<Layer xsi:type="MyObjectBuilder_AreaUpkeepLayer">
<TaxIcon>Textures\GUI\Map\TaxIcon.png</TaxIcon>
</Layer>
</pre>
This layer displays tax icon on areas that belong to you and require tax payment soon. Texture is 80x80 pixels, png.
[[File:Taxes.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapPositionLayer">
<LocalPlayerImage>Textures\GUI\Map\PlayerPosition.png</LocalPlayerImage>
<OtherPlayersImage>Textures\GUI\Map\AllyPosition.png</OtherPlayersImage>
</Layer>
</pre>
PlanetMapPositionLayer displays player icon above area where they are.
[[File:Ally.png|frameless]]
[[File:Player.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_ActionTrackingLayer">
<ActionImage>Textures\GUI\Map\Action.png</ActionImage>
</Layer>
</pre>
Shows icon over an area on map with fighting / destruction.
[[File:AttackedArea.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_CurrentMapSelectionLayer">
<SelectionImage>Textures\GUI\Map\MapSelection.dds</SelectionImage>
</Layer>
</pre>
This is highlight of a region, that player selected with his mouse.
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapGridLayer">
<GridColor R="0" G="0" B="0" A="228"/>
</Layer>
</pre>
This layer sets which color is the grid drawn.
<pre>
<Layer xsi:type="MyObjectBuilder_KingdomFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for kingdom, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_RegionOwnershipLayer">
<PlayerIcon>Textures\GUI\Map\PlayerLandIcon.png</PlayerIcon>
<AllyIcon>Textures\GUI\Map\AllyLandIcon.png</AllyIcon>
<EnemyIcon>Textures\GUI\Map\EnemyLandIcon.png</EnemyIcon>
<PlayerAllyIcon>Textures\GUI\Map\PlayerAllyLandIcon.png</PlayerAllyIcon>
<PlayerEnemyIcon>Textures\GUI\Map\PlayerEnemyLandIcon.png</PlayerEnemyIcon>
<AllyEnemyIcon>Textures\GUI\Map\AllyEnemyLandIcon.png</AllyEnemyIcon>
<PlayerAllyEnemyIcon>Textures\GUI\Map\PlayerAllyEnemyLandIcon.png</PlayerAllyEnemyIcon>
</Layer>
</pre>
RegionOwnershipLayer generates textures used to express ownership on regional map.

===Background generator (trees, mountains, roads,...)===
Map background is where all the trees, mountains, hills are drawn. It is also capable of coloring map based on what is in planet’s material map (this is how we make roads for example).
All settings for map background are in MedievalMapBackgroundDefinition. The definition also in Content\Data\Screens\MapDefinition.sbc. I will go through various parts of the definition.

<pre><Id Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
Type of the definition says that this map background definition. Subtype is name of this specific background definition. If create your own background with unique subtype
Make sure you create your own background with unique subtype

<DrawHeightmap>false</DrawHeightmap>
When set on “true” planet’s heightmap is drawn under the map.
<Resolution>4096</Resolution><
Sets resolution of the generated in-game map.

<Features>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</Features>

<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</Definition>
</pre>
===Map Coloring===
You can use colors in material or biome map of a planet to appear on the game map. (roads for example). You define map coloring in a node called ”Features”. The coloring uses colors from planet material texture. You can learn more about material texture in biomes modding and surface material modding.
<pre>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
</pre>
This specific feature is used for painting roads on map with dark brown color. In Color you define which color will be the in-game map colored. Material=”67” decides where will be the color applied and refers to a red channel value on planet material texture.
<pre>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</pre>
This specific feature is used for painting forests on map with opaque brown. In Color you define which color will be the in-game map colored. Biome=”60” decides where will be the color applied and refers to a green channel value on planet material texture.

===Sprites===
Medieval Engineers map can also place sprites on map based on terrain shape. All the sprites are on one texture
<pre>
<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</pre>

[[File:AtlasCoordinateUsage.png|512px]]

Note: Illustrates how sprite is defined on our spritesheet. Example sprite:
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />

==Voxel color overlay modding==
We have a cool tech that enables us to color-shift color of almost any item in the game. Currently we are using it for trees(adds small color variations to the same model of a tree) and voxels above iron deposits.
==Fast travel settings modding==
In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around.
In this section of the guide we will show you how to mod which sectors are blocked.
There are 2 ways you can go about it:
===Generate automatically based on terrain shape===
Game is capable of creating fast travel map on its own based on height and terrain steepness. It is possible to mod thresholds for both height and steepness.
You will find the thresholds in Content\Data\Game\FastTravel.sbc. In a MyObjectBuilder_TerrainReachabilityProviderDefinition.
<RiseThreshold> - Sets min. terrain height change which will cause that area is unreachable.
<HeightThreshold> - Sets height of terrain after which area is unreachable, if it goes over this value. Range is 0 - 1.

If there are texture overrides in the definition, you have to erase them in order for the parameters to take effect. Texture overrides are nodes that are called in this fashion: <OverrideNAMEOFFACE>. You will learn more about these overrides in the next part of Fast travel modding.

===Creating fast travel texture override===
If you want to have full control over which areas are reachable and which are not regardless of terrain, you can create a simple texture on which you mark unreachable areas.

The texture is 80x80 pixels, RGB 8 bit. Black pixels forbid entrance.

When you have the texture, select route to it in the definition:
<pre><OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward></pre>
Reachability definition example:
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>
<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>
<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
</Definition>
</pre>
This definition would generate fast travel reachability everywhere, except for front planet face (Fareon kingdom) where fast travel reachability is created based on your texture.

===Development reachability===
Claimable area size, border highlight, contested timer modding
Size of the area and highlight properties are moddable as well.

===Area borders highlight===
<NeutralColor R="225" G="32" B="0" A="64" /> - Set color of an unowned territory
<SelfColor R="0" G="255" B="0" A="64" /> - Sets color of area border owned by you
<AliedColor R="65" G="105" B="225" A="64" /> - Sets color of area border that belongs to allies
<EnemyColor R="225" G="32" B="0" A="64" /> - Sets color of area border that is hostile
<WallSettings Depth="15" Rise="3" SegmentCount"71" End="115" /> - Changes shape of the border. Depth sets how deep is border submerged. Rise sets how tall is the border.
<Fade Start="71" End="115" /> - This sets at which point the border starts to fade.
Contested timer
When players claim area with claimblock, area goes to a “contested” phase for some amount of time, in this phase other players can still attempt to build their own claim block and claim the area. This time is moddable.
Content\Data\Game\SessionComponents.sbc contains definition called MyObjectBuilder_AreaOwnershipSystemDefinition. To mod this value, add this definition to your mod with changed value of <ContestedTimeInMinutes> parameter.

==Permissions modding - what is/isn’t allowed to do in claimed areas==
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.
Description of available actions to set permissions for:
Name=”Build” -> block placement permissions
Name=”Repair” -> Repairing/building already placed blocks
Name=”Deconstruct” -> Deconstructing
Name=”QuickDeconstruct” -> Faster deconstruction
Name=”VoxelEdit” -> Mining or shoveling
Name=”Destroy” -> Damage with hand weapons
Name=”Interaction” -> Chest opening, door opening
Name=”ClaimBlockInteraction” -> ClaimblockGui

===List of available Groupnames:===
Groupname: “Owner” -> Player who owns area
Groupname: “Allies” -> Mostly faction members of owner of the area
Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
Groupname: “Enemies” -> Players in factions that are hostile to your faction

==Compass modding==
It is possible to mod visual look of an in-game compass. All definitions of compass are stored in Content\Data\GUI\CompassDefinition.sbc. Our textures for compass are in Content\Textures\GUI\Compass folder if you want to check out how they look or use them in your mod.
===Creating compass texture atlas and setting coordinates for its elements===
Just like with map sprites, we save main compass elements on a single texture, then define parts of it using pixel coordinates. First setup origin point, then add width and height of the rectangle
Example texture coordinates for top part of the compass:
[[File:CompassTextureCoordinates.png|1024px]]
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>

===Explanation of compass definition line by line===
<pre><Texture>Textures/GUI/Compass/compass.png</Texture> </pre>
Route to a texture atlas.
<pre><KingdomIcon>Textures/GUI/Compass/Icon-Kingdom.png</KingdomIcon> </pre>
Route to icon symbolizing a kingdom.
<pre><Padding>7</Padding></pre>
Padding is added vertically between the top and bottom textures and the edges of the contents of the compass.
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>
Rectangle in the texture that contains the top part.
<pre><BottomCrop X="0" Y="0" Width="0" Height="0"/></pre>
Rectangle in the texture that contains the bottom part.
<pre><BackgroundCrop X="0" Y="64" Width="512" Height="64"/></pre>
Rectangle in the texture that contains the background.
<pre><ArrowCrop X="0" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the little marker used for elements that are drawn and have no icon.
<pre><MarkerCrop X="32" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the interval bars drawn every few degrees.
<pre><ShadowCrop X="64" Y="128" Width="80" Height="32" Left="8" Right="8"/></pre>
<pre><ShadowPadding Left="12" Top="8" Right="12" Bottom="8"/></pre>
Rectangle in the texture that contains the text shadows. Shadow is 3-Sliced, meaning the texture is split in three parts: [left|middle|right]
The sizes of left and right define the cropping lines that split the texture into three. The Sides are then always kep proportional as the texture is scaled.
<pre><VisibleRange>200</VisibleRange></pre>
Visible range in degrees.
<pre><Width>700</Width></pre>
Width in reference resolution pixels.
<pre><FontSize>1.1</FontSize></pre>
Scale of the font based on default.
<pre><VerticalOffset>0.065</VerticalOffset></pre>
Vertical offset from the top of the screen. 0 = top of the screen, 1 is the bottom. Compass is centered around this position.
<pre>
<TagStyles>
<TagStyle Tag="ClaimArea" Style="Bellow" MaxCharacters="15" Ellipsis="true"/>
<TagStyle Tag="Cardinal" Style="Above" MaxCharacters="1"/>
<TagStyle Tag="Kingdom" Style="Bellow"/>
</TagStyles>
</pre>
This section adds tags that are visible on compass and in which style. Currently we have 3 types of tags. Claim area - shows your claimed area on the compass, Kingdom tag shows kingdoms and Cardinal tag shows cardinal points (North, South,...). Each tag’s visual appearance is defined in tag/waypoint definition. Styles defines where should the text appear. Available styles: Center, IconOnly, NotShown, Bellow, Above.

===Explanation of Waypoint/Tag definition===
<pre>
<Definition xsi:type="MyObjectBuilder_WaypointDefinition">
<Id Type="MyObjectBuilder_WaypointDefinition" Subtype="Kingdom"/>
<IconPath>Textures/GUI/Compass/IconKeep.png</IconPath>
<Color R="255" G="255" B="255" A="255"/>
</Definition>
</pre>
IconPath contains path to the texture of kingdom icon. Color defines color of the text that is shown with the icon. (Example: Fareon, [[File:Kingdom Icon.png|thumb]])
===Compass texture vs in-game look comparison===
Texture:

[[File:Compas Texture with Zones.png|1024px]]

In-game look:

[[File:In-gameCompassZones.png|1024px]]
<NoWiki>*</NoWiki>note that background crop and bottom crop are not used in vanilla (empty opaque texture)

==Indestructible grids==
There is a way how to make some buildings in your save indestructible. We are using this feature for starting area buildings. Some you guys might make a good use of this feature in your pre-made worlds.

Currently, only way how to do this is to make edits to an existing save file. So you can only use it for world modding.

===Making indestructible cubegrids in existing safe===
Goal is to open world’s safe file in a text editor, find your cubegrid in it and add this tag to it: <DestructibleBlocks>true</DestructibleBlocks>.

#Find your save file. By default save files are stored in C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Saves
#Open folder with your save and find file called SANDBOX_0_0_0_.sbs. This file can be opened with any text editor you prefer.
#In the SANDBOX_0_0_0_.sbs search for the cubegrid name of the building you want to make indestructible. (use find/search function in your text editor, or you will grow old before you find it)
#Tip: To find out name of a cubegrid, create blueprint of the building. The name that the building saves as in your blueprint screen is the name of the cubegrid.
#You should find the name in tags called: <DisplayName>YOURCUBEGRIDNAME</DisplayName>
#Under the name, add following tag with setting set to false: <DestructibleBlocks>false</DestructibleBlocks>
#If you followed instruction, the indestructibility tag is now in node called <MyObjectBuilder_EntityBase> and not in any of its child nodes.
#Save the edited file.
#Load the save and test destructibility
#It worked! Enjoy
#It is still destructible. Go to point 1.

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding/Fast Travel

2017-03-13T14:51:48Z

Lukas: Lukas moved page Official Content/ Fast Travel to Official Content/Fast Travel without leaving a redirect

Keen:Planet Modding/Area Permissions

2017-03-13T13:42:35Z

Lukas: Protected "Official Content/Areas Permissions" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

==Permissions modding - what is/isn’t allowed to do in claimed areas==
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.

===Description of available actions to set permissions for:===
#Name=”Build” -> block placement permissions
#Name=”Repair” -> Repairing/building already placed blocks
#Name=”Deconstruct” -> Deconstructing
#Name=”QuickDeconstruct” -> Faster deconstruction
#Name=”VoxelEdit” -> Mining or shoveling
#Name=”Destroy” -> Damage with hand weapons
#Name=”Interaction” -> Chest opening, door opening
#Name=”ClaimBlockInteraction” -> ClaimblockGui

===List of available Groupnames:===

#Groupname: “Owner” -> Player who owns area
#roupname: “Allies” -> Mostly faction members of owner of the area
#Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
#Groupname: “Enemies” -> Players in factions that are hostile to your faction

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding/Area Permissions

2017-03-13T13:42:03Z

Lukas: Lukas moved page Official Content/ Areas Permissions to Official Content/Areas Permissions without leaving a redirect

Keen:Planet Modding/In-game map

2017-03-13T11:29:15Z

Lukas:

==In-game map modding==
Maps in Medieval Engineers are generated based on terrain and buildings on it. This means that they will work for any modded planet in their default form. That being said, the way map is generated is also fully moddable.

We definitions for map are located in Content\Data\Screens\MapDefinition.sbc. To mod maps you will have to alter/add definitions in this file, all vanilla textures for maps can be found in Content\Textures\GUI\Map. Feel free to use/alter any of them for creation of mods for Medieval Engineers.
Map content modding (Friend/foe display, tax notifications,...
In Medieval Engineers there are 2 view modes of map. Kingdom view which is showing entire kingdom and region view which is zoomed part of a kingdom map. Region is 1kmx1km large on 10 km diameter planet. Both views display different elements.
What is shown in these views depends on what layers it contains
<pre>
<Definition xsi:type="MyObjectBuilder_PlanetMapDefinition">
<Id Type="MyObjectBuilder_PlanetMapDefinition" Subtype="Main"/>
<BackgroundGenerator Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
<RegionView>
<Layers>...</Layers>
</RegionView>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</Definition>
</pre>
BackgroundGenerator refers to a definition of background texture that serves as a background on top of which all the map elements are placed.
<pre>
<RegionView>
<Layers>...</Layers>
</RegionView>
</pre>
The three dots in middle represent layers of elements that show in region view. List and description of all layers is in next section of this document.
<pre>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</pre>
The three dots in middle represent layers of elements that show in kingdom view. List and description of all layers is in next section of this document.
(I did not Kingdom view in its expanded form because it would take up too much space.)

==Layers description==
<pre><Layer xsi:type="MyObjectBuilder_MapBackgroundLayer" /></pre>
This layer draws the background. As generated based on chosen background definition.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaDevelopmentLayer">
<Threshold BlockCount="10" Sprite="Textures\GUI\Map\SmallGrid.png"/>
<Threshold BlockCount="30" Sprite="Textures\GUI\Map\MediumGrid.png"/>
<Threshold BlockCount="60" Sprite="Textures\GUI\Map\LargeGrid.png"/>
</Layer>
</pre>
This layer displays icons based on amount of blocks there is in an area. You can set the block thresholds, or mod the textures. It is also possible to add more thresholds. 80x80 px, png.

[[File:Smallest Settlement.png|150px|frameless]]
[[File:Medium Settlement.png|150px|frameless]]
[[File:LargestSettlement.png|150px|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_RegionFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for region, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaOwnershipLayer">
<AlliedBgColor Hex="#806464FF" />
<PlayerBgColor Hex="#8064FF64" />
<EnemyBgColor Hex="#80DC6415" />
</Layer>
</pre>
This layer defines color overlay over map areas based on ownership. You can mod which color is used for allies, your own areas or for enemies
<pre>
<Layer xsi:type="MyObjectBuilder_AreaUpkeepLayer">
<TaxIcon>Textures\GUI\Map\TaxIcon.png</TaxIcon>
</Layer>
</pre>
This layer displays tax icon on areas that belong to you and require tax payment soon. Texture is 80x80 pixels, png.
[[File:Taxes.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapPositionLayer">
<LocalPlayerImage>Textures\GUI\Map\PlayerPosition.png</LocalPlayerImage>
<OtherPlayersImage>Textures\GUI\Map\AllyPosition.png</OtherPlayersImage>
</Layer>
</pre>
PlanetMapPositionLayer displays player icon above area where they are.
[[File:Ally.png|frameless]]
[[File:Player.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_ActionTrackingLayer">
<ActionImage>Textures\GUI\Map\Action.png</ActionImage>
</Layer>
</pre>
Shows icon over an area on map with fighting / destruction.
[[File:AttackedArea.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_CurrentMapSelectionLayer">
<SelectionImage>Textures\GUI\Map\MapSelection.dds</SelectionImage>
</Layer>
</pre>
This is highlight of a region, that player selected with his mouse.
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapGridLayer">
<GridColor R="0" G="0" B="0" A="228"/>
</Layer>
</pre>
This layer sets which color is the grid drawn.
<pre>
<Layer xsi:type="MyObjectBuilder_KingdomFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for kingdom, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_RegionOwnershipLayer">
<PlayerIcon>Textures\GUI\Map\PlayerLandIcon.png</PlayerIcon>
<AllyIcon>Textures\GUI\Map\AllyLandIcon.png</AllyIcon>
<EnemyIcon>Textures\GUI\Map\EnemyLandIcon.png</EnemyIcon>
<PlayerAllyIcon>Textures\GUI\Map\PlayerAllyLandIcon.png</PlayerAllyIcon>
<PlayerEnemyIcon>Textures\GUI\Map\PlayerEnemyLandIcon.png</PlayerEnemyIcon>
<AllyEnemyIcon>Textures\GUI\Map\AllyEnemyLandIcon.png</AllyEnemyIcon>
<PlayerAllyEnemyIcon>Textures\GUI\Map\PlayerAllyEnemyLandIcon.png</PlayerAllyEnemyIcon>
</Layer>
</pre>
RegionOwnershipLayer generates textures used to express ownership on regional map.

==Background generator (trees, mountains, roads,...)==
Map background is where all the trees, mountains, hills are drawn. It is also capable of coloring map based on what is in planet’s material map (this is how we make roads for example).
All settings for map background are in MedievalMapBackgroundDefinition. The definition also in Content\Data\Screens\MapDefinition.sbc. I will go through various parts of the definition.

<pre><Id Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
Type of the definition says that this map background definition. Subtype is name of this specific background definition. If create your own background with unique subtype
Make sure you create your own background with unique subtype

<DrawHeightmap>false</DrawHeightmap>
When set on “true” planet’s heightmap is drawn under the map.
<Resolution>4096</Resolution><
Sets resolution of the generated in-game map.

<Features>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</Features>

<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</Definition>
</pre>
==Map Coloring==
You can use colors in material or biome map of a planet to appear on the game map. (roads for example). You define map coloring in a node called ”Features”. The coloring uses colors from planet material texture. You can learn more about material texture in biomes modding and surface material modding.
<pre>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
</pre>
This specific feature is used for painting roads on map with dark brown color. In Color you define which color will be the in-game map colored. Material=”67” decides where will be the color applied and refers to a red channel value on planet material texture.
<pre>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</pre>
This specific feature is used for painting forests on map with opaque brown. In Color you define which color will be the in-game map colored. Biome=”60” decides where will be the color applied and refers to a green channel value on planet material texture.

==Sprites==
Medieval Engineers map can also place sprites on map based on terrain shape. All the sprites are on one texture
<pre>
<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</pre>

[[File:AtlasCoordinateUsage.png|512px]]

Note: Illustrates how sprite is defined on our spritesheet. Example sprite:
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding/In-game map

2017-03-13T11:28:18Z

Lukas: /* Sprites */

Keen:Planet Modding/In-game map

2017-03-13T11:28:00Z

Lukas: Created page with "==In-game map modding== Maps in Medieval Engineers are generated based on terrain and buildings on it. This means that they will work for any modded planet in their default fo..."

==In-game map modding==
Maps in Medieval Engineers are generated based on terrain and buildings on it. This means that they will work for any modded planet in their default form. That being said, the way map is generated is also fully moddable.

We definitions for map are located in Content\Data\Screens\MapDefinition.sbc. To mod maps you will have to alter/add definitions in this file, all vanilla textures for maps can be found in Content\Textures\GUI\Map. Feel free to use/alter any of them for creation of mods for Medieval Engineers.
Map content modding (Friend/foe display, tax notifications,...
In Medieval Engineers there are 2 view modes of map. Kingdom view which is showing entire kingdom and region view which is zoomed part of a kingdom map. Region is 1kmx1km large on 10 km diameter planet. Both views display different elements.
What is shown in these views depends on what layers it contains
<pre>
<Definition xsi:type="MyObjectBuilder_PlanetMapDefinition">
<Id Type="MyObjectBuilder_PlanetMapDefinition" Subtype="Main"/>
<BackgroundGenerator Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
<RegionView>
<Layers>...</Layers>
</RegionView>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</Definition>
</pre>
BackgroundGenerator refers to a definition of background texture that serves as a background on top of which all the map elements are placed.
<pre>
<RegionView>
<Layers>...</Layers>
</RegionView>
</pre>
The three dots in middle represent layers of elements that show in region view. List and description of all layers is in next section of this document.
<pre>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</pre>
The three dots in middle represent layers of elements that show in kingdom view. List and description of all layers is in next section of this document.
(I did not Kingdom view in its expanded form because it would take up too much space.)

==Layers description==
<pre><Layer xsi:type="MyObjectBuilder_MapBackgroundLayer" /></pre>
This layer draws the background. As generated based on chosen background definition.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaDevelopmentLayer">
<Threshold BlockCount="10" Sprite="Textures\GUI\Map\SmallGrid.png"/>
<Threshold BlockCount="30" Sprite="Textures\GUI\Map\MediumGrid.png"/>
<Threshold BlockCount="60" Sprite="Textures\GUI\Map\LargeGrid.png"/>
</Layer>
</pre>
This layer displays icons based on amount of blocks there is in an area. You can set the block thresholds, or mod the textures. It is also possible to add more thresholds. 80x80 px, png.

[[File:Smallest Settlement.png|150px|frameless]]
[[File:Medium Settlement.png|150px|frameless]]
[[File:LargestSettlement.png|150px|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_RegionFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for region, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaOwnershipLayer">
<AlliedBgColor Hex="#806464FF" />
<PlayerBgColor Hex="#8064FF64" />
<EnemyBgColor Hex="#80DC6415" />
</Layer>
</pre>
This layer defines color overlay over map areas based on ownership. You can mod which color is used for allies, your own areas or for enemies
<pre>
<Layer xsi:type="MyObjectBuilder_AreaUpkeepLayer">
<TaxIcon>Textures\GUI\Map\TaxIcon.png</TaxIcon>
</Layer>
</pre>
This layer displays tax icon on areas that belong to you and require tax payment soon. Texture is 80x80 pixels, png.
[[File:Taxes.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapPositionLayer">
<LocalPlayerImage>Textures\GUI\Map\PlayerPosition.png</LocalPlayerImage>
<OtherPlayersImage>Textures\GUI\Map\AllyPosition.png</OtherPlayersImage>
</Layer>
</pre>
PlanetMapPositionLayer displays player icon above area where they are.
[[File:Ally.png|frameless]]
[[File:Player.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_ActionTrackingLayer">
<ActionImage>Textures\GUI\Map\Action.png</ActionImage>
</Layer>
</pre>
Shows icon over an area on map with fighting / destruction.
[[File:AttackedArea.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_CurrentMapSelectionLayer">
<SelectionImage>Textures\GUI\Map\MapSelection.dds</SelectionImage>
</Layer>
</pre>
This is highlight of a region, that player selected with his mouse.
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapGridLayer">
<GridColor R="0" G="0" B="0" A="228"/>
</Layer>
</pre>
This layer sets which color is the grid drawn.
<pre>
<Layer xsi:type="MyObjectBuilder_KingdomFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for kingdom, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_RegionOwnershipLayer">
<PlayerIcon>Textures\GUI\Map\PlayerLandIcon.png</PlayerIcon>
<AllyIcon>Textures\GUI\Map\AllyLandIcon.png</AllyIcon>
<EnemyIcon>Textures\GUI\Map\EnemyLandIcon.png</EnemyIcon>
<PlayerAllyIcon>Textures\GUI\Map\PlayerAllyLandIcon.png</PlayerAllyIcon>
<PlayerEnemyIcon>Textures\GUI\Map\PlayerEnemyLandIcon.png</PlayerEnemyIcon>
<AllyEnemyIcon>Textures\GUI\Map\AllyEnemyLandIcon.png</AllyEnemyIcon>
<PlayerAllyEnemyIcon>Textures\GUI\Map\PlayerAllyEnemyLandIcon.png</PlayerAllyEnemyIcon>
</Layer>
</pre>
RegionOwnershipLayer generates textures used to express ownership on regional map.

==Background generator (trees, mountains, roads,...)==
Map background is where all the trees, mountains, hills are drawn. It is also capable of coloring map based on what is in planet’s material map (this is how we make roads for example).
All settings for map background are in MedievalMapBackgroundDefinition. The definition also in Content\Data\Screens\MapDefinition.sbc. I will go through various parts of the definition.

<pre><Id Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
Type of the definition says that this map background definition. Subtype is name of this specific background definition. If create your own background with unique subtype
Make sure you create your own background with unique subtype

<DrawHeightmap>false</DrawHeightmap>
When set on “true” planet’s heightmap is drawn under the map.
<Resolution>4096</Resolution><
Sets resolution of the generated in-game map.

<Features>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</Features>

<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</Definition>
</pre>
==Map Coloring==
You can use colors in material or biome map of a planet to appear on the game map. (roads for example). You define map coloring in a node called ”Features”. The coloring uses colors from planet material texture. You can learn more about material texture in biomes modding and surface material modding.
<pre>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
</pre>
This specific feature is used for painting roads on map with dark brown color. In Color you define which color will be the in-game map colored. Material=”67” decides where will be the color applied and refers to a red channel value on planet material texture.
<pre>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</pre>
This specific feature is used for painting forests on map with opaque brown. In Color you define which color will be the in-game map colored. Biome=”60” decides where will be the color applied and refers to a green channel value on planet material texture.

===Sprites===
Medieval Engineers map can also place sprites on map based on terrain shape. All the sprites are on one texture
<pre>
<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</pre>

[[File:AtlasCoordinateUsage.png|512px]]

Note: Illustrates how sprite is defined on our spritesheet. Example sprite:
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />

Keen:Planet Modding/Indestructible Buildings

2017-03-13T11:25:07Z

Lukas: Created page with "==Indestructible buildings introduction== There is a way how to make some buildings in your save indestructible. We are using this feature for starting area buildings. Some yo..."

==Indestructible buildings introduction==
There is a way how to make some buildings in your save indestructible. We are using this feature for starting area buildings. Some you guys might make a good use of this feature in your pre-made worlds.

Currently, only way how to do this is to make edits to an existing save file. So you can only use it for world modding.

==Making indestructible cubegrids in existing safe==
Goal is to open world’s safe file in a text editor, find your cubegrid in it and add this tag to it: <DestructibleBlocks>true</DestructibleBlocks>.

#Find your save file. By default save files are stored in C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Saves
#Open folder with your save and find file called SANDBOX_0_0_0_.sbs. This file can be opened with any text editor you prefer.
#In the SANDBOX_0_0_0_.sbs search for the cubegrid name of the building you want to make indestructible. (use find/search function in your text editor, or you will grow old before you find it)
#Tip: To find out name of a cubegrid, create blueprint of the building. The name that the building saves as in your blueprint screen is the name of the cubegrid.
#You should find the name in tags called: <DisplayName>YOURCUBEGRIDNAME</DisplayName>
#Under the name, add following tag with setting set to false: <DestructibleBlocks>false</DestructibleBlocks>
#If you followed instruction, the indestructibility tag is now in node called <MyObjectBuilder_EntityBase> and not in any of its child nodes.
#Save the edited file.
#Load the save and test destructibility
#It worked! Enjoy
#It is still destructible. Go to point 1.

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding - Full Guide

2017-03-13T11:23:00Z

Lukas: /* Indestructible grids */

==Introduction==
Hello fellow Medieval Engineers!
I would like to present you with a guide that will help you understand how we created planets at Keen Software House and how to mod your own into the game.
Feel free to use/alter company owned files for your Medieval Engineers mods.

So let's get to modding!

==Recommended Software==
# Microsoft Visual Studio - or Notepad++ (Link[notepad-plus-plus.org]) - for opening files with .sbc extension where we have definitions for every feature in the game.
# Adobe Photoshop - for editing material and heightmap textures
# World Machine Professional - for heightmap easier creation (much more realistic looking terrain, without manual work)

(Basic Edition is also available, but the max resolution output is limited to 512x512 pixels)
http://www.world-machine.com

===Advice===
We would like to mention one thing before you get into modding planets:
For your own sake we recommend you to load either PlanetTemplate or EarthLikeModExample and test/edit all the things there, so you get to know the system and how everything works.

After that you can create your own from scratch. This is entirely up to you.

==General modding principles - how to make any mod==
I will explain again basic principles of how mods are applied.

All of our vanilla source files are all saved in a folder called content in your *game folder. If no mods are assigned to a world that you are loading, game uses only files from this content folder but if there are mods, game loads also files from mod adding more content or potentially rewriting vanilla content based on content of the mod’s folder. Mod is nothing else but a folder with another files.
Mod files are stored in mods folder on your computer , and if you are using them for the first time, they are downloaded from workshop first time you try to load/connect to a world with those mods.
Mod folder: C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Mods
===Opening mod and examining mods content===
When you open Mods folder, you will see mods as files with .sbm extension. But they are really just folders and to examine them, all you have to do is rewrite the extension from .sbm to .rar and then you can open them with rar and examine content.
Mods are not listed with their names, but with their steam id number. To find specific mod, you have to go to the mods workshop page

Examining other mods similar to your idea is a fast way to learn.
Example:

<NoWiki>*</NoWiki>By default this is SteamLibrary\steamapps\common\MedievalEngineers\Content. You can also get there if you go to steam library(same place where you start the game), right-click Medieval Engineers, select properties, local files and finally click on “browse local files”.
==Materials modding==
In case you are thinking about making your own trees and voxel materials, we have some good news for you!

There are two separate guides that you can follow to make your own stuff.

General modding guide - get started

===Voxel material modding===
http://steamcommunity.com/sharedfiles/filedetails/?id=568406623

==Planet Size==
Planet size is defined in a scenarios.sbc. Every time you click on create new world in the game it uses scenario definition to create a new safe file. Although this scenario definition is not moddable, you can still use it to create a world and share the world itself on the workshop.

First go to where you have Medieval Engineers source files and find Data folder (SteamLibrary\steamapps\common\MedievalEngineers\Content\Data\Scenarios.sbx)

==All planet related files overview and where to find them==
To summarize how planet modding in ME works, we can say this:
We use 2 types of textures and then we define how the game should interpret those textures in definitions. One texture is heightmap that is used just for generating terrain shape, another one is used to place everything else on the planet (ores, trees and plants, bots).
[[File:Diagram.png|1024px|center]]

==Material Texture modding==
Material texture is used to store information about location of various planet surface features. These features are surface materials, biomes (trees, bots, plants,..etc) and where you can find ore. Each one of these uses one color channel. Surface materials use red channel. Biomes use green. Ores are in blue channel.
We use 6 material textures (2048x2048) for each planet. You can find all our material textures here: Content\Data\PlanetDataFiles.
Each planet has its own folder. The folder has to have the same name as the planet.

[[File:MaterialMapBreakdown.jpg|512px]]

Illustration of how are the material textures connected to each other:

[[File:Planet Material Texture Order.jpg|512px]]

====The process of material texture creation is really simple. You have two options:====
=====Copy an existing map to your folder and overwrite the green channel and edit them to your liking=====
This is highly recommended to avoid errors!
=====Create a new: step by step in Photoshop=====
#Set both width and height to 2048 pixels
#(for smaller planets this can also be 1024 or less, but all textures need to have the same resolution! Even the heightmap)
#Set resolution - Pixels/Inch to 72.
#Set colour mode to RGB Colour - 8bit
#Now start painting with the pencil tool on each RGB Channel separately.
#Never on all three at once! (It will F. up everything - trust me).

===Surface voxel material definitions modding - grass, sand, snow===

[[File:RedChannel.jpg|22px|frameless]]

Surface “voxel materials” refers to what you know as grass, soil, stone.. We use red channel of the material texture to set where all the terrain appears. Then you need to write definitions in the Content\Data\PlanetGenerator.sbc to tell game which voxel should appear at specific red channel value.
Example of the definition of road:
<pre>
<ComplexMaterials>
<MaterialGroup Name="Road" Value="67">
<Rule>
<Layers>
<Layer Material="Soil" Depth="2"/>
</Layers>
<Slope Min="0" Max="90"/>
</Rule>
</MaterialGroup>
</ComplexMaterials>
</pre>
Example of corresponding material texture with road:

[[File:RoadMaterialTextureExample.png|512px]]

====Complex materials====
Complex materials definition allows to paint the map with a set of “voxel coloring rules”. Meaning that one color value in red channel can color terrain with different voxels based on rules like slope, longitude or latitude and height. (So with our road example)
<pre>
<MaterialGroup Name="Forest_Grass" Value="120">
<Rule>
<Layers>
<Layer Material="Woods_grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="0" Max="25"/>
<Latitude Min="-180" Max="180"/>
<Longitude Min="-180" Max="180"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="25" Max="45"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Rocks_grass" Depth="2"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="45" Max="55"/>
</Rule>
</MaterialGroup>
</pre>
This definition says what voxels should be generated in spots, that are painted with red channel value of 120.
The rules in this definition will lead to following:
Flat lands (up to 20 degrees slope) will have Wood grass 1 m thick, soil will be right under the WoodGrass up to 5 m depth and there will be stone underneath the soil.
In places with medium slope, there is Grass instead of WoodGrass. And in slopes from 45 to 55 there is rocks grass 2 m thick with stone right away under it.
With this technology, we can make the color react on its own to terrain bumps or even position on planet. This saves lots of meticulous painting with heightmap.

<Layer Material="Woods_grass" Depth="1"/>
Material refers to voxelmaterial definition. (You can find it in Content\Data\VoxelMaterials.sbc). Depth means how deep should the material go under ground.
<Slope Min="0" Max="25"/>
Slope of the terrain in degrees.
<Latitude Min="-180" Max="180"/>
Latitude in degrees. 0 degree is an equator.
<Longitude Min="-180" Max="180"/>
Longitude in degrees. 0 is in the middle of front planetary texture. (Fareon Kingdom)

===Biomes definitions modding - trees, plants and bots===
[[File:GreenChannel.jpg|frameless|22px]]

Biomes refers to everything that is spawned on top of the planet. We use green channel of the material texture to set where all the terrain features appear. Then you need to write definitions in the Content\Data\Environment\ProceduralEnvironments.sbc to tell game which environment item should appear at specific green channel value. Also you need to assign Environment to planet in the Content\Data\PlanetGenerator.sbc
First make/modify environment:
Go to Content\Data\Environment\ProceduralEnvironments.sbc
Assign environment to a planet
Go to Content\Data\PlanetGenerator.sbc and find definition of the planet you want your environment to be on. Then assign the environment to the planet this way:
<pre>
<Environment>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>Earth Environment</SubtypeId>
</Environment>
</pre>
SutypeId refers to the name of the environment from:
Content\Data\Environment\ProceduralEnvironments.sbc

===Ores definitions modding===
[[File:BlueChannel.jpg|frameless|22px]]

Ores are placed using blue channel of the material texture to set where should ore deposits appear. When your ore deposits are painted on the material map, you need to define what ores will be there. Go to Content\Data\Environment\ProceduralEnvironments.sbc to tell game which ore should appear at specific blue channel value.

<pre>
<OreMappings>
<Ore Value="130" Type="IronOre_RichYield" Start="3" Depth="7" TargetColor="#b7340a" ColorInfluence="15 "/>
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
<Ore Value="110" Type="IronOre_PoorYield" Start="2" Depth="5" TargetColor="#a76a41" ColorInfluence="15" />
</OreMappings>
</pre>
The section you need to use is Ore Mappings.
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
Value refers to blue channel value on material texture.
Type refers to name of a voxel material from Content\Data\VoxelMaterials.sbc.
Start is depth at which the ore deposit starts. Depth is how deep under ground it goes.
TargetColor is color that will be used to color surface above the ore.
ColorInfluence sets strenght of coloring.

==Working with RGB==
Ok, Steam won't let me share that link to a small RGB Photoshop tutorial with you, so just go to photoshopessentials.com and search for RGB and it's the first link.

This is a simple tutorial to explain you what we mean when we say Grayscale ID, which can also be called the RGB values
(each channel only has one number per shade of that color ranging from 0 to 255).

Here I have loaded a Biome map texture front_mat texture which is used on the Vanilla EarthLike planet.

[[File:RGBChannels.jpg|frameless]]These are the RGB channels as you can see them in Photoshop.

NOTE: Edit each RGB channel separately!

Always use the pencil tool to paint pixels.
The brush tool has a falloff that has different values and you will not have control over those!
[[File:Color Picker.jpg|thumb]]

You can see if the numbers are correct on the top right of the screen if you have your workspace set to Essentials.

Here you will enter the values you want to paint.
Make sure you check them before saving, sometimes Photoshop can move the number +-1 (personal experience).

It doesn't matter if the numbers match, just as long as you have the correct value (ID) in the correct channel!

==Height-maps modding - terrain shape, roads==
As mentioned in 2. Required software, we used the program World Machine to create our heightmaps and then we did some minor tweaks by hand (like putting in lakes and desert areas)

First, to explain how our planet heightmaps work:
We have 6 textures that connect together (image below). Our standard resolution for a big 120km planet is 2048x2048. But you can use a lower one if you want to.

To create your own heightmap, the best action would be to find a heightmap here:
C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\PlanetDataFiles

Then you can open the texture and place yours/paint yours on a new layer, flatten the image and save it as a .PNG

There are other options for you also!
You can visit[terrain.party] this site and download a heightmap from a real place on Earth. You can even set the size of the map (maximum is 60 km). And then you can edit it further in Photoshop.
You can try painting it yourself in Photoshop (or any other similar software, like Gimp).
You can also just try Googling for heightmaps and try which one suits you the best (keep in mind the resolution must be 512,1024, 2048!)
However you get your heightmap, always keep in mind how each texture of the heightmap is connected, so the seams need to fit together. Bad texture connection is very visible in the game.
Here is an image of how the textures are connected:

[[File:Planet Material Texture Order.jpg|512px]]

===Roads===
We created roads using World Machine tools. You can find guide how to do that in between World Machine tutorials.

==Atmosphere==
[[File:View Image.jpg|1024px]]

Here, you will find everything you ever wanted to know about Atmosphere Settings in Space Engineers but were afraid to ask, my dear friend. So without any further ado. Let’s start with the “Atmosphere” settings window which you access in-game by hitting F12 -> Render Button -> Atmosphere checkbox. The new Atmosphere settings window opens immediately on the right side of the screen, showing a bunch of tricky sliders.

[[File:Cloud Layers Definition.jpg|1024px]]

If your pants are still dry, and if by any chance you’re still reading this, let us assure you that everything is pretty simple and not so scary as it may seem when you first open it. So let’s start with the brief and really quick explanation of what every slider or group of sliders are meant for. Lastly, remember that to alter any setting in this Window you have to hold “Alt” on your keyboard.

Enable Atmosphere (checkbox) – Well, as Captain Obvious immediately states to us – it just enables or disables Atmosphere on a planet and nothing more.

Time of Day (slider) – Controls rotation of the Sun around a Planet. You’re given the Power to decide which time of day it is now. Cool isn’t it?

Pick Planet (Button) – In situations when you have more than one planet in your world, you may want to alter the settings of each planet’s atmosphere individually. So this button enables you to immediately pick the current atmosphere values of the planet you’re currently on. For example, fly to the Moon, press “Pick planet” button and you will get corresponding atmosphere values of that planet to play with. Fly back to Earth or any alien planet, and do the same to alter atmosphere settings of these planets. Yay!

Rayleigh Scattering R,G and B (sliders) – Group of three sliders which control the main, overall color of the Atmosphere. It’s that atmosphere color which is going to be seen from outer space and on the ground too! If you want to make your atmosphere alien green or purple – these are the correct set of sliders to play with. Each slider controls corresponding R,G or B (0-255) values. Pretty straightforward.

[[File:Atmosphere Settings.jpg|512px]]

Mie Scattering R, G and B (sliders) – Group of three sliders to control the color of the Sun glow. It would be weird to have Green atmosphere and Red sun glow right? You would normally want to set it to yellow or something light green or so. But it’s your choice you can make any color you want. But please note that in order to have noticeable results you have to actually HAVE that glow around your sun. This setting is called “Mie Height” and it has to be set to a fairly high value otherwise it wouldn’t be too prominent. We will talk about this “Mie Height” setting in a minute. No worries.

The following three sliders are complementary and play well together. It means you have to find a good balance setting them which is quite easy:

Rayleigh Height Surface (slider) – Controls the thickness of the atmospheric layer when you’re on or near planet’s Surface. For example. You normally want atmosphere layer to be fairly thick to cover high points of the planet’s surface like mountains and high hills while you’re on the ground because you have actual high picks in your surface geometry which you have to cover. Otherwise you would see black space when you’re on the high mountain. But technically, when you’re leaving the planet’s atmosphere all of these high peaks and mountains are starting to slowly collapse vertically forming a smooth spherical shape of the planet, if they wouldn’t - we would have planets looking like a spiky balls with mountain peaks sticking out in all directions. That’s why when all the high peaks are collapsed to the ground to form a perfect sphere - we are left with abnormally thick and wrong looking atmospheric layer thickness when observed from the outer space. How to fix this?! That’s where “Rayleigh Height Space” slider comes into play, as it controls the thickness of the atmospheric layer seen from outer space.

Rayleigh Height Space (slider) – Controls the thickness of atmospheric layer when you observing the planet from outer space. Like it was said earlier, settings for atmosphere thickness when you’re on the Surface and when you’re in an outer Space can’t be same and normally you want to make it much thinner when it is seen from outer space like it’s in real world. Refer to the following Pic to get better understanding.

Rayleigh Transition (slider) – Ok, so now that we have set the width of the planetary atmosphere for both - when we’re on the Surface and when we’re observing it from outer space, it is time to decide at which distance to switch between two, right? So that’s exactly what this slider does – sets the exact value at which distance that transition must happen. You can play around with this value to find the best setting, just remember that the main goal is to have this transition as smooth as possible, fortunately it’s super easy to achieve. Just make sure that while you’re on the ground and standing on a highest point you still see some atmosphere color (like Blue color in earthlike planets) ,and just about when you start to see the whole planet on your way to the outer space, switch it to the thinner (Rayleigh Height Space) version.

Mie Height (slider) – Controls the size of the outer glow effect of the Sun. Like it was said earlier, when you’re setting your color of the Glow effect via “Mie Scattering RGB” sliders, this particular setting (Mie Height) must be set to a fairly high value otherwise you won’t see it as there won’t be any glow. Look, you can’t change the color of a non-existing thing, soldier. Dismissed!

Sun size (slider) – Controls the size of the Sun.. What else did you expect from it?!

Sea Floor modifier (slider) – Defines the lowest (starting) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer starts. It depends on your planet’s relief, your lowest and highest peaks. Adjust individually for each planet. You’ll “feel” the right value immediately.

Atmosphere Top Modifier (slider) – Defines the highest (ending) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer stops. It depends on your planet’s relief. Adjust individually for each planet. You’ll “feel” the right value immediately. But normally you want this value to be set pretty high.

Intensity (slider) – Actually it should be called “Fog Intensity” as it’s exactly what it’s responsible for but I hope it will be changed by some coder guys eventually J. Controls the amount or intensity of the fog while you’re on or near the planet’s surface (doesn’t do anything when you’re in outer space).

Fog Intensity (slider) – And this, should be actually called “Fog Distance”. It controls the distance fog actually covers. The higher this value – more objects in front of view are covered with fog. (doesn’t do anything when you’re in outer space).

Restore (Button) – Ok, just in case you screw everything up, you always have a chance to revert all the changes you’ve made by clicking this Restore button, soldier! Very convenient isn’t it?!

==Atmosphere 2/2==
Ok, now that we got acquainted with all Atmosphere settings and know how they work, it is time for us to actually change a few settings to alter the look of our Atmosphere! Now the fun part begins. Let’s say that we want to change the color of Earthlike planet’s atmosphere from its natural Blue color to the Green one, so it looks more “alienish”. Please note, that all atmosphere settings are stored in “PlanetGeneratorDefinitions.sbc” file and they are NOT replaced even when you change these values in game and make a save. If you want to change those values you have to change them directly in the code of the “PlanetGeneratorDefinitions.sbc” file only! The system reads those atmosphere values from this file every time you’re loading your worlds.

But how for God’s sake would you know which values are correct and really desirable to put them in the code? This is really simple. You just adjust your atmosphere settings to your liking right in the game, and when you’re done and happy with it, you just copy those values into the code (you can screen grab the in-game view with Atmosphere Settings window or just write them down manually, not a big deal) But to paste those values in the code, you have to know WHERE to paste it, right? You don’t just randomly paste numbers into the code, do you? You may hurt yourself!

So please open “PlanetGeneratorDefinitions.sbc” file in any decent text editor and find the following line:
<pre>
<SubtypeId>EarthLike</SubtypeId>
</pre>
It’s a name or identifier of a planet, and since it’s named Earthlike, we know for sure that below are the definitions related to Earthlike planet. Cool! Now just scroll down to the part where you will see a commented (inactive) line of code which goes like:



Or alternatively, just Ctrl+F to find the following line. You must see something similar to this:

[[File:Atmosphere definition.jpg|512px]]

So here as you can see everything is pretty self-explanatory. Except a few lines that are just named differently in the code. If you want your atmosphere to “remember” the settings you have made you have to enter those values here to the corresponding lines. The following schematic pic shows dependencies between the code lines and the slider names in Atmosphere Settings window quite clearly:
(Click to enlarge)

[[File:In-game Atmosphere Debug Input.jpg|1024px]]

Now let’s just change the blue color of the atmosphere to orange. As you remember, group of three RGB sliders named “Rayleigh Scattering” are responsible for changing the main color of the Atmosphere. So why wait?

[[File:Mars-Like Atmosphere.jpg|1024px]]

Spectacular right? Now, let’s change the sun glow color “Mie Scattering RGB” to an orange tint too. It could stay the same yellow of course but let’s change it so you could have an idea. Remember to press “Alt” on your keyboard while you’re dragging those sliders.

[[File:Another Red Atmosphere.jpg|1024px]]

Ok, now it’s more orange but we have to increase the glow effect a bit to see it more prominently. And as we remember, the glow size control is “Mie Height” slider. Crank it up from 30 to 50.

Good, the glow effect became more prominent. Looking nice isn’t it? Of course, you can continue adjusting it and come up with really crazy results, but if you’re ok with what we already have, then just write down all the values that you currently have in your Atmosphere Settings window on the right or screenshot them and paste into any image editor for your reference. And back in the code editor, just enter those values into corresponding tags in the code and save it:

[[File:CloseUp Atmosphere definition.jpg|512px]]

That’s it! From now on, every time you load up your world with Earthlike planet in it, or spawn Earthlike planet, the atmosphere on it will be exactly the way you adjusted it via Atmosphere Settings! The God himself must have been using something like this we suppose..

[[File:Mars-like Atmosphere Final.jpg|1024px]]

==Clouds==
The first thing that should (probably) come in to your mind when you finally learn how to tweak Atmosphere settings, is probably how to change the look of the Clouds! Because, normally, when you change the color of the atmosphere you would like the clouds color to be relatively close to the Atmosphere color. In our Atmosphere guide (if you read it) we were sharing some knowledge about changing the look of the Atmosphere. We made it orange which is kind of cool all on its own, but what really draws our attention and not in a very good way – is the color of the clouds. As you can see they’re white which is looking wrong isn’t it? In an orange atmosphere environment you would expect orange or yellow clouds right? So that’s what we’ll be doing in a minute – changing the look of our cloud layer and getting to know their under-the-hoods.

Like with Atmosphere settings, the Clouds setting are stored in the same “PlanetGeneratorDefinitions.sbc” file located in KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Data and are individual for each planet. Usually we base our code lines so the Cloud definitions come right after Atmosphere definitions which makes it very convenient to search for. Just open your “PlanetGeneratorDefinitions.sbc” file in any decent advanced text editor and search for this commented (inactive) line of code:



Note: you can download the DDS files from here[mirror.keenswh.com]

[[File:Cloud Layers Definition.jpg|1024px]]

That’s where all the cloud settings for particular planet are stored. The following picture is a brief breakdown of cloud definitions:

Basically, the structure of placing clouds on any planet is as follows:
<pre>
<CloudLayers>
<CloudLayer>
Blah Blah Blah Beautiful Clouds Blah Blah Blah
</CloudLayer>
</CloudLayers>
</pre>
So, as you can see everything is super easy. Simply put, <CloudLayers> tags are meant for global separation of Cloud definitions from other code definitions and are here just to define where the code for the clouds start, while <CloudLayer> tags (again, don’t mistake with CloudLayers) are the actual cloud layers and each pair of these tags (<CloudLayer>…</CloudLayer>) define the look and behavior of each cloud layer. As Captain Obvious states - The more <CloudLayer> pairs you have.. umm - the more cloud layers you will have!

For example. You can have more than one Cloud layer, to simulate even more complex cloud patterns than you initially had in your texture file! And that’s when <InitialRotation> and <RotationAxis> tags come into play. You can assign values to these tags for each Cloud layer individually thus having the cloud spheres to be initially rotated and spinning on different angles creating more interesting and natural cloud patterns. So you basically just stack them this way:
<pre>
<CloudLayers>
<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>
</CloudLayers>
</pre>

That’s it! Now you have three Cloud Layers! And of course you can do it for the Far and the Near cloud layers as well.

Your main cloud color texture must be 4096x2048px RGB file saved in DDS format without alpha as “CloudName_cm.dds file” and it must contain only the color information of your clouds. For Alphamask file please create a separate file of the same 4096x2048px dimensions containing only Alpha mask, make it a greyscale file, save as DDS luminance format and name it “CloudName_Alphamask.dds”. Back in the code, in <texture> tags you just write “Cloudname.dds”, no worries - the engine will identify required “cm” and “alphamask” files itself, just make sure both files are in the correct folder. (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Models\Environment\Sky).

As you know, clouds that are seen from the outer space and the clouds that you see through your window don’t look the same because of the huge differences in scales in both cases. That’s why we have two types of clouds on each planet. First one (commented as “Far layer” in the code) – the clouds that you see from the outer space. They usually look like NASA satellite orbital photo shots.

[[File:Clouds.jpg|1024px]]

And the Second one (commented as “Near layer” in the code) – the clouds that are seen when you’re on the ground or close to it. These should look like a significantly zoomed version of the first ones - more detailed, wispy and more individual. Like the ones you used to see in the sky every day. Refer to the picture.

[[File:LargeClouds.jpg|1024px]]

Now, how to actually separate these two types of cloud layers and to make them come in layers – one after the other. This is very simple too. The maximum overall Altitude (height) of our atmosphere layer is 2. So we have to set up our cloud layers in a tricky way, so that when we’re in outer space - we would see the “Far layer” clouds ONLY, and as we’re getting lower (approaching the ground), on a particular altitude (height) smoothly switch to the “Near layer” clouds and have the “Far layer” clouds hidden. Sounds crazy but it will become clear if you look at the following pic:

[[File:CloudLayerDiagram.jpg|1024px]]

As you can see things are really self-explanatory here too. By setting the Start and End values in <FadeOutRelativeAltitude..> you basically create a vector, the starting point of which is infinity which means anything below this start point will be constant value, thus – making it possible to set the Far layer to be seen from outer space (values greater than 2), and preventing Near cloud layer from being seen - because it is set to fade out on 1.6. And vice versa – when you’re on the ground, you won’t see Far layer clouds layer because it faded out on much higher distance of 1.4. Not so hard right? Of course you can alter and tweak those values to your liking depending on the planets height maps/relief to get the desired transition between Far and Near cloud layers.

So now that we’re empowered with this knowledge, the only thing we’re left to do is to actually change the color of the clouds from white to yellow color so our clouds look more natural in an orange Atmosphere environment. As we remember, our clouds are consisting of two texture files – a file containing color information (usually just a plain color) and a file with an alpha mask only. We already know that the “Far layer” clouds (the ones seen from space) use “EarthFarClouds_cm.dds” texture file and the “Near layer” clouds use “Landsky_texture_cm.dds”. How we know that? It’s written in <texture> </texture> definitions, remember?

[[File:CloudTextureRoute.jpg|512px]]

Great! So now just open “EarthFarClouds_cm.dds” and the “Landsky_texture_cm.dds” and fill both files with plain yellow color and save them!

[[File:YellowCloud Texture.jpg|1024px]]

Start the game and spawn an Earthlike planet and voila! You got perfect yellow clouds!

[[File:Scenery With Yellow Clouds.jpg|1024px]]

==Planet ambient sounds modding - day/night biome sounds==

Sound rules are in the Content\Data\PlanetGeneratorDefinitions.sbc file. Here you can set different sounds based on player’s location or daytime on the planet.
<pre>
<SoundRule>
<Height Min="0" Max="0.5"/>
<Latitude Min="55" Max="80"/>
<SunAngleFromZenith Min="0" Max="180"/>
<EnvironmentSound>AmbIcelandDay</EnvironmentSound>
</SoundRule>
</pre>
Height stands for where you want the sound to play at the height of the heightmap (0-7200m). It is always +12% of the planet's diameter. 0 is from the the lowest start of the surface to 1.0 which is 100% of the surface (maximum height).
Latitude means angle from the equator. Therefore 0 to 20 will mean that this sound will mostly play in the desert area, 20-50 is mostly the green forest area, and so on.
SunAngleFromZenith NEEDS MORE INFO!!!
EnvironmentSound this is the name of the sound you want to use.

You can find all available sounds in Audio.sbc (location shown below) Here you will also put your own ambient sound with your own custom name.

How to implement custom ambient sound

All Ambient sounds are stored here:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Audio\ARC\AMB\

If you want your own sounds, they should be a loop sound, and on average should not be bigger than +-5 MB.
The supported format is: .xwm but .wav can also work, even though its file size is usually a lot bigger (not recommended).

Once your audio is done, implement it here in this file:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\Audio.sbc
<pre>
<Sound>
<Id>
<TypeId>MyObjectBuilder_AudioDefinition</TypeId>
<SubtypeId>AmbAlienForestDay</SubtypeId>
</Id>
<Category>AMB</Category>
<MaxDistance>100</MaxDistance>
<Volume>0.2</Volume>
<Loopable>true</Loopable>
<Waves>
<Wave Type="D2">
<Loop>ARC\AMB\AmbAlienForestDayLoop2d.xwm</Loop>
</Wave>
</Waves>
</Sound>
</pre>
Here edit only what is highlighted, otherwise I cannot guarantee that it will work properly!
<SubtypeId> This is how you will name your AMB sound, keeping in mind upper and lower case letters. Do not use _ or other special characters!
<Volume> This is self explanatory I hope.
<Loop> Here you just need to lead the definition to your file. ARC/AMB/ is the default location, so do not change that.
But if you want, you can make another folder in AMB for your custom ambient sounds for better organisation.

==In-game map modding==
Maps in Medieval Engineers are generated based on terrain and buildings on it. This means that they will work for any modded planet in their default form. That being said, the way map is generated is also fully moddable.

We definitions for map are located in Content\Data\Screens\MapDefinition.sbc. To mod maps you will have to alter/add definitions in this file, all vanilla textures for maps can be found in Content\Textures\GUI\Map. Feel free to use/alter any of them for creation of mods for Medieval Engineers.
Map content modding (Friend/foe display, tax notifications,...
In Medieval Engineers there are 2 view modes of map. Kingdom view which is showing entire kingdom and region view which is zoomed part of a kingdom map. Region is 1kmx1km large on 10 km diameter planet. Both views display different elements.
What is shown in these views depends on what layers it contains
<pre>
<Definition xsi:type="MyObjectBuilder_PlanetMapDefinition">
<Id Type="MyObjectBuilder_PlanetMapDefinition" Subtype="Main"/>
<BackgroundGenerator Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
<RegionView>
<Layers>...</Layers>
</RegionView>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</Definition>
</pre>
BackgroundGenerator refers to a definition of background texture that serves as a background on top of which all the map elements are placed.
<pre>
<RegionView>
<Layers>...</Layers>
</RegionView>
</pre>
The three dots in middle represent layers of elements that show in region view. List and description of all layers is in next section of this document.
<pre>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</pre>
The three dots in middle represent layers of elements that show in kingdom view. List and description of all layers is in next section of this document.
(I did not Kingdom view in its expanded form because it would take up too much space.)

===Layers description===
<pre><Layer xsi:type="MyObjectBuilder_MapBackgroundLayer" /></pre>
This layer draws the background. As generated based on chosen background definition.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaDevelopmentLayer">
<Threshold BlockCount="10" Sprite="Textures\GUI\Map\SmallGrid.png"/>
<Threshold BlockCount="30" Sprite="Textures\GUI\Map\MediumGrid.png"/>
<Threshold BlockCount="60" Sprite="Textures\GUI\Map\LargeGrid.png"/>
</Layer>
</pre>
This layer displays icons based on amount of blocks there is in an area. You can set the block thresholds, or mod the textures. It is also possible to add more thresholds. 80x80 px, png.

[[File:Smallest Settlement.png|150px|frameless]]
[[File:Medium Settlement.png|150px|frameless]]
[[File:LargestSettlement.png|150px|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_RegionFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for region, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaOwnershipLayer">
<AlliedBgColor Hex="#806464FF" />
<PlayerBgColor Hex="#8064FF64" />
<EnemyBgColor Hex="#80DC6415" />
</Layer>
</pre>
This layer defines color overlay over map areas based on ownership. You can mod which color is used for allies, your own areas or for enemies
<pre>
<Layer xsi:type="MyObjectBuilder_AreaUpkeepLayer">
<TaxIcon>Textures\GUI\Map\TaxIcon.png</TaxIcon>
</Layer>
</pre>
This layer displays tax icon on areas that belong to you and require tax payment soon. Texture is 80x80 pixels, png.
[[File:Taxes.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapPositionLayer">
<LocalPlayerImage>Textures\GUI\Map\PlayerPosition.png</LocalPlayerImage>
<OtherPlayersImage>Textures\GUI\Map\AllyPosition.png</OtherPlayersImage>
</Layer>
</pre>
PlanetMapPositionLayer displays player icon above area where they are.
[[File:Ally.png|frameless]]
[[File:Player.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_ActionTrackingLayer">
<ActionImage>Textures\GUI\Map\Action.png</ActionImage>
</Layer>
</pre>
Shows icon over an area on map with fighting / destruction.
[[File:AttackedArea.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_CurrentMapSelectionLayer">
<SelectionImage>Textures\GUI\Map\MapSelection.dds</SelectionImage>
</Layer>
</pre>
This is highlight of a region, that player selected with his mouse.
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapGridLayer">
<GridColor R="0" G="0" B="0" A="228"/>
</Layer>
</pre>
This layer sets which color is the grid drawn.
<pre>
<Layer xsi:type="MyObjectBuilder_KingdomFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for kingdom, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_RegionOwnershipLayer">
<PlayerIcon>Textures\GUI\Map\PlayerLandIcon.png</PlayerIcon>
<AllyIcon>Textures\GUI\Map\AllyLandIcon.png</AllyIcon>
<EnemyIcon>Textures\GUI\Map\EnemyLandIcon.png</EnemyIcon>
<PlayerAllyIcon>Textures\GUI\Map\PlayerAllyLandIcon.png</PlayerAllyIcon>
<PlayerEnemyIcon>Textures\GUI\Map\PlayerEnemyLandIcon.png</PlayerEnemyIcon>
<AllyEnemyIcon>Textures\GUI\Map\AllyEnemyLandIcon.png</AllyEnemyIcon>
<PlayerAllyEnemyIcon>Textures\GUI\Map\PlayerAllyEnemyLandIcon.png</PlayerAllyEnemyIcon>
</Layer>
</pre>
RegionOwnershipLayer generates textures used to express ownership on regional map.

===Background generator (trees, mountains, roads,...)===
Map background is where all the trees, mountains, hills are drawn. It is also capable of coloring map based on what is in planet’s material map (this is how we make roads for example).
All settings for map background are in MedievalMapBackgroundDefinition. The definition also in Content\Data\Screens\MapDefinition.sbc. I will go through various parts of the definition.

<pre><Id Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
Type of the definition says that this map background definition. Subtype is name of this specific background definition. If create your own background with unique subtype
Make sure you create your own background with unique subtype

<DrawHeightmap>false</DrawHeightmap>
When set on “true” planet’s heightmap is drawn under the map.
<Resolution>4096</Resolution><
Sets resolution of the generated in-game map.

<Features>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</Features>

<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</Definition>
</pre>
===Map Coloring===
You can use colors in material or biome map of a planet to appear on the game map. (roads for example). You define map coloring in a node called ”Features”. The coloring uses colors from planet material texture. You can learn more about material texture in biomes modding and surface material modding.
<pre>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
</pre>
This specific feature is used for painting roads on map with dark brown color. In Color you define which color will be the in-game map colored. Material=”67” decides where will be the color applied and refers to a red channel value on planet material texture.
<pre>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</pre>
This specific feature is used for painting forests on map with opaque brown. In Color you define which color will be the in-game map colored. Biome=”60” decides where will be the color applied and refers to a green channel value on planet material texture.

===Sprites===
Medieval Engineers map can also place sprites on map based on terrain shape. All the sprites are on one texture
<pre>
<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</pre>

[[File:AtlasCoordinateUsage.png|512px]]

Note: Illustrates how sprite is defined on our spritesheet. Example sprite:
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />

==Voxel color overlay modding==
We have a cool tech that enables us to color-shift color of almost any item in the game. Currently we are using it for trees(adds small color variations to the same model of a tree) and voxels above iron deposits.
==Fast travel settings modding==
In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around.
In this section of the guide we will show you how to mod which sectors are blocked.
There are 2 ways you can go about it:
===Generate automatically based on terrain shape===
Game is capable of creating fast travel map on its own based on height and terrain steepness. It is possible to mod thresholds for both height and steepness.
You will find the thresholds in Content\Data\Game\FastTravel.sbc. In a MyObjectBuilder_TerrainReachabilityProviderDefinition.
<RiseThreshold> - Sets min. terrain height change which will cause that area is unreachable.
<HeightThreshold> - Sets height of terrain after which area is unreachable, if it goes over this value. Range is 0 - 1.

If there are texture overrides in the definition, you have to erase them in order for the parameters to take effect. Texture overrides are nodes that are called in this fashion: <OverrideNAMEOFFACE>. You will learn more about these overrides in the next part of Fast travel modding.

===Creating fast travel texture override===
If you want to have full control over which areas are reachable and which are not regardless of terrain, you can create a simple texture on which you mark unreachable areas.

The texture is 80x80 pixels, RGB 8 bit. Black pixels forbid entrance.

When you have the texture, select route to it in the definition:
<pre><OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward></pre>
Reachability definition example:
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>
<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>
<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
</Definition>
</pre>
This definition would generate fast travel reachability everywhere, except for front planet face (Fareon kingdom) where fast travel reachability is created based on your texture.

===Development reachability===
Claimable area size, border highlight, contested timer modding
Size of the area and highlight properties are moddable as well.

===Area borders highlight===
<NeutralColor R="225" G="32" B="0" A="64" /> - Set color of an unowned territory
<SelfColor R="0" G="255" B="0" A="64" /> - Sets color of area border owned by you
<AliedColor R="65" G="105" B="225" A="64" /> - Sets color of area border that belongs to allies
<EnemyColor R="225" G="32" B="0" A="64" /> - Sets color of area border that is hostile
<WallSettings Depth="15" Rise="3" SegmentCount"71" End="115" /> - Changes shape of the border. Depth sets how deep is border submerged. Rise sets how tall is the border.
<Fade Start="71" End="115" /> - This sets at which point the border starts to fade.
Contested timer
When players claim area with claimblock, area goes to a “contested” phase for some amount of time, in this phase other players can still attempt to build their own claim block and claim the area. This time is moddable.
Content\Data\Game\SessionComponents.sbc contains definition called MyObjectBuilder_AreaOwnershipSystemDefinition. To mod this value, add this definition to your mod with changed value of <ContestedTimeInMinutes> parameter.

==Permissions modding - what is/isn’t allowed to do in claimed areas==
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.
Description of available actions to set permissions for:
Name=”Build” -> block placement permissions
Name=”Repair” -> Repairing/building already placed blocks
Name=”Deconstruct” -> Deconstructing
Name=”QuickDeconstruct” -> Faster deconstruction
Name=”VoxelEdit” -> Mining or shoveling
Name=”Destroy” -> Damage with hand weapons
Name=”Interaction” -> Chest opening, door opening
Name=”ClaimBlockInteraction” -> ClaimblockGui

===List of available Groupnames:===
Groupname: “Owner” -> Player who owns area
Groupname: “Allies” -> Mostly faction members of owner of the area
Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
Groupname: “Enemies” -> Players in factions that are hostile to your faction

==Compass modding==
It is possible to mod visual look of an in-game compass. All definitions of compass are stored in Content\Data\GUI\CompassDefinition.sbc. Our textures for compass are in Content\Textures\GUI\Compass folder if you want to check out how they look or use them in your mod.
===Creating compass texture atlas and setting coordinates for its elements===
Just like with map sprites, we save main compass elements on a single texture, then define parts of it using pixel coordinates. First setup origin point, then add width and height of the rectangle
Example texture coordinates for top part of the compass:
[[File:CompassTextureCoordinates.png|1024px]]
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>

===Explanation of compass definition line by line===
<pre><Texture>Textures/GUI/Compass/compass.png</Texture> </pre>
Route to a texture atlas.
<pre><KingdomIcon>Textures/GUI/Compass/Icon-Kingdom.png</KingdomIcon> </pre>
Route to icon symbolizing a kingdom.
<pre><Padding>7</Padding></pre>
Padding is added vertically between the top and bottom textures and the edges of the contents of the compass.
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>
Rectangle in the texture that contains the top part.
<pre><BottomCrop X="0" Y="0" Width="0" Height="0"/></pre>
Rectangle in the texture that contains the bottom part.
<pre><BackgroundCrop X="0" Y="64" Width="512" Height="64"/></pre>
Rectangle in the texture that contains the background.
<pre><ArrowCrop X="0" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the little marker used for elements that are drawn and have no icon.
<pre><MarkerCrop X="32" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the interval bars drawn every few degrees.
<pre><ShadowCrop X="64" Y="128" Width="80" Height="32" Left="8" Right="8"/></pre>
<pre><ShadowPadding Left="12" Top="8" Right="12" Bottom="8"/></pre>
Rectangle in the texture that contains the text shadows. Shadow is 3-Sliced, meaning the texture is split in three parts: [left|middle|right]
The sizes of left and right define the cropping lines that split the texture into three. The Sides are then always kep proportional as the texture is scaled.
<pre><VisibleRange>200</VisibleRange></pre>
Visible range in degrees.
<pre><Width>700</Width></pre>
Width in reference resolution pixels.
<pre><FontSize>1.1</FontSize></pre>
Scale of the font based on default.
<pre><VerticalOffset>0.065</VerticalOffset></pre>
Vertical offset from the top of the screen. 0 = top of the screen, 1 is the bottom. Compass is centered around this position.
<pre>
<TagStyles>
<TagStyle Tag="ClaimArea" Style="Bellow" MaxCharacters="15" Ellipsis="true"/>
<TagStyle Tag="Cardinal" Style="Above" MaxCharacters="1"/>
<TagStyle Tag="Kingdom" Style="Bellow"/>
</TagStyles>
</pre>
This section adds tags that are visible on compass and in which style. Currently we have 3 types of tags. Claim area - shows your claimed area on the compass, Kingdom tag shows kingdoms and Cardinal tag shows cardinal points (North, South,...). Each tag’s visual appearance is defined in tag/waypoint definition. Styles defines where should the text appear. Available styles: Center, IconOnly, NotShown, Bellow, Above.

===Explanation of Waypoint/Tag definition===
<pre>
<Definition xsi:type="MyObjectBuilder_WaypointDefinition">
<Id Type="MyObjectBuilder_WaypointDefinition" Subtype="Kingdom"/>
<IconPath>Textures/GUI/Compass/IconKeep.png</IconPath>
<Color R="255" G="255" B="255" A="255"/>
</Definition>
</pre>
IconPath contains path to the texture of kingdom icon. Color defines color of the text that is shown with the icon. (Example: Fareon, [[File:Kingdom Icon.png|thumb]])
===Compass texture vs in-game look comparison===
Texture:

[[File:Compas Texture with Zones.png|1024px]]

In-game look:

[[File:In-gameCompassZones.png|1024px]]
<NoWiki>*</NoWiki>note that background crop and bottom crop are not used in vanilla (empty opaque texture)

==Indestructible grids==
There is a way how to make some buildings in your save indestructible. We are using this feature for starting area buildings. Some you guys might make a good use of this feature in your pre-made worlds.

Currently, only way how to do this is to make edits to an existing save file. So you can only use it for world modding.

===Making indestructible cubegrids in existing safe===
Goal is to open world’s safe file in a text editor, find your cubegrid in it and add this tag to it: <DestructibleBlocks>true</DestructibleBlocks>.

#Find your save file. By default save files are stored in C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Saves
#Open folder with your save and find file called SANDBOX_0_0_0_.sbs. This file can be opened with any text editor you prefer.
#In the SANDBOX_0_0_0_.sbs search for the cubegrid name of the building you want to make indestructible. (use find/search function in your text editor, or you will grow old before you find it)
#Tip: To find out name of a cubegrid, create blueprint of the building. The name that the building saves as in your blueprint screen is the name of the cubegrid.
#You should find the name in tags called: <DisplayName>YOURCUBEGRIDNAME</DisplayName>
#Under the name, add following tag with setting set to false: <DestructibleBlocks>false</DestructibleBlocks>
#If you followed instruction, the indestructibility tag is now in node called <MyObjectBuilder_EntityBase> and not in any of its child nodes.
#Save the edited file.
#Load the save and test destructibility
#It worked! Enjoy
#It is still destructible. Go to point 1.

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding/Compass

2017-03-13T11:21:17Z

Lukas:

==Compass modding introduction==
It is possible to mod visual look of an in-game compass. All definitions of compass are stored in Content\Data\GUI\CompassDefinition.sbc. Our textures for compass are in Content\Textures\GUI\Compass folder if you want to check out how they look or use them in your mod.
===Creating compass texture atlas and setting coordinates for its elements===
Just like with map sprites, we save main compass elements on a single texture, then define parts of it using pixel coordinates. First setup origin point, then add width and height of the rectangle
Example texture coordinates for top part of the compass:
[[File:CompassTextureCoordinates.png|1024px]]
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>

==Explanation of compass definitions line by line==
<pre><Texture>Textures/GUI/Compass/compass.png</Texture> </pre>
Route to a texture atlas.
<pre><KingdomIcon>Textures/GUI/Compass/Icon-Kingdom.png</KingdomIcon> </pre>
Route to icon symbolizing a kingdom.
<pre><Padding>7</Padding></pre>
Padding is added vertically between the top and bottom textures and the edges of the contents of the compass.
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>
Rectangle in the texture that contains the top part.
<pre><BottomCrop X="0" Y="0" Width="0" Height="0"/></pre>
Rectangle in the texture that contains the bottom part.
<pre><BackgroundCrop X="0" Y="64" Width="512" Height="64"/></pre>
Rectangle in the texture that contains the background.
<pre><ArrowCrop X="0" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the little marker used for elements that are drawn and have no icon.
<pre><MarkerCrop X="32" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the interval bars drawn every few degrees.
<pre><ShadowCrop X="64" Y="128" Width="80" Height="32" Left="8" Right="8"/></pre>
<pre><ShadowPadding Left="12" Top="8" Right="12" Bottom="8"/></pre>
Rectangle in the texture that contains the text shadows. Shadow is 3-Sliced, meaning the texture is split in three parts: [left|middle|right]
The sizes of left and right define the cropping lines that split the texture into three. The Sides are then always kep proportional as the texture is scaled.
<pre><VisibleRange>200</VisibleRange></pre>
Visible range in degrees.
<pre><Width>700</Width></pre>
Width in reference resolution pixels.
<pre><FontSize>1.1</FontSize></pre>
Scale of the font based on default.
<pre><VerticalOffset>0.065</VerticalOffset></pre>
Vertical offset from the top of the screen. 0 = top of the screen, 1 is the bottom. Compass is centered around this position.
<pre>
<TagStyles>
<TagStyle Tag="ClaimArea" Style="Bellow" MaxCharacters="15" Ellipsis="true"/>
<TagStyle Tag="Cardinal" Style="Above" MaxCharacters="1"/>
<TagStyle Tag="Kingdom" Style="Bellow"/>
</TagStyles>
</pre>
This section adds tags that are visible on compass and in which style. Currently we have 3 types of tags. Claim area - shows your claimed area on the compass, Kingdom tag shows kingdoms and Cardinal tag shows cardinal points (North, South,...). Each tag’s visual appearance is defined in tag/waypoint definition. Styles defines where should the text appear. Available styles: Center, IconOnly, NotShown, Bellow, Above.

==Explanation of Waypoint/Tag definition==
<pre>
<Definition xsi:type="MyObjectBuilder_WaypointDefinition">
<Id Type="MyObjectBuilder_WaypointDefinition" Subtype="Kingdom"/>
<IconPath>Textures/GUI/Compass/IconKeep.png</IconPath>
<Color R="255" G="255" B="255" A="255"/>
</Definition>
</pre>
IconPath contains path to the texture of kingdom icon. Color defines color of the text that is shown with the icon. (Example: Fareon, [[File:Kingdom Icon.png|thumb]])
===Compass texture vs in-game look comparison===
Texture:

[[File:Compas Texture with Zones.png|1024px]]

In-game look:

[[File:In-gameCompassZones.png|1024px]]
<NoWiki>*</NoWiki>note that background crop and bottom crop are not used in vanilla (empty opaque texture)

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding/Compass

2017-03-13T11:20:42Z

Lukas: /* Explanation of compass definition line by line */

==Compass modding==
It is possible to mod visual look of an in-game compass. All definitions of compass are stored in Content\Data\GUI\CompassDefinition.sbc. Our textures for compass are in Content\Textures\GUI\Compass folder if you want to check out how they look or use them in your mod.
===Creating compass texture atlas and setting coordinates for its elements===
Just like with map sprites, we save main compass elements on a single texture, then define parts of it using pixel coordinates. First setup origin point, then add width and height of the rectangle
Example texture coordinates for top part of the compass:
[[File:CompassTextureCoordinates.png|1024px]]
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>

===Explanation of compass definitions line by line===
<pre><Texture>Textures/GUI/Compass/compass.png</Texture> </pre>
Route to a texture atlas.
<pre><KingdomIcon>Textures/GUI/Compass/Icon-Kingdom.png</KingdomIcon> </pre>
Route to icon symbolizing a kingdom.
<pre><Padding>7</Padding></pre>
Padding is added vertically between the top and bottom textures and the edges of the contents of the compass.
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>
Rectangle in the texture that contains the top part.
<pre><BottomCrop X="0" Y="0" Width="0" Height="0"/></pre>
Rectangle in the texture that contains the bottom part.
<pre><BackgroundCrop X="0" Y="64" Width="512" Height="64"/></pre>
Rectangle in the texture that contains the background.
<pre><ArrowCrop X="0" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the little marker used for elements that are drawn and have no icon.
<pre><MarkerCrop X="32" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the interval bars drawn every few degrees.
<pre><ShadowCrop X="64" Y="128" Width="80" Height="32" Left="8" Right="8"/></pre>
<pre><ShadowPadding Left="12" Top="8" Right="12" Bottom="8"/></pre>
Rectangle in the texture that contains the text shadows. Shadow is 3-Sliced, meaning the texture is split in three parts: [left|middle|right]
The sizes of left and right define the cropping lines that split the texture into three. The Sides are then always kep proportional as the texture is scaled.
<pre><VisibleRange>200</VisibleRange></pre>
Visible range in degrees.
<pre><Width>700</Width></pre>
Width in reference resolution pixels.
<pre><FontSize>1.1</FontSize></pre>
Scale of the font based on default.
<pre><VerticalOffset>0.065</VerticalOffset></pre>
Vertical offset from the top of the screen. 0 = top of the screen, 1 is the bottom. Compass is centered around this position.
<pre>
<TagStyles>
<TagStyle Tag="ClaimArea" Style="Bellow" MaxCharacters="15" Ellipsis="true"/>
<TagStyle Tag="Cardinal" Style="Above" MaxCharacters="1"/>
<TagStyle Tag="Kingdom" Style="Bellow"/>
</TagStyles>
</pre>
This section adds tags that are visible on compass and in which style. Currently we have 3 types of tags. Claim area - shows your claimed area on the compass, Kingdom tag shows kingdoms and Cardinal tag shows cardinal points (North, South,...). Each tag’s visual appearance is defined in tag/waypoint definition. Styles defines where should the text appear. Available styles: Center, IconOnly, NotShown, Bellow, Above.

===Explanation of Waypoint/Tag definition===
<pre>
<Definition xsi:type="MyObjectBuilder_WaypointDefinition">
<Id Type="MyObjectBuilder_WaypointDefinition" Subtype="Kingdom"/>
<IconPath>Textures/GUI/Compass/IconKeep.png</IconPath>
<Color R="255" G="255" B="255" A="255"/>
</Definition>
</pre>
IconPath contains path to the texture of kingdom icon. Color defines color of the text that is shown with the icon. (Example: Fareon, [[File:Kingdom Icon.png|thumb]])
===Compass texture vs in-game look comparison===
Texture:

[[File:Compas Texture with Zones.png|1024px]]

In-game look:

[[File:In-gameCompassZones.png|1024px]]
<NoWiki>*</NoWiki>note that background crop and bottom crop are not used in vanilla (empty opaque texture)

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding/Compass

2017-03-13T11:20:04Z

Lukas: Created page with "==Compass modding== It is possible to mod visual look of an in-game compass. All definitions of compass are stored in Content\Data\GUI\CompassDefinition.sbc. Our textures for..."

==Compass modding==
It is possible to mod visual look of an in-game compass. All definitions of compass are stored in Content\Data\GUI\CompassDefinition.sbc. Our textures for compass are in Content\Textures\GUI\Compass folder if you want to check out how they look or use them in your mod.
===Creating compass texture atlas and setting coordinates for its elements===
Just like with map sprites, we save main compass elements on a single texture, then define parts of it using pixel coordinates. First setup origin point, then add width and height of the rectangle
Example texture coordinates for top part of the compass:
[[File:CompassTextureCoordinates.png|1024px]]
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>

===Explanation of compass definition line by line===
<pre><Texture>Textures/GUI/Compass/compass.png</Texture> </pre>
Route to a texture atlas.
<pre><KingdomIcon>Textures/GUI/Compass/Icon-Kingdom.png</KingdomIcon> </pre>
Route to icon symbolizing a kingdom.
<pre><Padding>7</Padding></pre>
Padding is added vertically between the top and bottom textures and the edges of the contents of the compass.
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>
Rectangle in the texture that contains the top part.
<pre><BottomCrop X="0" Y="0" Width="0" Height="0"/></pre>
Rectangle in the texture that contains the bottom part.
<pre><BackgroundCrop X="0" Y="64" Width="512" Height="64"/></pre>
Rectangle in the texture that contains the background.
<pre><ArrowCrop X="0" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the little marker used for elements that are drawn and have no icon.
<pre><MarkerCrop X="32" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the interval bars drawn every few degrees.
<pre><ShadowCrop X="64" Y="128" Width="80" Height="32" Left="8" Right="8"/></pre>
<pre><ShadowPadding Left="12" Top="8" Right="12" Bottom="8"/></pre>
Rectangle in the texture that contains the text shadows. Shadow is 3-Sliced, meaning the texture is split in three parts: [left|middle|right]
The sizes of left and right define the cropping lines that split the texture into three. The Sides are then always kep proportional as the texture is scaled.
<pre><VisibleRange>200</VisibleRange></pre>
Visible range in degrees.
<pre><Width>700</Width></pre>
Width in reference resolution pixels.
<pre><FontSize>1.1</FontSize></pre>
Scale of the font based on default.
<pre><VerticalOffset>0.065</VerticalOffset></pre>
Vertical offset from the top of the screen. 0 = top of the screen, 1 is the bottom. Compass is centered around this position.
<pre>
<TagStyles>
<TagStyle Tag="ClaimArea" Style="Bellow" MaxCharacters="15" Ellipsis="true"/>
<TagStyle Tag="Cardinal" Style="Above" MaxCharacters="1"/>
<TagStyle Tag="Kingdom" Style="Bellow"/>
</TagStyles>
</pre>
This section adds tags that are visible on compass and in which style. Currently we have 3 types of tags. Claim area - shows your claimed area on the compass, Kingdom tag shows kingdoms and Cardinal tag shows cardinal points (North, South,...). Each tag’s visual appearance is defined in tag/waypoint definition. Styles defines where should the text appear. Available styles: Center, IconOnly, NotShown, Bellow, Above.

===Explanation of Waypoint/Tag definition===
<pre>
<Definition xsi:type="MyObjectBuilder_WaypointDefinition">
<Id Type="MyObjectBuilder_WaypointDefinition" Subtype="Kingdom"/>
<IconPath>Textures/GUI/Compass/IconKeep.png</IconPath>
<Color R="255" G="255" B="255" A="255"/>
</Definition>
</pre>
IconPath contains path to the texture of kingdom icon. Color defines color of the text that is shown with the icon. (Example: Fareon, [[File:Kingdom Icon.png|thumb]])
===Compass texture vs in-game look comparison===
Texture:

[[File:Compas Texture with Zones.png|1024px]]

In-game look:

[[File:In-gameCompassZones.png|1024px]]
<NoWiki>*</NoWiki>note that background crop and bottom crop are not used in vanilla (empty opaque texture)

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding/Fast Travel

2017-03-13T11:15:10Z

Lukas: /* Area borders highlight */

Keen:Planet Modding/Area Permissions

2017-03-13T11:14:51Z

Lukas: /* List of available Groupnames: */

Keen:Planet Modding/Area Permissions

2017-03-13T11:13:53Z

Lukas: Created page with "==Permissions modding - what is/isn’t allowed to do in claimed areas== Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we ch..."

Keen:Planet Modding/Fast Travel

2017-03-13T11:12:54Z

Lukas:

Keen:Planet Modding/Fast Travel

2017-03-13T11:11:34Z

Lukas:

==Introduction==
In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around.
In this section of the guide we will show you how to mod which sectors are blocked.
There are 2 ways you can go about it:
===Generate automatically based on terrain shape===
Game is capable of creating fast travel map on its own based on height and terrain steepness. It is possible to mod thresholds for both height and steepness.
You will find the thresholds in Content\Data\Game\FastTravel.sbc. In a MyObjectBuilder_TerrainReachabilityProviderDefinition.
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>

<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>

<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
<OverrideBackward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Back_ForbiddenAreas.png</OverrideBackward>
<OverrideLeft>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Left_ForbiddenAreas.png</OverrideLeft>
<OverrideRight>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Right_ForbiddenAreas.png</OverrideRight>
<OverrideUp>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Up_ForbiddenAreas.png</OverrideUp>
<OverrideDown>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Down_ForbiddenAreas.png</OverrideDown>
</Definition>
</pre>
'''<RiseThreshold>''' - Sets min. terrain height change which will cause that area is unreachable.

'''<HeightThreshold>''' - Sets height of terrain after which area is unreachable, if it goes over this value. Range is 0 - 1.

If there are texture overrides in the definition, you have to erase them in order for the parameters to take effect. Texture overrides are used to override the generated fast travel map. You will learn more about these overrides in the next part of Fast travel modding.

===Creating fast travel texture override===
If you want to have full control over which areas are reachable and which are not regardless of terrain, you can create a simple texture on which you mark unreachable areas.

The texture is 80x80 pixels, RGB 8 bit. Black pixels forbid entrance.

When you have the texture, select route to it in the definition:
<pre><OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward></pre>
Reachability definition example:
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>
<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>
<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
</Definition>
</pre>
This definition would generate fast travel reachability everywhere, except for front planet face (Fareon kingdom) where fast travel reachability is created based on your texture.

===Development reachability===
Claimable area size, border highlight, contested timer modding
Size of the area and highlight properties are moddable as well.

===Area borders highlight===
<NeutralColor R="225" G="32" B="0" A="64" /> - Set color of an unowned territory
<SelfColor R="0" G="255" B="0" A="64" /> - Sets color of area border owned by you
<AliedColor R="65" G="105" B="225" A="64" /> - Sets color of area border that belongs to allies
<EnemyColor R="225" G="32" B="0" A="64" /> - Sets color of area border that is hostile
<WallSettings Depth="15" Rise="3" SegmentCount"71" End="115" /> - Changes shape of the border. Depth sets how deep is border submerged. Rise sets how tall is the border.
<Fade Start="71" End="115" /> - This sets at which point the border starts to fade.
Contested timer
When players claim area with claimblock, area goes to a “contested” phase for some amount of time, in this phase other players can still attempt to build their own claim block and claim the area. This time is moddable.
Content\Data\Game\SessionComponents.sbc contains definition called MyObjectBuilder_AreaOwnershipSystemDefinition. To mod this value, add this definition to your mod with changed value of <ContestedTimeInMinutes> parameter.

Permissions modding - what is/isn’t allowed to do in claimed areas
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.

===Description of available actions to set permissions for:===
#Name=”Build” -> block placement permissions
#Name=”Repair” -> Repairing/building already placed blocks
#Name=”Deconstruct” -> Deconstructing
#Name=”QuickDeconstruct” -> Faster deconstruction
#Name=”VoxelEdit” -> Mining or shoveling
#Name=”Destroy” -> Damage with hand weapons
#Name=”Interaction” -> Chest opening, door opening
#Name=”ClaimBlockInteraction” -> ClaimblockGui

===List of available Groupnames:===

#Groupname: “Owner” -> Player who owns area
#roupname: “Allies” -> Mostly faction members of owner of the area
#Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
#Groupname: “Enemies” -> Players in factions that are hostile to your faction

Keen:Planet Modding - Full Guide

2017-03-13T11:04:48Z

Lukas: /* Area borders highlight */

==Introduction==
Hello fellow Medieval Engineers!
I would like to present you with a guide that will help you understand how we created planets at Keen Software House and how to mod your own into the game.
Feel free to use/alter company owned files for your Medieval Engineers mods.

So let's get to modding!

==Recommended Software==
# Microsoft Visual Studio - or Notepad++ (Link[notepad-plus-plus.org]) - for opening files with .sbc extension where we have definitions for every feature in the game.
# Adobe Photoshop - for editing material and heightmap textures
# World Machine Professional - for heightmap easier creation (much more realistic looking terrain, without manual work)

(Basic Edition is also available, but the max resolution output is limited to 512x512 pixels)
http://www.world-machine.com

===Advice===
We would like to mention one thing before you get into modding planets:
For your own sake we recommend you to load either PlanetTemplate or EarthLikeModExample and test/edit all the things there, so you get to know the system and how everything works.

After that you can create your own from scratch. This is entirely up to you.

==General modding principles - how to make any mod==
I will explain again basic principles of how mods are applied.

All of our vanilla source files are all saved in a folder called content in your *game folder. If no mods are assigned to a world that you are loading, game uses only files from this content folder but if there are mods, game loads also files from mod adding more content or potentially rewriting vanilla content based on content of the mod’s folder. Mod is nothing else but a folder with another files.
Mod files are stored in mods folder on your computer , and if you are using them for the first time, they are downloaded from workshop first time you try to load/connect to a world with those mods.
Mod folder: C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Mods
===Opening mod and examining mods content===
When you open Mods folder, you will see mods as files with .sbm extension. But they are really just folders and to examine them, all you have to do is rewrite the extension from .sbm to .rar and then you can open them with rar and examine content.
Mods are not listed with their names, but with their steam id number. To find specific mod, you have to go to the mods workshop page

Examining other mods similar to your idea is a fast way to learn.
Example:

<NoWiki>*</NoWiki>By default this is SteamLibrary\steamapps\common\MedievalEngineers\Content. You can also get there if you go to steam library(same place where you start the game), right-click Medieval Engineers, select properties, local files and finally click on “browse local files”.
==Materials modding==
In case you are thinking about making your own trees and voxel materials, we have some good news for you!

There are two separate guides that you can follow to make your own stuff.

General modding guide - get started

===Voxel material modding===
http://steamcommunity.com/sharedfiles/filedetails/?id=568406623

==Planet Size==
Planet size is defined in a scenarios.sbc. Every time you click on create new world in the game it uses scenario definition to create a new safe file. Although this scenario definition is not moddable, you can still use it to create a world and share the world itself on the workshop.

First go to where you have Medieval Engineers source files and find Data folder (SteamLibrary\steamapps\common\MedievalEngineers\Content\Data\Scenarios.sbx)

==All planet related files overview and where to find them==
To summarize how planet modding in ME works, we can say this:
We use 2 types of textures and then we define how the game should interpret those textures in definitions. One texture is heightmap that is used just for generating terrain shape, another one is used to place everything else on the planet (ores, trees and plants, bots).
[[File:Diagram.png|1024px|center]]

==Material Texture modding==
Material texture is used to store information about location of various planet surface features. These features are surface materials, biomes (trees, bots, plants,..etc) and where you can find ore. Each one of these uses one color channel. Surface materials use red channel. Biomes use green. Ores are in blue channel.
We use 6 material textures (2048x2048) for each planet. You can find all our material textures here: Content\Data\PlanetDataFiles.
Each planet has its own folder. The folder has to have the same name as the planet.

[[File:MaterialMapBreakdown.jpg|512px]]

Illustration of how are the material textures connected to each other:

[[File:Planet Material Texture Order.jpg|512px]]

====The process of material texture creation is really simple. You have two options:====
=====Copy an existing map to your folder and overwrite the green channel and edit them to your liking=====
This is highly recommended to avoid errors!
=====Create a new: step by step in Photoshop=====
#Set both width and height to 2048 pixels
#(for smaller planets this can also be 1024 or less, but all textures need to have the same resolution! Even the heightmap)
#Set resolution - Pixels/Inch to 72.
#Set colour mode to RGB Colour - 8bit
#Now start painting with the pencil tool on each RGB Channel separately.
#Never on all three at once! (It will F. up everything - trust me).

===Surface voxel material definitions modding - grass, sand, snow===

[[File:RedChannel.jpg|22px|frameless]]

Surface “voxel materials” refers to what you know as grass, soil, stone.. We use red channel of the material texture to set where all the terrain appears. Then you need to write definitions in the Content\Data\PlanetGenerator.sbc to tell game which voxel should appear at specific red channel value.
Example of the definition of road:
<pre>
<ComplexMaterials>
<MaterialGroup Name="Road" Value="67">
<Rule>
<Layers>
<Layer Material="Soil" Depth="2"/>
</Layers>
<Slope Min="0" Max="90"/>
</Rule>
</MaterialGroup>
</ComplexMaterials>
</pre>
Example of corresponding material texture with road:

[[File:RoadMaterialTextureExample.png|512px]]

====Complex materials====
Complex materials definition allows to paint the map with a set of “voxel coloring rules”. Meaning that one color value in red channel can color terrain with different voxels based on rules like slope, longitude or latitude and height. (So with our road example)
<pre>
<MaterialGroup Name="Forest_Grass" Value="120">
<Rule>
<Layers>
<Layer Material="Woods_grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="0" Max="25"/>
<Latitude Min="-180" Max="180"/>
<Longitude Min="-180" Max="180"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Grass" Depth="1"/>
<Layer Material="Soil" Depth="5"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="25" Max="45"/>
</Rule>
<Rule>
<Layers>
<Layer Material="Rocks_grass" Depth="2"/>
<Layer Material="Stone" Depth="100"/>
</Layers>
<Slope Min="45" Max="55"/>
</Rule>
</MaterialGroup>
</pre>
This definition says what voxels should be generated in spots, that are painted with red channel value of 120.
The rules in this definition will lead to following:
Flat lands (up to 20 degrees slope) will have Wood grass 1 m thick, soil will be right under the WoodGrass up to 5 m depth and there will be stone underneath the soil.
In places with medium slope, there is Grass instead of WoodGrass. And in slopes from 45 to 55 there is rocks grass 2 m thick with stone right away under it.
With this technology, we can make the color react on its own to terrain bumps or even position on planet. This saves lots of meticulous painting with heightmap.

<Layer Material="Woods_grass" Depth="1"/>
Material refers to voxelmaterial definition. (You can find it in Content\Data\VoxelMaterials.sbc). Depth means how deep should the material go under ground.
<Slope Min="0" Max="25"/>
Slope of the terrain in degrees.
<Latitude Min="-180" Max="180"/>
Latitude in degrees. 0 degree is an equator.
<Longitude Min="-180" Max="180"/>
Longitude in degrees. 0 is in the middle of front planetary texture. (Fareon Kingdom)

===Biomes definitions modding - trees, plants and bots===
[[File:GreenChannel.jpg|frameless|22px]]

Biomes refers to everything that is spawned on top of the planet. We use green channel of the material texture to set where all the terrain features appear. Then you need to write definitions in the Content\Data\Environment\ProceduralEnvironments.sbc to tell game which environment item should appear at specific green channel value. Also you need to assign Environment to planet in the Content\Data\PlanetGenerator.sbc
First make/modify environment:
Go to Content\Data\Environment\ProceduralEnvironments.sbc
Assign environment to a planet
Go to Content\Data\PlanetGenerator.sbc and find definition of the planet you want your environment to be on. Then assign the environment to the planet this way:
<pre>
<Environment>
<TypeId>MyObjectBuilder_ProceduralWorldEnvironment</TypeId>
<SubtypeId>Earth Environment</SubtypeId>
</Environment>
</pre>
SutypeId refers to the name of the environment from:
Content\Data\Environment\ProceduralEnvironments.sbc

===Ores definitions modding===
[[File:BlueChannel.jpg|frameless|22px]]

Ores are placed using blue channel of the material texture to set where should ore deposits appear. When your ore deposits are painted on the material map, you need to define what ores will be there. Go to Content\Data\Environment\ProceduralEnvironments.sbc to tell game which ore should appear at specific blue channel value.

<pre>
<OreMappings>
<Ore Value="130" Type="IronOre_RichYield" Start="3" Depth="7" TargetColor="#b7340a" ColorInfluence="15 "/>
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
<Ore Value="110" Type="IronOre_PoorYield" Start="2" Depth="5" TargetColor="#a76a41" ColorInfluence="15" />
</OreMappings>
</pre>
The section you need to use is Ore Mappings.
<Ore Value="120" Type="IronOre_RegularYield" Start="3" Depth="7" TargetColor="#b75e0a" ColorInfluence="15" />
Value refers to blue channel value on material texture.
Type refers to name of a voxel material from Content\Data\VoxelMaterials.sbc.
Start is depth at which the ore deposit starts. Depth is how deep under ground it goes.
TargetColor is color that will be used to color surface above the ore.
ColorInfluence sets strenght of coloring.

==Working with RGB==
Ok, Steam won't let me share that link to a small RGB Photoshop tutorial with you, so just go to photoshopessentials.com and search for RGB and it's the first link.

This is a simple tutorial to explain you what we mean when we say Grayscale ID, which can also be called the RGB values
(each channel only has one number per shade of that color ranging from 0 to 255).

Here I have loaded a Biome map texture front_mat texture which is used on the Vanilla EarthLike planet.

[[File:RGBChannels.jpg|frameless]]These are the RGB channels as you can see them in Photoshop.

NOTE: Edit each RGB channel separately!

Always use the pencil tool to paint pixels.
The brush tool has a falloff that has different values and you will not have control over those!
[[File:Color Picker.jpg|thumb]]

You can see if the numbers are correct on the top right of the screen if you have your workspace set to Essentials.

Here you will enter the values you want to paint.
Make sure you check them before saving, sometimes Photoshop can move the number +-1 (personal experience).

It doesn't matter if the numbers match, just as long as you have the correct value (ID) in the correct channel!

==Height-maps modding - terrain shape, roads==
As mentioned in 2. Required software, we used the program World Machine to create our heightmaps and then we did some minor tweaks by hand (like putting in lakes and desert areas)

First, to explain how our planet heightmaps work:
We have 6 textures that connect together (image below). Our standard resolution for a big 120km planet is 2048x2048. But you can use a lower one if you want to.

To create your own heightmap, the best action would be to find a heightmap here:
C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\PlanetDataFiles

Then you can open the texture and place yours/paint yours on a new layer, flatten the image and save it as a .PNG

There are other options for you also!
You can visit[terrain.party] this site and download a heightmap from a real place on Earth. You can even set the size of the map (maximum is 60 km). And then you can edit it further in Photoshop.
You can try painting it yourself in Photoshop (or any other similar software, like Gimp).
You can also just try Googling for heightmaps and try which one suits you the best (keep in mind the resolution must be 512,1024, 2048!)
However you get your heightmap, always keep in mind how each texture of the heightmap is connected, so the seams need to fit together. Bad texture connection is very visible in the game.
Here is an image of how the textures are connected:

[[File:Planet Material Texture Order.jpg|512px]]

===Roads===
We created roads using World Machine tools. You can find guide how to do that in between World Machine tutorials.

==Atmosphere==
[[File:View Image.jpg|1024px]]

Here, you will find everything you ever wanted to know about Atmosphere Settings in Space Engineers but were afraid to ask, my dear friend. So without any further ado. Let’s start with the “Atmosphere” settings window which you access in-game by hitting F12 -> Render Button -> Atmosphere checkbox. The new Atmosphere settings window opens immediately on the right side of the screen, showing a bunch of tricky sliders.

[[File:Cloud Layers Definition.jpg|1024px]]

If your pants are still dry, and if by any chance you’re still reading this, let us assure you that everything is pretty simple and not so scary as it may seem when you first open it. So let’s start with the brief and really quick explanation of what every slider or group of sliders are meant for. Lastly, remember that to alter any setting in this Window you have to hold “Alt” on your keyboard.

Enable Atmosphere (checkbox) – Well, as Captain Obvious immediately states to us – it just enables or disables Atmosphere on a planet and nothing more.

Time of Day (slider) – Controls rotation of the Sun around a Planet. You’re given the Power to decide which time of day it is now. Cool isn’t it?

Pick Planet (Button) – In situations when you have more than one planet in your world, you may want to alter the settings of each planet’s atmosphere individually. So this button enables you to immediately pick the current atmosphere values of the planet you’re currently on. For example, fly to the Moon, press “Pick planet” button and you will get corresponding atmosphere values of that planet to play with. Fly back to Earth or any alien planet, and do the same to alter atmosphere settings of these planets. Yay!

Rayleigh Scattering R,G and B (sliders) – Group of three sliders which control the main, overall color of the Atmosphere. It’s that atmosphere color which is going to be seen from outer space and on the ground too! If you want to make your atmosphere alien green or purple – these are the correct set of sliders to play with. Each slider controls corresponding R,G or B (0-255) values. Pretty straightforward.

[[File:Atmosphere Settings.jpg|512px]]

Mie Scattering R, G and B (sliders) – Group of three sliders to control the color of the Sun glow. It would be weird to have Green atmosphere and Red sun glow right? You would normally want to set it to yellow or something light green or so. But it’s your choice you can make any color you want. But please note that in order to have noticeable results you have to actually HAVE that glow around your sun. This setting is called “Mie Height” and it has to be set to a fairly high value otherwise it wouldn’t be too prominent. We will talk about this “Mie Height” setting in a minute. No worries.

The following three sliders are complementary and play well together. It means you have to find a good balance setting them which is quite easy:

Rayleigh Height Surface (slider) – Controls the thickness of the atmospheric layer when you’re on or near planet’s Surface. For example. You normally want atmosphere layer to be fairly thick to cover high points of the planet’s surface like mountains and high hills while you’re on the ground because you have actual high picks in your surface geometry which you have to cover. Otherwise you would see black space when you’re on the high mountain. But technically, when you’re leaving the planet’s atmosphere all of these high peaks and mountains are starting to slowly collapse vertically forming a smooth spherical shape of the planet, if they wouldn’t - we would have planets looking like a spiky balls with mountain peaks sticking out in all directions. That’s why when all the high peaks are collapsed to the ground to form a perfect sphere - we are left with abnormally thick and wrong looking atmospheric layer thickness when observed from the outer space. How to fix this?! That’s where “Rayleigh Height Space” slider comes into play, as it controls the thickness of the atmospheric layer seen from outer space.

Rayleigh Height Space (slider) – Controls the thickness of atmospheric layer when you observing the planet from outer space. Like it was said earlier, settings for atmosphere thickness when you’re on the Surface and when you’re in an outer Space can’t be same and normally you want to make it much thinner when it is seen from outer space like it’s in real world. Refer to the following Pic to get better understanding.

Rayleigh Transition (slider) – Ok, so now that we have set the width of the planetary atmosphere for both - when we’re on the Surface and when we’re observing it from outer space, it is time to decide at which distance to switch between two, right? So that’s exactly what this slider does – sets the exact value at which distance that transition must happen. You can play around with this value to find the best setting, just remember that the main goal is to have this transition as smooth as possible, fortunately it’s super easy to achieve. Just make sure that while you’re on the ground and standing on a highest point you still see some atmosphere color (like Blue color in earthlike planets) ,and just about when you start to see the whole planet on your way to the outer space, switch it to the thinner (Rayleigh Height Space) version.

Mie Height (slider) – Controls the size of the outer glow effect of the Sun. Like it was said earlier, when you’re setting your color of the Glow effect via “Mie Scattering RGB” sliders, this particular setting (Mie Height) must be set to a fairly high value otherwise you won’t see it as there won’t be any glow. Look, you can’t change the color of a non-existing thing, soldier. Dismissed!

Sun size (slider) – Controls the size of the Sun.. What else did you expect from it?!

Sea Floor modifier (slider) – Defines the lowest (starting) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer starts. It depends on your planet’s relief, your lowest and highest peaks. Adjust individually for each planet. You’ll “feel” the right value immediately.

Atmosphere Top Modifier (slider) – Defines the highest (ending) edge of the atmosphere. Sometimes it is needed to set how low (or how high) actual atmospheric layer stops. It depends on your planet’s relief. Adjust individually for each planet. You’ll “feel” the right value immediately. But normally you want this value to be set pretty high.

Intensity (slider) – Actually it should be called “Fog Intensity” as it’s exactly what it’s responsible for but I hope it will be changed by some coder guys eventually J. Controls the amount or intensity of the fog while you’re on or near the planet’s surface (doesn’t do anything when you’re in outer space).

Fog Intensity (slider) – And this, should be actually called “Fog Distance”. It controls the distance fog actually covers. The higher this value – more objects in front of view are covered with fog. (doesn’t do anything when you’re in outer space).

Restore (Button) – Ok, just in case you screw everything up, you always have a chance to revert all the changes you’ve made by clicking this Restore button, soldier! Very convenient isn’t it?!

==Atmosphere 2/2==
Ok, now that we got acquainted with all Atmosphere settings and know how they work, it is time for us to actually change a few settings to alter the look of our Atmosphere! Now the fun part begins. Let’s say that we want to change the color of Earthlike planet’s atmosphere from its natural Blue color to the Green one, so it looks more “alienish”. Please note, that all atmosphere settings are stored in “PlanetGeneratorDefinitions.sbc” file and they are NOT replaced even when you change these values in game and make a save. If you want to change those values you have to change them directly in the code of the “PlanetGeneratorDefinitions.sbc” file only! The system reads those atmosphere values from this file every time you’re loading your worlds.

But how for God’s sake would you know which values are correct and really desirable to put them in the code? This is really simple. You just adjust your atmosphere settings to your liking right in the game, and when you’re done and happy with it, you just copy those values into the code (you can screen grab the in-game view with Atmosphere Settings window or just write them down manually, not a big deal) But to paste those values in the code, you have to know WHERE to paste it, right? You don’t just randomly paste numbers into the code, do you? You may hurt yourself!

So please open “PlanetGeneratorDefinitions.sbc” file in any decent text editor and find the following line:
<pre>
<SubtypeId>EarthLike</SubtypeId>
</pre>
It’s a name or identifier of a planet, and since it’s named Earthlike, we know for sure that below are the definitions related to Earthlike planet. Cool! Now just scroll down to the part where you will see a commented (inactive) line of code which goes like:



Or alternatively, just Ctrl+F to find the following line. You must see something similar to this:

[[File:Atmosphere definition.jpg|512px]]

So here as you can see everything is pretty self-explanatory. Except a few lines that are just named differently in the code. If you want your atmosphere to “remember” the settings you have made you have to enter those values here to the corresponding lines. The following schematic pic shows dependencies between the code lines and the slider names in Atmosphere Settings window quite clearly:
(Click to enlarge)

[[File:In-game Atmosphere Debug Input.jpg|1024px]]

Now let’s just change the blue color of the atmosphere to orange. As you remember, group of three RGB sliders named “Rayleigh Scattering” are responsible for changing the main color of the Atmosphere. So why wait?

[[File:Mars-Like Atmosphere.jpg|1024px]]

Spectacular right? Now, let’s change the sun glow color “Mie Scattering RGB” to an orange tint too. It could stay the same yellow of course but let’s change it so you could have an idea. Remember to press “Alt” on your keyboard while you’re dragging those sliders.

[[File:Another Red Atmosphere.jpg|1024px]]

Ok, now it’s more orange but we have to increase the glow effect a bit to see it more prominently. And as we remember, the glow size control is “Mie Height” slider. Crank it up from 30 to 50.

Good, the glow effect became more prominent. Looking nice isn’t it? Of course, you can continue adjusting it and come up with really crazy results, but if you’re ok with what we already have, then just write down all the values that you currently have in your Atmosphere Settings window on the right or screenshot them and paste into any image editor for your reference. And back in the code editor, just enter those values into corresponding tags in the code and save it:

[[File:CloseUp Atmosphere definition.jpg|512px]]

That’s it! From now on, every time you load up your world with Earthlike planet in it, or spawn Earthlike planet, the atmosphere on it will be exactly the way you adjusted it via Atmosphere Settings! The God himself must have been using something like this we suppose..

[[File:Mars-like Atmosphere Final.jpg|1024px]]

==Clouds==
The first thing that should (probably) come in to your mind when you finally learn how to tweak Atmosphere settings, is probably how to change the look of the Clouds! Because, normally, when you change the color of the atmosphere you would like the clouds color to be relatively close to the Atmosphere color. In our Atmosphere guide (if you read it) we were sharing some knowledge about changing the look of the Atmosphere. We made it orange which is kind of cool all on its own, but what really draws our attention and not in a very good way – is the color of the clouds. As you can see they’re white which is looking wrong isn’t it? In an orange atmosphere environment you would expect orange or yellow clouds right? So that’s what we’ll be doing in a minute – changing the look of our cloud layer and getting to know their under-the-hoods.

Like with Atmosphere settings, the Clouds setting are stored in the same “PlanetGeneratorDefinitions.sbc” file located in KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Data and are individual for each planet. Usually we base our code lines so the Cloud definitions come right after Atmosphere definitions which makes it very convenient to search for. Just open your “PlanetGeneratorDefinitions.sbc” file in any decent advanced text editor and search for this commented (inactive) line of code:



Note: you can download the DDS files from here[mirror.keenswh.com]

[[File:Cloud Layers Definition.jpg|1024px]]

That’s where all the cloud settings for particular planet are stored. The following picture is a brief breakdown of cloud definitions:

Basically, the structure of placing clouds on any planet is as follows:
<pre>
<CloudLayers>
<CloudLayer>
Blah Blah Blah Beautiful Clouds Blah Blah Blah
</CloudLayer>
</CloudLayers>
</pre>
So, as you can see everything is super easy. Simply put, <CloudLayers> tags are meant for global separation of Cloud definitions from other code definitions and are here just to define where the code for the clouds start, while <CloudLayer> tags (again, don’t mistake with CloudLayers) are the actual cloud layers and each pair of these tags (<CloudLayer>…</CloudLayer>) define the look and behavior of each cloud layer. As Captain Obvious states - The more <CloudLayer> pairs you have.. umm - the more cloud layers you will have!

For example. You can have more than one Cloud layer, to simulate even more complex cloud patterns than you initially had in your texture file! And that’s when <InitialRotation> and <RotationAxis> tags come into play. You can assign values to these tags for each Cloud layer individually thus having the cloud spheres to be initially rotated and spinning on different angles creating more interesting and natural cloud patterns. So you basically just stack them this way:
<pre>
<CloudLayers>
<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>

<CloudLayer>LAYERPROPERTIES</CloudLayer>
</CloudLayers>
</pre>

That’s it! Now you have three Cloud Layers! And of course you can do it for the Far and the Near cloud layers as well.

Your main cloud color texture must be 4096x2048px RGB file saved in DDS format without alpha as “CloudName_cm.dds file” and it must contain only the color information of your clouds. For Alphamask file please create a separate file of the same 4096x2048px dimensions containing only Alpha mask, make it a greyscale file, save as DDS luminance format and name it “CloudName_Alphamask.dds”. Back in the code, in <texture> tags you just write “Cloudname.dds”, no worries - the engine will identify required “cm” and “alphamask” files itself, just make sure both files are in the correct folder. (KeenSWH\Sandbox\Sources\SpaceEngineers\Content\Textures\Models\Environment\Sky).

As you know, clouds that are seen from the outer space and the clouds that you see through your window don’t look the same because of the huge differences in scales in both cases. That’s why we have two types of clouds on each planet. First one (commented as “Far layer” in the code) – the clouds that you see from the outer space. They usually look like NASA satellite orbital photo shots.

[[File:Clouds.jpg|1024px]]

And the Second one (commented as “Near layer” in the code) – the clouds that are seen when you’re on the ground or close to it. These should look like a significantly zoomed version of the first ones - more detailed, wispy and more individual. Like the ones you used to see in the sky every day. Refer to the picture.

[[File:LargeClouds.jpg|1024px]]

Now, how to actually separate these two types of cloud layers and to make them come in layers – one after the other. This is very simple too. The maximum overall Altitude (height) of our atmosphere layer is 2. So we have to set up our cloud layers in a tricky way, so that when we’re in outer space - we would see the “Far layer” clouds ONLY, and as we’re getting lower (approaching the ground), on a particular altitude (height) smoothly switch to the “Near layer” clouds and have the “Far layer” clouds hidden. Sounds crazy but it will become clear if you look at the following pic:

[[File:CloudLayerDiagram.jpg|1024px]]

As you can see things are really self-explanatory here too. By setting the Start and End values in <FadeOutRelativeAltitude..> you basically create a vector, the starting point of which is infinity which means anything below this start point will be constant value, thus – making it possible to set the Far layer to be seen from outer space (values greater than 2), and preventing Near cloud layer from being seen - because it is set to fade out on 1.6. And vice versa – when you’re on the ground, you won’t see Far layer clouds layer because it faded out on much higher distance of 1.4. Not so hard right? Of course you can alter and tweak those values to your liking depending on the planets height maps/relief to get the desired transition between Far and Near cloud layers.

So now that we’re empowered with this knowledge, the only thing we’re left to do is to actually change the color of the clouds from white to yellow color so our clouds look more natural in an orange Atmosphere environment. As we remember, our clouds are consisting of two texture files – a file containing color information (usually just a plain color) and a file with an alpha mask only. We already know that the “Far layer” clouds (the ones seen from space) use “EarthFarClouds_cm.dds” texture file and the “Near layer” clouds use “Landsky_texture_cm.dds”. How we know that? It’s written in <texture> </texture> definitions, remember?

[[File:CloudTextureRoute.jpg|512px]]

Great! So now just open “EarthFarClouds_cm.dds” and the “Landsky_texture_cm.dds” and fill both files with plain yellow color and save them!

[[File:YellowCloud Texture.jpg|1024px]]

Start the game and spawn an Earthlike planet and voila! You got perfect yellow clouds!

[[File:Scenery With Yellow Clouds.jpg|1024px]]

==Planet ambient sounds modding - day/night biome sounds==

Sound rules are in the Content\Data\PlanetGeneratorDefinitions.sbc file. Here you can set different sounds based on player’s location or daytime on the planet.
<pre>
<SoundRule>
<Height Min="0" Max="0.5"/>
<Latitude Min="55" Max="80"/>
<SunAngleFromZenith Min="0" Max="180"/>
<EnvironmentSound>AmbIcelandDay</EnvironmentSound>
</SoundRule>
</pre>
Height stands for where you want the sound to play at the height of the heightmap (0-7200m). It is always +12% of the planet's diameter. 0 is from the the lowest start of the surface to 1.0 which is 100% of the surface (maximum height).
Latitude means angle from the equator. Therefore 0 to 20 will mean that this sound will mostly play in the desert area, 20-50 is mostly the green forest area, and so on.
SunAngleFromZenith NEEDS MORE INFO!!!
EnvironmentSound this is the name of the sound you want to use.

You can find all available sounds in Audio.sbc (location shown below) Here you will also put your own ambient sound with your own custom name.

How to implement custom ambient sound

All Ambient sounds are stored here:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Audio\ARC\AMB\

If you want your own sounds, they should be a loop sound, and on average should not be bigger than +-5 MB.
The supported format is: .xwm but .wav can also work, even though its file size is usually a lot bigger (not recommended).

Once your audio is done, implement it here in this file:

C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content\Data\Audio.sbc
<pre>
<Sound>
<Id>
<TypeId>MyObjectBuilder_AudioDefinition</TypeId>
<SubtypeId>AmbAlienForestDay</SubtypeId>
</Id>
<Category>AMB</Category>
<MaxDistance>100</MaxDistance>
<Volume>0.2</Volume>
<Loopable>true</Loopable>
<Waves>
<Wave Type="D2">
<Loop>ARC\AMB\AmbAlienForestDayLoop2d.xwm</Loop>
</Wave>
</Waves>
</Sound>
</pre>
Here edit only what is highlighted, otherwise I cannot guarantee that it will work properly!
<SubtypeId> This is how you will name your AMB sound, keeping in mind upper and lower case letters. Do not use _ or other special characters!
<Volume> This is self explanatory I hope.
<Loop> Here you just need to lead the definition to your file. ARC/AMB/ is the default location, so do not change that.
But if you want, you can make another folder in AMB for your custom ambient sounds for better organisation.

==In-game map modding==
Maps in Medieval Engineers are generated based on terrain and buildings on it. This means that they will work for any modded planet in their default form. That being said, the way map is generated is also fully moddable.

We definitions for map are located in Content\Data\Screens\MapDefinition.sbc. To mod maps you will have to alter/add definitions in this file, all vanilla textures for maps can be found in Content\Textures\GUI\Map. Feel free to use/alter any of them for creation of mods for Medieval Engineers.
Map content modding (Friend/foe display, tax notifications,...
In Medieval Engineers there are 2 view modes of map. Kingdom view which is showing entire kingdom and region view which is zoomed part of a kingdom map. Region is 1kmx1km large on 10 km diameter planet. Both views display different elements.
What is shown in these views depends on what layers it contains
<pre>
<Definition xsi:type="MyObjectBuilder_PlanetMapDefinition">
<Id Type="MyObjectBuilder_PlanetMapDefinition" Subtype="Main"/>
<BackgroundGenerator Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
<RegionView>
<Layers>...</Layers>
</RegionView>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</Definition>
</pre>
BackgroundGenerator refers to a definition of background texture that serves as a background on top of which all the map elements are placed.
<pre>
<RegionView>
<Layers>...</Layers>
</RegionView>
</pre>
The three dots in middle represent layers of elements that show in region view. List and description of all layers is in next section of this document.
<pre>
<KingdomView>
<Layers>...</Layers>
</KingdomView>
</pre>
The three dots in middle represent layers of elements that show in kingdom view. List and description of all layers is in next section of this document.
(I did not Kingdom view in its expanded form because it would take up too much space.)

===Layers description===
<pre><Layer xsi:type="MyObjectBuilder_MapBackgroundLayer" /></pre>
This layer draws the background. As generated based on chosen background definition.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaDevelopmentLayer">
<Threshold BlockCount="10" Sprite="Textures\GUI\Map\SmallGrid.png"/>
<Threshold BlockCount="30" Sprite="Textures\GUI\Map\MediumGrid.png"/>
<Threshold BlockCount="60" Sprite="Textures\GUI\Map\LargeGrid.png"/>
</Layer>
</pre>
This layer displays icons based on amount of blocks there is in an area. You can set the block thresholds, or mod the textures. It is also possible to add more thresholds. 80x80 px, png.

[[File:Smallest Settlement.png|150px|frameless]]
[[File:Medium Settlement.png|150px|frameless]]
[[File:LargestSettlement.png|150px|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_RegionFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for region, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_AreaOwnershipLayer">
<AlliedBgColor Hex="#806464FF" />
<PlayerBgColor Hex="#8064FF64" />
<EnemyBgColor Hex="#80DC6415" />
</Layer>
</pre>
This layer defines color overlay over map areas based on ownership. You can mod which color is used for allies, your own areas or for enemies
<pre>
<Layer xsi:type="MyObjectBuilder_AreaUpkeepLayer">
<TaxIcon>Textures\GUI\Map\TaxIcon.png</TaxIcon>
</Layer>
</pre>
This layer displays tax icon on areas that belong to you and require tax payment soon. Texture is 80x80 pixels, png.
[[File:Taxes.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapPositionLayer">
<LocalPlayerImage>Textures\GUI\Map\PlayerPosition.png</LocalPlayerImage>
<OtherPlayersImage>Textures\GUI\Map\AllyPosition.png</OtherPlayersImage>
</Layer>
</pre>
PlanetMapPositionLayer displays player icon above area where they are.
[[File:Ally.png|frameless]]
[[File:Player.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_ActionTrackingLayer">
<ActionImage>Textures\GUI\Map\Action.png</ActionImage>
</Layer>
</pre>
Shows icon over an area on map with fighting / destruction.
[[File:AttackedArea.png|frameless]]
<pre>
<Layer xsi:type="MyObjectBuilder_CurrentMapSelectionLayer">
<SelectionImage>Textures\GUI\Map\MapSelection.dds</SelectionImage>
</Layer>
</pre>
This is highlight of a region, that player selected with his mouse.
<pre>
<Layer xsi:type="MyObjectBuilder_PlanetMapGridLayer">
<GridColor R="0" G="0" B="0" A="228"/>
</Layer>
</pre>
This layer sets which color is the grid drawn.
<pre>
<Layer xsi:type="MyObjectBuilder_KingdomFastTravelLayer" Name="FastTravel" Visible="false">
<UnreachableColor R="255" G="255" B="255" A="128"/>
<ReachableColor R="100" G="255" B="100" A="0"/>
<BlockedByTerrainColor R="0" G="0" B="0" A="224"/>
<BlockedByPlayerColor R="240" G="192" B="0" A="128"/>
</Layer>
</pre>
This layer shows fast travel overlay for kingdom, when fast travel button is pressed. You can define which colors are used for displaying accessibility.
<pre>
<Layer xsi:type="MyObjectBuilder_RegionOwnershipLayer">
<PlayerIcon>Textures\GUI\Map\PlayerLandIcon.png</PlayerIcon>
<AllyIcon>Textures\GUI\Map\AllyLandIcon.png</AllyIcon>
<EnemyIcon>Textures\GUI\Map\EnemyLandIcon.png</EnemyIcon>
<PlayerAllyIcon>Textures\GUI\Map\PlayerAllyLandIcon.png</PlayerAllyIcon>
<PlayerEnemyIcon>Textures\GUI\Map\PlayerEnemyLandIcon.png</PlayerEnemyIcon>
<AllyEnemyIcon>Textures\GUI\Map\AllyEnemyLandIcon.png</AllyEnemyIcon>
<PlayerAllyEnemyIcon>Textures\GUI\Map\PlayerAllyEnemyLandIcon.png</PlayerAllyEnemyIcon>
</Layer>
</pre>
RegionOwnershipLayer generates textures used to express ownership on regional map.

===Background generator (trees, mountains, roads,...)===
Map background is where all the trees, mountains, hills are drawn. It is also capable of coloring map based on what is in planet’s material map (this is how we make roads for example).
All settings for map background are in MedievalMapBackgroundDefinition. The definition also in Content\Data\Screens\MapDefinition.sbc. I will go through various parts of the definition.

<pre><Id Type="MyObjectBuilder_MedievalMapBackgroundDefinition" Subtype="FundinhoDoMapinha"/>
Type of the definition says that this map background definition. Subtype is name of this specific background definition. If create your own background with unique subtype
Make sure you create your own background with unique subtype

<DrawHeightmap>false</DrawHeightmap>
When set on “true” planet’s heightmap is drawn under the map.
<Resolution>4096</Resolution><
Sets resolution of the generated in-game map.

<Features>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</Features>

<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</Definition>
</pre>
===Map Coloring===
You can use colors in material or biome map of a planet to appear on the game map. (roads for example). You define map coloring in a node called ”Features”. The coloring uses colors from planet material texture. You can learn more about material texture in biomes modding and surface material modding.
<pre>
<Feature Material="67">
<Color R="75" G="30" B="0" A="255"/>
</Feature>
</pre>
This specific feature is used for painting roads on map with dark brown color. In Color you define which color will be the in-game map colored. Material=”67” decides where will be the color applied and refers to a red channel value on planet material texture.
<pre>
<Feature Biome="60">
<Color R="130" G="100" B="42" A="80"/>
</Feature>
</pre>
This specific feature is used for painting forests on map with opaque brown. In Color you define which color will be the in-game map colored. Biome=”60” decides where will be the color applied and refers to a green channel value on planet material texture.

===Sprites===
Medieval Engineers map can also place sprites on map based on terrain shape. All the sprites are on one texture
<pre>
<SpriteSheet Texture="Textures\GUI\Map\BackgroundSprites.png" BaseSize="64">
<SpriteCount>100</SpriteCount>
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />
<Sprite Name="ForestSparse" X="0" Y="320" Width="64" Height="64" />

<HeightSprite AltitudeDiff=".09" Altitude=".20" Priority="1">
<Sprite>HillSmall</Sprite>
</HeightSprite>
<BiomeSprite Biome="60" Density=".1" Priority="6">
<Sprite>ForestSparse</Sprite>
</BiomeSprite>
</SpriteSheet>
</pre>

[[File:AtlasCoordinateUsage.png|512px]]

Note: Illustrates how sprite is defined on our spritesheet. Example sprite:
<Sprite Name="HillSmall" X="768" Y="192" Width="127" Height="64" />

==Voxel color overlay modding==
We have a cool tech that enables us to color-shift color of almost any item in the game. Currently we are using it for trees(adds small color variations to the same model of a tree) and voxels above iron deposits.
==Fast travel settings modding==
In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around.
In this section of the guide we will show you how to mod which sectors are blocked.
There are 2 ways you can go about it:
===Generate automatically based on terrain shape===
Game is capable of creating fast travel map on its own based on height and terrain steepness. It is possible to mod thresholds for both height and steepness.
You will find the thresholds in Content\Data\Game\FastTravel.sbc. In a MyObjectBuilder_TerrainReachabilityProviderDefinition.
<RiseThreshold> - Sets min. terrain height change which will cause that area is unreachable.
<HeightThreshold> - Sets height of terrain after which area is unreachable, if it goes over this value. Range is 0 - 1.

If there are texture overrides in the definition, you have to erase them in order for the parameters to take effect. Texture overrides are nodes that are called in this fashion: <OverrideNAMEOFFACE>. You will learn more about these overrides in the next part of Fast travel modding.

===Creating fast travel texture override===
If you want to have full control over which areas are reachable and which are not regardless of terrain, you can create a simple texture on which you mark unreachable areas.

The texture is 80x80 pixels, RGB 8 bit. Black pixels forbid entrance.

When you have the texture, select route to it in the definition:
<pre><OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward></pre>
Reachability definition example:
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>
<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>
<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
</Definition>
</pre>
This definition would generate fast travel reachability everywhere, except for front planet face (Fareon kingdom) where fast travel reachability is created based on your texture.

===Development reachability===
Claimable area size, border highlight, contested timer modding
Size of the area and highlight properties are moddable as well.

===Area borders highlight===
<NeutralColor R="225" G="32" B="0" A="64" /> - Set color of an unowned territory
<SelfColor R="0" G="255" B="0" A="64" /> - Sets color of area border owned by you
<AliedColor R="65" G="105" B="225" A="64" /> - Sets color of area border that belongs to allies
<EnemyColor R="225" G="32" B="0" A="64" /> - Sets color of area border that is hostile
<WallSettings Depth="15" Rise="3" SegmentCount"71" End="115" /> - Changes shape of the border. Depth sets how deep is border submerged. Rise sets how tall is the border.
<Fade Start="71" End="115" /> - This sets at which point the border starts to fade.
Contested timer
When players claim area with claimblock, area goes to a “contested” phase for some amount of time, in this phase other players can still attempt to build their own claim block and claim the area. This time is moddable.
Content\Data\Game\SessionComponents.sbc contains definition called MyObjectBuilder_AreaOwnershipSystemDefinition. To mod this value, add this definition to your mod with changed value of <ContestedTimeInMinutes> parameter.

==Permissions modding - what is/isn’t allowed to do in claimed areas==
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.
Description of available actions to set permissions for:
Name=”Build” -> block placement permissions
Name=”Repair” -> Repairing/building already placed blocks
Name=”Deconstruct” -> Deconstructing
Name=”QuickDeconstruct” -> Faster deconstruction
Name=”VoxelEdit” -> Mining or shoveling
Name=”Destroy” -> Damage with hand weapons
Name=”Interaction” -> Chest opening, door opening
Name=”ClaimBlockInteraction” -> ClaimblockGui

===List of available Groupnames:===
Groupname: “Owner” -> Player who owns area
Groupname: “Allies” -> Mostly faction members of owner of the area
Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
Groupname: “Enemies” -> Players in factions that are hostile to your faction

==Compass modding==
It is possible to mod visual look of an in-game compass. All definitions of compass are stored in Content\Data\GUI\CompassDefinition.sbc. Our textures for compass are in Content\Textures\GUI\Compass folder if you want to check out how they look or use them in your mod.
===Creating compass texture atlas and setting coordinates for its elements===
Just like with map sprites, we save main compass elements on a single texture, then define parts of it using pixel coordinates. First setup origin point, then add width and height of the rectangle
Example texture coordinates for top part of the compass:
[[File:CompassTextureCoordinates.png|1024px]]
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>

===Explanation of compass definition line by line===
<pre><Texture>Textures/GUI/Compass/compass.png</Texture> </pre>
Route to a texture atlas.
<pre><KingdomIcon>Textures/GUI/Compass/Icon-Kingdom.png</KingdomIcon> </pre>
Route to icon symbolizing a kingdom.
<pre><Padding>7</Padding></pre>
Padding is added vertically between the top and bottom textures and the edges of the contents of the compass.
<pre><TopCrop X="0" Y="0" Width="512" Height="32"/></pre>
Rectangle in the texture that contains the top part.
<pre><BottomCrop X="0" Y="0" Width="0" Height="0"/></pre>
Rectangle in the texture that contains the bottom part.
<pre><BackgroundCrop X="0" Y="64" Width="512" Height="64"/></pre>
Rectangle in the texture that contains the background.
<pre><ArrowCrop X="0" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the little marker used for elements that are drawn and have no icon.
<pre><MarkerCrop X="32" Y="128" Width="32" Height="32"/></pre>
Rectangle in the texture that contains the interval bars drawn every few degrees.
<pre><ShadowCrop X="64" Y="128" Width="80" Height="32" Left="8" Right="8"/></pre>
<pre><ShadowPadding Left="12" Top="8" Right="12" Bottom="8"/></pre>
Rectangle in the texture that contains the text shadows. Shadow is 3-Sliced, meaning the texture is split in three parts: [left|middle|right]
The sizes of left and right define the cropping lines that split the texture into three. The Sides are then always kep proportional as the texture is scaled.
<pre><VisibleRange>200</VisibleRange></pre>
Visible range in degrees.
<pre><Width>700</Width></pre>
Width in reference resolution pixels.
<pre><FontSize>1.1</FontSize></pre>
Scale of the font based on default.
<pre><VerticalOffset>0.065</VerticalOffset></pre>
Vertical offset from the top of the screen. 0 = top of the screen, 1 is the bottom. Compass is centered around this position.
<pre>
<TagStyles>
<TagStyle Tag="ClaimArea" Style="Bellow" MaxCharacters="15" Ellipsis="true"/>
<TagStyle Tag="Cardinal" Style="Above" MaxCharacters="1"/>
<TagStyle Tag="Kingdom" Style="Bellow"/>
</TagStyles>
</pre>
This section adds tags that are visible on compass and in which style. Currently we have 3 types of tags. Claim area - shows your claimed area on the compass, Kingdom tag shows kingdoms and Cardinal tag shows cardinal points (North, South,...). Each tag’s visual appearance is defined in tag/waypoint definition. Styles defines where should the text appear. Available styles: Center, IconOnly, NotShown, Bellow, Above.

===Explanation of Waypoint/Tag definition===
<pre>
<Definition xsi:type="MyObjectBuilder_WaypointDefinition">
<Id Type="MyObjectBuilder_WaypointDefinition" Subtype="Kingdom"/>
<IconPath>Textures/GUI/Compass/IconKeep.png</IconPath>
<Color R="255" G="255" B="255" A="255"/>
</Definition>
</pre>
IconPath contains path to the texture of kingdom icon. Color defines color of the text that is shown with the icon. (Example: Fareon, [[File:Kingdom Icon.png|thumb]])
===Compass texture vs in-game look comparison===
Texture:

[[File:Compas Texture with Zones.png|1024px]]

In-game look:

[[File:In-gameCompassZones.png|1024px]]
<NoWiki>*</NoWiki>note that background crop and bottom crop are not used in vanilla (empty opaque texture)

===Indestructible grids===
There is a way how to make some buildings in your save indestructible. We are using this feature for starting area buildings. Some you guys might make a good use of this feature in your pre-made worlds.

Currently, only way how to do this is to make edits to an existing save file. So you can only use it for world modding.
===Making indestructible cubegrids in existing safe===
Goal is to open world’s safe file in a text editor, find your cubegrid in it and add this tag to it: <DestructibleBlocks>true</DestructibleBlocks>.

#Find your save file. By default save files are stored in C:\Users\YOURUSERNAME\AppData\Roaming\MedievalEngineers\Saves
#Open folder with your save and find file called SANDBOX_0_0_0_.sbs. This file can be opened with any text editor you prefer.
#In the SANDBOX_0_0_0_.sbs search for the cubegrid name of the building you want to make indestructible. (use find/search function in your text editor, or you will grow old before you find it)
#Tip: To find out name of a cubegrid, create blueprint of the building. The name that the building saves as in your blueprint screen is the name of the cubegrid.
#You should find the name in tags called: <DisplayName>YOURCUBEGRIDNAME</DisplayName>
#Under the name, add following tag with setting set to false: <DestructibleBlocks>false</DestructibleBlocks>
#If you followed instruction, the indestructibility tag is now in node called <MyObjectBuilder_EntityBase> and not in any of its child nodes.
#Save the edited file.
#Load the save and test destructibility
#It worked! Enjoy
#It is still destructible. Go to point 1.

[[Category:Keen_Modding_Guides]]

Keen:Planet Modding/Fast Travel

2017-03-13T11:02:53Z

Lukas: /* Generate automatically based on terrain shape */

==Fast travel settings modding==
In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around.
In this section of the guide we will show you how to mod which sectors are blocked.
There are 2 ways you can go about it:
===Generate automatically based on terrain shape===
Game is capable of creating fast travel map on its own based on height and terrain steepness. It is possible to mod thresholds for both height and steepness.
You will find the thresholds in Content\Data\Game\FastTravel.sbc. In a MyObjectBuilder_TerrainReachabilityProviderDefinition.
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>

<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>

<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
<OverrideBackward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Back_ForbiddenAreas.png</OverrideBackward>
<OverrideLeft>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Left_ForbiddenAreas.png</OverrideLeft>
<OverrideRight>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Right_ForbiddenAreas.png</OverrideRight>
<OverrideUp>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Up_ForbiddenAreas.png</OverrideUp>
<OverrideDown>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Down_ForbiddenAreas.png</OverrideDown>
</Definition>
</pre>
'''<RiseThreshold>''' - Sets min. terrain height change which will cause that area is unreachable.

'''<HeightThreshold>''' - Sets height of terrain after which area is unreachable, if it goes over this value. Range is 0 - 1.

If there are texture overrides in the definition, you have to erase them in order for the parameters to take effect. Texture overrides are used to override the generated fast travel map. You will learn more about these overrides in the next part of Fast travel modding.

===Creating fast travel texture override===
If you want to have full control over which areas are reachable and which are not regardless of terrain, you can create a simple texture on which you mark unreachable areas.

The texture is 80x80 pixels, RGB 8 bit. Black pixels forbid entrance.

When you have the texture, select route to it in the definition:
<pre><OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward></pre>
Reachability definition example:
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>
<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>
<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
</Definition>
</pre>
This definition would generate fast travel reachability everywhere, except for front planet face (Fareon kingdom) where fast travel reachability is created based on your texture.

===Development reachability===
Claimable area size, border highlight, contested timer modding
Size of the area and highlight properties are moddable as well.

===Area borders highlight===
<NeutralColor R="225" G="32" B="0" A="64" /> - Set color of an unowned territory
<SelfColor R="0" G="255" B="0" A="64" /> - Sets color of area border owned by you
<AliedColor R="65" G="105" B="225" A="64" /> - Sets color of area border that belongs to allies
<EnemyColor R="225" G="32" B="0" A="64" /> - Sets color of area border that is hostile
<WallSettings Depth="15" Rise="3" SegmentCount"71" End="115" /> - Changes shape of the border. Depth sets how deep is border submerged. Rise sets how tall is the border.
<Fade Start="71" End="115" /> - This sets at which point the border starts to fade.
Contested timer
When players claim area with claimblock, area goes to a “contested” phase for some amount of time, in this phase other players can still attempt to build their own claim block and claim the area. This time is moddable.
Content\Data\Game\SessionComponents.sbc contains definition called MyObjectBuilder_AreaOwnershipSystemDefinition. To mod this value, add this definition to your mod with changed value of <ContestedTimeInMinutes> parameter.

Permissions modding - what is/isn’t allowed to do in claimed areas
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.

===Description of available actions to set permissions for:===
#Name=”Build” -> block placement permissions
#Name=”Repair” -> Repairing/building already placed blocks
#Name=”Deconstruct” -> Deconstructing
#Name=”QuickDeconstruct” -> Faster deconstruction
#Name=”VoxelEdit” -> Mining or shoveling
#Name=”Destroy” -> Damage with hand weapons
#Name=”Interaction” -> Chest opening, door opening
#Name=”ClaimBlockInteraction” -> ClaimblockGui

===List of available Groupnames:===

#Groupname: “Owner” -> Player who owns area
#roupname: “Allies” -> Mostly faction members of owner of the area
#Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
#Groupname: “Enemies” -> Players in factions that are hostile to your faction

Keen:Planet Modding/Fast Travel

2017-03-13T11:00:39Z

Lukas: /* Generate automatically based on terrain shape */

==Fast travel settings modding==
In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around.
In this section of the guide we will show you how to mod which sectors are blocked.
There are 2 ways you can go about it:
===Generate automatically based on terrain shape===
Game is capable of creating fast travel map on its own based on height and terrain steepness. It is possible to mod thresholds for both height and steepness.
You will find the thresholds in Content\Data\Game\FastTravel.sbc. In a MyObjectBuilder_TerrainReachabilityProviderDefinition.
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>

<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>

<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
<OverrideBackward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Back_ForbiddenAreas.png</OverrideBackward>
<OverrideLeft>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Left_ForbiddenAreas.png</OverrideLeft>
<OverrideRight>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Right_ForbiddenAreas.png</OverrideRight>
<OverrideUp>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Up_ForbiddenAreas.png</OverrideUp>
<OverrideDown>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Down_ForbiddenAreas.png</OverrideDown>
</Definition>
</pre>
<RiseThreshold> - Sets min. terrain height change which will cause that area is unreachable.
<HeightThreshold> - Sets height of terrain after which area is unreachable, if it goes over this value. Range is 0 - 1.

If there are texture overrides in the definition, you have to erase them in order for the parameters to take effect. Texture overrides are used to override the generated fast travel map. You will learn more about these overrides in the next part of Fast travel modding.

===Creating fast travel texture override===
If you want to have full control over which areas are reachable and which are not regardless of terrain, you can create a simple texture on which you mark unreachable areas.

The texture is 80x80 pixels, RGB 8 bit. Black pixels forbid entrance.

When you have the texture, select route to it in the definition:
<pre><OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward></pre>
Reachability definition example:
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>
<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>
<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
</Definition>
</pre>
This definition would generate fast travel reachability everywhere, except for front planet face (Fareon kingdom) where fast travel reachability is created based on your texture.

===Development reachability===
Claimable area size, border highlight, contested timer modding
Size of the area and highlight properties are moddable as well.

===Area borders highlight===
<NeutralColor R="225" G="32" B="0" A="64" /> - Set color of an unowned territory
<SelfColor R="0" G="255" B="0" A="64" /> - Sets color of area border owned by you
<AliedColor R="65" G="105" B="225" A="64" /> - Sets color of area border that belongs to allies
<EnemyColor R="225" G="32" B="0" A="64" /> - Sets color of area border that is hostile
<WallSettings Depth="15" Rise="3" SegmentCount"71" End="115" /> - Changes shape of the border. Depth sets how deep is border submerged. Rise sets how tall is the border.
<Fade Start="71" End="115" /> - This sets at which point the border starts to fade.
Contested timer
When players claim area with claimblock, area goes to a “contested” phase for some amount of time, in this phase other players can still attempt to build their own claim block and claim the area. This time is moddable.
Content\Data\Game\SessionComponents.sbc contains definition called MyObjectBuilder_AreaOwnershipSystemDefinition. To mod this value, add this definition to your mod with changed value of <ContestedTimeInMinutes> parameter.

Permissions modding - what is/isn’t allowed to do in claimed areas
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.

===Description of available actions to set permissions for:===
#Name=”Build” -> block placement permissions
#Name=”Repair” -> Repairing/building already placed blocks
#Name=”Deconstruct” -> Deconstructing
#Name=”QuickDeconstruct” -> Faster deconstruction
#Name=”VoxelEdit” -> Mining or shoveling
#Name=”Destroy” -> Damage with hand weapons
#Name=”Interaction” -> Chest opening, door opening
#Name=”ClaimBlockInteraction” -> ClaimblockGui

===List of available Groupnames:===

#Groupname: “Owner” -> Player who owns area
#roupname: “Allies” -> Mostly faction members of owner of the area
#Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
#Groupname: “Enemies” -> Players in factions that are hostile to your faction

Keen:Planet Modding/Fast Travel

2017-03-13T11:00:00Z

Lukas: /* Generate automatically based on terrain shape */

==Fast travel settings modding==
In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around.
In this section of the guide we will show you how to mod which sectors are blocked.
There are 2 ways you can go about it:
===Generate automatically based on terrain shape===
Game is capable of creating fast travel map on its own based on height and terrain steepness. It is possible to mod thresholds for both height and steepness.
You will find the thresholds in Content\Data\Game\FastTravel.sbc. In a MyObjectBuilder_TerrainReachabilityProviderDefinition.

<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>

<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>

<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
<OverrideBackward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Back_ForbiddenAreas.png</OverrideBackward>
<OverrideLeft>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Left_ForbiddenAreas.png</OverrideLeft>
<OverrideRight>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Right_ForbiddenAreas.png</OverrideRight>
<OverrideUp>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Up_ForbiddenAreas.png</OverrideUp>
<OverrideDown>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Down_ForbiddenAreas.png</OverrideDown>
</Definition>

<RiseThreshold> - Sets min. terrain height change which will cause that area is unreachable.
<HeightThreshold> - Sets height of terrain after which area is unreachable, if it goes over this value. Range is 0 - 1.

If there are texture overrides in the definition, you have to erase them in order for the parameters to take effect. Texture overrides are used to override the generated fast travel map. You will learn more about these overrides in the next part of Fast travel modding.

===Creating fast travel texture override===
If you want to have full control over which areas are reachable and which are not regardless of terrain, you can create a simple texture on which you mark unreachable areas.

The texture is 80x80 pixels, RGB 8 bit. Black pixels forbid entrance.

When you have the texture, select route to it in the definition:
<pre><OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward></pre>
Reachability definition example:
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>
<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>
<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
</Definition>
</pre>
This definition would generate fast travel reachability everywhere, except for front planet face (Fareon kingdom) where fast travel reachability is created based on your texture.

===Development reachability===
Claimable area size, border highlight, contested timer modding
Size of the area and highlight properties are moddable as well.

===Area borders highlight===
<NeutralColor R="225" G="32" B="0" A="64" /> - Set color of an unowned territory
<SelfColor R="0" G="255" B="0" A="64" /> - Sets color of area border owned by you
<AliedColor R="65" G="105" B="225" A="64" /> - Sets color of area border that belongs to allies
<EnemyColor R="225" G="32" B="0" A="64" /> - Sets color of area border that is hostile
<WallSettings Depth="15" Rise="3" SegmentCount"71" End="115" /> - Changes shape of the border. Depth sets how deep is border submerged. Rise sets how tall is the border.
<Fade Start="71" End="115" /> - This sets at which point the border starts to fade.
Contested timer
When players claim area with claimblock, area goes to a “contested” phase for some amount of time, in this phase other players can still attempt to build their own claim block and claim the area. This time is moddable.
Content\Data\Game\SessionComponents.sbc contains definition called MyObjectBuilder_AreaOwnershipSystemDefinition. To mod this value, add this definition to your mod with changed value of <ContestedTimeInMinutes> parameter.

Permissions modding - what is/isn’t allowed to do in claimed areas
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.

===Description of available actions to set permissions for:===
#Name=”Build” -> block placement permissions
#Name=”Repair” -> Repairing/building already placed blocks
#Name=”Deconstruct” -> Deconstructing
#Name=”QuickDeconstruct” -> Faster deconstruction
#Name=”VoxelEdit” -> Mining or shoveling
#Name=”Destroy” -> Damage with hand weapons
#Name=”Interaction” -> Chest opening, door opening
#Name=”ClaimBlockInteraction” -> ClaimblockGui

===List of available Groupnames:===

#Groupname: “Owner” -> Player who owns area
#roupname: “Allies” -> Mostly faction members of owner of the area
#Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
#Groupname: “Enemies” -> Players in factions that are hostile to your faction

Keen:Planet Modding/Fast Travel

2017-03-13T10:53:39Z

Lukas: /* Area borders highlight */

==Fast travel settings modding==
In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around.
In this section of the guide we will show you how to mod which sectors are blocked.
There are 2 ways you can go about it:
===Generate automatically based on terrain shape===
Game is capable of creating fast travel map on its own based on height and terrain steepness. It is possible to mod thresholds for both height and steepness.
You will find the thresholds in Content\Data\Game\FastTravel.sbc. In a MyObjectBuilder_TerrainReachabilityProviderDefinition.
<RiseThreshold> - Sets min. terrain height change which will cause that area is unreachable.
<HeightThreshold> - Sets height of terrain after which area is unreachable, if it goes over this value. Range is 0 - 1.

If there are texture overrides in the definition, you have to erase them in order for the parameters to take effect. Texture overrides are nodes that are called in this fashion: <OverrideNAMEOFFACE>. You will learn more about these overrides in the next part of Fast travel modding.

===Creating fast travel texture override===
If you want to have full control over which areas are reachable and which are not regardless of terrain, you can create a simple texture on which you mark unreachable areas.

The texture is 80x80 pixels, RGB 8 bit. Black pixels forbid entrance.

When you have the texture, select route to it in the definition:
<pre><OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward></pre>
Reachability definition example:
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>
<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>
<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
</Definition>
</pre>
This definition would generate fast travel reachability everywhere, except for front planet face (Fareon kingdom) where fast travel reachability is created based on your texture.

===Development reachability===
Claimable area size, border highlight, contested timer modding
Size of the area and highlight properties are moddable as well.

===Area borders highlight===
<NeutralColor R="225" G="32" B="0" A="64" /> - Set color of an unowned territory
<SelfColor R="0" G="255" B="0" A="64" /> - Sets color of area border owned by you
<AliedColor R="65" G="105" B="225" A="64" /> - Sets color of area border that belongs to allies
<EnemyColor R="225" G="32" B="0" A="64" /> - Sets color of area border that is hostile
<WallSettings Depth="15" Rise="3" SegmentCount"71" End="115" /> - Changes shape of the border. Depth sets how deep is border submerged. Rise sets how tall is the border.
<Fade Start="71" End="115" /> - This sets at which point the border starts to fade.
Contested timer
When players claim area with claimblock, area goes to a “contested” phase for some amount of time, in this phase other players can still attempt to build their own claim block and claim the area. This time is moddable.
Content\Data\Game\SessionComponents.sbc contains definition called MyObjectBuilder_AreaOwnershipSystemDefinition. To mod this value, add this definition to your mod with changed value of <ContestedTimeInMinutes> parameter.

Permissions modding - what is/isn’t allowed to do in claimed areas
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.

===Description of available actions to set permissions for:===
#Name=”Build” -> block placement permissions
#Name=”Repair” -> Repairing/building already placed blocks
#Name=”Deconstruct” -> Deconstructing
#Name=”QuickDeconstruct” -> Faster deconstruction
#Name=”VoxelEdit” -> Mining or shoveling
#Name=”Destroy” -> Damage with hand weapons
#Name=”Interaction” -> Chest opening, door opening
#Name=”ClaimBlockInteraction” -> ClaimblockGui

===List of available Groupnames:===

#Groupname: “Owner” -> Player who owns area
#roupname: “Allies” -> Mostly faction members of owner of the area
#Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
#Groupname: “Enemies” -> Players in factions that are hostile to your faction

Keen:Planet Modding/Fast Travel

2017-03-13T10:52:54Z

Lukas: /* List of available Groupnames: */

==Fast travel settings modding==
In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around.
In this section of the guide we will show you how to mod which sectors are blocked.
There are 2 ways you can go about it:
===Generate automatically based on terrain shape===
Game is capable of creating fast travel map on its own based on height and terrain steepness. It is possible to mod thresholds for both height and steepness.
You will find the thresholds in Content\Data\Game\FastTravel.sbc. In a MyObjectBuilder_TerrainReachabilityProviderDefinition.
<RiseThreshold> - Sets min. terrain height change which will cause that area is unreachable.
<HeightThreshold> - Sets height of terrain after which area is unreachable, if it goes over this value. Range is 0 - 1.

If there are texture overrides in the definition, you have to erase them in order for the parameters to take effect. Texture overrides are nodes that are called in this fashion: <OverrideNAMEOFFACE>. You will learn more about these overrides in the next part of Fast travel modding.

===Creating fast travel texture override===
If you want to have full control over which areas are reachable and which are not regardless of terrain, you can create a simple texture on which you mark unreachable areas.

The texture is 80x80 pixels, RGB 8 bit. Black pixels forbid entrance.

When you have the texture, select route to it in the definition:
<pre><OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward></pre>
Reachability definition example:
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>
<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>
<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
</Definition>
</pre>
This definition would generate fast travel reachability everywhere, except for front planet face (Fareon kingdom) where fast travel reachability is created based on your texture.

===Development reachability===
Claimable area size, border highlight, contested timer modding
Size of the area and highlight properties are moddable as well.

===Area borders highlight===
<NeutralColor R="225" G="32" B="0" A="64" /> - Set color of an unowned territory
<SelfColor R="0" G="255" B="0" A="64" /> - Sets color of area border owned by you
<AliedColor R="65" G="105" B="225" A="64" /> - Sets color of area border that belongs to allies
<EnemyColor R="225" G="32" B="0" A="64" /> - Sets color of area border that is hostile
<WallSettings Depth="15" Rise="3" SegmentCount"71" End="115" /> - Changes shape of the border. Depth sets how deep is border submerged. Rise sets how tall is the border.
<Fade Start="71" End="115" /> - This sets at which point the border starts to fade.
Contested timer
When players claim area with claimblock, area goes to a “contested” phase for some amount of time, in this phase other players can still attempt to build their own claim block and claim the area. This time is moddable.
Content\Data\Game\SessionComponents.sbc contains definition called MyObjectBuilder_AreaOwnershipSystemDefinition. To mod this value, add this definition to your mod with changed value of <ContestedTimeInMinutes> parameter.

Permissions modding - what is/isn’t allowed to do in claimed areas
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.
Description of available actions to set permissions for:
#Name=”Build” -> block placement permissions
#Name=”Repair” -> Repairing/building already placed blocks
#Name=”Deconstruct” -> Deconstructing
#Name=”QuickDeconstruct” -> Faster deconstruction
#Name=”VoxelEdit” -> Mining or shoveling
#Name=”Destroy” -> Damage with hand weapons
#Name=”Interaction” -> Chest opening, door opening
#Name=”ClaimBlockInteraction” -> ClaimblockGui
===List of available Groupnames:===

#Groupname: “Owner” -> Player who owns area
#roupname: “Allies” -> Mostly faction members of owner of the area
#Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
#Groupname: “Enemies” -> Players in factions that are hostile to your faction

Keen:Planet Modding/Fast Travel

2017-03-13T10:52:16Z

Lukas: Created page with "==Fast travel settings modding== In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around. In t..."

==Fast travel settings modding==
In Medieval Engineers players can only fast travel through reachable terrain, blocked terrain has to be crossed on foot or walked around.
In this section of the guide we will show you how to mod which sectors are blocked.
There are 2 ways you can go about it:
===Generate automatically based on terrain shape===
Game is capable of creating fast travel map on its own based on height and terrain steepness. It is possible to mod thresholds for both height and steepness.
You will find the thresholds in Content\Data\Game\FastTravel.sbc. In a MyObjectBuilder_TerrainReachabilityProviderDefinition.
<RiseThreshold> - Sets min. terrain height change which will cause that area is unreachable.
<HeightThreshold> - Sets height of terrain after which area is unreachable, if it goes over this value. Range is 0 - 1.

If there are texture overrides in the definition, you have to erase them in order for the parameters to take effect. Texture overrides are nodes that are called in this fashion: <OverrideNAMEOFFACE>. You will learn more about these overrides in the next part of Fast travel modding.

===Creating fast travel texture override===
If you want to have full control over which areas are reachable and which are not regardless of terrain, you can create a simple texture on which you mark unreachable areas.

The texture is 80x80 pixels, RGB 8 bit. Black pixels forbid entrance.

When you have the texture, select route to it in the definition:
<pre><OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward></pre>
Reachability definition example:
<pre>
<Definition xsi:type="MyObjectBuilder_TerrainReachabilityProviderDefinition">
<Id Type="MyObjectBuilder_TerrainReachabilityProviderDefinition" Subtype="Terra"/>
<RiseThreshold>.14</RiseThreshold>
<HeightThreshold>.6</HeightThreshold>
<OverrideForward>Data/PlanetDataFiles/EarthLike/FastTravelOverrides/Front_ForbiddenAreas.png</OverrideForward>
</Definition>
</pre>
This definition would generate fast travel reachability everywhere, except for front planet face (Fareon kingdom) where fast travel reachability is created based on your texture.

===Development reachability===
Claimable area size, border highlight, contested timer modding
Size of the area and highlight properties are moddable as well.

===Area borders highlight===
<NeutralColor R="225" G="32" B="0" A="64" /> - Set color of an unowned territory
<SelfColor R="0" G="255" B="0" A="64" /> - Sets color of area border owned by you
<AliedColor R="65" G="105" B="225" A="64" /> - Sets color of area border that belongs to allies
<EnemyColor R="225" G="32" B="0" A="64" /> - Sets color of area border that is hostile
<WallSettings Depth="15" Rise="3" SegmentCount"71" End="115" /> - Changes shape of the border. Depth sets how deep is border submerged. Rise sets how tall is the border.
<Fade Start="71" End="115" /> - This sets at which point the border starts to fade.
Contested timer
When players claim area with claimblock, area goes to a “contested” phase for some amount of time, in this phase other players can still attempt to build their own claim block and claim the area. This time is moddable.
Content\Data\Game\SessionComponents.sbc contains definition called MyObjectBuilder_AreaOwnershipSystemDefinition. To mod this value, add this definition to your mod with changed value of <ContestedTimeInMinutes> parameter.

Permissions modding - what is/isn’t allowed to do in claimed areas
Have you noticed you cannot mine voxels in claimed areas of your enemies? That is because of how we chose to define permission settings for safe area. And yes, this and much more is also moddable :).
This time there is no need create any textures, we will only need to edit one text file and add it to your mod.
You will find the file with permissions definitions in Data\Permissions.sbc
Descriptions of permission nodes:
<pre>
<Permission Name="Build">
<Usergroup Groupname="Owner" Allowed="true"/>
<Usergroup Groupname="Allies" Allowed="true"/>
<Usergroup Groupname="Neutral" Allowed="false"/>
<Usergroup Groupname="Enemies" Allowed="false"/>
</Permission>
</pre>
Permission definition sets which groups of players are allowed to perform an action. In this example, it is “Build” action.

<pre><Usergroup Groupname=”Owner” Allowed=”true”></pre>
Groupname refers to group of players, for which we are setting the permission(in this example it is player who owns the area). Allowed parameter allows/disallows the action depending on if it is set to “true” or “false”.

<pre><IsDefault>true</IsDefault></pre>
Parameter sets which area permission set is used for player owned territories.
Description of available actions to set permissions for:
#Name=”Build” -> block placement permissions
#Name=”Repair” -> Repairing/building already placed blocks
#Name=”Deconstruct” -> Deconstructing
#Name=”QuickDeconstruct” -> Faster deconstruction
#Name=”VoxelEdit” -> Mining or shoveling
#Name=”Destroy” -> Damage with hand weapons
#Name=”Interaction” -> Chest opening, door opening
#Name=”ClaimBlockInteraction” -> ClaimblockGui
===List of available Groupnames:===
Groupname: “Owner” -> Player who owns area
Groupname: “Allies” -> Mostly faction members of owner of the area
Groupname: “Neutral” -> Random players, who are not in an enemy faction (mostly everyone without faction allegiance)
Groupname: “Enemies” -> Players in factions that are hostile to your faction