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
- Wait for the Map Editor's sync indicator to finish. Cloud sync is helpful but is not a backup of every local file.
- Close every smudgy window so logs, settings, package state, and map files are no longer being written.
- Copy the entire
smudgydirectory to a dated location. - 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
|
|
|---|