Skip to content

Instances

An instance is the game folder of a profile: its worlds, options, screenshots and mods. Each Minecraft version has its own instance. Your server list, key binds and client settings are shared between instances, and resource packs come from your normal Minecraft folder.

Where instances live

Operating system Instances folder
Windows %APPDATA%\Xol\instances\
macOS ~/Library/Application Support/Xol/instances/

Each profile gets a default instance named after the profile: xol-1.8.9 and xol-1.7.10. The instance is created the first time you press Play or Repair for that profile. A clone gets the name you give it.

The fastest way to get there is the Open folder menu. It is on the main screen, beside Launch options, and as a row of buttons in Settings ▸ Instance ▸ Open folder.

Entry Opens
Mods Your own mods folder, my-mods. Its jars are loaded while the Forge mods add-on is on.
Resource packs, Screenshots, Saves (worlds), Config, Logs, Crash reports That folder inside the instance. A standard folder that does not exist yet is created first.
Instance folder The instance itself
Game output logs The data folder's logs folder, where the launcher keeps game-<date and time>.log for each run. In Settings only.
Xol data folder The data folder

Until the instance exists, the entries inside it are disabled: "This instance is created the first time you press Play. Its folders exist after that." The launcher only opens folders inside the Xol data folder.

Folder layout

instances/xol-1.8.9/
├── instance.json        what Xol installed here (do not edit)
├── options.txt          Minecraft's options; presets merge into this file
├── optionsof.txt        OptiFine's options, when OptiFine is in use
├── mods/                Xol's own folder: the profile's jars and OptiFine.jar while the add-on is on
├── my-mods/             your own mods, loaded while Forge mods is on
├── saves/               your worlds
├── resourcepacks/       a link to your normal Minecraft resource packs folder, unless you switch sharing off
├── screenshots/         F2 screenshots
├── crash-reports/       crash reports written by the game
├── servers.dat          the server list, shared between instances
└── xol/
    ├── config.json         client settings: modules and layouts, shared between instances
    ├── xol-settings.json   written by Export in the client's settings
    ├── remote.json         written by the launcher before the game starts
    ├── smart.json          fixes this instance has taken from the crash panel
    └── shared-state.json   what this folder last agreed with the shared copy

saves, resourcepacks, screenshots and crash-reports are created by Minecraft itself when it first needs them, unless Xol links the resource packs folder first.

The game log that the launcher keeps for each run is not inside the instance. It is in the data folder's logs folder as game-<date and time>.log. Settings ▸ Instance ▸ Open folder ▸ Game output logs opens that folder. The Logs entry opens the logs folder inside the instance, which the game writes itself.

What instance.json is for

It records which profile the instance belongs to, the manifest revision it was last prepared with, the preset that was last applied, what Xol last wrote into options.txt, and the list of files Xol placed in the instance with their checksums. That list is the basis of the isolation rule below.

What remote.json is for

Right before the game starts, the launcher writes the newest remote configuration it has into xol/remote.json. The format can only list module identifiers to switch off, a short plain-text reason for each, and simple on or off flags. It cannot name a file, a class, an address or an argument. The in-game client does not read this file yet. The reader is on the roadmap.

Shared between instances

  • Server list, options and client settings. servers.dat, the option keys both Minecraft versions understand (including key binds) and xol/config.json are kept in step across every instance through a shared copy in the data folder. See Profiles and add-ons.
  • Resource packs. By default, each instance's resourcepacks folder points at the one in your normal Minecraft folder, so a pack you add anywhere shows up everywhere, including in the official launcher. Packs that were already in the instance are moved there first. When a pack of the same name exists in both places, the instance keeps its own folder and nothing is overwritten. Switch Use my Minecraft resource packs folder off in Settings ▸ Instance to give the instance a normal folder again, with the shared packs copied into it.

Worlds, screenshots, mods and mod configs stay per instance.

The isolation rule

Xol only ever replaces or removes files that it placed itself. Everything else in an instance is yours.

  • When a profile's components change (for example the Xol client moves to a new version), the old managed jar is retired and the new one is copied in. Your files are untouched.
  • Your own mods live in my-mods and are never deleted or changed. A jar that lands in Xol's mods folder is moved to my-mods at the next start. See Forge mods.
  • OptiFine follows the same rule. Xol places its copy of the file you added right before the game starts, and takes it out again while the add-on is off.
  • An instance belongs to one profile. Pointing another profile at it is refused: "instance "…" belongs to profile …; clone it or choose another instance".

Clone

Settings ▸ Instance ▸ Tools ▸ Clone copies the selected instance under a new name, so you can customize it freely and keep the original as it was.

Name Letters, numbers, dot, dash and underscore. Starts with a letter or number. At most 64 characters. If you leave the field empty, the name is <instance>-custom.
What is copied Everything except logs, crash-reports and the record of which Java runtime the instance last used
Existing name Refused: "An instance named "…" already exists. Choose another name." The comparison ignores upper and lower case.
Not created yet "This instance has not been created yet. Press Play or Repair once, then clone it."
While the game runs "Close the game before cloning its instance."

The copy is made under a temporary name and renamed when it is complete, so a failed clone leaves nothing behind. After cloning, pick the new instance in the list at the top of the Instance tab. The choice is remembered per profile.

Repair

Settings ▸ Instance ▸ Tools ▸ Repair runs the same preparation as Play without starting the game. It re-checks every file Xol installed against its checksum and restores any that are missing or changed: game files, libraries, assets, the Java runtime, Forge and the profile's components. Your own files are never touched.

Repair also deletes the instance's runtime.json. On an Apple Silicon Mac, an instance that fell back to the Intel runtime therefore tries the native one again on its next start.

On success: "Repair finished: every managed file is present and matches its checksum. The next Play checks the game files in full once more." While the game runs: "Close the game before repairing its instance."

What uninstalling keeps

Uninstalling the launcher removes the program. It does not remove the data folder, so every instance, world, screenshot and setting stays on your computer.

  • On Windows this is a setting of the installer: application data is not deleted on uninstall. The automated build checks that %APPDATA%\Xol\instances survives a silent uninstall.
  • On macOS, dragging Xol to the Trash does not touch ~/Library/Application Support/Xol.

To remove everything, see Reset and uninstall.

Backing up

Copy the instance folder, or at least its saves folder, while the game is closed. Xol is pre-release software, so back up worlds you care about.