--datadir

--datadir redirects the single global root path that the slicer uses to locate and persist every piece of configuration. Without it the slicer derives that root from the OS user-data convention: on Windows and macOS via the platform-native user-data path (typically AppData\Roaming\<AppName> on Windows and ~/Library/Application Support/<AppName> on macOS), and on Linux from $XDG_CONFIG_HOME/<AppName> falling back to ~/.config/<AppName>. OrcaSlicer also checks for a folder named data_dir placed adjacent to the application bundle before consulting the OS default; if that folder exists, it takes priority. Supplying --datadir writes the path into the global data-dir slot before any of that default resolution runs, so both headless and GUI paths use the specified directory.

Every subsequent file operation in the session resolves relative to that root. The slicer expects a conventional subdirectory layout under it: system/ holds vendor-supplied machine (machine/), process (process/), and filament (filament/) presets; user/ holds user-authored presets organised per user subfolder; ota/ is the over-the-air bundle cache; log/ receives log output. The application config file (<AppKey>.conf or <AppKey>.ini depending on build configuration) lives at the root level. These are the only paths the core engine ever consults -- there is no secondary search path.

When the slicer starts in GUI mode without --datadir, it computes the OS default, creates the log/ subdirectory if absent, and changes the process working directory to log/. When --datadir is supplied the GUI detects that the path was already set, skips that block, and does not change the process working directory -- log output still goes to <datadir>/log/ via the logging sink (which creates that directory as needed), but the process cwd remains wherever it was at launch.

If the supplied path is empty or unpopulated the slicer starts with a clean-slate config and no vendor profiles. In GUI mode the first-launch directory setup creates the required subdirectory tree (system/, user/, ota/) on first launch; in headless CLI mode that step is not performed, so the caller is responsible for ensuring the directory structure exists before supplying the path. Supplying a populated directory from a context that used upstream Slic3r's layout may produce preset-load failures because this fork renamed the directories (for example, machine/ and process/ replace Slic3r's printer/ and print/).