Revit MEP 2014 - Reapply Type

This button snuck past me in my reading about what's new. I don't see anything at all about it in the What's New documentation at the WikiHelp pages at Autodesk either.

Originally I was preparing for my What's New session at RTC (happening right now!) and while I was working through various tasks I noticed the button and thought, "Hey I don't remember that in 2013!"

Well my memory isn't that good anymore apparently because it IS in 2013 too.

I don't see it in the What's New for 2013 though and I didn't find it in 2012. Perhaps I am sort of correct (a little?) that it is new, or at least undocumented? I guess this fits into "What's old is new again"? I left a mention of it in my What's New class handout even though it isn't new to 2014.

If you haven't noticed it then let me explain.

Imagine you've placed a lot of duct and then change the related duct system settings about which fittings should be used. Nothing will happen to the existing duct. The Reapply Type button will take whatever duct you select and REAPPLY your recent changes (to the type) to your selection. Once a duct is placed it more or less remains inert unless another duct it trimmed or extended into it, touches it. When the duct is harrassed by another Revit will start to refer to the settings to determine what fittings to use.

Here's to "new" old features!

Create a Type Catalog

There is a relatively new feature available to create a type catalog automatically. Anyone who has tried to deal with this task using Revit MEP can relate to the awkwardness of trying to define the units for each parameter properly. The syntax and names used don't necessarily leap to mind.

If you visit the Application Menu > Export you'll find the Family Types option.

This does not create a perfect type catalog. By perfect I mean it may provide more parameters than you really intend to use in the catalog. That's because it will export them all. We often only provide the critical or most relevant values in a type catalog and leave others as default settings that all types will share. It works great if you want them all though.

Just to quibble though, I think that the name of the command ought to be Export > Type Catalog instead of Family Types. It would be more consistent with what the resulting file is called and used for, a Type Catalog.

Creating New Types

We have a few options when we need a new version of a door, wall or window etc. System families (wall, floor or ceiling for example) are created in a project while component families (door, window or furniture for example) are separate files, created in Revit's family editor mode.

If you need a new wall type you can choose door number one or two to make it. Door number one is using the Project Browser. You need to expand the Families category in the browser, then expand Walls and finally expand either Basic Walls, Curtain Walls or Stacked Walls.

When you select the wall you'd like to edit, or in this case duplicate, a right click will provide a list of options, one of which is Duplicate.

You can also double click on the name in the browser to open the Type Properties dialog. Once that is open you can click the Duplicate button.

I usually double click because I can duplicate and then immediately edit the type. The right click approach will still involve opening the dialog to edit its properties as well as renaming it. I figure the double click approach is a slight shortcut.

Once the new type is created it is available to use but not actually in use. Keep in mind that when using Worksharing it is only available in the local file we are using, we need to SwC to make it available to others.

Door number two is to select a wall you see in the drawing area and then click Edit Type on the Properties Palette. Once the Type Properties dialog is open you can duplicate and edit its properties. The significant different between these two doors is that this one alters the wall we selected, unless we reassign the wall back to the previous type first.

Worth restating, creating a new type by selecting a wall placed in the model will result in changing that wall to the new type unless you remember to reassign the selected wall to the original type before closing the dialog.

Another mistake we can make is to just edit the properties of the selected wall instead of remembering to create a new type first. This usually results in cries of anguish after all the walls change in the model. Fortunately if you catch it quick using undo will usually fix it.

With component families (aka loadable families) we can use the same approach in the project, either door number one or two. However this does not alter the original family in our project, office or stock libraries. If the new type really ought to be part of the library version then that family needs to be opened and have the type created there. Then you can reload the family to add the new type to the project.

Here's a two minute (ish) video if it helps.

Family Types or Type Catalogs

Jose Fandos wrote a post in August titled, The Death of the Family Types. He thinks that the role and or usefulness of built-in family types is over or "dead" as he puts it.

I don't agree entirely. I do agree that for someone who makes content regularly that adding types to the family directly is a task best left for last. Making sure every type is properly defined can be quite tedious inside the family. It isn't a lot of fun making sure every value is correct in the rows of a type catalog either though. At least it IS easier to copy/paste and then adjust values than within the family itself.

While making "my" life easier when making content, Type Catalogs can be perceived as a hassle by the end user because they need to load the family each time they find they don't have the type/size they need. The recommendation of no more than 5 types in a family found within the Autodesk Seek recommendations is one less than the earlier family editor guidelines that suggest no more than six. The text of the Revit Content Standards document that the team used internally said: (David Conant shared it with me in 2005 while preparing a session for AU)

Predefined Types:
• All families should have at least one pre-defined type unless a type catalog is used.
• Where real world examples come in typical sizes, pre-defined types should be generated.
• Where there are to be more than 6 predefined types in a family, use a type catalog to organize the types.

Keep in mind that these rules or standards were coming from the viewpoint that they are generic families meant to be pretty broadly applicable. Obviously the document David shared with me came after the introduction of type catalogs since it makes reference to them. Jose's post shares that Wesley Benn provided him with the text from What's New in Release 4.0 that show when type catalogs were introduced. Regardless, the point at which we choose one over the other family types or a type catalog boils down to preference.

As a daily user I don't enjoy interacting with Type Catalogs as much as I prefer them as a person who also makes content. If there are only five types in the family I'd probably be inclined to load them all to avoid doing it again to get the one I left behind. I also find that once users realize how easy it is to create a new type in their project, they are just as likely or inclined to do that instead of editing the family externally and reloading. If users start doing that the type catalog starts getting out of sync with the library. Keeping track of the flock can be hard on the Family Shepherd at that point, with strange sheep showing up in the fields.

I think that family types have a place and the rumors of their demise are greatly exaggerated.

Dept. of Subtle - Family Editor Parameter Lock

A recent exchange at the RevitForum.org reminded me of this subtlety. The Family Types dialog introduced the concept of locking a parameter.

You can select a reference plane and the dimension changes to blue like "normal" when the parameter is un-locked. When it is locked you can edit the dimension value by selecting the dimension, which is counter-intuitive because that's how we create a dimension override in the project environment. I believe the lock check box is "supposed" to lock out editing in canvas but they left a "back door" unlocked (pun intended).

It is easiest to see this in action so I did a quick video demo.