I am trying to write to a type, rather than instance, parameter. It isn’t quite working.
On the first attempt, I used an instance parameter but as my model contains a number of groups with doors within, the script produced a warning that it would have to ungroup everything in order to write the instance parameter.
So i am trying to tag by type but there doesn’t seem to be a “type.setparameterbyname” node.
The custom node Door Set Handing is taken from here and can be downloaded from the package manager.
To set a Type Parameter you would first aquire the type from the door (GetParameterValue and Type is one way). Just SetParameter on an Element would set Instance parameters.
However it sounds like you should rather change that parameter to Instance and make sure it’s set to “Vary in Groups”. A door swing parameter on Type doesn’t really make sense to me…
Your issue here is you are really dealing with something that needs to be instance based as flipping is instance driven. The only parameter that can vary by group instance is a text based one I believe, so many write values to that vs using something like a boolean.
If you make the parameter project based and tick on vary by group instance this will be possible even if a text parameter sits at the door level also.
Thank you Gavin. I am still trying to reach a solution for the job. Here are the results I get when I run the script:
One thing I am trying to figure out is why my project doors get a different result than the OTB doors. I marked the exterior of each door family with an X. As you can see, doors #1 and #5 appear identically oriented but receive different results from the script.
just take in mind also that your content is clean modeled! ( i had a project with imported doors, it was fatal) to use BuiltInParameters for set door Opening directionHandFlipped Property
@Draxl_Andreas - well, unfortunately for me I can never assume that my door families are cleanly and consistently modelled since they are made by all kinds of friendly customers/people…
To digress for a moment, another issue occurs when there are rooms on both sides of the wall.Then the results are as follows:
In my actual project model, there are typically unit rooms and corridor/other rooms on both sides of doors. In this condition, the exterior parameter seemingly stops impacting the handedness of the script outcome.
It would seem like we need a way to categorize/sort the “Type” of room in order to ensure that “exterior/interior” always corresponds to “less secure/more secure” which seems to be the working definition my team uses. I’m not totally sure how to reconcile exterior/interior otherwise for the purposes of determining if a door is reversed.
Basically it seems like the script works, except in reverse, if I have no room on the exterior side. If I have a room on the exterior side, no side is considered to be exterior by the script and it default to LH/RH only (no LHR/RHR). Is that accurate?
This would be wonderful… but it would require that everyone work to the standard you referenced (or any one standard for that matter). Since the global industry doesn’t have one standard (or even a 2/3 majority) Revit can’t enforce a standard and therefore Dynamo can’t produce a standard. This is doubly complicated by the previous post around ‘the source families aren’t usually reliable’, as if the door swing is opposite what the standard expect we get opposite results.
