Miner Replacedunofficial guide

Edit a file, confirm the change, then run

The base game supports editing its .py code files with an external editor such as VS Code. Enable File Watcher, save a change to the active file and confirm that the game displays it before running. File detection and program execution are separate steps.

Programming Updated

Start with the active file and a backup

Stop the program and keep a copy of the code you are about to change. Identify the actual .py file used by the current save, then open that same file in your editor. A similarly named copy in another folder will not update the program you are looking at.

This workflow deliberately gives no hard-coded Windows or macOS save path: the current official description confirms the file format and watcher, but not a universal folder path. Use your installation’s current documentation or a file you have positively matched to the in-game code window.

Enable File Watcher in the game’s settings. Base-game option documentation describes it as incompatible with code Autosave; if the watcher cannot be enabled, check whether that setting is active. Confirm the wording in your current version rather than relying on an assumed menu layout.

One safe edit round trip Active .py file Save edit File Watcherdetects save Confirm textin game manual choice Run
File detection and execution are separate. Confirm the changed text in the game before deliberately starting the program.

Verify one round trip before a large edit

  1. Identify: compare the file’s existing content with the corresponding in-game code window.
  2. Edit: while stopped, make one small change that is easy to recognize. A harmless whitespace change can test synchronization without adding a new game action.
  3. Save: explicitly save the file in the external editor. Unsaved text is not a filesystem change.
  4. Confirm: check that the game’s displayed code matches the saved file.
  5. Run: start the program in the game when you are ready and inspect the expected result.

If the displayed text does not change, stop at the confirmation step. Repeatedly executing old code makes a synchronization problem look like a logic problem.

The watcher’s job is detecting edits. The official description does not say that saving automatically executes the program, so do not treat a save as a run.

When the edit does not appear

The editor still marks the file as unsaved.
Save it first, then check the game again.
The file is saved but the game shows old text.
Recheck File Watcher and confirm the file belongs to the active save and code window. Compare actual content, not just the filename.
The watcher cannot be enabled.
Check the documented Autosave conflict and the current setting explanation.
The text appears, but the behavior is unchanged.
Confirm which program you executed and inspect the changed line’s execution path. A saved line in a branch that never runs will not change the observed result.
The editor reports valid Python, but the game rejects it.
Return to the game-language boundary. Editor validation does not establish game support.

Keep a clear recovery path

Change one copy at a time and keep the last working version until the new one behaves correctly. When restoring a backup, repeat the save → confirm → run sequence instead of assuming the restoration has already reached the game.

This page covers the documented base-game editing workflow as preparation for DLC work. It does not establish DLC-specific file layout, cross-file import behavior, cloud-sync conflict resolution or automatic handling of file creation and deletion.

Once the saved text is confirmed, use the first-failure method for code problems. Keeping synchronization and execution separate gives you one fewer unknown when diagnosing a run.

Sources and further reading