PrusaSlicer has encountered an error: Failed loading the preset file:

[Photogad]

Version

2.2.0+Win64

Operating system type + version

Windows 10 64

3D printer brand / version + firmware version (if known)

MK3

Behavior

Get this error when open PrusaSlicer. But after I dismiss it, the program loads fine but I'm not able to use my presets. This error happen every time I open the program.

.Zip of profiles

print.zip

[Photogad]

I figured out the issue,

top_fill_pattern = smooth

I originally generate these profiles with a different fork of PrusaSlicer that have a different top infill pattern available.

In previous versions of PrusaSlicer, I was able to import the profiles between both with no problems, only in the latest 2.2.0 PrusaSlicer does it no longer compatible for profiles generated on other forks.

Is possible to make PrusaSlicer not throw error message and just use default values for those profiles for any fields that aren't compatible as it did before?

[bubnikv]

I have improved error reporting with 8d7f88b
this time you should get the option key and value that our poor slicer does not understand.

Trying to load config of other software is like feeding diesel into your gasoline car. We cannot easily support that. Silently loading such config does not make sense. Giving warnings and loading my make sense, but we would have to convert these unknown config keys to something else, which adds complexity. I believe current behavior is fine (with the change above), our software will give you a feedback why the config could not be loaded.

Closing.

[bubnikv]

Also please understand that this story is scary to us. PrusaSlicer writes its name into the 3MF / AMF files, config files, G-codes. I am tempted to refuse anything that has not been created by PrusaSlicer or Slic3r PE, possibly the upstream Slic3r. We are already overloaded supporting people on github using 3rd party printers. It would be a nightmare to support other slic3r forks with incompatible configuration parameters.

[Photogad]

Also please understand that this story is scary to us. PrusaSlicer writes its name into the 3MF / AMF files, config files, G-codes. I am tempted to refuse anything that has not been created by PrusaSlicer or Slic3r PE, possibly the upstream Slic3r. We are already overloaded supporting people on github using 3rd party printers. It would be a nightmare to support other slic3r forks with incompatible configuration parameters.

I understand your reasoning, I'm just saying that previous version of prusaslicer (2.2.0 beta) had no issues loading configs from other slic3rs, when I loaded them in it just changed the incompatible values to the defaults in prusaslicer.