How to Find the Master Bundle Tool

The Master Bundle Tool is the menu-driven utility that compiles your Unity project's assets into the bundle format that Unturned™ loads at runtime. After you import the Unturned project package, the tool installs itself as a menu entry in the Unity Editor's menu bar. Locating that menu entry, understanding what it does, and confirming it is operational are the final steps in the Unity Setup section of the 57 Studios™ Modding Knowledge Base.

This reference shows where the menu entry appears, what each option inside it does, what a successful build looks like, and how to recognize and resolve the most common build errors.

The article is written for beginners who have imported the Unturned project package but have not yet built a bundle. It assumes the project is open in the correct Editor version and that the package import completed successfully (the SDG folder is visible in the Project window).

Prerequisites

Before locating the Master Bundle Tool, confirm the following.

• The Unturned project package was imported into your Unity project in the previous article.
• The SDG folder is visible at the top level of the Assets folder in the Project window.
• The Editor finished processing all imported assets and is no longer showing a progress bar.
• At least one example prefab or sample asset is present so you have something to build during the verification at the end of this article.

Pro tip

Use one of the example prefabs from the imported SDG/Examples folder for your first test build. The examples are guaranteed to be configured correctly, so a failed build with an example as the input narrows the problem to your setup rather than the asset.

Did you know?

The Master Bundle Tool is implemented as a set of editor scripts inside the imported package. The tool is not a separate executable; it lives entirely inside the Editor process and is activated through the menu bar.

What you'll learn

• Where the Master Bundle Tool menu entry appears in the Unity menu bar.
• What each submenu option inside the tool typically does.
• How to identify your project's master bundle configuration asset.
• How to perform a test build and read the resulting log output.
• How to interpret common build errors.
• What the output folder structure looks like after a successful build.
• How to inspect the build cache and clear it when needed.
• How to recognize a healthy build versus a build that succeeded with warnings worth investigating.

Background

Unturned does not load loose Unity assets at runtime. Instead, the game expects asset bundles, which are compiled binary files that pack many assets into a single file along with metadata describing how the game should reference them. The Master Bundle Tool is the bridge between your authored Unity assets and these final bundle files.

The tool is implemented as a set of editor scripts that ship inside the SDG folder of the imported project package. When the Editor loads those scripts, Unity automatically registers the menu items they declare. The result is a new top-level menu entry that appears after the standard Unity menus.

Why bundles exist

Asset bundles are Unity's mechanism for shipping assets separately from the executable that loads them. A built bundle contains the assets (textures, models, sounds, prefabs) and a small index that maps each asset to a stable identifier. At runtime, an application can load a bundle, look up an asset by its identifier, and instantiate the asset into the scene.

For Unturned this mechanism is exactly what mod content needs. The Unturned executable is shipped by Smartly Dressed Games; mods provide additional bundles that the executable loads at runtime. The bundle format is the standard contract between modders and the game.

The bundle format is Unity-version-specific. A bundle built with Unity 2021.3.29 will not load correctly in a runtime built against a different Unity version. This is why the Unity Setup section spends so much attention on matching the Editor version to the version Unturned requires.

Why the tool is menu-driven rather than command-line

The Master Bundle Tool is invoked through the Editor's menu bar rather than through a command-line interface. This design choice reflects two practical realities. First, Unity's bundle build APIs are easier to call from an in-Editor context than from a command-line context. Second, the typical user of the tool is a mod author working interactively in the Editor; a menu-driven flow is more natural than a command line.

For advanced users who want to build bundles from automation (a continuous integration server, for example), the tool's underlying API can be invoked from a script that the Editor runs in batch mode. This is an advanced topic covered briefly in the appendices.

Primary content

Step 1: Look at the Unity menu bar

With your project open, examine the menu bar at the top of the Editor window. The standard Unity menus from left to right are: File, Edit, Assets, GameObject, Component, Window, and Help.

After the Unturned project package import, an additional menu entry appears between the standard menus. The exact name varies by package version, but it typically reads in a form that identifies it as the Smartly Dressed Games or Master Bundle tool. Look for a label that contains the words "Master Bundle," "SDG," or "Bundle Tool."

Common mistake

If you do not see a new menu entry, the package may not have imported successfully. Return to the previous article and verify that the SDG folder exists at the top level of the Assets folder. If the folder is missing, repeat the import.

Step 2: Open the menu and read the entries

Click the Master Bundle Tool menu entry. A dropdown opens with several submenu options. The exact names and counts depend on the package version, but the categories below are common.

Submenu	Typical purpose
Build Master Bundle	Compiles the current bundle configuration into output files
Build All Master Bundles	Compiles every bundle configuration in the project
Open Output Folder	Opens File Explorer at the build output location
Clear Cache	Removes intermediate build artifacts to force a clean rebuild
Settings	Opens the tool's settings inspector for the current project

Step 3: Locate or create a Master Bundle configuration asset

The tool builds bundles based on a configuration asset that lives inside your Assets folder. A fresh project will not have one. If the imported package includes a sample configuration, locate it in the Project window. Otherwise, create one through the Assets > Create menu under the SDG or Master Bundle submenu.

The configuration asset names the bundle, lists which folders or assets to include, and selects compression options. For a first test build, use a sample configuration or create a configuration that points at a single example prefab.

Step 4: Perform a test build

With a configuration asset selected, click the Master Bundle Tool menu and choose "Build Master Bundle." The Editor begins compiling. A progress bar appears at the bottom of the Editor window showing each stage of the build.

A successful build takes 10 seconds to several minutes depending on bundle size. When the build completes, the Editor's Console window (Window > General > Console) shows a success message with the output path.

Step 5: Inspect the build output

Use the "Open Output Folder" submenu option to open File Explorer at the build's output location. Inside, you will see the compiled bundle file along with its manifest.

BuildOutput/
└── YourBundleName/
    ├── YourBundleName.dat          (compiled bundle)
    ├── YourBundleName.dat.manifest (Unity-side manifest)
    └── (additional platform-specific files)

The exact filenames depend on platform target and compression settings. The presence of the .dat file and its manifest is the indicator of a successful build.

Step 6: Read the Console for warnings

Even when a build succeeds, the Console may show warnings. Warnings are informational and do not block the build, but they can hint at problems that will surface later. Common warnings include missing scripts on imported assets, references to assets outside the configured bundle scope, and shader compilation messages.

Best practice

Resolve warnings as you author rather than letting them accumulate. A growing list of warnings makes it hard to spot a new and meaningful one when something genuinely breaks.

Step 7: Confirm a healthy build state

A healthy build state looks like this.

• The Console window shows a success message naming the bundle and the output path.
• The output folder contains the .dat file and the corresponding .dat.manifest file.
• No errors (red entries) appear in the Console.
• Warnings (yellow entries) are minimal and explainable.
• The Editor returns to its normal idle state with no progress bar.

If any of these indicators are off, the build did not fully succeed. Read the Console output carefully and resolve any issues before treating the bundle as shippable.

Step 8: Optionally inspect the bundle with a third-party tool

For modders who want to look inside a built bundle, third-party tools like AssetStudio can open .dat files and list the assets they contain. This is an advanced inspection step that is not necessary for normal authoring, but it is useful for debugging cases where a bundle does not load as expected.

Pro tip

Inspecting a bundle with a third-party tool is a diagnostic step, not an authoring step. Treat the bundle as the opaque shippable artifact; if a bundle's contents need to change, change the source assets and rebuild rather than editing the bundle directly.

Comparison

The table below summarizes the compression options typically available in a master bundle configuration.

Compression mode	File size	Build time	Load time in Unturned	Recommended for
No compression	Largest	Fastest	Fastest	Development iteration
LZ4 (chunk-based)	Medium	Medium	Fast	Most published mods
LZMA (whole-bundle)	Smallest	Slowest	Slower	Large mods where download size matters

LZ4 is the standard choice for published mods because it balances file size against runtime load performance. LZMA is appropriate for very large mods that distribute through bandwidth-sensitive channels. No compression is useful only during local development.

Build time by bundle size

The build time of a bundle scales approximately linearly with the number of assets included. The table below documents typical build times observed across the 57 Studios pipeline.

Bundle size	LZ4 build time	LZMA build time
Small (single prefab, 1-10 assets)	< 10 seconds	10-20 seconds
Medium (a single weapon pack, 50-200 assets)	20-60 seconds	1-3 minutes
Large (a complete map with terrain, 500-2000 assets)	2-10 minutes	5-30 minutes
Very large (full content pack, 2000+ assets)	10-30 minutes	30-90 minutes

Build time is dominated by texture compression and shader compilation. Bundles with many textures take significantly longer than bundles with many prefabs but few textures.

Common build errors

The table below lists the most common build errors and the typical resolution for each.

Error message pattern	Likely cause	Resolution
"No master bundle config asset found"	No configuration asset selected or none exist in the project	Create a configuration asset and ensure it is selected before invoking the build
"Asset is outside bundle scope"	An asset referenced by the configuration is in a folder the bundle does not include	Move the asset into the configured folder or expand the scope
"Shader not found in compiled bundle"	A required shader is not included in the bundle or its dependencies	Add the shader to a resources list inside the configuration
"Missing script on prefab"	A C# script referenced by a prefab is missing from the project	Restore the script or remove the missing component from the prefab
"Build platform mismatch"	The Editor is set to a platform that does not match the target	Switch the Editor build target through File > Build Settings
"Insufficient disk space"	The output drive is full	Free space on the output drive or change the output location

Critical warning

Do not edit files inside the SDG folder to try to fix build errors. The folder is part of the imported package, and your edits will be reverted the next time you re-import the package. Address build errors by changing your own assets or your configuration asset, not by modifying the tool's scripts.

Decision flowchart

Build state machine

The build process runs through a documented sequence of states. The diagram below shows the state machine the tool follows during a typical build.

Advanced considerations

For large projects, the build cache can grow substantially. Use the "Clear Cache" submenu option periodically to reclaim disk space. Clearing the cache forces the next build to recompile every asset, which takes longer but produces a known-clean output.

When distributing a mod, the bundle file plus its companion files form a single unit. Renaming any of them after the build breaks Unturned's ability to load the bundle. Always distribute the entire output folder for a bundle as a unit, preserving the filenames the tool generated.

Did you know?

The Master Bundle Tool builds the same bundle format that Unturned's own runtime expects, which is why a freshly built bundle can be dropped into the appropriate Unturned mods folder and loaded immediately by the game. This direct compatibility is what makes Unity the canonical authoring environment for Unturned content.

Best practice

Before publishing a mod, perform a clean build by clearing the cache and then rebuilding. Clean builds catch problems that intermediate caches sometimes hide.

Multiple bundle configurations in a single project

A single Unity project can host multiple master bundle configurations. Each configuration produces a separate bundle, which is useful when a single project contains content that ships as separate mods (a weapon pack and a vehicle pack, for example).

The "Build All Master Bundles" submenu option builds every configuration in the project. The "Build Master Bundle" option builds the currently selected configuration. The choice between the two depends on whether you want to produce all bundles at once or iterate on a single bundle.

Pro tip

Use "Build Master Bundle" during iteration on a single mod to save build time. Use "Build All Master Bundles" before a release to ensure every mod in the project is up to date.

Build target platform

The Master Bundle Tool builds bundles for the Editor's current build target. The build target is set through File > Build Settings and defaults to Windows for new projects. For Unturned, bundles targeted at Windows clients are built with the Windows target; bundles targeted at Linux servers are built with the Linux target.

To produce bundles for multiple target platforms, switch the build target through File > Build Settings, rebuild, and rename or relocate the output before switching again. The tool does not automatically produce multi-target bundles in a single invocation.

Headless builds

For continuous integration setups, Unity supports headless builds through the -batchmode command-line flag. Combining -batchmode with a custom build script that invokes the Master Bundle Tool's API produces bundles without launching the Editor's GUI. The custom script is typically a small C# class with a static method that calls the tool's build API.

This is an advanced topic. Most individual modders do not need headless builds. The flag is documented here for completeness.

FAQ

Q: The Master Bundle Tool menu is missing even though SDG folder is present. What now?

The editor scripts in the SDG/Editor folder may have failed to compile. Open the Console window and look for compilation errors highlighted in red. Resolving those errors usually restores the menu.

Q: My build succeeds but Unturned does not load the mod. Where is the problem?

A successful build only confirms the bundle compiled. Game-side loading requires the bundle to be placed in the correct Unturned mods folder with the correct metadata files alongside it. Mod packaging is covered in later sections of this knowledge base.

Q: Can I script the build process from the command line?

Unity supports headless builds through the -batchmode command-line flag. Combining -batchmode with a custom build script that invokes the Master Bundle Tool's API is possible for studios that need automated builds. This is an advanced topic beyond the scope of this article.

Q: How often should I clear the build cache?

Once per week of active development is a reasonable cadence. Always clear the cache before producing a release build.

Q: My build produces a bundle but the file is much larger than I expected. Why?

A larger-than-expected bundle usually means the bundle includes more assets than you intended. Open the configuration asset and review the included folders or assets. Common causes of bloat include accidentally including the SDG/Resources folder in your bundle scope, or including high-resolution textures that should have been downscaled.

Q: The build produces multiple .dat files. What are the extra ones?

A typical bundle build produces a primary .dat file and one or more dependency .dat files. The dependency files contain shaders or shared resources that the primary bundle references. Distribute all of them together; the primary bundle will not load without its dependencies.

Q: Can I rename the bundle output files after the build?

Renaming the primary .dat file or its manifest will break the bundle. The names are referenced internally. If you need a different bundle name, change the bundle name in the configuration asset and rebuild.

Q: How do I configure compression for a bundle?

Compression is selected per configuration asset, typically through a dropdown in the Inspector when the configuration asset is selected. The choices are usually None, LZ4, and LZMA. LZ4 is the cohort default.

Q: The build hangs on "Compiling shaders" for a long time. Is something wrong?

Shader compilation is the slowest stage of most builds. A long compile is not necessarily a problem; complex shaders can take minutes to compile. If the compile genuinely hangs (no progress for more than 20 minutes), the most common cause is a shader that produces an internal compiler error. Inspect the Console for shader compilation errors and resolve them.

Q: My bundle loads in Unturned but the textures look wrong. What happened?

Texture issues in a loaded bundle usually trace to color space or texture import settings. Verify that your project's color space matches Unturned's (Edit > Project Settings > Player > Other Settings > Color Space) and that your texture import settings produce platform-appropriate formats. The color space mismatch is the most common cause.

Q: Can two bundles share an asset?

The Master Bundle Tool resolves asset references at build time. If two configurations include the same asset, the tool typically copies the asset into each bundle. For more advanced sharing (where one bundle references an asset that lives only in another bundle), consult the package's documentation on bundle dependencies.

Best practices

• Verify the Master Bundle Tool menu is visible before attempting any build.
• Start with a small test build using a sample prefab to confirm the toolchain works.
• Use LZ4 compression for published mods unless file size is a binding constraint.
• Clear the cache before producing a release build.
• Distribute the entire bundle output folder as a unit, preserving every filename.
• Resolve Console warnings as you author rather than letting them accumulate.
• Record the bundle's build configuration (compression, included assets, target platform) in your project notes.
• Use "Build All Master Bundles" before a release; use "Build Master Bundle" during iteration.

Appendix A: The master bundle configuration asset in detail

The master bundle configuration asset is a Unity asset (a .asset file in the Assets folder) that the Master Bundle Tool reads to know what to build. The asset is typically created through Assets > Create > SDG > Master Bundle (or a similarly named menu under the package's hierarchy).

The configuration asset typically exposes the following properties through the Inspector.

Property	Purpose
Bundle Name	The name of the bundle; determines the output filename
Include Folders	The list of folders whose assets should be included in the bundle
Include Assets	A list of specific assets to include (additive to the folder list)
Compression	None, LZ4, or LZMA
Output Path	The folder where the build writes the bundle (relative to the project root)
Target Platforms	The list of platforms this bundle is intended for
Strip Unused Resources	Whether to strip assets not referenced by any included prefab

The exact property set varies by package version. Inspect the Inspector when the configuration asset is selected to see the current options.

Configuration asset best practices

A few conventions make configuration assets easier to maintain.

• One configuration per mod. Each shippable mod should have its own configuration asset. Combining many mods into one configuration produces oversized bundles and complicates per-mod versioning.
• Configuration assets near the content. Place the configuration asset in the same folder hierarchy as the mod content. Centralized configuration folders make it harder to know which asset configures which content.
• Descriptive bundle names. Use bundle names that reflect the mod content (e.g., BlazetailRifleSet), not generic names (e.g., Bundle1).
• Documented assumptions. If a configuration depends on a specific Editor version, compression mode, or target platform, document the assumption in the project's README.

Pro tip

A configuration asset is a small .asset file that takes up almost no disk space. Create multiple configurations freely; each one represents an intentional shippable unit.

Appendix B: The build cache in detail

The build cache is the per-project storage where the Master Bundle Tool keeps intermediate build artifacts. The cache exists to speed up incremental builds: if an asset has not changed since the last build, the cache provides the pre-processed form without re-processing it.

The cache typically lives at Library/MasterBundleCache/ or a similarly named subfolder of the project's Library folder. The exact location varies by package version. The cache can grow to several gigabytes for large projects.

The "Clear Cache" submenu option deletes the cache. The next build after a cache clear is slow (every asset is reprocessed), but the build output is known-clean.

When to clear the cache	Rationale
Before a release build	Catches issues that intermediate caches might hide
When troubleshooting a bundle that loads incorrectly	Eliminates cache as a cause
When disk space is tight	Frees substantial space
After a major Unturned package update	Ensures the cache does not retain stale per-asset data
Otherwise	Not necessary; the cache speeds up routine builds

Appendix C: A timeline view of a first test build

For readers who learn well from a timeline, the diagram below maps a first test build from menu click to bundle inspection.

Appendix D: A summary of the article

This article walked through every step of locating the Master Bundle Tool, understanding its submenu options, and performing a first test build. The high-level flow is:

1. Confirm the Master Bundle Tool menu is visible in the Editor's menu bar.
2. Open the menu and read the submenu options.
3. Locate or create a master bundle configuration asset.
4. Perform a test build.
5. Inspect the build output folder.
6. Read the Console for warnings.
7. Confirm a healthy build state.

With this article complete, the Unity Setup section is also complete. Your Unity environment is fully configured to author and compile Unturned mod content.

The next section covers Blender, the 3D modeling software you will use to create custom meshes that you import into Unity.

Appendix E: Cohort observations on first-time builds

Across the 57 Studios pipeline, the first-time build is one of the more failure-prone steps in the Unity Setup section. The first-attempt success rate sits near 75 percent, with the remaining 25 percent of cases tracing to a small set of documented causes.

Cause	Frequency in cohort	Resolution
No configuration asset created yet	About one third of failures	Create a configuration asset through Assets > Create
Wrong build target selected	About one fifth of failures	Switch build target through File > Build Settings
Missing script on a prefab in scope	About one fifth of failures	Restore the script or remove the missing component
Asset outside configured scope	About one sixth of failures	Move the asset or expand the scope
Insufficient disk space on output drive	About one tenth of failures	Free space or change output path
Other	Remainder	Inspect the Console output

The configuration asset failure is the most common because the tool's flow assumes a configuration asset exists, and a fresh project does not have one until you create it. The Primary content section above includes a deliberate step to create the configuration asset to prevent this failure.

Appendix F: A note on the relationship with the broader 57 Studios pipeline

The Master Bundle Tool is the final piece of the Unity Setup section in this knowledge base, and it is also the bridge between Unity authoring and the rest of the 57 Studios pipeline. Once a bundle is built, the pipeline takes over: the bundle is packaged with metadata (covered in a later section), uploaded to Tebex (covered in the Distribution section), and made available to players who purchase the mod.

The pipeline treats the bundle as the unit of distribution. Everything upstream of the bundle (the Unity project, the imported package, the configuration asset) is authoring infrastructure. Everything downstream of the bundle (the packaging, the upload, the storefront listing) is distribution infrastructure. The bundle itself is the artifact that flows from authoring to distribution.

This is why the article above spends so much attention on confirming a healthy build state. A bundle that builds with hidden warnings is harder to distribute later, because the warnings often surface as player-visible bugs that prompt support tickets. A clean bundle, by contrast, distributes cleanly.

Pro tip

Treat every release build as a contract between you and your players. The bundle you ship is what they download and load. Confirm a healthy build state before each release, even if the same configuration produced a healthy build last time.

Appendix G: A glossary of bundle-related terminology

The terms below appear throughout this article and are worth defining once.

Term	Definition
Bundle	A compiled binary that packs assets together; the format Unturned loads at runtime
Master bundle	A bundle produced by the Master Bundle Tool; the conventional name for an Unturned mod bundle
Configuration asset	A Unity asset that defines what a bundle includes and how it is built
Compression mode	The algorithm used to compress the bundle (None, LZ4, LZMA)
Manifest	The Unity-side metadata file that sits alongside a built bundle
Build cache	The per-project storage of intermediate build artifacts
Build target	The platform the editor produces output for (Windows, Linux, etc.)
Output folder	The folder where the build writes the bundle and its manifest
Headless build	A build invoked from the command line through Unity's -batchmode flag
Asset reference	A reference from one asset to another, resolved by GUID at load time

The glossary builds on the glossaries in earlier articles in the section.

Appendix H: A short reflection on the Unity Setup section as a whole

The Unity Setup section is the foundation of the 57 Studios modding workflow. The five articles together (this one plus the four that precede it) take a modder from a Windows computer with no Unity software installed to a fully configured Unturned mod authoring environment with the ability to build and inspect bundles.

The flow is linear: each article depends on the one before it. The Hub is the prerequisite for the Editor; the Editor is the prerequisite for a project; the project is the prerequisite for the package import; the package import is the prerequisite for the Master Bundle Tool. A modder who completes all five articles in order has a complete authoring environment.

The Unity Setup section is also the longest section in the Unity-related portion of the knowledge base. Subsequent sections (Blender Setup, asset authoring, distribution) build on the foundation but are individually shorter because they assume the Unity environment is already configured.

Best practice

After completing the Unity Setup section, save your project in a healthy state and create a baseline _v1 snapshot following the 57 Studios file-snapshot pattern. The baseline gives you a clean rollback point if subsequent work breaks something. The 5-minute snapshot cost is a worthwhile insurance premium against losing a working setup.

Appendix I: A long-form note on bundle dependencies

Bundles can depend on other bundles. When a configuration includes a prefab that references a material that lives in a different bundle, the tool records the dependency in the bundle's manifest. At runtime, Unturned loads the bundle and follows the dependency manifest to load the referenced material from its own bundle.

Dependencies are useful for shared resources (shaders, common textures, base materials) that many mods reference. By placing the shared resources in a single dependency bundle and having every mod bundle depend on it, each mod bundle stays small.

Dependencies are also a source of bugs. If a mod is distributed without its dependencies, the mod will not load. The recommendation is to distribute every dependency alongside the primary bundle as a single unit.

Reading the manifest to identify dependencies

The bundle's .dat.manifest file is a plain-text file that lists the bundle's contents and its dependencies. Open the file in a text editor to inspect it. The dependency list, if present, names every other bundle this bundle requires.

Manifest section	Purpose
CRC	A checksum the runtime uses to verify the bundle was downloaded intact
Hashes	Per-asset hash values
ClassTypes	The Unity types of the included assets
Assets	The list of included assets
Dependencies	The list of bundles this bundle requires

Modders who maintain complex multi-bundle projects benefit from reading the manifest to verify the dependency structure. Modders who ship single-bundle mods rarely need to inspect the manifest.

Pro tip

Keep the manifest file alongside the bundle in your distribution. The runtime needs the manifest to load the bundle correctly; distributing the .dat file without the .dat.manifest produces a load failure that is hard to diagnose.

Appendix J: A note on platform-specific bundle quirks

Bundles built for different platforms have small but meaningful differences. The table below documents the quirks that matter for Unturned mod authoring.

Platform	Quirk	Implication
Windows	Default for new projects	The most-tested target
Linux	Server-side target	Used for Unturned dedicated servers
macOS	Less commonly used	Build only if you target macOS Unturned clients
Switch / mobile	Not supported by Unturned	Do not build for these targets

The Windows target produces bundles compatible with the most common Unturned clients. The Linux target produces bundles compatible with Unturned dedicated servers. Most mods need both, and the cohort convention is to build both targets and ship them as a paired distribution.

Common mistake

Building only the Windows target and shipping the resulting bundle is sufficient for clients but not for servers. Linux Unturned servers expect Linux-target bundles. Servers attempting to load a Windows-target bundle will fail with platform-mismatch errors.

Appendix K: A short tour of the Editor's Console window

The Console window (Window > General > Console) is the Editor's log output panel. The Master Bundle Tool writes its build messages to the Console, and the Console is the primary diagnostic surface for build issues.

The Console displays three categories of messages.

Category	Color	Meaning
Errors	Red	A condition that prevents the build from completing
Warnings	Yellow	A condition that does not prevent the build but is worth investigating
Info	White	Informational messages from the build process

Click any message in the Console to see its full detail. The detail pane shows the stack trace (for script errors), the asset path (for asset-specific messages), and any other context the message carries.

Console filters

The Console has filter buttons in its toolbar that toggle the visibility of each category. During an active build, leave all three filters enabled. During diagnostic work, disable the Info filter to reduce noise.

The "Clear" button in the toolbar empties the Console. Clearing the Console at the start of a build makes it easier to see only the messages from that specific build.

Best practice

Clear the Console before every Master Bundle build. The build's messages then stand alone in the Console without interference from earlier sessions. This makes post-build inspection faster and more reliable.

Appendix L: The relationship between the Master Bundle Tool and Unity's built-in AssetBundle API

Unity ships with a built-in AssetBundle API that any Unity project can use to build bundles. The Master Bundle Tool is built on top of this API; it does not implement bundle building from scratch. The tool's value is the Unturned-specific configuration model, the menu integration, and the post-build verification.

Modders who want to author Unturned bundles outside the Master Bundle Tool can call the AssetBundle API directly from their own editor scripts. This is an advanced path that the 57 Studios pipeline does not recommend for routine work. The Master Bundle Tool encodes years of Smartly Dressed Games convention; reimplementing that convention from scratch is error-prone.

The relationship between the two layers is:

Master Bundle Tool (menu integration, configuration, verification)
       |
       v
Unity AssetBundle API (low-level bundle build)
       |
       v
Bundle file on disk (.dat + .dat.manifest)

For most modders the Master Bundle Tool is the right level to interact with. The lower-level API is documented in Unity's official documentation for advanced users.

Appendix M: A second visual reference for healthy build output

The output folder of a healthy build contains the bundle file and its manifest. For an Unturned mod targeting Windows, the typical output structure is:

ProjectFolder/
└── BuildOutput/
    └── BlazetailRifleSet/
        ├── BlazetailRifleSet.dat
        ├── BlazetailRifleSet.dat.manifest
        └── (optional dependency files)

For a more complex mod that produces multiple bundles, the output structure typically extends to:

ProjectFolder/
└── BuildOutput/
    ├── BlazetailRifleSet/
    │   ├── BlazetailRifleSet.dat
    │   └── BlazetailRifleSet.dat.manifest
    ├── BlazetailVehiclePack/
    │   ├── BlazetailVehiclePack.dat
    │   └── BlazetailVehiclePack.dat.manifest
    └── SharedResources/
        ├── SharedResources.dat
        └── SharedResources.dat.manifest

The presence of every .dat file with its corresponding .dat.manifest file is the indicator of a successful build. Missing manifests or missing dependency bundles are the most common post-build issues.

Appendix N: A final reminder on the importance of clean builds

The article above repeatedly emphasizes the importance of clean builds before a release. The reason is worth restating.

A build cache that accumulates over many days of authoring eventually contains stale per-asset data that does not match the current asset state. The cache is correct in most cases (it is updated when an asset changes), but edge cases (a script that depends on a metadata field that changed without triggering a reimport, a shader that compiled differently in a previous build) can produce a built bundle that includes stale data alongside fresh data.

Stale data in a bundle typically manifests as small visual or behavioral bugs at runtime: a model that renders without a texture, an item that produces the wrong sound, a vehicle whose physics behave unexpectedly. These bugs are hard to diagnose because the source assets are fine; the bug is in the bundle.

A clean build eliminates the entire class of issue. Clear the cache, rebuild, and the resulting bundle reflects the current asset state without any stale carry-over. This is why the cohort convention is to clear the cache before every release build.

Critical warning

A mod shipped with stale-cache bugs is a mod that produces player support tickets weeks later. The 5-minute cost of a clean build before every release is a worthwhile insurance premium against weeks of post-release debugging.

Appendix O: A long-form note on the relationship with version control

The Master Bundle Tool produces build output in a folder that the tool manages. The build output should not be checked into version control. The output is regenerable from the source assets and the configuration, and checking it in would clutter the repository with large binary files that change on every build.

The recommended .gitignore pattern for a project that uses the Master Bundle Tool is to exclude:

• The Library folder (already standard for Unity projects)
• The Temp, obj, Logs, and UserSettings folders
• The BuildOutput folder
• Any other folder the tool uses for intermediate artifacts

The source assets, the configuration asset, and the project settings are all that need to be in version control. From those inputs, anyone with the project can reproduce the build.

Reproducible builds across machines

A useful property of the Master Bundle Tool is that the build output is approximately reproducible across machines. Given the same Editor version, the same package version, the same source assets, and the same configuration, two different machines should produce nearly identical bundles. Small differences may arise from timestamps and per-build identifiers embedded in the manifest, but the contents of the bundles are deterministic.

This property matters when collaborating on a mod. A colleague can clone the project repository, build a bundle on their machine, and produce a bundle that matches what you would have produced on your machine. The cohort relies on this property when distributing build responsibility across team members.

Pro tip

If you suspect a build is not reproducible, the most common cause is a divergent Editor version between machines. Confirm both machines use the same Editor version before troubleshooting further.

Appendix P: A note on supporting multiple Unturned versions

A mod author who supports multiple Unturned versions simultaneously (e.g., maintaining mods for both the current Unturned release and the previous one) needs separate Unity projects for each version. Each project has its own Editor version, its own imported Unturned package, and its own Master Bundle Tool configuration.

The cohort convention is to suffix the project folder name with the Unturned version it targets, for example:

D:\UnturnedMods\
├── BlazetailRifleSet_U3.24\
└── BlazetailRifleSet_U3.23\

This convention makes the version target immediately visible in the file system. Modders who maintain only the current version can omit the suffix; modders who maintain multiple versions benefit from the suffix.

Common mistake

Attempting to maintain multiple Unturned versions inside a single Unity project does not work. Each version requires its own Editor version, and Unity does not support side-by-side editor versions inside a single project. Use separate projects.

Appendix Q: Cohort observations on long-term Master Bundle Tool usage

Across the 57 Studios pipeline, modders who use the Master Bundle Tool over many months report a small set of recurring observations.

Observation	Frequency in cohort	Notes
Build times grow as projects accumulate assets	Common	Clear the cache periodically to keep build times manageable
Configuration assets drift out of sync with content	Occasional	Periodic configuration review catches the drift early
Warnings accumulate in the Console	Common	A weekly Console review keeps warnings manageable
The tool's UI feels stable for years	Universal	The tool's UI rarely changes between package versions
Headless builds are rarely needed	Universal	Only studios with continuous integration need them

The observations above are not failure modes; they are the natural patterns of long-term tool usage. Modders who recognize them adapt their workflow accordingly: clearing the cache, reviewing configuration assets, and addressing warnings as part of routine maintenance.

Appendix R: A wrap-up reflection on the Unity Setup section

This article is the last in the Unity Setup section. The section as a whole is the foundation of the Unturned modding workflow with the 57 Studios pipeline, and the Master Bundle Tool is the capstone: the point where authored assets become shippable bundles.

Modders who have completed this section have a complete Unity-side toolchain. They can install the Hub, install the Editor, create projects, import the Unturned project package, and build bundles. From this foundation the rest of the 57 Studios pipeline (Blender for modeling, Photoshop or Krita for textures, Audacity for sound, the broader Unturned authoring conventions) builds upward.

The article above has been deliberately long because the Master Bundle Tool is both the most consequential tool in the section (it produces the shippable artifact) and one of the more failure-prone tools (the cohort's first-build success rate is around 75 percent). Spending extra attention here pays off in fewer post-section troubleshooting requests later.

Best practice

Before moving on to the Blender Setup section, build at least one test bundle and confirm it loads in Unturned. The end-to-end confirmation (Unity authoring -> Master Bundle Tool -> Unturned loading) is the strongest validation that your Unity Setup is complete and correct.

Next steps

With the Master Bundle Tool located, understood, and verified through a test build, the Unity Setup section is complete. Your Unity environment is now fully configured to author and compile Unturned mod content.

The next section covers Blender, the 3D modeling software you will use to create custom meshes that you import into Unity. Continue to How to Install Blender.