Intro

 
So what is blueprint editing and why is it important? The name alone doesn’t tell much, given that it says “edit blueprints”, which is practically what we do when we build things right? Well, not exactly. Blueprint editing relies on editing the actual blueprint files as they are stored in the game from outside the game. This allows as to bypass many of the games restrictions and create custom blocks that are normally impossible to make. 
 
 
 
The picture in the thumbnail is one such example: It’s a tank with large grid 1×1 wheels on a small grid chassis, which is normally impossible given that we can’t place small suspensions that come with this type of wheel. We acquired this custom wheel with the help of blueprint editing, and this particular technique will be taken up in this guide aswell. 
 
Here is a list of things you will need: 
Space Engineers (obviously) 
File access on your computer 
A text editor program (any will do) 
A bit of patience 
 
It is also very important to disable Steam Cloud in-game, otherwise you cannot edit your blueprints since they are saved to the cloud and not your computer. 
 
This guide will be split into several parts. These explain how to find blueprints and carry out edits on them, but you will also find a reference section at the bottom of the guide. This serves as a short reference list of steps to work out simple techniques that one might easily forget. 
 
 

Finding your way around the files

 
Assuming we turned off cloud saving, the blueprints we save from now on are saved on our computer, this also means you need to have a bit of storage space available. So, where do we find our blueprints then? 
 
The directory is as follows: 
C:\Users\user\AppData\Roaming\Space Engineers\Blueprints\local. 
Note that this folder may be hidden, and you might also need administrator access to peek inside, so make sure you can access this folder before continuing. C can also be whichever letter your disk has (the one you installed the game on, though its usually C) and user is of course your username. 
 
This is the folder that stores all your local blueprints, and this is where you can access them for editing. Now, blueprints are built the following way: 
 
The folders name is the name you see when opening the blueprint menu. 
Inside the folder you find 3 or more files. These include: 
bp.sbc <- This file stores the data for loading the blueprint. 
bp.sbcB5 <- This file is used by the game for easier spawning. 
thumb.png <- The thumbnail picture of the blueprint you see when spawning. 
 
Of these 3 files, we will edit the .sbc one. There can also be more .sbcBX type files: these are from older game versions and you can discard them. 
 
 

Understanding blueprints

 
First and foremost, go find the blueprint you wish to edit. Remember; you find them by their folders name which is the same as their ingame blueprint name. For example: If you open up the blueprint menu with F10 and find your grid, note its name. That is the same name the folder containing the files will have. Searching up the particular name is a viable option however this may take longer than simply going to the directory and finding the blueprint folder there. 
 
As stated before, blueprints are made up of mainly 3 files: 
bp.sbc <- This file stores the data for loading the blueprint. 
bp.sbcB5 <- This file is used by the game for easier spawning. 
thumb.png <- The thumbnail picture of the blueprint you see when spawning. 
 
To begin with, we want to delete the bp.sbcB5. This is because the game will only use the sbcB5 file when spawning UNLESS it’s not available, in which case it will read directly from the .sbc file. Given that we can’t edit the .sbcB5 file we have to override the system and force it to read from the .sbc file, which we can read and thereby edit. Fortunately, this action also creates a new sbcB5 file so we don’t have to worry about removing it unless we make new changes outside the game. 
 
Assuming we have done the previous steps the blueprint is ready for editing. Open up a text editor of your choosing (i’m using notepad++), and open the bp.sbc file. The first thing you will notice is that its filled with alot of information, most of which are probably unknown to you. When editing blueprints, there two things you must keep in mind: 
 

1: Formatting:

 
Blueprints are written in a format called XML, which means there is a certain way you have to write things to properly edit them. Now, all information is locked inside brackets <-> and this will become more important when actually editing. Properly formatted XML code works based on the following: 
<flag>attribute</flag> 
 
Note that because steam is not a text editor, these lines appear flat here; fortunately they are properly indented when looking at the actual blueprint file. 
 
You will probably notice things like: 
<MyObjectBuilder_CubeBlock xsi:type=”MyObjectBuilder_CubeBlock”> 
<SubtypeName>LargeHeavyBlockArmorBlock</SubtypeName> 
<Min x=”0″ y=”0″ z=”5″ /> 
<ColorMaskHSV x=”0″ y=”-0.8″ z=”0″ /> 
</MyObjectBuilder_CubeBlock> 
These too follow the same structure, they are only slotted in a way thats easier to read. 
 

2: Structure:

 
Note that an attribute can consist of multiple flags, for example, this “CubeBlock” used in the example above consists of a SubtypeName, which is the type of block, Min, which is its placement on the grid, and ColorMaskHSV, which is the color / skin of the block. 
 
There are 3 types of flag structures: 
<flag/> 
——————————— 
<flag>attribute</flag> 
——————————— 
<flag> 
<flag/> 
</flag> 
——————————— 
 
Flags can be a single attribute, contain a single attribute, or be made of multiple flags with their own attributes. This may seem like a lot to take in but once we understand what these flags and attributes mean, it is amazingly simple. The attributes of flags may also vary in size, shape and form. Sometimes, they are a bool where you can change between true / false. In others, it may be a piece of text (also known as “string”), or a certain number / percentage. 
 

3: Cubegrids:

 
One last importnat thing to note, before moving on, is that blueprints are devised into certain grids. This is the same as per ingame terms, where each grid is part of a “cubegrid” flag, which then houses all the other blocks and options inside it. For example: 
 
<CubeGrid> 
<SubtypeName /> 
<EntityId>118958631637267643</EntityId> 
<PersistentFlags>CastShadows InScene</PersistentFlags> 
<PositionAndOrientation> 
<Position x=”52947.422116716509″ y=”29539.455854213735″ z=”6542.1000319122″ /> 
<Forward x=”0.09258442″ y=”-0.0596833825″ z=”-0.9939146″ /> 
<Up x=”0.475492328″ y=”-0.874378264″ z=”0.0967980847″ /> 
<Orientation> 
<X>-0.0375143476</X> 
<Y>0.0404404178</Y> 
<Z>0.9673581</Z> 
<W>-0.24733679</W> 
</Orientation> 
</PositionAndOrientation> 
<LocalPositionAndOrientation xsi:nil=”true” /> 
<GridSizeEnum>Small</GridSizeEnum> 
<CubeBlocks> 
<MyObjectBuilder_CubeBlock xsi:type=”MyObjectBuilder_Wheel”> 
<SubtypeName>OffroadSmallRealWheelmirrored</SubtypeName> 
<EntityId>126942723798764738</EntityId> 
<ColorMaskHSV x=”0.333333343″ y=”-0.33″ z=”-0.05″ /> 
<SkinSubtypeId>Clean_Armor</SkinSubtypeId> 
<BuiltBy>144115188075856760</BuiltBy> 
<YieldLastComponent>false</YieldLastComponent> 
</MyObjectBuilder_CubeBlock> 
</CubeBlocks> 
<LinearVelocity x=”-0.0022735″ y=”-0.0004732497″ z=”0.00105179753″ /> 
<AngularVelocity x=”-0.000382635422″ y=”0.000675625459″ z=”-0.0005931617″ /> 
<DisplayName>Small Grid 9186</DisplayName> 
<DestructibleBlocks>true</DestructibleBlocks> 
<IsRespawnGrid>false</IsRespawnGrid> 
<LocalCoordSys>0</LocalCoordSys> 
<TargetingTargets /> 
</CubeGrid> 
 
This is an entire grid, in our case, a wheel connected to a suspension. A grid may contain any amount of blocks, so long as there is one, and contains a plethora of other options; such as grid size, entity id and position. Any edits made inside this particular grid will only affect what’s on this grid and no other grids. Grid selection will become important in some later edits, where you have to watch out for such phenomenon. 
 
 

Simple edits

 
Now that we know and hopefully understand how to work with the blueprints’ internals, it’s time to make the desired changes. There can be a plethora of changes you wish to make; this guide will cover the most common edits. We will start with a few simple ones then slowly progress in difficulty until we reach some pretty advanced edits. 
 

Types of edits:

 
First however we will go over what kind of edits are the most common. Essentially, there are 4 techniques that all edits use. These are as follows: 

• Finding flags: Every edit starts with this, as we have to find the flag which we want to edit. Their names will be given in the instructions for the edits. 
• Altering/Replacing attributes: The most common type of edit, we simple take an existing flag and replace its attribute to achieve a desired effect. 
• Adding/Removing flags: In certain cases, we don’t have the required flag available, and so we have to make our own. If a flag has to be added or removed, it will be explained in detail. 
• Multi-stage edits: This kind of edit is somewhat rare, and is only explained later in the advanced edits section. It’s essentialy multiple edits to achieve a higher goal.

Altering durability:

 
This is one of the simplest edits in the entire game. By the term “durability”, i’m talking about making grids invincible to every form of attack. In this edit we are to find a flag named: <DestructibleBlocks> 
Note that this variable is grid sensitive, i.e the change wil only affect the cubegrid that has been changed as each cubegrid has its own such variable. You may choose to change one, several or all, but note that you will have to figure out which grid is which. This is most easily done by searching up a flag called: 
<DisplayName> 
This flag is the cubegrids name as displayed in-game. You can also find named blocks and looking at cubegrids’ block counts to figure out if you got the right one. 
 
Let’s assume we have a single grid fighter, and we want to make this invincible. We search up “DestructibleBlocks” (case sensitive but notepad++ can ignore such). What we are looking for looks like this: 
 
<DestructibleBlocks>true</DestructibleBlocks>. 
 
The “true” attribute is a bool, which means this flag is either true or false. DestructibleBlocks changes whether damage can affect the grid, so to make it invincible we switch out true for false. If we properly respawn our fighter (see prior chapters) shooting at a rifle will not have any effect. 
 
For those wanting to go the extra mile, we can also make our ship unaffected by building. Testing reveals that, although the fighter cannot be harmed by weapons, it can have its blocks removed and grinded off, as these don’t go under the damage category. To defend against this, we have to add a flag of our own. Remember that such is grid sensitive, thus it’s best to place it right next to the DestructibleBlocks flag, so both flags will apply to the same grid. The flag to add goes as follows: 
 
<Editable>false</Editable> 
 
This is essentially the same as with damage, but this time, we block the system from doing edits to the ship, which includes any form of building and grinding, except for welding. Speaking of which; a grid with this attribute disabled resists placing and removing of blocks. There is however one exception: spawning. Pasting grids onto uneditable ones is still possible. 
 
Some final notes to finish up this edit: Adding both attributes will make a grid essentially indestructible regardless of what form of attack is used against it. This however is not recommended for use in multiplayer, as it can easily upset others given that you have a “godmode” ship. As to where this is useful, not many places but there are a few examples. Arenas are one such, where derby events can be held and you don’t want the contestants to destroy it. 
 

Making grids static:

 
A similar edit to the previous one, this one will make grids static or not static based on the flag that we intend to change. The same technique is used as per before; this time the attribute we search is “IsStatic”. Much like the previous two flags, this one is also based on a bool, and just like the previous ones, it is also grid sensitive. Example of a static grid: 
 
<IsStatic>true</IsStatic> 
 
This edit isn’t much useful beyond this, except in one area: small grids. With this edit, you can actually make small grids static and have the ability to paste them into voxels. Note that they can easily become ships if they are not placed in voxel, as small grids are not meant to be static by default. 
 

Ripping blueprints from prefabs:

 
Another difficult looking, but actually very simple edit. Some of you might know the NPC cargo ships and drones found in the world when certain settings are enabled. These are based on prefabs; which are essentially blueprints but the game spawns them instead of us. Prefabs, in their original form, cannot be spawned by players as they use different flags, but are otherwise completely identical to blueprints. 
 
Converting prefabs is fairly simple, as again they are essentially blueprints but changed up a little. To convert, first find a prefab; the directory is as follows: 
C:/Program Files (x86)/Steam/steamapps/Common/SpaceEngineers/Content/Data/Prefabs 
As you can probably tell, their feature the same sbc and sbcB5 formats like blueprints, and thus are also built the same way. Once you found a prefab, you have to make a new blueprint for it which it can occupy. 
 
You can either create a new folder in the blueprints/local folder or just make a new blueprint and replace its sbc file with the prefabs (don’t forget to remove the sbcB5 as per before). Then it’s time to edit the sbc. The only change that has to be carried out is to replace “Prefab” with “ShipBlueprint” in the entire file. This is the only difference in prefabs and blueprints, and so the game will recognise this as a blueprint and allow you to spawn it. 
 

Altering values:

 
A slightly more difficult edit. Altering basically any values that can be altered, for example: Jump drive charge state, hydrogen fill level, etc… This is not more difficult than previous edits in that we still only alter a single flag, however finding this flag is the challenge. When altering values, it’s block sensitive and so the attribute will only change for the block we change it for. However there is an easy way to find what we are looking for: CustomName. Each functional block that can have its values edited can also be found in the terminal. And each such block will have a flag called <CustomName>. If we know what the block is called, we can search up its name in the blueprint, and we know we got the right one if they match. 
 
Once we have found the correct block, it’s time to alter its values. All the configuration flags will be found inside the <MyObjectBuilder_CubeBlock> flag, as always. I don’t have a list of all the variables at the moment, but most flags names represent the value they change. For example; jump drives have a flag named StoredPower, whereas hydrogen tank have another flag with the name FilledRatio and so on. Note that their values are essentially the same as what we see ingame, so change accordingly. 
 
 

Advanced edits

 
The followings edits are more advanced, due to requiring more challenging measures or even multiple steps to achieve. If you wish to make these edits, make sure to have atleast gotten yourself familiar with the previous techniques and pages, as these are not all that simple. 
 

Armor conversion:

 
Armor conversion exists in mainly two variants: replacing type and replacing color / material. Both variants rely on mass-replacing, since picking individual blocks from inside a blueprint is virtually impossible. Armor type essentially means converting armor between light and heavy, while converting color means either replacing or adding a new color / material to blocks. 
 
Converting armor type is slightly more difficult because of the different armor block names. Converting from heavy armor to light armor is, on the contrary, rather simple, as all you have to do is take out “Heavy” from all the block names, and they will be instantly converted to light armor. Converting to heavy armor is the challenging part, as not all blocks can have “Heavy” in the name, which will result in functional blocks not spawning due to improper definitions. For this reason, i have compiled a list of names you should replace to achieve a full heavy-armor conversion. The list is as follows: 
 
Small Grid ———————————- 
1. SmallBlockArmor = SmallHeavyBlockArmor 
2. SmallHeavyBlockArmorCorner = SmallBlockHeavyArmorCorner 
3. Half = HeavyHalf 
4. SmallHeavyBlockArmorHeavyHalf = SmallBlockHeavyArmorHalf 
5. SmallHeavyBlockArmorSloped = SmallBlockHeavyArmorSloped 
Large Grid ———————————- 
1. LargeBlockArmor = LargeHeavyBlockArmor 
2. LargeHeavyBlockArmorCorner = LargeBlockHeavyArmorCorner 
3. LargeHalf = LargeHeavyHalf 
4. LargeHeavyBlockArmorHalf = LargeBlockHeavyArmorHalf 
5. LargeHeavyBlockArmorSloped = LargeBlockHeavyArmorSloped 
——————————————————— 
 
Replace each definition in order, based on this list. These are not the names of the blocks, but rather collective names that they share, which we use to replace them instead of having to replace each individual block definitions; making the process easier and faster. 
 

Replacing blocks

 
Much like with armor conversion, replacing blocks is a bit more difficult than just replacing values. On the contrary, it is very much block-dependant as we alter the very type of block. The reason is that for a block to be acceptable by the game, it has to have all the required flags the block normally inhibits. 
 
This type of edit should only be used when replacing blocks that are otherwise impossible to in-game. For example, replacing a wheel with a rotor on the front of a suspension so that one can add blocks onto the head of a suspension. Generally, replacing functional blocks is not recommended unless, again, cannot be done in-game. The method to replacing generally consists of replacing: 
<MyObjectBuilder_CubeBlock xsi:type=”x”> 
Where x is the type of block the game will recognise when loading the blueprint. To get the correct block type, i suggest blueprinting the desired block then looking at its blueprint. 
 

Supergridding

 
Building onto the previous chapter, is a method called supergridding. This method consists of putting the wrong size block on a particular grid; for example adding a large grid turret onto a small grid ship or vice versa. The edit is very similar to replacing blocks, but with an added twist. Supergridding can exist in two versions: 
 
Some blocks only require you to edit the following flag: 
<SubtypeName> 
Subtypename is a block-type flag but for blocks that fall under the same category. For example, changing one particular block from small to large; this is usually the place to do it. Subtypenames often have the keywords Large and Small which can be used to identify the block size. 
 
Another method involves chagning: 
<MyObjectBuilder_CubeBlock xsi:type=”x”> 
Much like described in the chapter above, some blocks will have their <SubtypeName> flag greyed out (displayed as <SubtypeName />), and in this case editing the cubeblock definition is required. 
 
Similarly with replacing blocks, to find cubeblock-types or subtypenames, it’s suggested to blueprint the desired block and then use that as a template to alter the one you wish to replace. Note that changing blocks this way will not change their grid size, as all blocks on the same grid will have the same grid size regardless of which blocks are present. 
 

Altering subgrids

 
The last of the advanced edits, we arrive at subgrids. Subgrids are perhaps the most broken aspect of this game, as they can be heavily edited and exploited. Some of you may recall that i mentioned how we can fit large grid wheels onto a small grid suspension. Well in this particular chapter, we take up how that works. 
 
Subgrids are also cubegrids, but belong to a certain “owner” block, i.e their base. Inside this cubegrid we then find cubeblocks, consisting of the heads of base-blocks. Rotor heads belong to rotors, piston heads to pistons and so on. As we know, we can change blocks through blueprints, and we can utilise this technique to change whats on the end of a base-block. 
 
The method works similarly to replacing blocks, however is grid-sensitive as we have to figure out which subgrid belongs to which owner. The easiest way to find this particular block is to find a flag called: 
<TopBlockId> 
This flag is found in all base-blocks/blocks that can have subgrids on them. The attribute of this flag refers to a long, which is the entity ID of the topblock/head. All you have to do is find the base block (this is covered in earlier chapters) and then search up it’s TopBlockId until you find the particular block that belongs to this entity ID. You can then change this block’s type or subtype depending on what you wish to put on its end. 
 
Note that stable behaviour can only be expected from blocks that are meant to belong on subgrids, such as wheels or head-blocks. Other blocks can work, but usually do not. One more thing to note is that we can also change the grid size of subgrid blocks. The reason is that base blocks can have subgrids not their own size, and so we can use small grid suspension blocks with a large grid wheel, and vice versa. 
 
 

Requested Edits

 
This page will be filled with user requested edits, once such requests are made. 
 
 

Reference list

 
This list refers to all techniques used in this guide, in case you would forget them. 
 
Blueprints Directory Sample: 
C:/Users/user/Application Data/Roaming/Space Engineers/Blueprints/local 
 
Edits don’t appear in game: 
Remove .sbcB5 file in the blueprint and respawn it. 
 
Finding specific blocks: 
Look for a flag called <CustomName>. 
 
Finding specific cubegrids: 
Look for flag called <DisplayName>. This is the name of the grid displayed in-game. 
 
Finding a specific subgrid block: 
Look for a flag called <TopBlockId> and search up this id. 
 
 

Outro

 
That’s all there is to it. Of course i did not go over single thing; these are only the ones i could come up with and the ones i assume are the most common aswell. If you have any edits of this nature i should show, please let me know in the comments and ill add it to this guide. If you have any other particular suggestions, of course let your voice be heard. 
 
On a more personal note, i had taken up this topic in my earlier guide about wheel tracks, but never really went in-depth on it, and so i decided it would be worth sharing this with the community. 
 
Also if you found any typos, please let me know! 
 

Here we come to an end for Space Engineers Blueprint Editing Guide hope you enjoy it. If you think we forget something to include or we should make an update to the post let us know via comment, and we will fix it asap! Thanks and have a great day!