Releasing A Mod

Once you consider that one of your mods is ready to be released, there’s a few extra steps to follow to ensure that it’s working correctly, and to set up the required information for the Mod Repository to work with the mod.

Local Testing

Before you release your mod, you should make sure that the features you implemented are working as you expect.

For example, if your mod adds new items, recipes, or milestones, try to unlock them the same way a normal player would to ensure they are accessible.

For recipes, try setting up a building to craft the recipe and ensure it actually works. For example, if a recipe requires more of an item than its stack size, the machine can’t operate even though the recipe appears otherwise valid.

If your mod has configuration options, make sure that the default configuration options you specified are what you want, since all users who install your mod will have them, and might not even realize they can be changed. The default config settings should represent the intended user experience for your mod.

Make sure that your mod works for both client and host players in multiplayer. For mods that add items, schematics, and recipes, this is not much of an issue, but if you have added additional buildings or other functionality,

You can find more info on how to test your mod, including directions for running two copies locally to test multiplayer, on the Testing/Multiplayer Testing page.

Your Mod’s UPlugin File

Every Unreal Engine plugin is require to have a <mod reference>.uplugin file, and Satisfactory mods are no exception. This file is json formatted and holds information about the mod, such as its version number, dependencies, credits, links, and more. Only one uplugin file should exist in a plugin’s directory, else the editor will get very confused.

The file should have been automatically generated for you when you created your mod with Alpakit.

At that point in the tutorial, we said we’d come back to some fields later, and now is that time.

Although you can find this file in your mod’s plugin directory, which is your modding project directory’s /Mods/<mod reference> folder, you should generally edit it within the unreal editor via Alpakit. Alpakit will automatically handle the file’s formatting for you and help to prevent mistakes that would create an invalid uplugin file and be annoying to track down.

Open the Alpakit editor by clicking the Edit button next to your mod in the Alpakit mods list.

You can hover over the labels on the left to get a tooltip that explains their purpose.

Edit your Plugin screenshot

Below we will go into more detail about their purpose. It is suggested that you read all of the field definitions below to make well-informed decisions about the values you specify.

If you’d like, you can read about all the different Unreal settings available at the Plugins documentation here or at the C++ reference here, but this page will cover the ones most important to Satisfactory mods.

After editing these fields, be sure to re-Alpak your mod so the files you upload will have your changes.

Default Fields

The following fields are part of Unreal’s normal uplugin format, but are given additional functionality by the modding toolkit.

Parameter Description of Function

Parameter	Description of Function
Version	This integer should match the first digit of your `SemVersion` (described in the Special Fields section). For example, a mod with a SemVersion of `1.0.0` should have a Version of `1`
VersionName	This string should exactly match your `SemVersion` (described in the Special Fields section).
FriendlyName	This string is the name of your mod as it will appear in the in-game loaded mods list and configs screen.
Description	This string will appear when someone looks at your mod in the in-game loaded mods list and configs screen.
CreatedBy	This string will appear as the author’s name section when someone looks at your mod in the in-game loaded mods list and configs screen.
DocsURL	If a link is provided here, a button will appear in the in-game loaded mods list that will open the URL when clicked. The `http://` / `https://` prefix is optional.
SupportURL	If a link is provided here, a button will appear in the in-game loaded mods list that will open the URL when clicked. The `http://` / `https://` prefix is optional.

Version

This integer should match the first digit of your SemVersion (described in the Special Fields section). For example, a mod with a SemVersion of 1.0.0 should have a Version of 1

VersionName

This string should exactly match your SemVersion (described in the Special Fields section).

FriendlyName

This string is the name of your mod as it will appear in the in-game loaded mods list and configs screen.

Description

This string will appear when someone looks at your mod in the in-game loaded mods list and configs screen.

CreatedBy

This string will appear as the author’s name section when someone looks at your mod in the in-game loaded mods list and configs screen.

DocsURL

If a link is provided here, a button will appear in the in-game loaded mods list that will open the URL when clicked. The http:// / https:// prefix is optional.

SupportURL

If a link is provided here, a button will appear in the in-game loaded mods list that will open the URL when clicked. The http:// / https:// prefix is optional.

Special Fields

Note that SML and SMR require you to include additional fields in your plugin descriptor file.

The most important of these is a mod dependency list and a SemVersion for the mod.

Make sure that you have SML listed as an item in the Plugins field, as explained below.

Below is a description of all extra fields SML and SMR require:

Parameter Description of Function

SemVersion

Version number for the mod. Should always increase with new releases, and should follow the semver format. To summarize, the format is Major.Minor.Patch

As a rule of thumb, version 1.0.0 should be used for the first public release of your mod. If you were to use a version number with a major version of 0, such as 0.1.0, then then the typical ^ range specifier explained below in the Plugins section would behave counter-intuitively, so you should try to avoid this.

When you release bugfixes, you should increment the Patch version, for example 1.0.1.
When you release changes that don’t break how other mods interact with your mod, you should increment the Minor version, for example 1.1.0.
When you release changes that are not backwards compatible, or break how other mods interact with your mod, you should increase the Major version, for example 2.0.0.

Note that 1.10.0 is a valid semver version, 2.0.0 does not necessarily have to come after 1.9.0.

This field is required, and should exactly match the VersionName field. The editor will prevent you from packaging your mod if an invalid value is specified.

Plugins

Additional functionality has been added to the regular uplugin Plugins array. You can list other mod references (or Unreal Plugins) here, and SMM will know to download when installing your mod. If you add a plugin with a Mod Reference, this basically makes the listed mod a dependency for your mod.

The SML plugin should also always be listed here, allowing you specify what SML versions your mod supports. Each plugin should be listed as an object with the following properties:

Parameter Description of Function

Name

The mod reference of the plugin you are listing as a dependency.

This field is required.

SemVersion

Version range specifier for this dependency mod. Should follow semver format. You can prefix the version number with a comparison operator to allow a range of versions.

We suggest using the prefix ^, which generally allows any number in the patch field (the 3 in 1.2.3), and any number in the minor version field (the 2 in 1.2.3). However, it functions differently when the major version (the 1 in 1.2.3) is 0, so be sure that your major version is at least 1 to avoid this.

The prefix >= will allow all semversions higher than (and including) the one listed. Unless you have a very specific reason for doing so, you should probably use the ^ prefix instead.

This field is required.

Optional

This boolean property can be set to true if the dependency is not required. But if it exists, our mod might be able to unlock more functionality that depends on it.

This field is optional, and defaults to false if unspecified.

BasePlugin

This boolean property should be set to true for all plugin dependencies that are not mod dependencies. For example, regular Unreal Engine plugins your mod requires. SMM will not attempt to download these because they aren’t mods.

This field is optional, and defaults to false if unspecified.

Enabled

This field is not given any extra functionality by SML, but we have listed it here as well in order to draw extra attention to it. This should be set to true in every plugin item.

This field is required, and Satisfactory will fail to launch if it is omitted, citing the offending uplugin file in the error message.

RemoteVersionRange

A Semver range of versions accepted from the remote clients. This requires other players to have a certain version of the mod installed to be able to join hosts. See the Plugins SemVersion item above for the format for this field.

This field is optional, and defaults to your SemVersion if unspecified. If you aren’t using this behavior, you should exclude the field.

AcceptsAnyRemoteVersion

When true, when a multiplayer client joins, the check for if both host and client have the mod is installed is skipped. You can use this to create client-side or server-side only mods.

This field is optional, and defaults to false if unspecified. If you aren’t using this behavior, you should exclude the field.

Important C++ Fields

If your mod has C++ code, make sure that you list a UBT Module in the Modules plugin descriptor section. The examples below will demonstrate this.

Examples

Some example .uplugin s are presented here in their JSON format.

Example Blueprint mod .uplugin:

{
	"FileVersion": 3,
	"Version": 6,
	"VersionName": "6.2.1",
	"SemVersion": "6.2.1",
	"FriendlyName": "Example Mod",
	"Description": "This is a random Blueprint mod.",
	"Category": "Modding",
	"CreatedBy": "Satisfactory Modding Team",
	"CreatedByURL": "https://ficsit.app/",
	"DocsURL": "https://docs.ficsit.app/",
	"MarketplaceURL": "",
	"SupportURL": "",
	"CanContainContent": true,
	"IsBetaVersion": false,
	"IsExperimentalVersion": false,
	"Installed": false,
	"Plugins": [
		{
			"Name": "SML",
			"SemVersion": "^3.6.1",
			"Enabled": true
		},
		{
			"Name": "DependencyMod",
			"SemVersion": "^1.3.0",
			"Enabled": true
		}
	]
}

Example C++ and Blueprint mod .uplugin:

{
	"FileVersion": 3,
	"Version": 6,
	"VersionName": "6.2.1",
	"SemVersion": "6.2.1",
	"FriendlyName": "Example Mod",
	"Description": "This is a random example C++ and Blueprint mod.",
	"Category": "Modding",
	"CreatedBy": "Satisfactory Modding Team",
	"CreatedByURL": "https://ficsit.app/",
	"DocsURL": "https://docs.ficsit.app/",
	"MarketplaceURL": "",
	"SupportURL": "",
	"CanContainContent": true,
	"IsBetaVersion": false,
	"IsExperimentalVersion": false,
	"Installed": false,
	"Modules": [
		{
			"Name": "ExampleMod",
			"Type": "Runtime",
			"LoadingPhase": "PostDefault"
		}
	],
	"Plugins": [
		{
			"Name": "SML",
			"SemVersion": "^3.6.1",
			"Enabled": true
		},
		{
			"Name": "DependencyMod",
			"SemVersion": "^1.3.0",
			"Enabled": true
		}
	]
}

SMR UPlugin Validator

If you’d like to check the format for your uplugin file, SMR offers a validator on its help page. You can paste in your uplugin file into the box on the right and it will display any error messages below the box.

The validator isn’t perfect, but it can help troubleshoot many errors that could occur during upload.

If it fails validation, keep your eyes out for things like missing commas and mismatched braces and brackets.

Remember, you can totally avoid formatting concerns by using the Alpakit widget in the editor!

Consider asking on the Discord if you get stuck on this step.

Exporting

Up until this point, you have likely been using the Alpakit 'copy to mods directory' feature to stage your mods files in game’s folders for testing.

Behind the scenes, using the 'Alpakit Dev' or the 'Alpakit!' (just this mod) buttons generates a zip archive for you located at <starter project folder>/Saved/ArchivedPlugins/YourModReference/YourModReference-TargetPlatformName.zip.

Note that this folder is in the starter project’s Saved folder, not the Saved folder of any of your mods.

This zip contains all of your mod’s packaged files, although it does not contain any dependency mods - you must specify those via the system described in the uplugin section.

Consider checking the zip’s contents to see if they’re what you expect. If for some reason you need extra files to be packaged into the mod, follow the directions here to tell Alpakit to include them when building.

Sending Your Mod to Testers

You may want to send out an early release of your mod to a few users you trust to test it before continuing.

They will have to follow the Manual Installation directions to install it from the zip file.

Package for Release

Once you’re ready to release your mod, you will need to package your mod for uploading. It’s time to make use of the Release Targets and "Alpakit Release" button that we’ve been ignoring until now.

Release Targets Explained

As you may be aware, there are multiple different versions of Satisfactory you can download.

The distinction between the Early Access (EA, the main branch) and Experimental (EXP, early feature testing) branch is relatively well known. However, there are also are also different builds of the game for different platforms (targets). There are EA and EXP variants of each of these:

Windows - Client version of Satisfactory, the one you launch to play the game. People playing the game on Linux still use this version, they run it through a compatibility/emulation layer.
Windows Server - Windows Dedicated Server version of Satisfactory. It doesn’t have a visual interface and is used to run servers from Windows, which is somewhat uncommon.
Linux Server - Linux Dedicated Server version of Satisfactory. This is what most dedicated servers will be running, especially those hosted by third party services.

Your mod must be compiled in a slightly different way to be usable on each of these platforms, especially to be compatible with Linux Server. Thankfully, Alpakit handles compiling your mod for all 3 of these target platforms for you. However, while you are testing your mod locally in singleplayer, it’s a waste of time to compile and package the code for the other platforms you aren’t using. The "Alpakit Dev" and "Alpakit!" (just this mod) buttons follow your Dev Packaging Settings, compiling just the target(s) you care about while testing.

Now that we’re ready for release we can use the Release Targets checkboxes to define which targets the mod is compatible with. If you leave out one of these targets, the mod will not on that platform! In most cases, especially for mods with no custom C++ code, you should check all 3 targets.

Pressing the Alpakit Release button will package all mods that you have checked in the leftmost column in the multi-target zip format that the Mod Repository is expecting. In the example image below, clicking Alpakit Release will package the SML and ExampleMod mods for all 3 release targets, skipping the second mod in the list.

Alpakit Release with Example Mod and SML selected

Adjust the left column checkboxes so that only your mod is selected, then use the 'Alpakit Release' button. This will generate file in the same ArchivedPlugins folder mentioned earlier called YourModReference.zip. This zip file contains all of the mods' selected targets in one file ready to be uploaded to SMR.

Last Chance to Change Your Mod Reference

As mentioned on the Mod Reference section of the Getting Started guide, once you release your mod, you can no longer change its Mod Reference.

If you decide to change it, you’ll have to edit a number of files, most of which are described on that page.

Upload to Satisfactory Mod Repository

Follow the directions on the Uploading to SMR page to create a modpage and a release.