mirror of
https://github.com/OrcaSlicer/OrcaSlicer.git
synced 2026-10-10 17:21:10 +00:00
Review findings on the preceding commit, plus one defect it should have caught. - The IDEX/IQEX pressure-advance loop fed resolve_filament_for_head()'s result straight into enable_pressure_advance and pressure_advance. That result is bounded by physical_extruder_map, which holds one entry per NOZZLE, while both options are indexed per filament SLOT. On a printer with more nozzles than the project has filaments the two spaces diverge and get_at() clamped the overflow onto filament 0, emitting its pressure advance on a secondary carriage. The second-layer temperature loop bounds the same lookup, but against nozzle_temperature, which is variant-expanded and so is not the slot count either -- it is not the precedent it looks like. IMEXHelpers.hpp states the rule once, and a test pins the contract that makes the bound necessary: resolve_filament_for_head() answers in nozzle space, so a non-negative result is not by itself safe to use as a filament id. - The header claimed every caller renders a -1 tool qualifier as "emit none". RepRapFirmware substitutes the historical D0 instead, deliberately and with its own comment in GCodeWriter. Say so, rather than leaving a contract a future author would code against. - A cross-reference pointed at a hard-coded line number that the preceding commit had itself shifted by nine lines. Name the function instead. - The multi-color rejection reasons reach the user through Print::validate() as raw English, while the returns on either side of them use L(). Wrap them and register IMEXHelpers.cpp for extraction. They also still said "IMEX", the internal name, so they move to IDEX/IQEX with the rest of the user-facing strings rather than shipping the internal one to translators. - Trim the preceding commit's comments. One block explained the same clamping hazard six times; the canonical explanation now lives in IMEXHelpers.hpp and the call sites point at it. The mode grid carried twelve lines of commentary and no code, most of it archaeology already in the commit message, and one claim about the modes editor that was not true. The ArrangeJob threading note stays: it documents an invariant that cannot be recovered from the code. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>