juli/OrcaSlicer
1
1
Fork 0
mirror of https://github.com/OrcaSlicer/OrcaSlicer.git synced 2026-08-08 02:27:44 +00:00
Code Issues Packages Projects Releases Wiki Activity

Rebuild the G-code line offsets after post-processing scripts run in place

Browse Source
This commit is contained in:
ExPikaPaka
2026-07-29 08:20:11 +02:00
parent 5ede9711f5
commit 9553326e7d
3 changed files with 49 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
src/slic3r/GUI/BackgroundSlicingProcess.cpp
View File

@@ -261,7 +261,13 @@ void BackgroundSlicingProcess::process_fff()
// GCodeProcessorResult, so m_gcode_result->nozzle_group_result (consumed by the H2C print-dispatch
// nozzle mapping) survives post-processing. No preservation guard is needed on this path.
if (m_fff_print->is_BBL_printer()) {
run_post_process_scripts(m_temp_output_path, false, "File", m_temp_output_path, m_fff_print->full_print_config());
if (run_post_process_scripts(m_temp_output_path, false, "File", m_temp_output_path, m_fff_print->full_print_config()))
// The scripts/plugins rewrote the very file the G-code viewer memory-maps, so every byte
// offset in m_gcode_result->lines_ends (built while exporting the pre-processed G-code) is
// now stale and GCodeWindow would slice the file mid-line. Re-scan it. Note this only
// realigns the line framing: if a script inserts or removes lines, the moves' gcode_id
// still refers to the pre-processed numbering and the highlighted line stays shifted.
m_gcode_result->rebuild_lines_ends();
}
BOOST_LOG_TRIVIAL(info) << __FUNCTION__ << boost::format(": export gcode finished");