Map Updates and Versioning

Intermediate40-60 minutesWindowsUnturnedUnity Editor

A published map is not a finished artifact. Map authors routinely release updates that add content, fix bugs, rebalance loot tables, rebake navmeshes, optimize performance, and fix compatibility issues after game updates. The update process on the Steam Workshop is straightforward in principle -- the author uploads a new payload and the Workshop points the existing entry at the new files -- but the operational details of version management, change communication, backward compatibility, and player data preservation determine whether the update improves or degrades the subscriber experience.

This article documents the cohort-validated map update and versioning workflow used by 57 Studios™ across every published map. The article covers version numbering conventions and when to increment each segment, change note writing for different update types, Workshop update propagation timing and what affects it, backward compatibility considerations across map versions, safe deprecation of old map versions, the player data persistence model across updates, safe removal of a map from active servers, and every common update failure mode with its resolution.

Prerequisites

• A map published to the Steam Workshop with a valid published_file_id.txt linkage file in the map folder.
• The map's original folder structure preserved. The folder must not have been renamed since the original publication.
• A backup of the current published version before beginning any update procedure.
• The map's Unity project accessible for rebuilding asset bundles.
• Access to the Workshop entry's edit page for metadata updates.
• A draft of the changelog entry for the new version.

What you will learn

• How to apply version numbering conventions that communicate the scope of each update to subscribers.
• How to write change notes that describe both the change and the reason for the change.
• How Workshop update propagation works from upload to subscriber download.
• How to maintain backward compatibility across map versions, and when breaking changes are appropriate.
• How to safely deprecate and retire old map versions without disrupting active subscribers.
• How the player data (save files, inventories, server state) is affected by map updates.
• How to safely remove a map from active servers without data loss.
• How to diagnose and resolve every common update failure mode.

Background: how Workshop updates work for maps

When a map author publishes an update to the Workshop, the Unturned™ Workshop tool packages the updated map folder into a new content payload, uploads the new payload to Valve's CDN, and points the existing Workshop entry at the new payload. The Workshop ID does not change. The update timestamp on the Workshop entry is updated to the current time. Subscribers' clients detect the updated timestamp during the next Workshop sync and download the new payload to replace the cached version.

A map update that is published correctly preserves every subscriber, every rating, every comment, and every favorite. The subscriber base does not need to re-subscribe. The map's Workshop history (change notes tab) records each update with its timestamp and change note.

The linkage file requirement

The published_file_id.txt file in the map folder is the critical piece of data that tells the Workshop tool to update an existing entry rather than create a new one. This file is created automatically by the Workshop tool when the map is first published. It contains the Workshop ID as a single line of text.

If the published_file_id.txt file is missing from the map folder, the Workshop tool will offer to create a new Workshop entry. This creates a duplicate entry with zero subscribers, while the original entry with all the subscribers continues to exist but no longer receives updates. The subscriber base is fragmented across two entries, and there is no clean recovery mechanism.

Update propagation timing

When a map update is published, the new payload is immediately available on Valve's CDN. However, subscribers' clients do not download the update immediately. The update propagates according to the following timeline:

Time since update	Subscriber experience
Immediate (0-1 minute)	The Workshop entry page shows the updated timestamp. Subscribers who manually refresh the page see the new change note.
1-30 minutes	Subscribers who launch Unturned™ during this window may download the update during the startup Workshop sync. The sync timing depends on Steam client settings.
30 minutes - 24 hours	The majority of active subscribers will have received the update by the end of this window. Subscribers who do not launch Unturned™ during this window will receive the update on their next launch.
24-72 hours	Subscribers with slow or intermittent internet connections may still be in the process of downloading the update. The Steam client handles the download in the background.
After 72 hours	Virtually all active subscribers will have received the update. Subscribers who have not launched Unturned™ in 72 hours or more will receive the update when they next launch.

The cohort recommendation is to wait 72 hours after publishing an update before announcing the update on community channels. This ensures that the majority of active subscribers have received the update before they see the announcement.

Version numbering

The Config.json file includes a Version field that the game reads to determine whether the locally cached version of the map matches the Workshop version. The version number must be incremented with every Workshop update that changes the map payload. The version number is displayed to subscribers in the Workshop entry's metadata and in the Unturned™ level selection menu.

Version format

The standard version format used by the 57 Studios™ cohort is Major.Minor.Patch.Build. Each segment communicates a specific type of change to subscribers and to server operators who manage the map's version on their servers.

Segment	What it communicates	When to increment
Major	A significant revision that may break backward compatibility. Major terrain overhauls, removal of custom assets, biome changes, or changes that invalidate existing player saves.	When updating from 1.x.x.x to 2.0.0.0 or similar.
Minor	New content additions that do not break backward compatibility. New towns, new custom assets, expanded playable area, new spawn table configurations.	When updating from 1.0.x.x to 1.1.0.0 or similar.
Patch	Bug fixes, balance adjustments, navmesh rebakes, performance optimizations. No new content.	When updating from 1.0.0.x to 1.0.1.0 or similar.
Build	Incremental build number for internal tracking. Reset to 0 when Minor or Patch increments.	Each Workshop upload that changes the map payload.

Version increment examples

Update type	Previous version	New version	Example change
Initial release	(none)	1.0.0.0	First Workshop upload
Bug fix	1.0.0.0	1.0.1.0	Fixed missing zombie spawn in sector B3
Bug fix	1.0.1.0	1.0.2.0	Fixed navmesh gap in industrial zone
Content addition	1.0.2.0	1.1.0.0	Added new town: abandoned fishing village
Content addition	1.1.0.0	1.2.0.0	Added new custom asset pack: dock props
Balance overhaul	1.2.0.0	1.3.0.0	Rebalanced all loot tables, adjusted zombie density
Major revision	1.3.0.0	2.0.0.0	Complete terrain overhaul, new biome, expanded playable area by 50 percent

The cohort recommendation is to reset the Patch and Build segments to 0 when incrementing the Minor segment, and to reset the Minor, Patch, and Build segments to 0 when incrementing the Major segment. This produces version numbers that are interpretable at a glance: 1.3.0.0 is the third minor update of the first major version.

Change notes

Every Workshop update must include a change note. The change note is a short text description of what changed in the update. It is displayed in the Workshop entry's Change Notes tab and, for curated maps, in the Unturned™ main menu when the map receives an update.

Change note structure

The 57 Studios™ cohort standard for change notes is:

[update type]: [specific change]. [reason for change, if not obvious].

Update type	Prefix	Example
Bug fix	Fixed:	Fixed: zombie spawn table in Northwood referenced an invalid zombie type. Zombies now spawn correctly in the Northwood industrial zone.
Content addition	Added:	Added: new point of interest at coordinates (1200, 800) -- an abandoned mine with three lootable structures and custom cave assets.
Balance adjustment	Adjusted:	Adjusted: high-tier weapon spawn rate reduced by 40 percent in coastal zones. This change addresses community feedback about early-game balance.
Optimization	Optimized:	Optimized: building mesh LOD chains for the downtown area. Framerate in this zone improved by approximately 15 percent on mid-range hardware.
Navmesh update	Navmesh:	Navmesh: rebaked navigation mesh for the entire map. Zombies can now pathfind through the forest region and across the river bridge.
Compatibility	Compatibility:	Compatibility: updated all shader references for Unturned 3.24.x. The map no longer displays pink placeholder materials on custom assets.

Multi-item change notes

For updates that include multiple changes, the cohort recommendation is to use a bullet-point format within the change note field:

Added: abandoned mine with three structures in the northeast region.
Fixed: missing zombie spawns in the fishing village.
Adjusted: reduced ambient zombie night spawn rate by 25 percent.
Updated: workshop description with correct asset ID list.

The Workshop change note field does not support BBCode formatting. Change notes are plain text only. Use simple prefixes and line breaks for structure.

Update procedure

The step-by-step update procedure below is the cohort-validated workflow for publishing a map update without losing subscribers or creating duplicate entries.

Pre-update checklist

Before beginning the update procedure, confirm:

• [ ] The map folder has not been renamed since the original publication.
• [ ] The published_file_id.txt file is present in the map folder.
• [ ] The map passes -ValidateAssets with zero errors.
• [ ] The map loads without errors in single-player testing.
• [ ] The map loads without errors on a dedicated server.
• [ ] The version number in Config.json has been incremented.
• [ ] A change note has been drafted.
• [ ] A backup of the current published version exists.

Update procedure via the built-in Workshop tool

1. Launch Unturned™ and navigate to the Workshop tab in the main menu.
2. Click Submit.
3. In the file picker, select the same map folder used for the original publish. The tool reads the published_file_id.txt file and offers to update the existing entry.
4. Confirm that the tool displays the existing Workshop entry title and ID, not a blank new-entry form.
5. In the Change Note field, enter the drafted change note.
6. If the preview image, description, or tags need updating, update them in the corresponding fields. For payload-only updates, leave these fields unchanged.
7. Click Submit.
8. The tool packages the updated map folder, uploads the new payload, and reports the Workshop URL. Open the URL in a browser to confirm the update timestamp and change note are displayed correctly.

Update procedure via SteamCMD

For authors who manage multiple maps or prefer a scriptable workflow, the SteamCMD update procedure uses a VDF configuration file.

1. Open the VDF file used for the original publish.
2. Update the publishedfileid value to the map's Workshop ID (change from 0 to the actual ID).
3. Update the changenote value to the drafted change note.
4. Update the contentfolder path if the map folder location has changed (but not the folder name).
5. Run SteamCMD with the workshop_build_item command:

   steamcmd.exe +login <username> +workshop_build_item "C:\path\to\map.vdf" +quit

6. SteamCMD detects the non-zero publishedfileid and updates the existing entry rather than creating a new one.

Do not rename the map folder

Renaming the map folder between publishes is the single most common cause of duplicate Workshop entries. The folder name is part of the linkage that the Workshop tool uses to find the published_file_id.txt file. If the folder is renamed, the tool may not find the linkage file and will offer to create a new entry. The folder name must remain stable across the map's entire lifecycle.

Backward compatibility

Backward compatibility refers to whether a map update preserves the ability for existing subscribers to continue playing without losing progress or encountering errors. Not every update needs to be backward compatible, but breaking changes should be communicated clearly and should be reserved for major version increments.

Backward-compatible changes

The following changes are backward compatible and can be published as a Minor or Patch version update without disrupting existing subscribers:

• Bug fixes (spawn table corrections, missing asset fixes, navmesh adjustments).
• Content additions that add new areas without modifying existing terrain.
• New custom assets that do not replace or remove existing assets.
• Performance optimizations (mesh LODs, material merging, occlusion adjustments).
• Spawn table balance adjustments (adding or removing entries, adjusting weights).
• Localization updates (new or corrected text entries).
• Workshop description, preview image, or tag changes (metadata does not affect map loading).

Breaking changes

The following changes break backward compatibility and should be published as a Major version update (e.g., 1.x.x.x to 2.0.0.0):

• Terrain heightmap or splatmap modifications that change the physical shape of the map.
• Removal or replacement of custom assets that are placed in the level.
• Biome changes (changing a winter map to a temperate map, for example).
• Changes to the level .asset file that alter the bundle reference or master bundle GUID.
• Changes to the map folder structure that affect asset bundle path resolution.
• Changes that invalidate existing player saves (player position, inventory, or progress data).

Player data across updates

Unturned™ stores player data for each map in the player's save directory. The save data includes player position, inventory contents, character skills, and progress state. When a map update is applied:

Save data type	What happens across updates	Risk
Player position	Saved as world coordinates. If the terrain changed at the saved coordinates, the player may spawn underground or inside an object.	Medium. Can be mitigated by only adding new terrain and not modifying existing terrain.
Player inventory	Saved as item ID references. If an item ID was removed from the map's spawn tables, the saved item still exists in the inventory but cannot be re-acquired if lost.	Low. The item remains in the inventory. It is only affected if the item's asset was removed from the bundle.
Character skills	Saved as skill level values. Not affected by map updates.	None.
World state (containers, buildables)	Saved as object state and position. If the map's object layout changed, containers or buildables may be floating, clipping, or missing.	High. This is the most common source of player frustration after a map update.
Quest or progress flags	Saved as custom data if the map uses custom quest systems. May break if the quest data format changes.	Medium to High. Depends on the custom quest implementation.

How to minimize player data disruption

The cohort recommendation for minimizing player data disruption across updates is:

1. Never modify the terrain heightmap after the map is published. All terrain changes should be additive (adding new terrain layers, new objects, new spawn table entries) rather than modifying existing terrain.
2. Never remove an asset from a bundle that is placed in the level. Removing an asset that is placed in the level causes that object to disappear from the map for existing players. Add new assets alongside existing ones rather than replacing them.
3. If an asset must be removed (due to a third-party content issue, for example), publish a breaking change as a Major version update and document the affected save data in the change note.
4. Test the update on a copy of an existing player save to confirm that the player can load into the updated map without errors.

Deprecating a map

Deprecation is the process of marking a map as no longer maintained. A map may be deprecated because the author no longer maintains it, because a newer map supersedes it, or because the map depends on a game version that is no longer supported.

Deprecation effects on subscribers

When a map is deprecated but remains on the Workshop:

• Existing subscribers retain their local copy of the map. The map continues to appear in the level selection menu and can be played in single-player and on servers that have the map installed.
• The map no longer receives updates. If a game update breaks the map's compatibility, the map will not be patched.
• New subscribers can still find and subscribe to the map, but they will receive the last published version with no expectation of future updates.

When a map is removed from the Workshop entirely:

• Existing subscribers retain their local copy on disk, but the map no longer syncs. If the subscriber reinstalls Unturned™ or moves to a new machine, the map cannot be re-downloaded.
• Servers that reference the map's Workshop ID through WorkshopDownloadConfig.json will fail to download the map during startup.

The cohort-recommended deprecation procedure

1. Update the Workshop description to include a prominent notice at the top: "This map is no longer maintained. [Alternative map name] is the recommended replacement."
2. Set the Workshop entry visibility to Public (if it was not already Public). Do not set it to Private. A deprecated map that is still useful to existing players should remain discoverable.
3. If an alternative map exists, add a [url] link to the alternative in the description header.
4. Do not update the map payload. The last published version remains available for existing subscribers.
5. If the map has associated Store Bundle items (curated maps), contact SDG to discuss the deprecation's effect on revenue share.

The cohort-recommended removal procedure

Removing a map from the Workshop is irreversible and should only be done when there is a compelling reason (third-party content dispute, legal issue, or the map is permanently broken and cannot be fixed). The cohort-recommended removal procedure is:

1. Announce the removal on the Workshop discussion page and community channels at least 30 days before the removal date.
2. After the 30-day notice period, set the Workshop entry visibility to Private.
3. The entry remains in Valve's database but is invisible to non-author accounts. Existing subscribers retain their local copies.

Map removal is irreversible

Deleting a Workshop entry is permanent. The Workshop ID, subscriber count, comments, ratings, and all metadata are lost. The only difference between setting the entry to Private and deleting it is that a Private entry can be restored to Public if needed. A deleted entry cannot be recovered.

Safe removal from active servers

When a map is removed from a dedicated server (because a newer version is available, because the server is changing maps, or because the map is deprecated), the server operator should follow the procedure below to ensure clean removal.

Removing a map from a server

1. Stop the dedicated server.
2. Remove the map folder from the server's Maps/ directory.
3. Remove or comment out the Map command in Commands.dat that references the map.
4. Remove the map's Workshop ID from WorkshopDownloadConfig.json.
5. Start the server and confirm the server starts without errors on the replacement map.
6. Notify players that the map has been removed.

Player data after map removal

When a map is removed from a server, the player data for that map (save files, buildables, container contents) remains in the server's save directory. The data is not automatically deleted. If the server operator intends to free disk space, the save files can be deleted manually after confirming that no rollback to the old map is planned.

Server operators who plan to re-install the map at a later date should keep the save files. The data is compatible with future versions of the same map as long as the backward compatibility guidelines in this article are followed.

Update failure modes

Failure mode	Cause	Resolution
Workshop tool creates a new entry instead of updating	The published_file_id.txt file is missing from the map folder, or the folder was renamed since the original publish.	Restore the original folder name. If the linkage file is lost, check backups. If no backup exists, set the original entry to Private and start a new entry, documenting the transition in the description.
Workshop tool reports "Failed to package folder"	The map folder structure is inconsistent. Files were added or removed since the last update in a way that the tool does not expect.	Compare the current folder structure against a backup of the last published version. Restore any missing required files.
Update published but subscribers report the old version	The Workshop CDN cache has not propagated the new payload to all edge servers. This is normal and resolves within 1-4 hours.	Wait 4 hours. If the issue persists, clear the local Workshop cache for the map and re-subscribe to force a fresh download.
Update published but the map does not appear updated for the author	The author's local Workshop cache has a stale copy. The author's client may be loading the map from the local Maps/ folder rather than from the Workshop cache.	Clear the Workshop cache for the map. Load the map through the Workshop subscription rather than from the local Maps/ folder.
Players report missing assets after an update	The update removed or renamed assets that were referenced by existing player saves or by the level data.	Restore the removed assets. Publish a corrective update. Document the issue in the change note.
Server crashes after a map update	The server's Workshop cache contains a partially downloaded updated payload.	Clear the server's Workshop cache. Re-download the map. Restart the server.
Update published at the wrong visibility	The visibility setting was accidentally changed during the update submission.	Change the visibility back to the intended setting through the Workshop entry's edit page in a browser. No re-upload is needed.
SteamCMD reports "publishedfileid not found"	The publishedfileid value in the VDF file is incorrect or the map was published under a different Steam account.	Verify the Workshop ID by opening the entry's URL. Confirm the VDF file uses the correct numeric ID.
Unturned game update breaks the map after a minor patch	The game update changed asset loading behavior or shader compatibility. This is not a map update issue but a game update compatibility issue.	Test the map against the new game version. Publish a compatibility update if the map does not load correctly.

Frequently asked questions

What happens if I lose the published_file_id.txt file?

The file can be recovered if you have a backup of the map folder from any point after the original publication. The file is a single line of text containing the Workshop ID. If no backup exists, you can recover the Workshop ID from the Workshop entry URL. Create the published_file_id.txt file manually with the Workshop ID as the only content.

If the file is lost and cannot be recovered, the only option is to update the existing entry through SteamCMD with the correct publishedfileid value. The built-in Workshop tool will offer to create a new entry if the linkage file is absent.

How do I revert a map update to a previous version?

The Steam Workshop does not support version rollback. When a new payload is uploaded, it replaces the previous payload. There is no mechanism to revert to a previous published version. If an update introduces issues, the author must either publish a corrective update that restores the previous content or publish a patch that fixes the specific issues.

The cohort recommendation is to maintain local archives of every published version. If a corrective update is needed, copy the previous version's files from the archive, apply only the fixes, and publish as a new version.

Can I update the map description without re-uploading the map payload?

Yes. The Workshop entry's metadata (title, description, preview image, tags, visibility) can be edited from the entry's edit page in a browser without re-uploading the map payload. Use the browser edit page for metadata-only changes. Use the built-in Workshop tool or SteamCMD only when the map payload itself is changing.

How do I notify subscribers about a breaking change?

Breaking changes should be communicated through multiple channels:

1. The change note in the Workshop update describes the breaking change explicitly.
2. The Workshop discussion page includes a pinned post about the breaking change.
3. Community channels (Discord, forums) where the map's player base congregates.

The cohort recommendation is to communicate breaking changes at least 1 week before the update is published, so that server operators and players can prepare for the transition.

Can I update a curated map without losing the curated status?

Yes. Curated maps are not frozen at the time of acceptance. Authors can submit updates through the normal Workshop update workflow. The main menu shows the "updated" label when a curated map receives an update. The curated status is not affected by updates.

What is the recommended minimum interval between updates?

There is no published minimum interval. The cohort recommendation is to batch minor fixes into a single update rather than publishing a new version for every individual fix. Publishing updates too frequently (more than once per week) can cause subscriber fatigue and may increase the likelihood of an update introducing new issues.

For curated maps, the cohort recommendation is to limit updates to once per month unless a critical bug or game compatibility issue requires an immediate patch.

How do I test a map update before publishing it?

1. Rebuild the asset bundles from the Unity project.
2. Run -ValidateAssets and confirm zero errors.
3. Test the map in single-player mode through the game client (not the editor).
4. Test the map on a dedicated server with the map installed locally.
5. Subscribe to the current Workshop version on a test account, then copy the updated folder over the cached version and confirm the map loads correctly.

Can I delete old versions from the Workshop change notes tab?

The Workshop change notes tab is an append-only log. Individual entries cannot be deleted. The only way to remove an entry is to delete the entire Workshop entry. Incorrect change notes can be corrected by publishing a new update with the corrected information.

What happens if I unpublish a map and re-publish it later?

If the map is set to Private, it can be returned to Public at any time. The Workshop ID, subscribers, ratings, and comments are preserved. If the map is deleted and re-published, it receives a new Workshop ID with zero subscribers and no history.

Best practices

• Never rename the map folder after the first publication. The folder name is part of the Workshop linkage.
• Keep a local archive of every published version. Label each archive with the version number.
• Write change notes that describe both the change and the reason for the change.
• Batch minor fixes into a single update rather than publishing multiple updates per week.
• Test every update on a dedicated server before publishing to the Workshop.
• Subscribe to the map from a test account to confirm the Workshop distribution path works for each update.
• Communicate breaking changes at least 1 week before the update is published.
• Maintain a changelog in the Workshop description that lists every version with its release date and key changes.
• Use a version number convention consistently across the map's entire lifecycle.
• Keep the published_file_id.txt file backed up in a location separate from the map folder.

Advanced considerations

Managing updates for curated maps with Store Bundles

If a curated map has associated Store Bundle items and an update changes the map's custom assets, the Store Bundle items may need updates as well. The author should coordinate with the SDG curation team before publishing the map update to ensure that the Store Bundle items remain compatible.

Large updates and subscriber patience

A large map update (500 MB or more) will take subscribers a noticeable amount of time to download. The cohort recommendation is to announce large updates in advance and to consider whether the update can be broken into smaller, incremental updates that are easier for subscribers to download.

Update dependencies across multiple Workshop entries

If a map update depends on another Workshop entry being updated first (for example, a map that uses a custom item pack that is also being updated), the dependency should be updated first, and the map update should be published after the dependency update has propagated. This ensures that subscribers who download the map update before the dependency update do not encounter missing assets.

Managing updates for curated maps

Curated maps require additional considerations during the update process. The SDG curation team monitors updates to curated maps, and an update that breaks the map's curated status or introduces issues for the associated Store Bundle items may require coordination with SDG before publication.

Coordinating with SDG

Before publishing a significant update to a curated map (Minor version increment or higher), the author should notify the SDG curation team through the established communication channel. The notification should include:

• The version number of the new build
• A summary of the changes (new content, removed content, balance adjustments)
• The expected publication date
• Any changes to Store Bundle items or custom assets that the Store Bundle items reference

SDG may request a review period before the update is published. The cohort recommendation is to allow at least one week between notifying SDG and publishing the update.

Updates that affect Store Bundle items

If the map update changes custom assets that the Store Bundle cosmetics reference (for example, removing a building model that a skin was designed around, or changing the material on a surface that appears in a cosmetic preview), the author should coordinate with SDG to update the Store Bundle items alongside the map update. Publishing a map update that breaks Store Bundle items without a corresponding Store Bundle update creates a mismatch between what players see in the store and what they see in the map.

Curated map update frequency

The SDG curation team does not enforce a minimum interval between curated map updates. However, the cohort recommendation is to limit curated map updates to once per month unless a critical bug or game compatibility issue requires an immediate patch. Frequent updates (more than once per week) can confuse players who see repeated "updated" labels on the main menu and may reduce the perceived stability of the curated map.

Worked example: publishing a minor update

The worked example below traces a real update scenario from start to finish. The map in this example is "Timber Valley" at version 1.2.0.0.

The change

The author of Timber Valley has created two new points of interest: an abandoned mine in the northeast quadrant of the map and a fishing village on the western coast. The new content requires:

• Modifying the terrain to add the mine entrance (heightmap change - breaking change)
• Adding 8 new custom assets (mine cart, fishing nets, dock planks, etc.)
• Updating the zombie spawn tables to include zombie spawns in the new areas
• Rebaking the navmesh to cover the new areas

Pre-update validation

The author runs -ValidateAssets on the updated build. The validation reports two errors: a mesh readable warning on the mine cart model (the navmesh CPU Readable flag is incorrectly enabled) and a missing material on the fishing village dock (a material was not assigned to the dock planks). The author fixes both issues, rebuilds the bundle, and re-runs validation. Zero errors.

Version increment

Because the update includes terrain heightmap modifications (a breaking change) and new content, the author increments the version from 1.2.0.0 to 2.0.0.0. The major version increment communicates that this update introduces breaking changes that may invalidate existing player saves.

Communication

One week before the update, the author posts on the Workshop discussion page that the 2.0.0.0 update is coming and that existing player saves in the northeast quadrant may be affected by the terrain changes. Server operators are advised to back up their save data before the update.

Publication

The author selects the map folder, confirms the published_file_id.txt file is present, enters the change note, and clicks Submit. The upload completes successfully. The author tests the update from a separate Steam account, confirms the new areas load correctly, and confirms that a test player save from the 1.2.0.0 version loads into the 2.0.0.0 map without errors (the player spawns at a safe distance from the modified terrain).

Post-update

The author monitors the Workshop discussion page for issues. One player reports that their base, which was located in the northeast quadrant, is now partially inside the new mine terrain. The author acknowledges the issue, explains that this was a documented breaking change, and offers to help the player recover their items via admin commands. The author adds a note to the update's change note about the affected area.

Appendix C: Version history template for Workshop description

The following BBCode template can be added to the Workshop description to display the map's version history. The template uses only tags that the Workshop BBCode renderer supports.

[h2]Version History[/h2]
[b]v2.0.0.0[/b] - 2026-07-26 - Major revision. Added abandoned mine and fishing village. Terrain heightmap changes in northeast quadrant. Breaking change: existing saves in NE quadrant may be affected.
[b]v1.2.0.0[/b] - 2026-06-15 - Added two new custom vehicle spawns. Adjusted high-tier loot distribution in coastal zones.
[b]v1.1.0.0[/b] - 2026-05-20 - Added custom tree pack. Replaced vanilla trees in forest biome with custom models.
[b]v1.0.1.0[/b] - 2026-05-01 - Fixed missing zombie spawn in Northwood sector. Corrected navmesh gap at river crossing.
[b]v1.0.0.0[/b] - 2026-04-15 - Initial release.

Cross-references

• Server Log Error Reference - the next article, a comprehensive reference of server log error messages related to maps.
• Map Curation and Submission - the previous article, covering the curation pipeline that a map may enter after initial publication.
• Workshop Upload Process - the Workshop publication workflow that is re-executed for each update.
• Steam Workshop Submission - the general Workshop submission workflow, including the update procedure for all mod types.
• Map Loading Failures - the loading validation reference that applies to new versions published as updates.
• Workshop Content on Dedicated Servers - how servers handle updated Workshop content and the dependency order for Workshop entries.

Appendix A: Version number convention reference card

MAJOR.MINOR.PATCH.BUILD
   |      |      |    |
   |      |      |    +-- Build number (internal, reset on Minor/Patch increment)
   |      |      +-- Patch: bug fixes, balance, optimizations (no new content)
   |      +-- Minor: new content, new assets, new areas (backward compatible)
   +-- Major: breaking changes, terrain overhaul, biome change

Examples:
1.0.0.0 = Initial release
1.0.1.0 = First bug fix
1.1.0.0 = First content addition
2.0.0.0 = Major revision (breaking changes)

Appendix B: Update checklist

Before publishing any map update, verify each item on this checklist.

• [ ] Backup of the previous published version exists
• [ ] Map folder name has not changed since original publication
• [ ] published_file_id.txt is present in the map folder
• [ ] Config.json version number is incremented correctly
• [ ] -ValidateAssets produces zero errors
• [ ] Map loads without errors in single-player testing
• [ ] Map loads without errors on dedicated server
• [ ] Change note is drafted (specific change + reason)
• [ ] Preview image updated if visual appearance changed significantly
• [ ] Description updated if features or content changed significantly
• [ ] Breaking changes communicated to community (if applicable)
• [ ] Old version archived locally

Document history

Version	Date	Author	Notes
1.0	2026-07-26	57 Studios	Initial publication. Complete map update and versioning guide with version numbering conventions, update procedure, backward compatibility guidelines, and deprecation workflow.