In IFC4X3 IfcQuantityCount is now more strict and requires only interger values.
Error for a reference:
TypeError: attribute 'CountValue' for entity 'IFC4X3.IfcQuantityCount' is expecting value of type 'INT', got 'float'.
E.g. it was impossible to contract category "TEST" if there was also a material with name "TEST" (and it's category was expanded). It occurred due to a mixup of materials and categories in expanded_categories.
Also changed is_expanded default value to False as it makes more sense (previous value didn't worked for materials and for categories you probably would want it to be False by default.
Previously if you had some item active before the category you're trying to expand/cotract it would jump back to that item which was confusing. Now it sets contracted/expanded category as active to prevent that jump.
Before - https://imgur.com/a/87ZDnVq
After - https://imgur.com/a/B9WOn8I
In Blender when we reload materials in collection property it's resetting scroll position in the template_list and setting it based template_list index, so the only way to preserve the scroll position is to manipulate template_list index.
Previously it would create multiple same named "Uncategorised" categories for each case when Category was "", None, "Uncategorised", which was confusing and some of them ("" and None) would expand simultaneously when you would try to expand one.
Removed `or "Uncategorised"` from ui.py as there shouldn't be a need for this since all cases are handled when items are added.
Probably have met this issue before - https://i.imgur.com/EOCSGg2.png
It occurred when you would remove e.g. IfcBuildingStorey's (or other aggregate's) collection from outliner. Deletion operator removes objects first and removing aggregate's main object is automatically removing it's collection. Then it would start removing collections and will break meeting an invalid collection.
Most of the times it was scary but harmless since all collections are probably removed either way but it's critical for batch removal as it would be never finished, possibly leaving unlinked ifc data (e.g. representations and it's items) that's not removed completely until batch removal is finalized.
Traceback:
Error: Python: Traceback (most recent call last):
File "\blenderbim\bim\ifc.py", line 360, in execute_ifc_operator
result = getattr(operator, "_execute")(context)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\blenderbim\bim\module\geometry\operator.py", line 720, in _execute
bpy.data.collections.remove(collection)
ReferenceError: StructRNA of type Collection has been removed
Issue occurred when cost item would have no quantities but had controlled objects with quantities.
1) just added a check to ensure that cost_item.CostQuantities are present
2) removed possible None return value in get_cost_item_quantity as it actually will break process_cost_data and it's never used anywhere else
3) has_changed_name was unused
4) fix possible similar issue in cost.data (though _get_object_quantities method is unused)
Base qtos shouldn't be too special, it should be based off a calculation mapping. This means we can also support IFC2X3 better (which has no base qtos)
1) e.g. in ifc4x3 previously for IfcWall it would prioritize Qto_BodyGeometryValidation over Qto_WallBaseQuantities
2) It would also prioritize general Qto_BodyGeometryValidation over Qto_BuildingElementProxyQuantities.
3) removed "Qto_" check as we do qto_only in get_applicable_names
This is a more flexible, non-Blender approach to doing QTO which allows:
- Doing QTO without Blender
- Doing QTO using query filters
- Using config files for QTOs
- Choosing your calculation engine, either built-in or creating your own
Andrej730
