This fixes a very old bug in Cura where sometimes after re-slicing it would display the layer as if you've been going horizontal through the path slider, even if you never touched the horizontal path slider.
This was caused by a tracking flag in the SimulationPass, _switching_layers. This bit of state in the SimulationPass was tracking whether the user is going through the vertical layer slider (True) or the horizontal path slider (False). If False, the nozzle mesh is drawn and lower layers get drawn in a shadowy shader. The state of this flag was being updated on every render by looking at whether the previous render has the same current layer number but a different path index. If so, it changed to False, meaning that it assumes you're going through the paths on a layer and things get shadowy.
However if you slice a different object such that the number of layers stay the same (or at least the current layer) but the number of paths on a layer change (e.g. by reducing Maximum Resolution, or by loading a different model that happens to be equally tall) then it would falsely think you were going through the horizontal path slider.
This change effectively resets this state flag when any layer data is changed in the scene. So if you re-slice, it always goes back to _switching_layers = True.
The side effect is that if you were going through the paths of a layer and you re-slice, you won't end up on the same path even if the number of paths on your current layer didn't change due to the reslice. But I think that is more towards what the user would accept a re-slice to do anyway.
I decided to take a look into this bug because I'm making a script to automatically refresh the screenshots of the Settings Guide plug-in. This script frequently hits cases like this, and it's easier to fix this bug than to work around it in my script.
Just a few calls to min() or max() do the trick, rather than if statements.
I consider this more semantic, because we just intend to clamp values here, and min() and max() are commonly used to do that.
It should also be slightly faster because it's less Python and more internal in CPython, but considering that this happens at best like 60 times per second the performance impact of this will be practically nil.
This was probably copy-pasted wrongly years ago.
The Cura interface currently doesn't allow changing the minimum path anyway, so this doesn't have any effect on the actual behaviour of Cura. Still, can't hurt to fix this, for posterity.
The commit adds:
- Machine definition files for the Layer One Atom 3 and Atom 3 Lite Printer
- One shared extruder definition file for the Atom 3 and the Atom 3 Lite
- A mesh file for the Atom 3 and Atom 3 Lite
- Variant files for [0.2; 0.4; 0.6]mm Nozzles for PTFE and full metal hotends
The code is clearly written to take into account that 'addresses' may be null. But not that the whole 'addresses' attribute may not exist. And then instead of printing one warning (Could not get information about XX) it instead printed a stacktrace and retried and printed a stacktrace and retried and printed a stacktrace and.... It ended up driving me a bit nuts when looking at the logs for unrelated reasons. So Ifinallay fixed it. Could end up as a speedup in some cases as well I suppose?
No idea why this was there in the first place. Our archeology attempts couldn't
find out as to why it was introduced. We suspect an issue with other Qt versions.
At least now ロボット.stl will not be mangled into ロホット.gcode upon saving (and
german bears into bars)
