Slicers might raise the print head first for a "nose dive" onto the print platform, leading to a high peakZ already dialed in, with no way to get it down again. This way events won't be fired until the print reaches the height of the initial starting point. As a z-change is a z-change if z changes, we'll just fire the event now (if oldZ != newZ). Event consumers will have to think of a way to filter out the noise.
(cherry picked from commit 9227bb5)
Since it's client side, if you leave these on when not printing, the log will go completely blank over time due to filling up with M105s. Re-enabling M105s will immediately restore the whole log (although it won't hold much information value).
Slicers might raise the print head first for a "nose dive" onto the print platform, leading to a high peakZ already dialed in, with no way to get it down again. This way events won't be fired until the print reaches the height of the initial starting point. As a z-change is a z-change if z changes, we'll just fire the event now (if oldZ != newZ). Event consumers will have to think of a way to filter out the noise.
Should hopefully now be also fixed in case of a newly established connection with the printer, which was a regression due to the fix of the resending code.
Previously it worked since the first command of every print was forced to be an M110 and the line number at the beginning of each print was always forced back to 0 as well. Now it just uses the actual line number (increased on each sent of a checksumed/numbered line) and resets that when an M110 is encountered. What was missing was forcing the line number of the actual M110 command to the desired line number as well. Should be "more correct" than before now, and work.
Something like three wrongs led to one right. Core issue (not starting with line 0 but line 1 and not using the current line but the current line from the gcode file being sent, regardless of reset by M110) should now be rooted out.