Coordinate arguments for G92 command are being ignored (again)

[DrLex0]

Version

2.4.0-alpha2+x64 This issue was not present in alpha1.

Operating system type + version

Mac OS 10.14.6

3D printer brand / version + firmware version (if known)

FlashForge Creator Pro, firmware irrelevant

Behavior

• This seems a straight regression of issue #3082. It looks like someone again assumed that the G92 command has no arguments and is supposed to always set all coordinates to zero, which is wrong.
• Steps needed to reproduce the problem
  • Load the attached 3MF and slice it.
• Expected Results
  • The box stays where it was: at the center of the bed.
• Actual Results
  • The sliced box is shifted to the front left corner of the bed.

Is this a new feature request? No

Please read my explanation in #3082 again. This printer has its homing position at the rear right corner (actually slightly beyond it). The X axis points to the right and the Y axis points to the rear. So, there is a real valid reason to use nonzero arguments with the G92 command here. If I would shift everything such that the homing position would be (0, 0, 0), all XY print coordinates would become negative, which would be cumbersome and make no sense.

Project File (.3MF) where problem occurs

G92-issue.3mf.zip

[bubnikv]

The issue is different this time.

We optimized the G-code parser. GCodeReader::parse_line_internal() seemingly used to mark an axis as "seen" if it contained no digits, while newly a number is required.

-                char   *pend = nullptr;
-                double  v = strtod(++ c, &pend);
-                if (pend != nullptr && is_end_of_word(*pend)) {
+                double v;
+                auto [pend, ec] = fast_float::from_chars(++ c, end, v);
+                if (pend != c && is_end_of_word(*pend)) {

[bubnikv]

Thus the reader now fails to process GCodeProcessor::process_M132()

[bubnikv]

Fixed in PrusaSlicer 2.4.0-alpha3.