--load-settings

--load-settings accepts a single string containing one or two file paths separated by a semicolon. Each path must point to a JSON preset file. The slicer reads the JSON's "type" field to decide how to apply it: a file with "type": "machine" replaces the machine profile; a file with "type": "process" replaces the process profile. Both may be provided together, or just one, but at most one file of each type is permitted — passing a second machine or second process file is a hard error. A file with "type": "filament" is accepted by the parser without an error but its settings are silently discarded in the processing loop; the hard error is reserved for any "type" value other than "machine", "process", or "filament".

The JSON must also carry a "from" field whose value is "system", "user", or "User" (the capitalized variant is treated the same as lowercase). A missing or unrecognized "from" value causes an immediate config error before any type checking occurs. This field governs how the slicer resolves inheritance: a system preset's own name becomes its system parent, while a user preset reads its "inherits" key to determine the system parent name, which is then used for compatibility checking. Unknown configuration keys are silently substituted with their defaults — the substitution rule is hardcoded to the permissive mode — so older preset files degrade gracefully without aborting.

Settings from --load-settings sit in the middle of the priority stack: they override anything embedded in the input 3MF, but are themselves overridden by any matching values passed directly on the command line. When the machine JSON names a different printer than the one recorded in the 3MF, a machine-switch path activates. If the 3MF's upward_compatible_machine list is non-empty, the new machine's system name must appear in that list or the slice is aborted with a compatibility error; if the list is empty, this check is skipped and the switch proceeds unconditionally. When an actual machine switch is detected, the slicer reads per-model safe limits from a bundled configuration file and clamps any machine_max_* motion parameters downward to the values defined there, if the file contains an entry for the new printer model. If the process profile is also being replaced, the new process's compatible_printers list must include the new machine's system name, or the slice is aborted with a process-compatibility error (the upward compatibility path can also satisfy this check when it applies).