mirror of
https://github.com/OrcaSlicer/OrcaSlicer.git
synced 2026-10-11 01:41:03 +00:00
Clifford GarwoodandClaude Opus 4.7
66891899e9
The mode-type tag (imex_mode_types config + imex_mode_type_for helper + Split sentinel) was added in0bb1cefas scaffolding for the Split rendering work that landed in4370ccaand then got reverted ind9be71b. With Phase 2-4 gone, this scaffolding is now unused dead code — and the design we settled on instead is to leave topology entirely implicit (parsed from active_tools_str) rather than carrying a per-mode type tag the user would otherwise have to manage explicitly. The multi-color slicing block + bare T<n> suppression that were the actual substance of the safeguards work stay in place: - imex_multicolor_block_reason still allows multi-color exactly when 2+ tools are active on the primary's gantry — Felix's hypothetical IQEX paired-gantry case works through this path, no new mode type required. - Slicer-side: bare T<n> stays suppressed at print-start in IMEX parallel modes; mid-print T<n> emits naturally for the legitimate IQEX 4-tool-active scenario. Removed: - ConfigOptionStrings imex_mode_types (PrintConfig.hpp/cpp + Preset.cpp key list) - imex_mode_type_for helper + kImexModeType{Primary,Copy,Mirror,Split} sentinels - mode_type parameter on imex_multicolor_block_reason and the Split short-circuit - mode_type plumbing in Print::validate and PartPlate::has_imex_multimaterial_conflict - Three unit tests for imex_mode_type_for + two Split-specific multicolor block tests Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>