Reduces confusion, I hope, and the feeling of being overwhelmed by a load of settings, because obviously only people who make all settings visible are going to see these settings at all.
They are not being used any more. For some reason people thought that an exception was made for extruders or something. And people keep adding them for the definition files too. I'll add a test to prevent that.
CURA-6913
getDefaultValueInExtruder() expects the extruder_position to be an int,
but defaultExtruderPosition() returns a str. This will cause the formula
evaluation to fail.
If the angle is 0 or negative, this setting won't have any effect since the support cannot be made wider than it already is using this setting. It can only prevent it from becoming smaller, and it will only become smaller from a positive conical support angle.
Discovered during work on the Settings Guide.
These are overrides of default_value while there is a value defined. As such these overrides had no effect at all.
Changing them to value can actually change the behaviour of the profile. That is not what the profile author has apparently tested with, so I'm not doing that. I'm just removing the unused data.
In the future if we get new definitions the author gets notified of the error so that he may test more effectively. The legacy can't be fixed without re-testing, so I'm leaving that to the authors.
Done during Turbo Testing & Tooling. I want to go home for the weekend now...
That's the only time when it will have any effect, since the only thing this does is to calculate the distance to the next infill line better if the nozzle has to make a detour due to combing.
We had changed it for all printers back when we changed the prime tower position to a formula, but since then we've been getting new printer definitions that were made from templates floating around with the old structure.
We should really have an automated test for this.
Discovered during review of #6518.
The default value here would not be used. Override must be `value` not `default_value` solves #6491 for BIBO but other printers may also be affected by #6491.
This is possible because CuraEngine rounds these to the nearest layer thickness. So if it's more than half the layer height it gets rounded up and it's still properly one layer.
Contributes to issue #6465.
It's not behaving as expected here. For instance, Ultimaker 3 wasn't specifying has_machine_materials and thus only the base materials would get loaded, but clearly the Ultimaker 3 has materials specialised for it.
Whether or not a printer has materials specialised for it is now determined by whether the specialisations exist in the material files. So we don't need the metadata entry any more. It seemed to have not been in use anyway, except by one printer which specified that has_machine_materials is true. I've now made it behave as if it's always true.
Contributes to issue CURA-6831.
