Workshop save folder name vs. SessionName mismatch breaks mod Storage lookup (SE1)

First Observed: Update 1.207 (persists through subsequent updates as of 28 July 2026)

Category: Save/Load, Workshop worlds, Mod API

Severity: High for worlds that ship per-save mod configuration in `Storage\`

When a player starts a new local instance of a subscribed workshop world, the game creates a save folder named after the workshop title, but writes <SessionName> in Sandbox.sbc and Sandbox_config.sbc with a (Workshop) prefix. These names diverge immediately.

Mods that store per-world settings under Storage\ (via IMyUtilities / WorldSavePath) look in a path derived from <SessionName>, not the actual folder on disk. They fail to find the author's bundled configuration, create a fresh Storage\ tree with defaults, and gameplay differs from what the world author intended (e.g. Realistic Gravity / Real Orbits speed limits).

This is a vanilla game bug, not a mod bug.

Here's the mismatch bug chain:

`Sandbox.Engine.Networking.MyWorkshop`:

line 50-57: source of Workshop prefix

public static MyWorkshopPathInfo CreateWorldInfo()
{
   return new MyWorkshopPathInfo
  {
      Path = m_workshopWorldsPath,
      Suffix = m_workshopWorldSuffix,
      NamePrefix = "Workshop" // source of Workshop prefix
  };
}

1. Mismatch is introduced when the save is created:

`Sandbox.Engine.Networking.MyWorkshop.TryCreateWorldInstanceBlocking`:

1722: string text = MyUtils.StripInvalidChars(world.Title);
...
1734: sessionPath = MyLocalCache.GetSessionSavesPath(text, contentFolder: false, createIfNotExists: false); // creates folder from world.Title (NO prefix)
...
1784: myObjectBuilder_Checkpoint.SessionName = $"({pathInfo.NamePrefix}) {world.Title}"; // NamePrefix = "Workshop" from CreateWorldInfo()
...
1791: MyLocalCache.SaveCheckpoint(myObjectBuilder_Checkpoint, sessionPath);

<SessionName> in sbc: `(Workshop) Proper Solar System with Asteroid Belt, Trojans (Real Solar Systems World)`

2. On load, WorldSavePath is overwritten to follow SessionName, not the actual folder:

`Sandbox.Game.World.MySession.Load`:

3194: Static = new MySession
      {
         // ...
3200:    CurrentPath = sessionPath // folder actually written by the game, no prefix
      };
      // ... load sector data from sessionPath ...
3244 Static.WorldSavePath = Path.Combine(MyFileSystem.SavesPath, checkpoint.SessionName.Replace(':', '-')); // WorldSavePath is overwritten to follow SessionName, but CurrentPath is the actual folder written by the game, no prefix

public string CurrentPath
{
   get
   {
      return m_currentPath;
   }
   set
   {
      m_currentPath = value;
      WorldSavePath = value;
   }
}

3. Mods use `WorldSavePath`, not `CurrentPath`

`Sandbox.ModAPI.MyAPIUtilities` — all per-world storage goes through `WorldSavePath`:

219: TextReader IMyUtilities.ReadFileInWorldStorage(string file, Type callingType)
     {
        // ...
225     string text = Path.Combine(MySession.Static.WorldSavePath, "Storage", StripDllExtIfNecessary(callingType.Assembly.ManifestModule.ScopeName));

So, for instance, Real Orbits looks in:

`...\Saves\<steamid>\(Workshop) Proper Solar System... \Storage\2609118808.sbm_RealisticGravity\Config.xml`

`...\Saves\<steamid>\Proper Solar System... \Storage\2609118808.sbm_RealisticGravity\Config.xml`

It also breaks campaign data for Proper Fleet Encounters, possibly breaks filters & blacklists in MES, custom configs in AiEnabled/CrewEnabled, world-author-configured consumable item returns in BB's Consumable Loot Items, and any other world-author-set custom (non-default) mod settings that are saved within any submitted community world.