Consistency, CONSISTENCY, consistency...
This post is the result of noticing that families that were using a specific group for some parameters were not showing up in the correct group once they were added to a project.
When you create content the names you use for parameters is one thing to worry about. The Group you assign them to is yet another. We don't get much control over how we present parameters to our users, but Groups are one thing we do get some say about. We can even change them without starting over, compared with getting the parameter name or data type wrong.
If you'd like all your content to show the same grouping you'd better be consistent. Then again even if you are you may not get your way though. I should explain myself now?
Here's a parameter called "Mounting Elevation". It's neatly tucked away in the "Construction" group.
I loaded it into a project and all is well. A bit later I notice this. The parameter has wandered into a new group called "Dimensions". Hmmm...
I went back to the beginning, just like Vezzini told Inigo he should. I started with a blank project template and a single family. I added a shared parameter for "Mounting Height" and assigned it to the "Construction" group. Parameter showed up as expected. I went back to the family and tried to change the group to something else. Loaded back into the project, no respect...parameter still located under "Construction". Apparently once the project captured the group, it stuck, even if I change it in the family and reload it.
Next I tried adding a second family that used the same shared parameter but assigned to a different group, no change. Still assigned to the original group. Hmmm... So how did the parameter move?? I started to think that maybe I assigned the parameter to the other group originally and later decided to use "Construction" instead. That was so hours ago, don't really remember now. Just not sure anymore.
Let's mix it up a little with Project Parameters. When you use a shared parameter in your family Revit is kind enough to make them available in schedules without doing anything extra (except for titleblock families, they are a special case). I thought I'd try adding the same parameter to the project and assign it to the group I really wanted. Aaah... the parameter moved to the group I wanted!
If I edit the Project Parameter and change it again it moves to the new group. Well that's consistent at least.
Fire Protection probably isn't the best group to use though eh? My lesson learned from this fun is to think a bit harder about the groups I want to use earlier and to be really sure I'm happy with the setup before putting it in a real project. If I don't I'll either have to live with it or just add the parameter to the project too (which isn't really a hardship even if it isn't technically necessary).
This post is the result of noticing that families that were using a specific group for some parameters were not showing up in the correct group once they were added to a project.
When you create content the names you use for parameters is one thing to worry about. The Group you assign them to is yet another. We don't get much control over how we present parameters to our users, but Groups are one thing we do get some say about. We can even change them without starting over, compared with getting the parameter name or data type wrong.
If you'd like all your content to show the same grouping you'd better be consistent. Then again even if you are you may not get your way though. I should explain myself now?
Here's a parameter called "Mounting Elevation". It's neatly tucked away in the "Construction" group.
- Curious about why I'm using Mounting Elevation when you can clearly see Default Elevation just above it? I can't tag something with the Default Elevation parameter (Data Devices in this situation), it's not among the parameters available in a tag family. I'm using a shared parameter for Mounting Elevation and "connecting the dots" with a formula that is equal to Default Elevation.
I loaded it into a project and all is well. A bit later I notice this. The parameter has wandered into a new group called "Dimensions". Hmmm...
I went back to the beginning, just like Vezzini told Inigo he should. I started with a blank project template and a single family. I added a shared parameter for "Mounting Height" and assigned it to the "Construction" group. Parameter showed up as expected. I went back to the family and tried to change the group to something else. Loaded back into the project, no respect...parameter still located under "Construction". Apparently once the project captured the group, it stuck, even if I change it in the family and reload it.
Next I tried adding a second family that used the same shared parameter but assigned to a different group, no change. Still assigned to the original group. Hmmm... So how did the parameter move?? I started to think that maybe I assigned the parameter to the other group originally and later decided to use "Construction" instead. That was so hours ago, don't really remember now. Just not sure anymore.
Let's mix it up a little with Project Parameters. When you use a shared parameter in your family Revit is kind enough to make them available in schedules without doing anything extra (except for titleblock families, they are a special case). I thought I'd try adding the same parameter to the project and assign it to the group I really wanted. Aaah... the parameter moved to the group I wanted!
If I edit the Project Parameter and change it again it moves to the new group. Well that's consistent at least.
Fire Protection probably isn't the best group to use though eh? My lesson learned from this fun is to think a bit harder about the groups I want to use earlier and to be really sure I'm happy with the setup before putting it in a real project. If I don't I'll either have to live with it or just add the parameter to the project too (which isn't really a hardship even if it isn't technically necessary).
10 comments:
You might find that if you remove the Project Parameter now, that it will hold the new Group.
We have used that trick to "fix" a few other family issues.
Weird, but totally Revit.
BTW, you may not want to link your "Mounting Height" param to "Default Elevation" since the Default Elevation param is only the "Default" when a Face hosted object is placed. If the object is later moved, the field does not update.
But maybe that is as intended.
This particular collection is not face based so the use can just change the "default elevation" value and it does update correctly.
Face based content is a future consideration. Face based is limited when there is "no model" to put things on "yet"... so we've chosen to start with "dumb" un-hosted elements. As the data they receive gets more cleverer...then we'll tackle the face based stuff.
the bug you found it can be avoided if you take care to never edit that family from inside the project via edit family. Just open the family from the window explorer every time you need modifications then load to project and overide the old version. Ones you edited from project the bug appears.
IMVHP they should go with Face Based anyway. They can be placed *on work plane* at which point they are basically unhosted. But later when they WANT Face Based, they wont have to redo them.
FWIW, i also just kill the Default Elevation Parameters, because in the project it ends up being a type property while the ambiguously unaccessible Elevation Parameter shows up as an instance, in the face based (which we cant tie anything to. Booooo)
ignore my last comment...
the bug I described is not related with your shared parameters problem. Only with normal parameters that are reordered using that reorder trick with "*" sign
It works as expected if the family is 'saved-as' in the family editor with a new name, then loaded back into the project.....
Thanks for the comments!
Face based families alter their model orientation when they are not hosted by a valid workplane that is in the correct orientation. In the case of a wall outlet, no wall would only leave the "floor" has a substitute host. The outlet ends up looking like a floor outlet in a 3D view.
The default elevation parameter only ends up as a Type Parameter with Face Based, works quite nicely in the "regular" family.
Quirky stuff...
From your last comment, I'm assuming that the only parameter you can set to equal the Mounting Height is the Default Elevation, regarding face based families (ie data outlets, receptacles, etc). I'm trying to tag the Elevation instance parameter, so that as we adjust the height of the object the tag updates as well. Have you found a way to make this work, using face based families?
My previous comment doesnt seem to work in later versions of Revit. My business partner just showed me an easy way:
Shedule the parameter in the project, go to the schedules "field" and change its grouping there.
I know this is a super old post but I thought I would post the work around in case anyone else is looking for it.
You can do this through scheduling. Schedule the item and go to" fields". Find the parameter you want to change in either "available" or "scheduled" fields and click "edit". Change the Group parameter in the "parameter data" box and put a check in "add to all elements in the selected categories" and then put a check in the "category" area next to the items the shared parameter affects, hit ok to close the edit box and ok to the schedule properties.
Check your family, it should now show the parameter in the grouping you moved it to. You can delete the schedule you just created after without affecting the grouping.
Post a Comment