I don't know what exactly caused this since it's impossible to trace. But the crash happened with a setting called 'dual_gcode' which currently doesn't exist in Cura. So I think it must be some plug-in that adds it. In any case, it's good to be defensive about this sort of thing. Good type checking would've caught this for us.
Fixes Sentry issue CURA-JB.
Subtract the thickness of the walls from this setting. This most likely ends up negative and thus not counting because it's maxed with something that starts at 0.
I've also simplified this algorithm a bit. Easier to follow if you ask me.
Done as a 5 minute fix.
Subtract the thickness of the walls from this setting. This most likely ends up negative and thus not counting because it's maxed with something that starts at 0.
I've also simplified this algorithm a bit. Easier to follow if you ask me.
Done as a 5 minute fix.
Added an enabled flag, allowing users to enable/disable ChangeAtZ layers at will without removing them
Improved performance of GCodeCommand, deferred parsing of arguments to when it is first requested as opposed to all the time
Removed type hints because the supported python version in Cura is too low
The resolution of the coordinates in these meshes is now reduced to 1 micron. Any unnecessary trailing zeros are removed. Any unnecessary data is removed (like object name). Any comments are removed. All normals are removed and no longer used by the faces.
This should save 10MB on the download and installation size or so.
The quality type 'fast' doesn't exist for Deltacomb. I'm going to be choosing a quality type that is available for this printer which has the name 'Fast', which is quality type 'd'.
Took me a while to see why Cura was confusing the extruder stacks. It worked fine during the actual upgrade itself. Then later after the start-up sequence it suddenly re-wrote them wrongly.
Why is there an ID field in here? Shouldn't it just take the file name as the ID? Stupid!
With this it's starting to look like something. It's no longer giving any corruption errors now with any of my test cases. However e1 is still being set to the definition of e3 for some reason.
Turns out that the parsers apparently refer to a lot of subobjects which are crucial here, and they don't implement the normal copy well. Deepcopy it is then.
