Phasing and Replacement Windows

Over the years people have often complained about trying to document replacing existing windows with modern windows but maintaining the existing opening. This means swapping windows with families that are the exact same size. This is related to the wall that Revit creates to infill a wall that has a demolished window. You may have encountered this warning message?

That message appeared when I attempted to place new windows in the New Construction phase after demolishing the existing windows first. I was careful to set up views assigned to different phases and phase filters so there wouldn't be any display conflicts.

I got interested in this issue again recently because of a thread at the Autodesk User Forums for Revit Architecture. A fellow member was sharing how much trouble Revit has been giving them trying to do this kind of work. After some back and forth I narrowed it down to one window family and another member realized that family uses a void to cut the hosting wall in the family itself versus the usual opening.

This led me to write some hypotheses for testing purposes. I wrote:

Hypothesis A: Within phasing we can replace Existing Window A with New replacement Window B using the exact same sizes (same size opening dimensions) IF they both use an OPENING in the family to cut the host.

Hypothesis B: Within phasing we can replace Existing Window A with New replacement Window B using the exact same sizes (same size opening dimensions) IF they both use a VOID in the family to cut the host.

If either of the above are false then...

Hypothesis C: Within phasing we CANNOT replace Existing Window A with New replacement Window B using the exact same sizes (same size opening dimensions) IF one uses an OPENING and the other uses a VOID, in the family, to cut the host.

I did some testing using the latest release of Revit, 2024.1 and I determined the following:

Hypothesis A is TRUE

Hypothesis B is FALSE

Hypothesis C is neither

I find that I can replace a Void based window with an Opening based window but not the reverse. Also any alterations to the hosting wall in the project; such as length adjustment, or top/bottom offsets, attach/detach will place the void type window at risk of being deleted. Weirder still is that it might not delete all of them, one or more.

It seems that the short answer is: eliminate window families that use a void to cut the hosting wall IF you intend to place identical sized windows in phased projects; to demonstrate existing window replacement without altering the existing openings. Windows created this way will not work for this task. A logical next hypothesis is to anticipate similar behavior in door families.

I speculate that this warning happens because an opening cuts fully through the host while a void (or combination of voids) might cut more and/or less of the host as it travels through it. I suspect that the infill wall can't abide the shape a void might create and that in turn means a void won't be viable as a window to alter the location of the infill wall. I think it's similar to curtain walls only supporting non-rectilinear panels with the system panel families.

I'd love to hear that the developers will test this against their own experience and expectations. I know that a lot of people rely on voids to shape the opening in a host wall to match a variety of actual construction techniques for openings. To eliminate voids in families as an option for this kind of project (replacement windows (and doors?)) is not ideal. They'd probably have to revisit the entire logic of infill elements where demolished hosted elements occur. Perhaps leave it up to us to fill in holes?

Parameter is Missing for Some Types

From a thread at RFO, Aaron explains what's gone wrong...

Aaron wrote:

"If someone deletes a family that is also the default option for a Family Type, with that Shared Parameter: Yes, the entire parameter gets deleted. It's terrible behavior, and its been that way for years.

In case I wasnt clear: This is a known issue, and it's easily reproducible.

1. Take any Family that uses a Shared Family Type Parameter, that has a default value.
2. Find the family in the project browser, that is the Family and Type that's in the default value.
3. Delete that family from the Project Browser.
4. After you've clicked *DELETE* in the warning, go back to the original Family (the parent family with the parameter).
5. For JUST the types that had that default value set, that parameter is now gone.

And yes, the instances in your project are hella broken, now."

Revit 2020.2.1 Hot Fix Posted

Regarding my last post - a Revit 2020.1 Hot Fix is now posted.

Of specific interest...Autodesk writes:

Issues Resolved:
Fixed an issue that resulted in the loss of family data in some workshared models when family definitions had not been recently modified. This fix does not repair models which have encountered loss of family data, for more information refer to Family Corruption in Revit 2020.2

Work Plane Based Families and Rotate w Copy

I participated in a thread at Autodesk's Revit forum and it took me far too long to catch on to the issue described at the outset. I should have retraced the thread sooner, but I did get there eventually.

I'm referring to the Rotate tool and its Copy option, this...

The issue boils down to this: the Rotate with Copy option works/affects a Work Plane-Based (and face-based) family differently than when a family is merely hosted by a Level (all non "based" families). Let's start here, imagine I want two screens on my desk like this.

These are stock families: TV - Flat Screen.rfa and Desk.rfa The desk has a top surface that isn't visible in plan view so it can't act as a face to host the TV. I changed that. The TV isn't a work plane-based family. In a plan view, when I place it on the desk it ends up eaten by the desk because it looks like this in a 3D view.

Sure, I can use its Elevation from Level parameter to put it on the desk (an illusion of a relationship). When I move the desk I need to remember to select the TV too (or make a group...or...I digress). I get the clever idea, "Make this family Work Plane-Based, that's easy!"

Using Rotate with Copy should give me the result I want in the first image and it does until I check the box for Work Plane-Based. The angle I decide I want between the screens is 22.5 degrees. I added a couple reference planes for the images to help see what happens, the desired result.

That's what I want except that they should be hosted by the desk, not relying on using the Elevation from Level parameter. When I use Rotate with the Copy option after editing the TV family to make it Work Plane-Based (also Always Vertical is checked) I get this result.

Notice the TV angle itself is correct but it's location is wrong...and a warning message appeared to help me notice... It's been moved/copied by double the input value of 22.5 degrees using the origin of rotation correctly and managed to maintain the angle I wanted. This next image summarizes what happened.

That's weird enough on its own but I can go weird by one more, un-check the TV's Always Vertical parameter. After running through the exercise again I get this outcome.

This time it applied the rotation input angle of 22.5 degrees x 2 = 45 degrees to both rotating the family and its position. This time it did it fully wrong while the previous time it only did it half wrong.

Introduce a Floor, instead of a desk family, into the mix and place the TV family before it is Work Plane-Base with Always Vertical and this happens. No rotation, just copy and in the same place no less.

When the TV family is Work Plane-Based and Always Vertical is used then it works wrong in the same way as relying on the desk's face as the host did.

I imagine Revit is attempting to relate the rotation and copy actions to the family's host, since that is the work plane the family is hosted by. Clearly it is unable to do so properly. I think it is reasonable to expect to get the same result whether level based or work plane-based. This post and the images are from using Revit 2020.2 but I did the same things in Revit 2016 with the same results. This has been around for quite awhile now.

If it is any consolation, the Mirror and Polar Array tools don't suffer from this malady but each have their own prep work required to make them a ready replacement.

Change a System Parameter from Type to Instance - Not Length

It is fairly common knowledge that we can change a built-in parameter like Width from Type to Instance by going through the side door, selecting a dimension assigned to the parameter and changing it to Instance on the ribbon (see the image).

Kurt Thompson wrote to me to share how he gets around this issue when the parameter isn't something a dimension can be associated with. Specifically he was referring to a thread at the Autodesk User Forums where a member (electrical focus) was asking Autodesk to change the default parameters for Mains (instance), MCB Rating (type) and Subfeed Lugs (type). They argue that each parameter should be the opposite of the current configuration based on how the information is really dealt with (not that he needs me to, but I agree with him).

Kurt writes:

"To change a System Type parameter to Instance...(specific to the mentioned thread)

Create a Shared Parameter built exactly like the built-in parameter you need to change but make it Instance instead of Type. Starting out with a Generic Model family, add the new parameter. Now assign the family to the category Electrical Equipment, Revit will replace the shared parameter with the built-in parameter but it will retain the Instance (or Type) property setting from the shared parameter. Give it a try."

Thanks Kurt!

Wish - Release Type Catalogs after Loading a Family

Revit needs to release the Type Catalog files after loading a family that use them.

That message makes the process of updating a type catalog tedious at best if you have to close Revit completely to release it so it can be edited, very inefficient. There was a brief period of time when Revit did release the file as it should, but that ended with 2018 if I recall correctly.

Revit 2018 - Insert Ribbon Search Field is Removed

When Autodesk Seek gave up on their mission and handed it over to BIM Object Revit 2017 started to redirect us to that site instead whenever we did a search. Prior to that it would take us to Autodesk Seek.

Notice anything missing from the 2018 Insert Ribbon image above? Well the post title gave it away but the search field has been stripped off. Remember this following image from way back when?

I realize it didn't make sense to leave references to Autodesk Seek in play. Now it's even less helpful to find external content. I guess it's more incentive to install BIM Object's Revit app? Probably what they intended.

No you're not imagining things, it's gone gone gone...

-- EDITED 5/2/2017 --

I installed the BIM Object Revit app.

Holy smokes that's a heck of a ribbon for the primary button I really want, Browse on the far left. Note if you launch any of the tools you can't do any work back in Revit until you finish interacting with their app. If you find that frustrating you could just open a separate browser.

It would be nice if there were some user settings to reduce the number of buttons to just those you're likely to use. I added the browse button to the QAT to get around accessing the ribbon tab each time.

Autodesk Seek is Dead - Long Live BIMobject

I've been busy, experiencing angst or lazy, you pick. Then again dear reader you may not have noticed that I haven't been posting as much lately. Apparently some readers are still hoping to be able to rely on me to try to stay current with things. At least that's what a few emails asking about this semi-recent change suggests to me. I do apologize if my reticence to post more often is disappointing. I have been busy as well as going through another spell of "What's it all about Alfie?". Oh I've given it away...or have I? (imagine Craig Ferguson was speaking).

Get on with it Mr. OpEd... At the moment the only place other than Autodesk sites that I recall reading information about this change is the Revit Add-Ons post on the day it happened, so well done Tim.

Specifically, you may have been, or will be, greeted by a message when attempting to search Autodesk Seek via Revit's Insert ribbon? The message begins with something like (I didn't capture the screen the first time) ..."As of January 18, 2017 Autodesk Seek has been transferred to BIMobject. At least I think the naming is BIMobject. It could be bimobjects because that's also on the site. I digress...yet again.

They've provided a transfer FAQ you can read but it's not really responding to any questions I have, as a user...UNLESS you are then careful to click the small link for User FAQ on the left side (link next paragraph).

I see they've set up a hotline for Autodesk Seek transition so look for that information there (via separate FAQ sections for User and BPM) too, it's the same telephone number for either category, user or BPM (Building Product Manufacturer).

I know nothing about BIM Object yet. I can say after arriving at their site via Revit once that the UI presented to us is a sight better than Seek. My first impression is that their customers are product manufacturers, selling the service of creating and hosting content for manufacturers, the same as for Autodesk Seek.

Assuming the somewhat jaundiced view of a Revit user, the user is the product they are selling to their customers, like Facebook for example. However attempting to be fair, users need good quality content to make quality building models so if these guys do well we BIM users ought to be winning.

Regarding my overall experience with Autodesk Seek, prompted by a post at RFO, I wrote this reply there a couple days ago, responding to Philip...(a bit more of the Opinion part of OpEd)

My own experience with Autodesk Seek began with hmm promising, let's see how this goes and ended with what's the point. If you consider RevitCity's content quality is ravaged pretty consistently by fellow Revit users, as such lately I have had the same dread reaction to resorting to searching Autodesk Seek. I even went there a couple times to pull down bad examples of content to show people I was mentoring on the subject...not a good recommendation eh? Inspiration for blog posts is one upside? Okay, getting snarkastic sorry.

My feelings changed sharply a short while after the Family Style Guide was published related to Seek. A great idea and initial effort but it was a bit plain to see the market/revenue generating bias of it toward Seek. ...and it too has died on the vine.

Overall, very disappointing. Especially considering I've heard it was no small investment of time and money by companies to get their content hosted by Seek. But then that's the secret about content it takes time and both involve money even if we don't look.

Back to BIMobject, I'm going to keep an open mind, more open than my obviously skeptical comments above suggests is possible. Let's see how this goes. Oh, I'll answer the question that's probably on any user's mind for them (from their User FAQ):

Do I have to pay for the BIM objects I download?

bimobject.com is a free of charge web service for architects, engineers, specifiers and all other disciplines in the AEC and Infrastructure industries.

They offer a free Revit app to directly integrate their content search and access into Revit too.

Feel free to use comments to share your observations and experience with Autodesk Seek (in the past) or BIMobject if you've been a using their content already.

Kinship and Autodesk University

My friends Jose Fandos and Gary Sprague have been working tirelessly to develop a product they call Kinship. It offers an intelligent way to organize, search for and place Revit content and even more compelling to me is the project insight it can provide us. After a couple years of private testing they are opening things up for real.

They were kind enough to invite me along with them to Autodesk University (AU) this year. If you are attending AU please stop by to say hello and find out more about Kinship. If you're not here at AU then let me encourage you to visit their site to learn more.

Load and Place a Family

Perhaps it isn't obvious enough but Revit is designed to deal with loading and placing a family according to context determined by our actions. Did we start a placement process or an admin process?

The component tools like Door, Window, Component, Detail Component, Air Terminal and so on provide Revit with placement context. The Insert ribbon tool Load Family is an administrative task which does not presume placement as a priority.

IF we start the Component > Place a Component tool first. Choose Load Family from the ribbon. In this context Revit knows we intend to place something but using Load Family tells it we need something that isn't already loaded in the project yet. If we choose to load multiple families it is ambiguous to Revit so it chooses for us which family to offer as the family to place now.

When we use Insert ribbon > Load from Library > Load Family separately it is regarded as an administrative task, i.e. "I need to load some things so they are available to everyone." Personally I have had many situations where I need to load families in this way, not place them immediately. If I do want to place a loaded family right away then I start the Component (or Door, Window etc.) tool first.

The Family has been Renamed

This warning message is probably familiar, troublesome and annoying.

I was reading a couple threads at RFO; THIS ONE and THAT ONE.

Apart from workset related issues I've written about before, I believe the underlying cause of renaming is that Revit perceives a family as different. That's not very surprising but I think that the actual difference is the result of different versions (2016 vs 2017) or having Save As used on the family (to put it in a different folder)...AND any operation that involves Copy/Paste, which includes the Insert from File tools.

When Load from Library > Load Family is used I only see it occur when worksets are being used (see the links at end of this post). The families merely having some different parameters (either instance or type) generates the dialog asking how we want to deal with the existing definition.

Using Revit 2017.1 and passing a family from one project to another I observed the following:

Family is renamed but no warning message:
If the family being introduced is an older version (upgraded) of one already in the model
If the family is same version but has had Save As used on it, i.e., to put it in a new folder location

Family is renamed and the warning appears:
If the family is an older version or Save As version AND Insert from File is used

Family is not renamed:
If the Family is copied from same library folder to a new folder
If the Family is from the same library folder
If the Family (existing) is reloaded from older version before using Copy/Paste or Insert from File.

The issue can be avoided if we are meticulous about using families from the same library and version. If we load office details from a detail library project file using Insert from File and the families (some or all) involved are based on older versions while newer versions are already present in the project we'll incur the renaming penalty.

The detail library should be updated, have the newer versions loaded first so they will be the same as those in the active project. If we need to keep the detail library in more than one version then we'll have to decide how to manage that and for how long. Merely upgrading the detail library model does not appear to be sufficient to avoid the issue.

I ought to mention that I can load a family and let it upgrade. Then if I use Copy/Paste to pass it along to another project file it does not get renamed unless the existing family in that project is based on a different version than the one I just upgraded. Upgrading a family does not seem to create the same problem that using Save As does for a family, at least not in the context of Revit treating it as a rogue family competing for the same name/existence in the project.

Regarding the workset issue I wrote three posts about previously, they describe how families can get renamed when worksets are being used and more than one person loads the same families and synchronizes their work in a specific way. The posts are:

FIRST post
SECOND post
THIRD post (references the first two as well)

Revit 2017 - Calculated Values in Tags

This addition permits us to do the same thing to tags that we've been using in schedules. For example, in a tag I'd like to show the difference between the client required area and the actual area of a room. That wasn't possible without some export/import or Dynamo shenanigans. Now it is possible, right in a tag.

This starts in the Edit Label dialog via a new button, then it is the same as the dialog we've seen in Schedules.

Since these can be used in schedules and tags, and it has to be done separately for each use, it probably makes sense to document all of the formulas we use so they are easily harvested for another project. Build them into a template and there is less need to do that at all. Regardless it wouldn't hurt to have a Drafting View set aside with the text versions of all the formulas we use stored there. That way a simple Copy/Paste operation can harvest a formula to use in a tag or a schedule or both.

Family Templates and Reference Plane Inequity

This is subtle but still a source of amusement or annoyance. Start a new family using the Generic Model template and try to copy an existing Reference Plane. Nope, the Copy tool is disabled.

Now try it with the Furniture template. Ah, Copy is enabled.

Try it in the Casework family template. You'll find Right, Left and Front Reference Planes are forbidden while the Center (Left/Right) and Back Reference Planes are not. That makes sense. Wait, what?

Okay, the rule is copying a Reference Plane working on furniture is okay and doing that in Generic Model templates = BAD? Doing it in the Casework template is, well it depends...

Actually the only rule is that you can expect some reference planes in some templates to be forbidden to copy while others are not affected by such thinking. Ralph Waldo Emerson cautioned us to avoid a foolish consistency. In this case a little more consistency wouldn't be bad.

...I'm not asking for all of them to be forbidden either...if you're wondering.

Warning Messages and Profile Families

Profile families are loadable (component) families but they don't exist on their own in projects. They are either used to create solid and void forms in the family editor, in-place families in projects or applied to System Families in projects. For example, a Railing, Sweep, Reveal and Floor Slab Edge can all use a Profile family.

Occasionally I'll get a generic sort of warning regarding the system family I'm trying to make, telling me "Sorry Steve, I can't make this thing for you".

Quite often the reason Revit is complaining is because I was sloppy making the Profile family. You may recall I've written about good sketches and bad sketches in the past.

Regardless the error message could certainly be written better; to mention that such an error may be related to a profile that isn't created properly. At this time, the error trapping process may not be able to reach deeply enough into the sketch mode process, for example like we use to create a Floor Slab Edge. Regardless, there is no reason the error message couldn't mention a common culprit, something to prod us to look more deeply for.

Technically the error is in a component family and then evaluated as part of a system family that references it. In a sense it is too far removed from the active operation for Revit to properly recognize what's wrong precisely. Therefore I think it would help if, while saving a profile family type, Revit tested it for proper closed boundaries to help us catch errors while editing the family. Revit does this when we attempt to finish a sketch for a solid or void form. Perhaps it could be a button on the ribbon? Something like Test Profile.

Help us help you Revit!

Did you Load a Family - Synchronize NOW

ALWAYS use Synchronize with Central (SwC) immediately after loading new families or types (or duplicating system family types). Don't place any instances until you have!

This post is tagging on two earlier posts on the subject of loading content, restating the punch line to emphasize it on its own. If you're inclined to just take my advice just reread the first two sentences and behave accordingly. If you're a bit curious, need more convincing, you can read the FIRST and SECOND posts for more background info.

Line Styles Embedded in Families

Reading a thread at AUGI tonight prompted this post. Line Styles aren't a thing in Revit families, the option is disabled if you attempt to review them while in the Family Editor UI.

The family discussed in the thread seems innocent enough until it is loaded into a project file. These are the line styles that are in the default template (imperial).

This is the same dialog after loading the family; nearly 100 more (98) line styles show up.

The culprit is Transfer Project Standards (TPS). It is easy to transfer line styles from a project to a family. We need Object Styles in families not Line Styles. Make sure you don't select Linestyles when/IF you use TPS.

If you've already got many rogue Line Styles you can delete them from the project and in Revit 2016 you can select more than one at a time and click Delete. Just remember if Delete is disabled then you've got a built-in (system) line style selected.

What about cleaning out the family itself? They don't give us a tool to do that. Purge Unused doesn't see them unfortunately. Robert Bell, in the AUGI Thread, offers a solution though. Load the bad family into a empty template (choose the None option for example). Delete all of the line styles you don't want. Then Save the family and overwrite the original. If the family is already loaded into your project just do the same thing, delete the line styles (it's just a little harder to tell) and Save the family to overwrite the original.

While you're at it, don't use TPS on Line Patterns, like shown in the image above. You'll probably get many more than you really want too. Those can be deleted a bit more easily though.

I checked the Autodesk Exchange Apps site to see if any offer a way to purge line styles from families. I found one that does it for projects but none that claim to do it for families; at least not based on searching for that criteria. It might be something Dynamo can be used to resolve; I'll have to check into that.

---------------------

Update 08/22/2016: Dale Bartlett has shared an app to purge these embedded line styles.
Update 05/09/2017: The file is no longer where Dale shared it, I don't know where it is now so I've removed the link.
Update 05/15/2017: Dale provided a new link to a 2017 compatible version VIA THIS URL.

Clearance Subcategory in Linked Files and Families

You've linked a model that has families which include clearance elements. That's excellent for doing clash detection. However you may not really want to see the graphics they've provided for this in all of your own documentation views.

Hopefully the clearance elements have been assigned to a unique subcategory that you can control by overriding the link's Visibility/Graphics.

If so and you'd like to control the subcategory without overriding their linked file you can use Copy to Clipboard on one of the families (TAB to select it) with the clearance elements in them. Then paste a copy somewhere in your model. Now the family's subcategories are part of your own model. You'll be able to control it via V/G without overriding the link, assuming the link is assigned to By Host.

You probably realized that doing the above is a shortcut to creating a matching subcategory assigned to the correct category in Object Styles ourselves. It is a shortcut because we probably won't know what subcategory the family is using without examining the family more closely, by opening the linked file and editing the family directly. Using Copy and then Paste provides us with a copy we can interact with directly instead and any subcategories it has are brought into our project for us.

Families are prone to inconsistency because they can be obtained from a variety of sources. Consider that even the families from Autodesk aren't entirely consistent from one to another. It may still be necessary to crack open a family to find out how their clearance elements are controlled. For example, the lines that form the "X", and the "box" around them, in this family are assigned to the Hidden Lines subcategory, not Clearance.

In 3D there are forms to indicate clearance requirements and they are assigned to a Clearance subcategory but they also have their Visible parameter unchecked which means we can't see them in the project at all, anywhere.

This family does not intend for us to turn off the clearance "X", at least not via its Clearance subcategory. It has a subcategory called clearance and the solid forms for its clearance zones are assigned it but then it was decided they shouldn't be visible at all. By the way, doing so does not prevent Revit from seeing the clearance forms when using its own Interference Checking. However in Navisworks they don't show up. That might be considered bad form (pun intended). From a family editor perspective (and user), it would have been more flexible if the Visible parameter had been associated with a Yes/No parameter to allow us to turn it on or off if necessary. Unfortunately, keeping in mind that this post began about families in a linked file, it wouldn't make any difference for us.

Consistency is easier to manage and achieve when it is your own content library and your project files. It can be a bit trickier dealing with the content that is part of the linked files you need from other disciplines. It's easy to create a family that makes me happy, or my team. It may not make the other consultants happy though. Something to think about while you're being happy making content.

Worksharing - Loading Content Part 2

In my previous post I recommended a point person be assigned to manage the loading of content for a team. That might sound like a beauracratic minded recommendation. Not me at all. It is more a matter of self preservation, wishing to avoid having to fix the resulting duplication before it becomes a bigger problem. As such there is a another minor measure we can take to help catch the issue when it occurs and fix it.

Always use Synchronize with Central (SwC) immediately after loading new families or types (or duplicating system family types). Don't place any instances.

If we can't get a single person to manage this loading then using SwC immediately afterward will increase the odds that a warning message will appear as soon as the transaction is completed. This does assume that we all develop this habit. If the warning appears than we need to examine the new family(ies) and or type(s) in the Project Browser and resolve the issue.

The goal is to avoid creating the duplicates and even more importantly using them in the project.

Worksharing - Loading Content

I read Jason's post this morning and he describes a classic worksharing gotcha. Unfortunately he hasn't identified the true culprit. I'm referring to this part of his post specifically.

One of our most notorious examples is the infamous Break Line. Each drafting view we imported had a copy of the break line family. By the time anyone noticed, the project model had “Break Line (1)” through “Break Line (22)”.

What he describes is the result of worksharing and multiple users loading the same family in their own local files. Revit sees multiple versions of the same file being loaded from different local files (users) and seeks to protect them by renaming the other versions it encounters. We see this sort of message when it happens.

This error and situation is easy to replicate.

• Two users open local files for the same project
• Each user loads a new family and the same type
• Each uses Synchronize with Central (SwC)

The first person to sync will be successful without an issue but the second person will receive a warning about the family being renamed. If this is repeated enough, and by enough users at the same time, we could end up with family22 like he described.

For example, if eight people all introduce the same new family to the project then by the time the last person uses SwC there will be eight versions of this family listed in the Project Browser. This is what the Project Browser looks like after just two users think they both need to load a new double door and type.

Jason's post is focused on cleaning up after oneself and it IS important but it is also important to manage the loading of content and harvested details. It is equally important that people understand why these extra versions show up in the first place. Each time someone uses Load Family or Insert from File they must reconcile the warnings that appear before anyone has a chance to begin using the wrong version of the families that are duplicated.

I think it is worth restating that the subtlety of this issue is that this only happens when more than one user is introducing the same new family to the project (via their Local Files).

Once the family is part of the project (defined in the Central File) Revit doesn't get confused anymore. Here's what happens when I introduce the Break Line family he mentioned to the project via two users. Keep in mind that there is no Break Line family defined in the Central File at the moment. Each user loads the family, into their Local File, unaware the other user is doing it too. The first person to use SwC is fine but the second user sees this message (I expanded the warning to see the family description).

When the first user uses Reload Latest or SwC they'll both be able to see this in the Project Browser, listed beneath Detail Items.

Subtlety compounded with yet another subtlety...if the family is already defined in the project (Central File) but a new TYPE is loaded by more than one user then we end up with this situation in the Project Browser.

How do we avoid this situation?

As soon as we think we need to load a new family or type...STOP.

Who (on our team) is responsible for ensuring the content we need is available to us? There ISN'T any ONE person assigned to this? There should be. All new content should be requested, requests sent to or asked of this person. That person can delegate the task.

The goal is to avoid the situation where more than one user is loading the same new content.

Only ONE person needs to load the family(ies)/type(s) and then use SwC to make it available to everyone else on the team (they use Reload Latest). We are working on the same project after all.

To close and return to what inspired my post, Jason went on to write that they've abandoned using Detail Components in their details because of this issue. Tragic. They (the detail families) aren't the problem; Revit's worksharing behavior and user habits are. I hope he'll revisit that decision.

Spacebar and Titleblocks

Titleblocks are families. The Spacebar will rotate a selected family (90 degree increments by default). Remember that when you have a titleblock selected. Today that startled a person when they thought they were tapping the space to insert a space in a text field but it was no longer selected. The titleblock spun out of view. What the...? OH...