Table of Contents

Data files and backups

Smudgy keeps ordinary configuration under your Documents directory: 

Documents/smudgy/

Development builds use Documents/smudgy-dev/ so test accounts, servers, maps, and packages do not alter release data. Release candidates use the release directory.

Make a complete backup

  1. Wait for the Map Editor's sync indicator to finish. Cloud sync is helpful but is not a backup of every local file.
  2. Close every smudgy window so logs, settings, package state, and map files are no longer being written.
  3. Copy the entire smudgy directory to a dated location.
  4. Keep at least one backup outside the computer when the maps or scripts would be difficult to recreate.

The operating-system credential store is separate. A directory backup does not necessarily include saved profile passwords, account sessions, API keys, or package secrets. Plan to sign in again and re-enter secrets after moving to another computer. When no credential store is available, some secrets use obfuscated fallback files inside the data directory. Those files are copied by a backup and are not encrypted, so protect the backup as you would protect the credentials themselves.

What is in the top-level directory

Path Purpose
settings.json Global appearance, input, logging, map preferences, and update settings.
map-scopes.json Which cloud map folders and loose areas belong to which server entries.
maps/ The local cache of cloud maps. Pending writes make this worth preserving even though the server is authoritative after sync.
smudgy.log Application diagnostics, not MUD session output.
<server>/ One directory for each saved server.

Account metadata may also appear here, while secret tokens normally live in the system keyring.

What is in a server directory