A vision for Shared Parameters

[etboards17]

I believe I have been deceived. Both by a moment of stumbling, moving on because my stumble caused something to happen that was undesired at the time, but cool, and also the verbiage of the help function validating my stumble and causing me to research the possibility.

I hope you can follow that sentence above, because what I thought I had discovered was going to revolutionize how I designed families. The desire to have this work was managing frame offsets within different wall types in a project. The rough opening dimensions are type based, therefore creating 40-50 different window types within one family of fixed frames. What is different between these types is which walls they were placed in.

Therefore I needed a parameter that could control all the types within one family. In essence, a 'Shared Parameter' controlling the frame offset of all masonry hosted windows.

The help dialogue states that Shared Parameters are parameters that you can add to families and then share with other families. Would this not exclude sharing a dimensioned offset value and enabling the ability to change one value that would change all other values sharing that parameter within the project?

Now I have come to grips with the fact that I am wrong: When changing a dimensioned value in one type does not change another parameter in another type within one family.

I am seeking out who else would find this function vital to setting up parameters that are shared between Families and Types within those families so that massive changes to dimensioned values, or anything else, could be made without having to mass select families that were organized in a primitive fashion of naming.

Another example that this would work well with is counter top thicknesses. Many types are made based on depth with instance based lengths. When the project learns what thickness of material is being used, the thickness parameter would be shared among all counter top families and types, therefore making the change once and being reflected in all shared families and types.


I would appreciate any input concerning this subject. Even suggestions to how I might manage the frame offsets between 50 different window types> 32 of which are in masonry and 18 in metal framed studs and siding all with different type based rough openings. (They have to be type based openings to develop type legends and tags on exterior elevations.)

[patricks]

How about just making a parameter for the type of wall you're putting the window in (masonry, siding, etc), then making a schedule, sort by that parameter and DON'T itemize all instances? Then you could change all window inset values for every window in a particular opening type very quickly.

Sure it's not quite as quick and intuitive as you would like, but it wouldn't be as tedious as the alternative you described.

Initial setup may take awhile, but once you get it set up, everything will be quick. If you have this type of issue on many projects, then just add this schedule to your template. Do it from the very beginning of the project and you won't have this issue anymore.

[Steve_Stafford]

As you've learned a shared parameter is not a global parameter that affects many families, it is simply a shared definition that many families and projects can use so that the same information (displayed in a single column of data in a schedule for example) can be understood across a variety of families etc.

What you describe, a global shared parameter that can be changed once and thus update a related group of families, is a request that has been mentioned here several times over the last few years. It remains a wish...

[Dimitri Harvalias]

I can't recall who suggested it (possibly you Steve or Phil Read) but the concept of project 'constants' would be of huge benefit for this type of thing.
These constants could be used as values in parameter formulas and would open up endless possibilities in paramater driven family creation and schedules.

[etboards17]

As a work around, creating a shared Frame Offset Parameter and utilizing the schedules to collapse all the types within families works. The window family creations would evolve with the creation and design of the wall types and be specific to the wall types by name or unique marking type that would cause the schedule to sort as the designer sees fit.

Once the schedule has been arranged properly and not itemizing each family type, you can then change one value to influence many types’ across a project.

The next task is creating symbols or signifiers for the team to recognize which wall types the windows are hosted in. This should be a simple management task. M for masonry, S for siding, and then moving to more complex compositions of walls with sub signifies such as S-1 or S-2 and a type legend for the rest of the team to refer too if needed.

In the long run, having the schedules create the location to control a universal parameter does the same thing I originally set out to do. It simply is not as literal as changing it in the properties of any type within a family, which would be nice to have when working with the model and creating hybrid details.

Thank you for your time. I hope others find this helpful and continue to chime in on this matter to help the evolution of 'Revitizing documentation'.

[Steve_Stafford]

...I can't recall who suggested it (possibly you Steve or Phil Read) but the concept of project 'constants' would be of huge benefit for this type of thing...I've definitely posted about this before but I don't know if I was the first, probably not.

[twiceroadsfool]

I've definitely posted about this before but I don't know if I was the first, probably not.

Parameters with values at the project level would be monumental for a number of reasons. Imagine dimensioning a wall to wall distance of a building, and assigning that dimension a Parameter label just like we do in the fmaily editor... And having it be tied to many other variables.

One single value for constraining FTF heights in a Building Section...

There are tons of uses for them. I wouldnt want to change the way *shared parameters* work now... They work great for THEIR intended purpose. But if there were "Project Variables" (since i cant call them project parameters, LOL), then i could go in the Type Properties of a FAMILY and tie it to the PROJECT VARIABLE, just like we do with Nested Families now...

[Scott Womack]

I can't recall who suggested it (possibly you Steve or Phil Read) but the concept of project 'constants' would be of huge benefit for this type of thing.
These constants could be used as values in parameter formulas and would open up endless possibilities in paramater driven family creation and schedules.

This is in effect a Wish that I posted a couple of weeks ago, so it has not been "Vetted" yet by the committee. I did go one further, in that you should be able to also allow this "global" parameter to be set equal to the grand total of a single schedule. Thus you could "drive" this global parameter with a single schedule. Then you should be able to use this in other shedules to drive formulas in those schedules.

[jamesgchambers]

There is a workaround for achiving this without relying on a schedule...I've tested this, but not put it through an actual implementation.

Say you have 4 window families, they all have changing paramaters, but there is one common one (say "Inset"). Take the 4 window families (these are the "Child" families) and place them into a "Parent" family. Once in the Parent family, place one fo the Child families into the wall, then give it a label. This will then let you cycle through each family+type loaded into the Parent family.

At this point, go into the element properties of the "Child" family and map the parameters to the parameters in the "Parent" family. Now when you change the "Inset" parameter in the Parent family, it's pushed to all the child families.

You can also use "trick" for changing consistent parameters in a family with many types. Say all your windows have the same Inset of 2," then you decide it should be 3." Rather than going through each type and changing it manually to 3," just enter 3" into the formula and hit Apply. Obviously, that has to be done in the family editor, and can't be done in the project.

Off the top of my head, all families would have to have the same parameters in order for the mapping to be contigious and not "break."

This might be a horrible idea, but it also might work well...

[twiceroadsfool]

James, it wont work.

When you nest a family in a family, if it is Shared (which it would have to be to do what you described) the only way to Tie Parameters to the Parent family is to make the Child Families parameters an Instance parameter.

Because of that, it only affects the INSTANCES that are nested. So the standalones would now change.

If it is not a Shared Family, it wont even recognize them as the same Family definition, so the type parameters will not affect the un-nested instances either.