Skip to content

FOrcaSlicer v2.3.2-fos.8.3

Choose a tag to compare

@jiyang1018 jiyang1018 released this 13 Jul 20:44

Fix: Corrected Snapmaker Profiles Never Reached Existing Installs

Problem

The same project file opened on two computers produced different line widths. On an
upgraded install, the Quality tab showed a mix of percentages and millimetres:

Default                 0.42     mm
First layer             0.5      mm
Outer wall              105%
Inner wall              110%
Top surface             105        <- no % sign: a 105 mm line width
Sparse infill           110%
Internal solid infill   0.42     mm
Support                 105%

Only the 0.4 mm nozzle presets were affected; 0.2 / 0.6 / 0.8 were clean. A fresh
install was also clean, which is what made this so hard to pin down.

The percentages are not cosmetic. Line widths are coFloatOrPercent with
ratio_over = "nozzle_diameter", so a stored 105% resolves to a different physical
width on every nozzle
- 0.21 mm on a 0.2 nozzle, 0.84 mm on a 0.8 nozzle. Under mixed
nozzles that silently changes what gets printed.

Root Cause

1. The fix existed, but was never delivered.

The U1 process presets went through three revisions:

Commit Change
df0a7e9d58 line widths converted mm -> 105% / 110%; top_surface_line_width became a bare 105 (no %)
03a404bda3 repaired the bare 105 -> 105%
7b5c73e1af converted everything back to absolute mm

The corrected mm values have shipped inside resources/profiles/ ever since. But
PresetUpdater::priv::check_installed_vendor_profiles() only refreshes
%APPDATA%/FOrcaSlicer/system/<Vendor>/ when the resource bundle declares a newer
version:

version_match = (resource.maj == vendor.maj) && (resource.min == vendor.min);
if (!version_match || vendor_ver < resource_ver)   // -> reinstall

resources/profiles/Snapmaker.json had sat at "02.02.46.02" through every FOS profile
edit. So the check never fired, the cached bundle was never replaced, and machines kept
whatever profiles they first installed - in this case the df0a7e9d58 state, frozen.
Every profile fix was faithfully packaged into the installer and then silently ignored on
upgrade.

2. Duplicate profile names.

Twenty process profiles declared the same "name" key as a real sibling, causing
nondeterministic preset binding:

  • 19 * copy.json files (0.2 / 0.6 / 0.8 nozzle presets)
  • 0.20 Standard @Snapmaker U1 (0.4 nozzle)_old.json

The _old.json is the 0.4-nozzle collision - which is exactly why 0.4 was the nozzle
that misbehaved. It is not a byte-identical duplicate; it is an older, thinner revision,
and it is not referenced by the Snapmaker.json index. (Prior commits eeebb38a47 and
710caf2ac1 cleaned up other collisions, but only on a development branch that never
shipped.)

Changes

resources/profiles/Snapmaker.json

  • Bumped bundle version 02.02.46.02 -> 02.02.47.00

    The version is parsed by Semver::parse, which is 3-component - the 4th field is
    invisible to the comparison, so bumping .02 -> .03 would have done nothing. Moving
    the patch field (46 -> 47) is what makes 2.2.46 < 2.2.47 true and triggers the
    refresh. It also keeps the FOS bundle ahead of Snapmaker's official 02.02.46.x, so
    their online updater will not overwrite it.

resources/profiles/Snapmaker/process/

  • Deleted the 20 duplicate-name profiles listed above.

    install_bundles_rsrc() calls remove_all() on the vendor folder before recopying, so
    the version bump both delivers the corrected profiles and sweeps these stale files
    off existing machines.

src/libslic3r/libslic3r.h

  • SLIC3R_APP_FULL_NAME: "Snapmaker Orca" -> "FOrcaSlicer"

    Drives the Help > About menu item, the About dialog title, error captions and
    MessageDialog titles. Paths and the data directory are driven by SLIC3R_APP_KEY
    (already FOrcaSlicer), so this is display-only.

src/common_func/common_func.hpp

  • Added FOS_VERSION "2.3.2-fos.8.3"

    Kept separate from Snapmaker_VERSION deliberately - that macro is written into 3mf
    metadata, project settings and the user_backup-v<ver> folder name, so changing it
    would break project round-trips and orphan existing backups.

src/slic3r/GUI/AboutDialog.cpp

  • Version line now reads FOrcaSlicer 2.3.2-fos.8.3, with
    Based on Snapmaker Orca 2.3.2 / Orca Slicer beneath it.
  • Fixed the mojibake copyright sign. A raw U+00A9 sat in a narrow string literal; the
    source is UTF-8 (/utf-8) so the bytes are C2 A9, but a wxString built from a
    const char* decodes with the current locale - under a GBK codepage that renders as a
    CJK glyph. The literal is now pure ASCII, decoded explicitly via wxString::FromUTF8.

No slicing code changed.

Result

  • Upgrading to 8.3 refreshes the cached vendor bundle: all U1 line widths load as
    absolute mm on every nozzle
  • The 20 duplicate-name profiles are removed from existing installs, not just from the
    package ✓
  • Zero percentage line widths remain anywhere in the Snapmaker profile tree ✓
  • Zero duplicate profile "name" values remain ✓
  • The same project file now yields identical line widths across machines ✓
  • Help > About reads About FOrcaSlicer; the dialog reads FOrcaSlicer
    2.3.2-fos.8.3
    with a correct (c) sign ✓

Upgrade Note

No action required. The corrected profiles are applied automatically on first launch of
8.3. If you had customized a Snapmaker system preset, your saved user presets are
untouched - only the system bundle under %APPDATA%\FOrcaSlicer\system\Snapmaker\ is
replaced.

Known Issue (carried from 8.2, not a regression)

With Thick internal bridges enabled, an internal bridge extrudes at a height of
nozzle_diameter * sqrt(bridge_flow) with no clamp against layer height. Under mixed
nozzles this can be extreme - a 0.8 mm nozzle on a 0.1 mm layer yields a single 0.8 mm
tall extrusion (8x the layer height) that overlaps the sparse infill beneath it.

This is upstream OrcaSlicer behavior, not FOS-specific: stock Orca with uniform 0.8 mm
nozzles at a 0.24 mm layer height produces the same 0.8 mm bridge extrusion (3.3x layer
height) with the same overlap. Mixed nozzles change the magnitude, not the mechanism.

Workaround: disable Thick internal bridges when the solid-infill nozzle is much
larger than the layer height. A layer-height-aware clamp is under consideration.