E.g. higher than maximum_value. This seems to work okay but is largely untested because switching to advanced mode gives a segfault.
Contributes to issues CURA-1278 and CURA-1588.
They have all been checked for correctness now. While I was doing that, I documented their working as far as I could understand.
Contributes to issues CURA-1278 and CURA-1588.
I was reading through these to check if they'd still work. They should still work, but since I went through them I went ahead and documented them too.
Contributes to issues CURA-1278 and CURA-1588.
We don't save the file name any more. The engine doesn't need any machine-specific definitions at the moment, so we can always just send FDMPrinter.. This may later change, but later we will also send a serialised JSON rather than a file name so then we won't need the file name any more.
Contributes to issues CURA-1278 and CURA-1588.
This was a concurrency issue: If the slicing was very fast, it could finish slicing before the listener was connected to the message of being finished. Therefore, we should connect to being finished before we even start the start-slice job.
Contributes to issue CURA-1278.
The parameters of the listener were out of date and it should only trigger a reslice if we're changing the value of a setting, not any other property.
Contributes to issue CURA-1278.
* 2.1:
Do not round convex hull points to nearest int
Use fdmprinter.json If we have no active machine instead of returning None
JSON fix: max value of infill_sparse_thickness based on engine MAX_COMBINE_COUNT hardcoded value (CURA-1374)
This is done to prevent the very large messages that would be sent otherwise.
Protobuf can't do anything with messages above 512MB. As we no longer send a
"collection" message, this should no longer occur.
CURA-1210
The layer processing job that was triggered by switching to layer view was not stored in the field. The field is where the start of slicing looks for jobs to abort.
Contributes to issue CURA-864.
This involved adding an abort flag to the layer processing job, and making the job check back on that flag periodically. If processing a single layer takes forever then it will never stop the job at all, so it assumes that the concurrent programming in Python is Fair.
Contributes to issue CURA-864.
No idea why this was the case as the result of an operation should decide
if a reslice should be triggered (eg; transformation causes scenechanged to be triggered)
CURA-829
