Previously for both cardinality optional/required ifctester would show same results.
E.g.
<ids:property dataType="IFCBOOLEAN" cardinality="required">
<ids:property dataType="IFCBOOLEAN" cardinality="optional">
Were resulting in something like
LoadBearing data shall be true and in the dataset Pset_WallCommon
LoadBearing data shall be true and in the dataset Pset_WallCommon
Now it will result in
LoadBearing data shall be true and in the dataset Pset_WallCommon
LoadBearing data may be true and in the dataset Pset_WallCommon
`transition_curve.py` is now obsolete and has been removed.
A python port of IfcAlignmentHelper.cpp has also been started.
It needs further development to accommodate vertical alignment.
We try to apply scales using bim.update_representation and if didn't worked (presumably because object has openings) we reset the scales.
It was confusing for users that they scaled an object, saved IFC and they would know that scaling didn't worked only after they reopen the IFC project.
Currently there is an UX problem that it's not clear for users when it's possible to use scale or not. We definitely won't be able to safely apply scales for objects with openings, so will try to lock them from the start.
* Implement rounding of elevation
Implement rounding of elevation based on precision stored in IfcGeometricRepresentationContext
* Move formating function to tool
The problem was that shared folders names are starting with `\\`, e.g. `\\SERVERNAME\shared_folder`. When we pass path strings we usually sanitize them and save them as posix, so it's saved as `//SERVERNAME/shared_folder` and Blender has a convention that paths starting with `//` it interprets as filepaths relative to the current .blend file, therefore it was giving some weird error that `C:\Users\xxxx\SERVERNAME\shared_folder\test.blend` is missing instead of `\\SERVERNAME\shared_folder`.
So need to be careful passing strings to Blender operators and use str instead of as_posix for those operators, so \\` wouldn't be misinterpreted.
Turn out storing bpy.types.PropetyGroups was not very reliable idea as they get invalidated, just as Objects.
It's still breaking if you'd try to rename the style and then undo.