Der Modul-Modus von find_package(wxWidgets) ignoriert wxWidgets_DIR und
sucht nur WXWIN/wx-config, das auf dem Windows-Builder leer ist. wx 3.3
liefert CMake-Config-Files; CONFIG-Modus nutzt sie wie im 2.4-Branch.
wxWidgets_USE_FILE wird im CONFIG-Modus nicht gesetzt -> include gewrappt.
The lane_data namespace (AFC / recent Happy Hare) was tried first and won
whenever any lane reported filament, shadowing a fully-populated Happy Hare
mmu object when lane_data was stale or only partially filled. Now both
sources are queried and the one reporting more loaded slots wins (lane_data
keeps priority on ties).
Also only advance max_lane_index for lanes that actually hold filament so
trailing empty lanes are trimmed, while interior empty lanes stay below the
highest filled index and are still emitted as empty placeholder slots.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
When a user creates a new filament preset by inheriting from an
existing one (e.g., "Brand ABS @BBL H2D" inheriting from "Generic
ABS @BBL H2D"), the resulting preset previously had no filament_id
of its own. This caused two problems:
1. The AMS sync pipeline could not distinguish the user preset from
its parent, so syncing filaments from the printer always resolved
to the generic base preset instead of the user's custom one.
2. External tools that rely on filament_id for preset identification
(e.g., Bambuddy, see maziggy/bambuddy#1053) could not assign or
recognize user-created inherited presets in AMS slots.
The root cause was twofold:
- No filament_id was generated during save_current_preset() for
inherited filament presets. Only base (non-inheriting) presets
received one via the CreatePresetsDialog flow.
- The AMS matching logic in sync_ams_list(), get_ams_cobox_infos(),
and get_filament_presets() filtered candidates with
`get_preset_base(f) == &f`, which by definition excludes any
preset with a non-empty inherits() field.
This commit:
- Generates a unique filament_id (MD5 hash of preset name, prefixed
with "P", truncated to 8 chars) when creating a new filament
preset in PresetCollection::save_current_preset(). This matches
the existing ID generation scheme used for base filaments in
CreatePresetsDialog::get_filament_id().
- Persists filament_id into the JSON when saving inherited presets
via Preset::save() and get_differed_values_to_update().
- Broadens the AMS filament matching predicates to also consider
user presets that carry their own filament_id, rather than
requiring them to be base presets.
Files changed:
src/libslic3r/Preset.cpp - ID generation, save, lookup
src/libslic3r/PresetBundle.cpp - AMS sync matching predicates
Flushing volumes only apply to SEMM and BBL printers. Multi-tool printers don't perform filament purging between tool changes, so the zero-volume warning was being incorrectly triggered.
## FIXES
• Corrects area height on windows while using 125% and 175% scaling. it
shows scrollbar when it incorrectly set. i have used directly size of
combobox this time instead static number
## IMPROVEMENTS
• Removes restriction for restarting orca when setting changed
# Description
This pull request fixes the bug where Orca Slicer enters an infinite
loop when a density of zero is introduced for the top layer solid infill
# Screenshots/Recordings/Graphs
<img width="2560" height="1392" alt="image"
src="https://github.com/user-attachments/assets/5bf5c220-a398-483f-9f69-63dadbc888af"
/>
Note: For bottom solid infill, this is not a problem because the minimum
density is 10%.
Makes sure all non-bbl printers go through the same filament reordering
code so custom filament sequence is properly handled, while skipping the
filament grouping part by mapping all filaments to group 0.
This is the same method used by BBL printer to calculate the optimal
filament grouping so should be robust.
Fix#12449Fix#12766
# Description
<!--
> Please provide a summary of the changes made in this PR. Include
details such as:
> * What issue does this PR address or fix?
> * What new features or enhancements does this PR introduce?
> * Are there any breaking changes or dependencies that need to be
considered?
-->
Happy Hare now writes mmu lane data to the moonraker db similar to AFC,
so we can normalize to the one implementation. For now, i've just
re-ordered it so that the moonraker db is checked first. I want this
because I've actually updated the happy hare data to include more data
than we had access to via the "mmu" object. For happy hare we now have
access to vendor name, which we can eventually use to further fine tune
the auto-matched filament preset.
# Screenshots/Recordings/Graphs
<!--
> Please attach relevant screenshots to showcase the UI changes.
> Please attach images that can help explain the changes.
-->
_n/a_
## Tests
<!--
> Please describe the tests that you have conducted to verify the
changes made in this PR.
-->
With certain irrational beam interlocking parameters, it will take a few
minutes to complete the interlocking generation; even worse:
cancellation doesn't work once it started.
This PR fix that by adding cancellation check inside some of the most
time consuming loops so it can be stopped ASAP.
Also cherry picked a sanity check from
https://github.com/bambulab/BambuStudio/pull/9925 by @mpaperno. Thanks!
The following test project (which was modified from the upper PR by
@mpaperno) took me more than 90s to complete with 0.1mm beam width:
[Interloack-Test2.orca.3mf.txt](https://github.com/user-attachments/files/25975637/Interloack-Test2.orca.3mf.txt)
Previously, wipe tower behavior was determined by checking if the printer
was a QIDI vendor. This introduces a configurable enum (Type 1 / Type 2)
so any printer can select its wipe tower implementation. BBL printers
remain hardcoded to Type 1. Qidi profiles default to Type 1.
The wipe tower config position (wipe_tower_x/y) could be outside the
plate boundary (e.g. default y=250 on a 200mm printer). No constraint
was applied at slice time, so the tower was generated out-of-bounds.
Happy Hare now writes mmu lane data to the moonraker db similar to AFC, so we can normalize to the one implementation. For now, i've just re-ordered it so that the moonraker db is checked first. I want this because I've actually updated the happy hare data to include more data than we had access to via the "mmu" object. For happy hare we now have access to vendor name, which we can eventually use to further fine tune the auto-matched filament preset.
