Open HL-code opened 1 year ago
It may not be conceptually a new door, but it is from a modelling point of view if a new element id is created. Probably this would need some sort of magic to work. Unclear how to proceed here.
Thank you for reply Angel.
In no point of view is moving a door a new door. If that was the case "disjoin" should not be needed. There's no door database/software that would automatically consider a moved door as "new" . And a door manufacturer such as Swedoor would still be instructed to make the exact same door. But lets forget that since it was not the question.
To the best of your knowledge, which is considerable. On export to IFC is there any way to export consistent ifcguids in Revit 2023+. Or will it dynamically change depending on the somewhat whimsical nature of UniqueId/ElementId ?
I suppose one way to achieve this is if the exporter accepted a shared parameter such "IfcGuidOverride". Otherwise its going to change when its not supposed to change.
OK, talked about this internally.
The real internal fix here is that for certain operations (e.g., disjoin), the new element will need to get the Ifc GUID of the old element. We would need to identify all of the places where internally we create a new element and make that work.
In the meantime, though - yes, you can overwrite the IFC GUID parameter. But it would be a pain to do. You would have to copy the existing parameter, then disjoin, then paste it. Perhaps there's some better way to do it.
Inquiry description
Hi
As of Revit 2023 the IfcGuid parameter seems to have changed behaviour. Its value is now dynamically linked to Element.UniqueId. So if UniqueId change then IfcGuid change. Which means if we move a door with Disjoin checked IfcGuid will change since both ElementId and UniqueId changes.
Obviously its not a new door and should retain is original IfcGuid value. Is there any way to lock the value of IfcGuid ?
Revit Version
2023.0.x
IFC for Revit Addon Version
23.2.5
Windows Version
10 22H2