If a submaterial doesn't exist for the current variant node but it does exist for a different variant node, then it would not be found in the variant-specific materials and then would be looked up in the printer-specific materials. It then depends on the order in which findInstanceContainersMetadata returns things for whether the actual printer-specific material is selected or a different variant-specific material is selected. No longer now, because the variant name is specified to be absent so it may not match on variant-specific profiles any more.
Maybe this even gives us a small performance gain when combining these dictionaries, since there are now like 80% fewer profiles in that query.
Contributes to issue CURA-6831.
Turns out that the material profiles deserialise the variant to the 'variant_name' metadata entry, not just 'variant'. This caused it to find no variant-specific material profiles at all anywhere. It would always fall back to the machine-specific names.
Contributes to issue CURA-6831.
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.
- Approximate diameter needed to be a string.
- GUID-tag is mostly in capitals.
- Workaround for an overload of 'get' not being called (default parameter didn't work somehow?).
part of CURA-6817
The logic using just a "skip_project_file_check" boolean was too obscure
imho, so used a string value with more explicit values
to improve readability
CURA-6824
It's a quality container, not a material container. This was a copy-paste mistake.
Also added that this may be a global quality container, not always a per-extruder quality container.
Found during testing & tooling.
... instead of crashing.
Not _really_ part of a ticket, but I'm solving this now because otherwise I can't even _reproduce_ the steps for the bug in CURA-6807
Previously it would use the material type from the material, but since
the material from the node can be different to that of the quality, we need
to use the one from quality instead (This is due to the fallback system)
CURA-6807
