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'.
Stupid stuff. All of these containers need to be copied. It's not possible to work this out for all materials properly, since we can't read into these materials what their GUIDs and material types are.
Conflicts:
resources/quality/deltacomb/deltacomb_abs_Draft_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/quality/deltacomb/deltacomb_abs_Fast_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/quality/deltacomb/deltacomb_abs_High_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/quality/deltacomb/deltacomb_abs_Normal_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/quality/deltacomb/deltacomb_abs_Verydraft_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/quality/deltacomb/deltacomb_global_Draft_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/quality/deltacomb/deltacomb_global_Fast_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/quality/deltacomb/deltacomb_global_High_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/quality/deltacomb/deltacomb_global_Normal_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/quality/deltacomb/deltacomb_global_Verydraft_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/quality/deltacomb/deltacomb_petg_Draft_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/quality/deltacomb/deltacomb_petg_Fast_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/quality/deltacomb/deltacomb_petg_High_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/quality/deltacomb/deltacomb_petg_Normal_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/quality/deltacomb/deltacomb_petg_Verydraft_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/quality/deltacomb/deltacomb_pla_Verydraft_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/quality/deltacomb/deltacomb_tpu_High_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/quality/deltacomb/deltacomb_tpu_Verydraft_Quality.inst.cfg: Modified by Ultimaker to update version number, but deleted by Kaleidoscopeit.
resources/variants/deltacomb/deltacomb_dc20_fbe025.inst.cfg: Modified by Ultimaker to update version number, and author added by Kaleidoscopeit.
resources/variants/deltacomb/deltacomb_dc20_fbe040.inst.cfg: Modified by Ultimaker to update version number, and author added by Kaleidoscopeit.
resources/variants/deltacomb/deltacomb_dc20_fbe060.inst.cfg: Modified by Ultimaker to update version number, and author added by Kaleidoscopeit.
Conflicts:
resources/texts/change_log.txt: Both modified but had different wording for the pause-at-height bugfix with motor timeout. I used the wording in 4.6 since it was more extensive.
Otherwise this print won't work at all. It'll just keep waiting forever until the build plate has reached a temperature that is way out of spec.
Applied at request of MaximeGL in #7280.
To do this, I'm giving more power to the NumericTextFieldWithUnit QML element, to allow an arbitrary minimum and maximum. Enforcing this minimum and maximum is fairly simple with a JavaScript hook. This hook is necessary because the DoubleValidator allows intermediary values which defeats the purpose, essentially allowing any number as long as it has the correct number of digits.
Printers larger than 2km would start to give overflow errors in its X and Y coordinates. Z is okay up to about 9 billion kilometres in theory, since we don't need to do any squaring math on those coordinates afaik. In practice I'm doing this because at very high values the Arranger also gives errors because Numpy can't handle those extremely big arrays (since the arranger creates a 2mm grid).
Fixes Sentry issue CURA-CB.
