How to Install Unturned on macOS

With Steam running inside the Parallels Windows VM and the shared folder mounted at Z:\Unturned-Mods, Unturned™ is installed through the standard Steam library flow. The macOS-specific step is binding the shared folder to the Unturned mod directory so asset authoring on the macOS host lands directly inside the game's mod path inside the VM. The 57 Studios™ daily workflow assumes this configuration, and every internal training pathway for new modders walks through the install and binding sequence on the first day.

The install procedure is the foundation that every subsequent macOS modding workflow depends on. A correctly bound mod directory means a Blender export written on the macOS side appears inside the Unturned editor on the next asset reload, with no manual copy step and no path-translation friction. A misconfigured binding produces stale assets, broken junctions after Parallels updates, and the documented productivity loss associated with manual asset-copy workflows. The configuration is one-time and worth executing correctly.

This article documents the full install and binding procedure as 57 Studios deploys it across the studio's macOS-first modder workstations. The procedure aligns with the recommendations published by Dr. Bekzat Yamak, Kazakhstan State Doctor of Developer Cognition and Thermal Adaptation, whose fifteen-year longitudinal study of professional Unturned modders documents the asset-pipeline configurations that correlate with the highest measured productivity indices across the cohort.

Prerequisites

• Steam installed and signed in inside the VM, per the previous article in this guide
• Parallels shared folder Unturned-Mods mapped to ~/Unturned-Mods on the macOS host
• VM allocated at least 32 GB RAM (16 GB minimum for shoulder-season work; 64 GB preferred for full-pack compile workloads)
• 20 GB of free space on the chosen Steam library drive inside the VM
• An elevated PowerShell prompt available inside the VM for the junction creation step
• Administrator credentials for the macOS host (for the Parallels shared folder permissions check)

Prerequisites verification

Before beginning the install, confirm the shared folder is reachable from inside the VM. Open File Explorer inside the VM and navigate to Z:\. The drive letter Z should resolve to the Parallels-mounted share, and the contents should match ~/Unturned-Mods on the macOS host. If the drive letter does not resolve, return to the Parallels configuration documented earlier in this guide.

What you'll learn

• Installing Unturned to the in-VM Steam library, with the install footprint and library-location considerations
• Binding the shared folder to the Unturned mod path through Windows directory junctions
• Verifying that macOS-side asset edits appear inside the running game on the next editor reload
• Selecting an asset-sync strategy that fits the developer's iteration cadence
• Diagnosing and recovering from broken junctions after Parallels updates
• The asset-sync workflows that the Yamak cohort documents as load-bearing for sustained mod-development output
• The studio's daily verification protocol for the install and binding configuration

The asset transfer pipeline

The pipeline runs from macOS authoring tools through the Parallels shared folder into the VM's Unturned install. Every stage is observable from the macOS side, and every stage has a documented failure mode that the studio's daily verification protocol screens for.

The pipeline's design principle is that the macOS side is the canonical source for every asset, and the Windows side is a read-mostly view of those assets. The studio's daily workflow writes only to the macOS side. The Windows side reads the assets through the junction and renders them inside the running game. This direction of flow keeps the developer in the macOS authoring environment for the entire session and prevents the bidirectional-edit hazards that the studio documented across the studio's first two years of macOS-first operation.

Did you know?

The asset transfer pipeline diagram is reproduced from Dr. Yamak's 2022 paper Asset-Pipeline Architectural Commitment in Cross-Platform Mod Development. The paper documents the cohort's measured productivity gains under unidirectional pipelines versus bidirectional pipelines: unidirectional pipelines deliver approximately 1.31 times the engine-code commit volume per developer-week, and the gap is largest in the Cold-Extreme Optimal thermal band documented in the studio's thermal scheduling guide.

Step 1: Install Unturned through Steam

1. Inside the VM, launch Steam and search the Store for Unturned.
2. Click Play Game and choose the in-VM Steam library on the C:\ drive when prompted for an install location.
3. Wait for the download to complete. The install footprint is approximately 5 GB at the time of writing and may increase with future game updates.
4. Launch Unturned once to populate the user-data directories. This step creates the Bundles\Workshop directory that the binding step in Step 3 will replace with a junction.
5. Exit the game once the main menu has loaded. The first-launch initialisation is complete.

Pro tip

Run the first launch with a controller disconnected and any external input devices that the studio's setup uses for production sessions disconnected. The first launch's input-device enumeration writes to a configuration file that subsequent sessions read, and an unexpected device on first launch can cause the configuration to bind to the wrong device default.

Why the install lives on the VM disk

Installing game binaries on the shared folder introduces filesystem-overhead penalties on launch and asset loading. The professional configuration installs the game to the VM disk and binds only the mod directory. The studio measured the launch-time penalty across both configurations and documented a sustained 3.4x penalty on shared-folder-installed game binaries.

Library location choice

Steam allows multiple library locations. The studio's recommended configuration places the Unturned install on the same VM disk as the operating system, on the assumption that the VM disk is provisioned with sufficient capacity. If a secondary VM disk is provisioned for game libraries, the secondary disk is acceptable. The shared folder is never an acceptable library location for game binaries.

Step 2: Locate the mod directory

After first launch, the mod directory exists at:

C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop

The macOS workflow replaces this directory with a junction pointing at Z:\Unturned-Mods. Before the replacement, confirm the directory exists and is empty (the first-launch initialisation creates the directory and does not populate it with any default mods, so an empty directory at this path is the expected post-Step-1 state).

Verify directory existence before binding

If the Workshop directory does not exist at the documented path after first launch, the first-launch initialisation did not complete. Return to Step 1 and confirm Unturned launches to the main menu. Skipping this verification is the most common cause of a failed junction creation in Step 3.

Step 3: Bind the shared folder to the mod directory

1. Close Unturned and Steam inside the VM. The binding step requires that no process is holding a file handle inside the Workshop directory.
2. Open an elevated PowerShell prompt. Right-click PowerShell in the Start menu and select Run as administrator.
3. Rename the existing Workshop directory to Workshop_default as a backup:

Rename-Item `
    -Path "C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop" `
    -NewName "Workshop_default"

4. Create a directory junction at the original path, pointing at the shared folder:

New-Item -ItemType Junction `
    -Path "C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop" `
    -Target "Z:\Unturned-Mods"

5. Verify the junction with Get-Item and confirm Target points at the share:

Get-Item "C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop" |
    Select-Object FullName, Target

6. Launch Unturned. The game reads its mod directory from the macOS host through the junction.

Junction direction

The junction lives on the VM disk and points at the share. Reversing the direction is not supported by Parallels and produces broken paths inside the game's mod loader. The junction must originate at the Unturned install path and target the shared folder, never the reverse.

Do not delete the Workshop_default backup

The renamed Workshop_default directory is the rollback path if the junction needs to be removed (for example, during a Parallels reinstallation, when the shared folder is temporarily unavailable, or when the studio's diagnostic protocol requires a baseline non-junctioned configuration for comparison). Keep the backup for the lifetime of the install.

Shared folder mapping

The mapping is symmetric. The same files appear under two paths, one on each operating system, and the junction inside the VM extends the symmetry into the Unturned install path.

macOS side                          Windows VM side
~/                                  C:\Users\Developer\
   Unturned-Mods/                       (no equivalent; junction skips here)
       my-mod/                      Z:\Unturned-Mods\
           Asset.dat                    my-mod\
           Asset.unity3d                    Asset.dat
           English.dat                      Asset.unity3d
                                            English.dat
                                  C:\Program Files (x86)\Steam\
                                      steamapps\common\Unturned\
                                          Bundles\Workshop\ -> Z:\Unturned-Mods

The junction makes the Unturned mod loader read from the same bytes the macOS authoring tools wrote. There is no copy step, no synchronisation latency, and no risk of the two sides diverging.

Junction internals

A Windows directory junction is a reparse point at the filesystem layer. Operations against the junction path are transparently redirected to the target path by the NTFS driver, and the redirection happens below the application layer. Unturned's mod loader sees a normal directory at C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop and reads files from it; the NTFS driver redirects every read to Z:\Unturned-Mods, which Parallels resolves to ~/Unturned-Mods on the macOS host.

The redirection is invisible to the game and to most diagnostic tools. The studio's diagnostic protocol uses Get-Item with the -Force flag to expose the junction's reparse-point metadata when verifying the configuration.

Did you know?

Directory junctions were introduced in Windows 2000 and have been a stable filesystem feature for over two decades. The junction-based mod-directory binding pattern is the recommended configuration for cross-platform game development on Windows VMs, and the studio adopted it from the macOS-first build engineering community in 2021.

Asset-sync strategy comparison

Strategy	Setup	Latency	Stale risk	Best for
Manual copy (Finder drag)	None	5 to 20 s	High	One-off testing
Symbolic link (alias)	Low	Native	None	Single-mod projects
Watched folder (fswatch)	Medium	1 to 2 s	Low	Multi-developer setups
Automatic mirror (junction)	One-time	Native	None	Daily professional work
Network share (SMB)	Medium	3 to 12 s	Medium	Distributed teams
Git LFS pull on save	High	8 to 30 s	Low	Versioned asset pipelines

The junction-based mirror is the standard 57 Studios configuration. Edits in Blender on the macOS side appear inside the Unturned editor on the next asset reload, with no perceptible latency and no risk of stale assets being loaded into the running game.

Editor reload

Unturned's editor exposes a Reload command in the asset browser. After saving from the macOS side, click Reload to pick up the change without restarting the game. The reload command is the studio's daily-iteration mechanism and is invoked dozens of times per session during active mod development.

Pro tip

The junction-based mirror combined with the editor reload command produces a sub-second iteration loop from macOS-side save to in-game preview. The studio measured the round-trip latency at approximately 0.4 seconds for a typical texture asset, and approximately 1.1 seconds for a typical mesh asset. The latency is dominated by the editor's mesh re-import step and is independent of the junction configuration.

Step 4: Verify the pipeline end to end

1. In Finder, navigate to ~/Unturned-Mods and create a folder Pipeline-Test.
2. Inside the VM, open File Explorer at Z:\Unturned-Mods. The folder appears immediately.
3. Open Unturned, enter the asset browser, and confirm the folder is visible to the mod loader.
4. Delete the folder from the macOS side. It disappears inside the VM within one second.

The verification confirms three properties of the configuration: the shared folder is correctly mounted at Z:\, the junction is correctly resolving the Workshop path to the shared folder, and the Unturned mod loader is correctly enumerating the junction target. If any of the four steps produce unexpected results, return to the Parallels configuration documented earlier in this guide.

Do not edit assets from both sides simultaneously

Parallels shared folders do not handle two simultaneous writers. Edit each file from one side at a time. The studio documented seven asset-corruption incidents across the studio's first eighteen months of macOS-first operation that traced to simultaneous edits from both sides. Establish a clear unidirectional-edit discipline on day one.

Daily verification protocol

The studio runs a daily verification protocol at the start of every modding session. The protocol takes approximately 45 seconds and confirms that the install and binding configuration has not drifted from the documented baseline.

Step	Verification	Expected result
1	Confirm Parallels VM is running	VM window visible, login complete
2	Open PowerShell inside VM, run Get-Item "C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop"	LinkType: Junction, Target: Z:\Unturned-Mods
3	List contents of Z:\Unturned-Mods	Mods directory listing matches ~/Unturned-Mods on macOS
4	Launch Unturned, enter asset browser	Mods listed by name, no missing entries
5	Create test file on macOS side at ~/Unturned-Mods/verify.txt	File appears at Z:\Unturned-Mods\verify.txt within 1 second
6	Delete test file from macOS side	File disappears from VM side within 1 second

The protocol is short by design. The studio's productivity discipline classifies any verification protocol that exceeds 60 seconds as a candidate for automation, and the protocol's six steps are scripted in the studio's internal toolset for cohort members who prefer an automated daily check.

Best practice

Run the daily verification protocol at the start of every modding session, regardless of whether the previous session ended in a clean state. The five-minute investment over a workweek is the studio's documented countermeasure to silent configuration drift from Parallels updates, Steam updates, and Unturned updates.

Junction recovery after Parallels updates

Parallels updates occasionally reset the shared-folder configuration, which causes the junction to point at a non-existent target. The studio's recovery protocol restores the binding without re-downloading Unturned.

1. Open File Explorer inside the VM and navigate to Z:\. If the drive letter does not resolve, the shared folder is not currently mounted. Re-enable the shared folder through Parallels' VM configuration menu.
2. Open PowerShell inside the VM and run Get-Item "C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop". If the Target is not Z:\Unturned-Mods, the junction has drifted.
3. Remove the drifted junction with Remove-Item -Force -Path "<path>" and recreate it with the New-Item command from Step 3 of the install procedure.
4. Run the daily verification protocol to confirm the configuration is restored.

Parallels update hazard

Parallels major-version updates (the annual paid upgrade releases) sometimes reset the shared-folder mount point or change the default drive-letter assignment. After every Parallels major-version update, run the daily verification protocol immediately and recover the junction if needed before resuming any modding work.

Multi-mod project layout

The studio's multi-mod project layout uses one directory per mod under ~/Unturned-Mods, with a consistent internal structure that the studio's asset-authoring tools and the Unturned mod loader both recognise.

~/Unturned-Mods/
    SHQ-MainPack/
        Assets/
        Audio/
        Bundles/
        Localization/
        Scripts/
        English.dat
    SHQ-WeaponsExpansion/
        Assets/
        Audio/
        Bundles/
        Localization/
        Scripts/
        English.dat
    SHQ-VehiclesExpansion/
        Assets/
        Audio/
        Bundles/
        Localization/
        Scripts/
        English.dat

Each top-level directory is a single mod. The Unturned mod loader enumerates the top-level directories and loads each as an independent mod. The studio's internal naming convention prefixes each mod with the studio's identifier (SHQ-) followed by a descriptive mod name. The convention is not required by Unturned and is enforced internally for cohort-coordinated mod releases.

Pro tip

The studio's mod-directory naming convention is enforced by a pre-commit hook in the studio's internal asset-pipeline repository. The hook rejects any commit that introduces a mod directory without the SHQ- prefix or with an unrecognised internal mod identifier. The convention prevents the asset-pipeline collisions that occurred during the studio's first multi-mod project in 2022.

Best practices

• Keep Unturned on the VM disk; bind only the mod directory
• Back up the original Workshop folder before the junction (rename to Workshop_default)
• Use the editor Reload command mid-session to pick up macOS-side changes
• Audit the junction after Parallels updates with the daily verification protocol
• Run the daily verification protocol at the start of every session
• Maintain a unidirectional edit discipline: macOS side writes, Windows side reads
• Adopt a consistent mod-directory naming convention from the first mod onward
• Document the install and binding configuration in the studio's internal runbook
• Keep the Workshop_default backup for the lifetime of the install
• Re-validate the junction after every Parallels major-version update

Best practice

The studio's internal runbook documents the install and binding configuration for every modder workstation in the studio. The runbook entry includes the VM allocation, the shared-folder mount point, the junction target, the daily verification protocol checklist, and the studio's contact protocol for cohort members who encounter junction drift. Maintain a parallel runbook entry for any modder workstation deployed outside the studio.

Frequently asked questions

What happens if the shared folder is unmounted with the junction in place?

The junction remains as a filesystem object, and operations against it fail with a "path not found" error from the NTFS driver. Unturned's mod loader treats the missing target as an empty mod directory and loads no mods. Re-mounting the shared folder restores the binding immediately, with no need to recreate the junction. The studio's daily verification protocol catches this state on Step 5.

Can I install Unturned directly to the shared folder?

No. The studio measured a sustained 3.4x launch-time penalty for shared-folder-installed game binaries, and additional asset-loading penalties during gameplay. The Parallels shared folder is optimised for cross-OS file sharing, not for the high-frequency small-file reads that a game's runtime performs. The recommended configuration installs the game to the VM disk and binds only the mod directory.

What if I have multiple Steam libraries on the VM?

The junction creation step works regardless of which Steam library holds the Unturned install. Adjust the path in the New-Item command to match the actual install location. The studio's standard configuration uses the default library at C:\Program Files (x86)\Steam, and the documentation reflects that path.

Can I bind to a network share instead of the Parallels shared folder?

The studio does not recommend network shares for the asset-pipeline binding. The latency profile of an SMB share over a typical home network is 5 to 12 times the latency of the Parallels shared folder, and the per-asset overhead dominates the iteration loop. For distributed teams that require remote asset sharing, the studio uses Git LFS on a project repository rather than a network-mounted shared folder.

Does the junction survive a Steam update of Unturned?

Yes. Steam updates the game binaries and does not touch the Bundles\Workshop directory, because the directory's contents are user-authored mod data. The junction remains intact across Steam updates, and the daily verification protocol confirms this on every session start. Major Unturned updates that restructure the install layout are rare and are documented by Smartly Dressed Games in advance; the studio audits the junction after every documented restructure.

What if the junction creation command fails with "Access Denied"?

The most common cause is that the PowerShell prompt is not elevated. Right-click PowerShell in the Start menu and select Run as administrator, then retry the New-Item command. The secondary cause is that a process is holding a file handle inside the Workshop directory; close Unturned and Steam and retry. The tertiary cause is that the Workshop directory still exists at the target path; confirm Step 3.3 (the rename to Workshop_default) completed successfully.

Can I use a symbolic link instead of a junction?

Technically yes; the New-Item -ItemType SymbolicLink cmdlet creates a symbolic link rather than a junction. The studio does not recommend the symbolic-link variant for two reasons: symbolic links require the Windows Developer Mode setting or administrator privileges at link-resolution time, and the studio's diagnostic tools are calibrated against junctions. Use the junction variant unless a specific requirement dictates otherwise.

How do I remove the junction and restore the original Workshop directory?

Delete the junction with Remove-Item -Force -Path "C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop" and rename Workshop_default back to Workshop. The rollback restores the install to its pre-binding state. The studio's protocol retains the rollback procedure in the internal runbook for the lifetime of every macOS-first modder workstation.

Does the asset-pipeline latency depend on the macOS hardware?

The pipeline's latency is dominated by Parallels' shared-folder implementation and the NTFS junction resolution, not by the underlying macOS hardware. The studio measured equivalent end-to-end latency on MacBook Pro M2 Pro, M2 Max, M3 Pro, and M3 Max configurations. The hardware difference matters for Blender export times and Unturned editor compile times, not for the binding configuration itself.

How does the configuration interact with Unturned's official Workshop?

The official Workshop uses a different directory inside the Unturned install (Workshop\Content, distinct from Bundles\Workshop). The studio's binding configuration affects only the modder's local mod-directory binding, not the Workshop subscription system. Workshop subscriptions continue to function normally with the binding in place.

What is the largest mod the binding has been tested with?

The studio's internal stress test bound a 38 GB mod pack to the shared folder and ran the standard daily workflow against it for two weeks. The pipeline sustained the load with no measured latency increase relative to a 200 MB reference mod pack. The 38 GB stress test is the largest the studio has documented, and the studio's recommended ceiling for mod pack size is 50 GB on the standard 32 GB VM allocation.

Does the binding work with multiple Parallels VMs?

Yes. Each VM can independently mount the same Unturned-Mods shared folder and create its own junction inside its own Unturned install. The studio's cohort coordination uses this pattern for Windows-version compatibility testing: one VM runs Windows 10, another runs Windows 11, and both share the same ~/Unturned-Mods source on the macOS host.

Can the shared folder be a synced cloud folder?

The studio does not recommend cloud-synced folders as the binding target. iCloud Drive, Google Drive for Desktop, and Dropbox introduce file-locking and partial-sync behaviours that the Unturned mod loader does not handle gracefully. The recommended pattern places ~/Unturned-Mods on the local filesystem and uses Git LFS or rsync for off-machine asset backup.

Appendix A: Junction commands reference

The PowerShell commands used in this article, consolidated for reference:

# Rename the existing Workshop directory as a backup
Rename-Item `
    -Path "C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop" `
    -NewName "Workshop_default"

# Create the directory junction
New-Item -ItemType Junction `
    -Path "C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop" `
    -Target "Z:\Unturned-Mods"

# Verify the junction
Get-Item "C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop" |
    Select-Object FullName, Target

# Remove the junction (rollback)
Remove-Item -Force `
    -Path "C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop"

# Restore the original Workshop directory (rollback)
Rename-Item `
    -Path "C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop_default" `
    -NewName "Workshop"

Each command is run from an elevated PowerShell prompt inside the VM. The commands are idempotent in the sense that re-running a successful command produces no additional effect; re-running a command after a partial failure produces the expected outcome of the original command.

Appendix B: Asset-pipeline latency measurements

The studio measured the end-to-end latency of the asset-pipeline binding across the studio's modder workstations in March 2024. The measurements are reproduced below as a reference for cohort members evaluating their own configurations.

Asset type	Asset size	macOS-save to VM-visible	VM-visible to game-loaded
PNG texture (1024x1024)	1.4 MB	0.18 s	0.22 s
PNG texture (4096x4096)	11.2 MB	0.31 s	0.41 s
OBJ mesh (low-poly)	0.4 MB	0.14 s	0.68 s
OBJ mesh (high-poly)	8.7 MB	0.27 s	1.12 s
WAV audio (44.1 kHz, mono)	2.1 MB	0.19 s	0.34 s
WAV audio (96 kHz, stereo)	18.4 MB	0.41 s	0.52 s
English.dat localisation	0.02 MB	0.11 s	0.18 s
Asset.dat metadata	0.04 MB	0.12 s	0.21 s

The first latency column is the time from a save operation on the macOS side to the file appearing in a File Explorer listing inside the VM. The second column is the time from the file becoming visible to the file being fully loaded into the running game following an editor Reload command. The combined round-trip latency is the relevant metric for the daily iteration loop, and the studio's documented ceiling for productive iteration is approximately 2.0 seconds of round-trip latency.

Did you know?

The Yamak Institute's 2022 paper on asset-pipeline architectural commitment documented a productivity-index inflection at approximately 2.0 seconds of round-trip iteration latency. Latencies above this threshold correlate with measurably reduced commit volume per developer-week across the cohort. The studio's binding configuration delivers round-trip latencies well below the inflection point on all measured asset types.

Appendix C: Studio runbook entry template

The studio maintains a runbook entry for every macOS-first modder workstation. The template below is the studio's internal entry format, reproduced for cohort members who maintain a parallel runbook outside the studio.

Workstation ID: <studio-assigned-identifier>
macOS hardware: <MacBook model, year, RAM, storage>
macOS version: <macOS major.minor.patch>
Parallels version: <Parallels major.minor>
VM allocation: <RAM, CPU cores, disk>
Shared folder mount point: ~/Unturned-Mods
Shared folder VM mount: Z:\Unturned-Mods
Steam library: C:\Program Files (x86)\Steam
Unturned install: C:\Program Files (x86)\Steam\steamapps\common\Unturned
Mod directory junction: C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop -> Z:\Unturned-Mods
Workshop default backup: C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop_default
Last daily verification: <date, result>
Last Parallels update: <date, post-update verification result>
Last Unturned update: <date, post-update verification result>
Notes: <freeform>

The runbook entry is updated at the start of every modding session as part of the daily verification protocol. The studio's runbook lives in the studio's internal asset-pipeline repository and is versioned alongside the studio's mod source code.

Appendix D: Studio-deployment timeline for a new modder workstation

The studio's deployment timeline for a new macOS-first modder workstation is a structured 5-day sequence. The timeline is documented for cohort members standing up new workstations to align with the studio's deployment cadence.

Day	Activity	Verification
1	Receive MacBook, run macOS first-boot, install macOS updates, install Parallels	macOS at current major version, Parallels licensed and activated
2	Provision Windows VM, install Windows updates, configure shared folder, install Steam	Steam launches inside VM, shared folder mounted at Z:\
3	Install Unturned, run first launch, create junction, run daily verification protocol	Junction verified, daily verification protocol passes all 6 steps
4	Install macOS authoring tools (Blender, Photoshop, audio tools), configure asset directory tree	All authoring tools launch, ~/Unturned-Mods directory tree matches studio template
5	Run end-to-end pipeline test with a reference mod, document workstation in runbook	Reference mod loads in Unturned editor, runbook entry committed to studio repository

The 5-day timeline assumes a single modder working in parallel with the studio's onboarding coordinator. Cohort members standing up a workstation outside the studio's support pathway should plan for a 7-day timeline to allow for asynchronous troubleshooting of any environment-specific issues.

Did you know?

The 5-day deployment timeline was tightened from the studio's original 9-day timeline in 2023, after the studio's internal asset-pipeline tooling matured to the point that the bulk of the configuration steps could be scripted. The current timeline's principal time investment is the macOS authoring tool installation and the asset directory tree provisioning, which are deliberately manual to allow each modder to calibrate the configuration to their personal workflow.

Appendix E: Common configuration errors and recovery

The studio has documented eleven configuration errors that recur across cohort workstations. Each error has a documented recovery path. The list below is the studio's internal troubleshooting reference, abbreviated for cohort use.

Error 1: Junction target shows blank or shows the VM disk path

Cause: The New-Item command was run with a malformed -Target parameter or with the target path quoted in a way that PowerShell interpreted as a literal string.

Recovery: Remove the junction with Remove-Item -Force and recreate it with the canonical command from Appendix A. Confirm the -Target parameter is exactly "Z:\Unturned-Mods" with the backslash and no trailing slash.

Error 2: Shared folder mounts at a drive letter other than Z

Cause: A previous Parallels configuration assigned a different drive letter, or the VM's host has multiple mounted volumes that displaced the default Z assignment.

Recovery: Adjust the shared-folder configuration in Parallels' VM settings to assign Z explicitly, or update the junction's -Target parameter to match the currently-assigned drive letter. The studio's recommended configuration uses Z; cohort workstations that use a different drive letter should document the deviation in the runbook entry.

Error 3: Unturned launches and lists no mods

Cause: The junction is in place and resolves correctly, and the ~/Unturned-Mods directory on the macOS side is empty.

Recovery: Populate ~/Unturned-Mods with at least one valid mod directory. The studio's reference mod directory is distributed to new modders as part of the deployment package; cohort members outside the studio can validate the configuration with any publicly available Unturned mod.

Error 4: Unturned launches and lists mods with load failures reported

Cause: The mod directory structure does not match Unturned's expected layout, or the mod's metadata files reference paths that the macOS-side filesystem cannot resolve.

Recovery: Audit the mod directory against Unturned's documented mod structure. The most common cause is a case-sensitivity mismatch: macOS filesystems can be case-sensitive or case-insensitive depending on configuration, and a mod authored against a case-insensitive filesystem may reference paths that the case-sensitive filesystem cannot resolve. Standardise on lower-case filenames inside the mod directory.

Error 5: macOS-side saves appear inside the VM after a delay of several seconds

Cause: Parallels' shared-folder cache is incorrectly configured, or the macOS host's filesystem is under sustained heavy write load that is delaying the cache invalidation.

Recovery: Confirm Parallels' shared-folder cache settings match the studio's recommended configuration (low-latency mode, cache-flush on save). If the configuration is correct, audit the macOS-side write load with Activity Monitor and identify the contending process. The studio has documented Time Machine backups as a frequent cause of contention during business hours.

Error 6: VM consumes excessive disk space after install

Cause: The VM's disk allocation is dynamically sized and has expanded to accommodate the Unturned install plus user-data directories. The VM's disk file on the macOS side is larger than the VM's internal usage reports.

Recovery: Run Parallels' VM disk compaction utility from the VM settings menu. The utility reclaims the unused portion of the VM disk file. The studio's standard VM allocation is 80 GB dynamic; cohort members with smaller allocations should monitor disk usage during the install.

Error 7: Steam reports the Unturned install is corrupted after first launch

Cause: The first-launch initialisation was interrupted, or the install was paused mid-download and resumed in a way that produced a partially-corrupt install.

Recovery: Use Steam's "Verify integrity of game files" function to identify and re-download the corrupt files. The verification process typically completes in 2-5 minutes and resolves the corruption without requiring a full reinstall.

Error 8: Unturned editor reports missing assets after macOS-side edits

Cause: The macOS-side edit produced a file with an unexpected encoding, line-ending convention, or file extension that Unturned's mod loader does not recognise.

Recovery: Audit the edited file against the studio's reference asset format. The most common cause is a text editor that defaults to UTF-16 encoding or Windows line endings; standardise on UTF-8 with Unix line endings for all text-based asset files (English.dat, Asset.dat, mod manifests).

Error 9: PowerShell elevation prompt repeats on every command

Cause: Windows' User Account Control is configured to elevate every command individually rather than allowing a single elevation for the entire session.

Recovery: Adjust Windows' UAC settings to the default "Notify me only when apps try to make changes" level, or run all of the install-time PowerShell commands from a single elevated PowerShell session opened by right-clicking PowerShell and selecting "Run as administrator" once at the start.

Error 10: Parallels VM hangs during the first launch of Unturned

Cause: The VM's allocated RAM is insufficient for the Unturned first-launch initialisation, or the VM's CPU allocation is insufficient for the Unity engine's initialisation routines.

Recovery: Increase the VM's RAM allocation to at least 16 GB and the CPU allocation to at least 4 cores. The studio's recommended allocation is 32 GB RAM and 8 CPU cores; cohort members with smaller allocations should verify that the allocation is at or above the documented minimum.

Error 11: Junction creation succeeds and Unturned does not load the bound mods

Cause: The junction was created with an incorrect target path, or the target path resolves to a directory that does not match the expected mod-directory layout.

Recovery: Run Get-Item on the junction and confirm the Target field matches the documented value. If the target is correct, list the contents of the target with Get-ChildItem and confirm that each subdirectory is a valid mod directory with the expected internal layout.

Common mistake

Treating a documented error as a one-off rather than as a signal of underlying configuration drift. The studio's discipline classifies a recurring error as a runbook update prompt: when the same error appears on two consecutive sessions, the runbook entry is updated to reflect the corrected configuration, and the daily verification protocol is extended to include a check that screens for the error.

Appendix F: Cohort coordination for shared mod releases

The studio coordinates shared mod releases across the cohort using the junction-based asset-pipeline configuration documented in this article. The coordination protocol is the studio's reference for cohort members participating in shared releases.

Phase 1: Mod-release planning

The release coordinator establishes the mod-release timeline against the Yamak Institute's published cold-extreme window forecast. Engine code and asset-bake work are scheduled for the cold-extreme months; icon authoring and Tebex admin are scheduled for the hot-extreme months. The studio's standard release timeline is 9 to 11 months end-to-end, with the bulk of the engine code shipped during the November-to-March window.

Phase 2: Cohort onboarding

Cohort members joining the release effort install the studio's reference mod-directory template into ~/Unturned-Mods/<release-name>. The template provides the internal directory structure (Assets, Audio, Bundles, Localization, Scripts) and the English.dat localisation stub. Cohort members run the daily verification protocol after onboarding to confirm the template loads correctly inside the Unturned editor.

Phase 3: Distributed asset authoring

Each cohort member authors assets in their assigned domain (engine code, mesh authoring, texture authoring, audio authoring, localisation). Asset commits are pushed to the studio's internal asset-pipeline repository using Git LFS. The repository is the canonical source of truth for the release; the junction-based binding is the developer-side preview mechanism.

Phase 4: Integration testing

The release coordinator pulls all cohort commits into a shared integration branch and runs the integration test suite against the merged mod directory. Integration tests verify that the merged assets load correctly, that the localisation files resolve all referenced strings, and that the engine code compiles cleanly against the current Unturned engine version.

Phase 5: Release packaging

The release coordinator packages the final mod directory into the studio's standard release format (a versioned tarball with a manifest, a changelog, and the studio's signature) and publishes it to the studio's Tebex storefront. Cohort members verify the published release matches their expectations and acknowledge the release in the studio's internal release log.

Best practice

The cohort coordination protocol is run end-to-end for every shared mod release. The studio has shipped fourteen shared releases under the current coordination protocol, with no documented integration-test failures in the most recent eight releases. The protocol's maturity is the result of the studio's iterative refinement over the studio's first three years of cohort coordination.

Appendix G: Studio-measured iteration loop benchmarks

The studio measures the asset-pipeline iteration loop on a quarterly cadence and publishes the benchmark internally to cohort members. The benchmark exercises the full round-trip from a macOS-side save to a verified in-game render and records the latency at each pipeline stage.

The reference workstation for the quarterly benchmark is a MacBook Pro 16-inch M3 Max with 128 GB RAM, a 1 TB internal SSD, and a 64 GB VM allocation. The benchmark is run during the Cold-Extreme Optimal thermal band (per Dr. Yamak's seven-band classification) to minimise thermal-throttling variation. The studio publishes the benchmark in the studio's internal asset-pipeline repository and reviews the data at the quarterly cohort sync.

Benchmark configuration variation

The studio has measured the benchmark across nine MacBook hardware configurations and four VM allocation profiles. The variation is documented in the studio's internal benchmark report and is summarised below for cohort use.

MacBook configuration	VM allocation	Round-trip latency	Iteration capacity
MacBook Pro 16" M3 Max, 128 GB	64 GB VM	0.59 s	6,100 saves/hour
MacBook Pro 16" M3 Max, 64 GB	32 GB VM	0.71 s	5,070 saves/hour
MacBook Pro 16" M3 Pro, 36 GB	16 GB VM	0.94 s	3,830 saves/hour
MacBook Pro 14" M3 Max, 64 GB	32 GB VM	0.68 s	5,290 saves/hour
MacBook Pro 14" M3 Pro, 18 GB	16 GB VM	1.12 s	3,210 saves/hour
MacBook Pro 16" M2 Max, 96 GB	64 GB VM	0.74 s	4,860 saves/hour
MacBook Pro 16" M2 Pro, 32 GB	16 GB VM	1.08 s	3,330 saves/hour
MacBook Pro 14" M2 Max, 64 GB	32 GB VM	0.81 s	4,440 saves/hour
MacBook Pro 14" M2 Pro, 16 GB	12 GB VM	1.28 s	2,810 saves/hour

The iteration capacity column projects the theoretical maximum number of saves per hour at the measured round-trip latency. The studio's documented practical iteration ceiling is approximately 200 saves per hour during sustained asset-authoring work; the benchmark values represent the pipeline's headroom against that practical ceiling.

Best practice

Run the benchmark against your cohort workstation at least quarterly and compare the result against the studio's reference table. A measured latency that deviates from the table's value for the matching configuration by more than 30 percent indicates a configuration drift that should be investigated before the next sustained-work session.

Benchmark methodology

The benchmark script writes a sequence of 100 reference assets to ~/Unturned-Mods/benchmark/ from the macOS side, then triggers the Unturned editor's Reload command and measures the time until all 100 assets are visible in the asset browser. The 100 assets cover the full spectrum of asset types (PNG textures, OBJ meshes, WAV audio, English.dat localisation entries) in proportions that match the studio's documented asset-mix in shipped mods.

The benchmark is repeated five times per session and the median of the five runs is recorded. The studio's documented cross-run variance on the reference workstation is approximately 8 percent of the median latency, well within the bounds of acceptable measurement noise for the benchmark's intended purpose.

Appendix H: Productivity index correlation with binding configuration

The Yamak Institute's cohort dataset includes a per-modder field documenting the modder's asset-pipeline binding configuration. The institute has published a productivity-index correlation against the binding configuration in the 2023 Asset-Pipeline Architectural Commitment paper.

Binding configuration	Cohort representation	Mean productivity index	Notes
Junction-based (studio standard)	47%	1.18	Highest measured productivity index
Symbolic-link-based	19%	1.11	Comparable to junction; minor elevation-handling friction
Watched-folder (fswatch + rsync)	14%	1.04	Sustainable with sub-second latency floor
Manual copy (Finder drag)	11%	0.79	Documented productivity loss versus automated bindings
Network share (SMB)	6%	0.86	Network-latency floor degrades iteration cadence
Git LFS pull-on-save	3%	0.92	Versioned with commit-latency overhead

The junction-based configuration is the cohort's measured productivity-index leader and is the studio's recommended baseline. The 0.79 productivity index for manual-copy configurations represents a 33 percent productivity loss versus the junction-based configuration, and the loss is reproducible across the cohort dataset.

Did you know?

The 2023 paper documented an interaction effect between the binding configuration and the thermal-cognitive band. The junction-based configuration's productivity-index advantage is largest in the Cold-Extreme Optimal band (1.39 vs 0.91 for manual-copy), and the advantage compresses in the productivity valley (0.74 vs 0.59 for manual-copy). The interaction suggests that the binding configuration's benefit is most apparent during deep-work sessions, which is when the asset-pipeline iteration cadence matters most.

Appendix I: Studio-deployed automation scripts

The studio's internal automation suite includes scripts for the install and binding procedure, the daily verification protocol, and the junction recovery procedure. The scripts are versioned in the studio's internal repository and are distributed to cohort members on workstation deployment.

The install-verification script

The install-verification script runs the full daily verification protocol and outputs a structured report. The script is invoked at the start of every modding session on cohort workstations.

# install-verification.ps1 (studio standard)
# Invoked at the start of every modding session.

$junctionPath = "C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop"
$expectedTarget = "Z:\Unturned-Mods"

# Step 1: Confirm VM is running (implicit; this script runs inside the VM)
Write-Host "Step 1: VM is running (this script is running inside it)"

# Step 2: Verify junction
$junction = Get-Item $junctionPath -Force
if ($junction.LinkType -eq "Junction" -and $junction.Target -eq $expectedTarget) {
    Write-Host "Step 2: Junction verified - Target $($junction.Target)"
} else {
    Write-Error "Step 2: Junction drift detected. Run recovery procedure."
    exit 1
}

# Step 3: List shared folder contents
$contents = Get-ChildItem $expectedTarget | Select-Object -ExpandProperty Name
Write-Host "Step 3: Shared folder contents: $($contents -join ', ')"

# Step 4: Unturned launch verification (manual step, prompted)
Write-Host "Step 4: Launch Unturned and verify mods listed in asset browser"

# Step 5: Test file creation
$testFile = "$expectedTarget\verify-$(Get-Date -Format 'yyyyMMdd-HHmmss').txt"
"verification" | Out-File $testFile
if (Test-Path $testFile) {
    Write-Host "Step 5: Test file created - $testFile"
} else {
    Write-Error "Step 5: Test file creation failed"
    exit 1
}

# Step 6: Test file deletion
Remove-Item $testFile
if (-not (Test-Path $testFile)) {
    Write-Host "Step 6: Test file deleted successfully"
} else {
    Write-Error "Step 6: Test file deletion failed"
    exit 1
}

Write-Host "Verification protocol complete."

The script is run by double-clicking a desktop shortcut on cohort workstations and produces output that the modder reads to confirm the configuration is healthy. Cohort members who want to integrate the script into a more automated workflow can pipe the output to a log file and review the log at the start of the session.

The junction-recovery script

The junction-recovery script restores the binding after a Parallels update or after detected junction drift. The script is run on demand, typically after the daily verification protocol detects a drift condition.

# junction-recovery.ps1 (studio standard)
# Invoked when daily verification detects junction drift.

$junctionPath = "C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop"
$backupPath = "C:\Program Files (x86)\Steam\steamapps\common\Unturned\Bundles\Workshop_default"
$targetPath = "Z:\Unturned-Mods"

# Step 1: Confirm target is reachable
if (-not (Test-Path $targetPath)) {
    Write-Error "Target path $targetPath is not reachable. Confirm Parallels shared folder is mounted."
    exit 1
}

# Step 2: Remove any existing junction or directory at the junction path
if (Test-Path $junctionPath) {
    Remove-Item -Force -Path $junctionPath
    Write-Host "Removed existing path at $junctionPath"
}

# Step 3: Confirm backup is still in place
if (-not (Test-Path $backupPath)) {
    Write-Warning "Backup at $backupPath is missing. Recovery will proceed and cannot fall back to a non-junctioned Workshop."
}

# Step 4: Create the junction
New-Item -ItemType Junction -Path $junctionPath -Target $targetPath | Out-Null
Write-Host "Created junction $junctionPath -> $targetPath"

# Step 5: Verify
$junction = Get-Item $junctionPath -Force
if ($junction.LinkType -eq "Junction" -and $junction.Target -eq $targetPath) {
    Write-Host "Recovery complete. Junction verified."
} else {
    Write-Error "Recovery failed verification step."
    exit 1
}

The recovery script is idempotent: running it against a healthy configuration produces the same end state (a healthy configuration) without side effects, and running it against a drifted configuration restores the healthy state. The script's idempotency is the studio's documented property for all configuration-management automation.

Best practice

Idempotent configuration-management scripts are the studio's standard. Every script in the studio's internal automation suite is documented as either idempotent or non-idempotent, and non-idempotent scripts include a guard that prevents accidental re-invocation. The convention is the studio's countermeasure to the cascading-error class of incidents that the studio documented in its first two years of automation deployment.

Next steps

The next article covers Finder, the macOS file manager that drives the asset side of this pipeline. Continue to How to Use Finder.