• Creating a local mod
• SBC (definition files)
• Assets (models, audio, textures, etc)
• Scripts/Programming (.cs files)
• Visual Scripting Tool (VST, for scenarios)
• Plugins (.dll files)
• Testing / publishing to workshop / updating

(Back to top)

First go to: %appdata%/SpaceEngineers/Mods
(Can paste this to folder explorer's address bar)

Once there you can create a folder with your mod name. Then inside you should create a Data folder.

The result would be like: %appdata%/SpaceEngineers/Mods/SomeFancyMod/Data

Next is filling it with content! Unless you want to make a mod collection instead.

(Back to top)

These are text files in XML format that declare stuff like blocks, weapons, ammo, items, etc.

The game will load all .sbc files (no matter the name) from your mod's Data folder and any subfolders.

Recommended editor: Notepad++ with "XML Tools" addon, but default notepad works too.

In <Game>/Content/Data you'll find everything the game declares.
You can copy any of the files there into your mod's Data folder, then you can edit those in your mod.
Do not edit the SBC files in the game folder.

Some other things to know:

• Definition's Id (type&subtype) is what determines if you overwrite an existing one or add a new one. You can only use predefined TypeId but the SubtypeId can be made up and must be unique per type, as you can also overwrite other mod's things.

• Overwriting things is a very mixed bag depending on the definition:

  • Vast majority of definitions are going to act as if you removed the original one then added yours, therefore nothing is merged from the original.
  • Some definitions are partially additive, like blueprint classes, block categories, where you can append to a list of things.
  • Environment.sbc is the only one that is fully mergeable, the tags that you declare will be appended, so you can only declare skybox if you so wish without including anything else.
  • Some definitions are not meant to be modded at all, like ones from AssetModifiers folder as they don't have support for reading assets from mod folders and are also not mergeable, so avoid modding the existing ones. Adding new ones is not a problem (except for the fact that the game won't detect them in the color picker or wardrobe windows).

• The names of the .sbc files do not matter, what matters is ending in .sbc and its content. You can have all of the definitions in a single file if you so wish or you can have each definition in its own file aswell. (Warning: don't close and re-open the first 2-level tags in the same file, like <Definitions>, <CubeBlocks>, <Blueprints>, etc).

(Back to top)

Game has a SDK available on Steam/Tools which contain the original .fbx files for models, as well as some commandline and GUI tools to convert from a format to another for textures, audio, fonts as well as their custom tool platform, VRageEditor, which can be started with the .bat files in its folder.

The game requires SBC definitions to point to assets. Adding a model/sound/texture to a relative folder won't do anything.

• Models are referenced by SBC of the blocks/components/items/etc that use them.
• Sounds are referenced by audio SBC which are then referenced by blocks/tools/weapons/etc.
• Model textures, model LODs, subparts, interactive areas, conveyor ports (and a few other specific things) are referenced by the model itself.
• Other textures can be linked by its relevant SBC like: icons, camera/turret overlays, spotlight beams, flares, HUD layouts, planetary clouds, etc.

To make models with Blender, a big workflow help would be the SEUT addon.

The game supports .wav and .xwm for audio. SDK/Tools/xWMAencode.exe allows you to convert between these two formats.
Perfect-loop sounds should be .wav, because the .xwm compression leaves gaps at the end.

For general help with assets, SBC or SEUT, ask in the #modding-art-sbc channel in Keen's discord.

(Back to top)

If you know at least the basics of C# language you can create scripts that can do all sorts of things to the game.

This does not cover Programmable Block as that is not modding. Mod scripts have control over the entire game world while PB is just an ingame computer, as well as significant difference in how they're "installed".
If you are looking to make PB scripts then refer to SE's wiki on ingame scripting: Ingame Scripting.

• Scripts in mods must reside in <Mod>/Data/Scripts/<AnyFolderHere>/*.cs and the game compiles the found .cs files upon world load.
  The subfolder in Scripts is important because each file/folder there is compiled as an individual assembly.
  Also that subfolder name decides the Storage folder name (<WorkshopId>.sbm_<FolderFromScripts>) when using Write/ReadToLocalStorage().
  Use the mod name for that folder in Scripts, makes it easier to identify the mod in Storage.

• Highly recommended to use a C# editor (IDE) that can support adding .dll references for context awareness (intellisense).
  Visual Studio community edition is free, see Visual Studio setup guide in the right-side bar.
  Mind that Visual Studio Code is an entirely different thing and way harder to configure to get intellisense.

• There's a whitelist of types that mod scripts are checked against, you cannot use everything from C#/.NET and not even everything from SE's codebase either.
  This is for security reasons, the workshop needs to be safe and not allow modders to do harm to one's computer.
  There's an official API docs site too keensoftwarehouse.github.io but it's not complete (for example MyGunBase is not there, but it's whitelisted).

See Gamelogic and Session examples, read comments from both.

In the same github repo there's various other examples! I sometimes add new stuff, you can see changes in the commits page.
And check out the other guides in the right-side bar in this wiki aswell.

For help finding your way around the API and other questions, ask in #modding-programming channel in Keen's discord.

• You'll likely need to dig around the game code to see how things actually function (from the lack of detail in the docs).
  You can do so by using ILspy or dnSpy.
  Using them is just a matter of opening all .dll files from the game's Bin64 then search for something and dig around in it.
  Can also right-click -> Analyze things to see where they're read/called/assigned from which helps track things.

• Don't have using for Ingame namespaces, they'll cause you ambiguity errors and are mostly unnecessary because the modding interfaces already implement the PB ones (Ingame namespaces are used by programmable block).
  If you need something that's in those namespaces (like an enum returned by something) you can give it an alias like:
  using MyShipConnectorStatus = Sandbox.ModAPI.Ingame.MyShipConnectorStatus; (the left side can be whatever name you want)

(Back to top)

VST is primarily for scenarios. Most of its things are available to modAPI (C#) so I've personally not dealt with VST much.

For more about it see:
Visual Scripting Tool (SpaceEngineersGame.com)
Visual Scripting guide collection (Steam)

And for questions/help ask in the #visual-scripting channel on the Keen's discord.

(Back to top)

These are basically C# programs attached to the game on launch, they don't obey any whitelist and therefore can do anything a normal program can do, both the awesome and the malicious things, so be weary what you run.

Major difference of plugins to mods, aside from having no limits, is that they have to be manually installed (via -plugin launch parameter) and can't be distributed using steam workshop or mod.io and such. There is however Plugin Loader plugin which aims to help with distribution and a bit of safety.

To make a plugin, the VS setup is the same like for mods, then the primary entry point is to make a class and make it implement IPlugin, and then add the methods it asks for.

There's also IConfigurablePlugin which is designed for dedicated servers to show fields in the GUI, never used it so I cannot provide more details.

(Back to top)

Once you've added the content you want to change in the mod, you can now test it.

The mod won't do anything by simply existing, just like workshop mods, you need to add it to a world first!

In-game on any world's settings you'll find Mods button where you can find your local mod with a folder icon indicating it's local.

In that same menu you can Publish the selected mod to workshop(s), but you should only do this after testing it locally first.

After it's been published once, the local folder will have a modinfo.sbmi generated (and a metadata.mod which does nothing so you can ignore).

That file tells the game which workshop id(s) to replace when you click Publish again, which it will also confirm by asking if you're ok overriding the published mod.

If that file does not exist but it's also published, you can manually create the file with this template, make sure you replace all the REPLACE_ prefixed things:

<?xml version="1.0"?>
<MyObjectBuilder_ModInfo xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <SteamIDOwner>REPLACE_YourSteamId</SteamIDOwner>
  <WorkshopIds>

    <WorkshopId>
      <Id>REPLACE_WorkshopIdFromTheLink</Id>
      <ServiceName>Steam</ServiceName>
    </WorkshopId>

    <WorkshopId>
      <Id>REPLACE_ResourceId</Id>
      <ServiceName>mod.io</ServiceName>
    </WorkshopId>

  </WorkshopIds>
</MyObjectBuilder_ModInfo>

If you don't have it published to both, then you can remove the section (4 lines from <WorkshopId> to </WorkshopId>) for the platform it's not uploaded to.

Further explanations:

• REPLACE_WorkshopIdFromTheLink
  Go to your mod's steam workshop page and look at the link, e.g. https://steamcommunity.com/sharedfiles/filedetails/?id=514062285, that number at the end is what you should replace this with, like <Id>514062285</Id>.
• REPLACE_ResourceId
  Go to your mod's mod.io page and on the right side there's a Resource ID, replace this with that number, e.g. <id>2870229</Id>.
• REPLACE_YourSteamId
  Either look to another one of your modinfo.sbmi or use a site like SteamIdFinder and copy the steamID64 (Dec).