Naming a Reference Plane

I read recently that just adding a name to a reference plane would cause it to be "strong". The notion of Strong, Weak and Not a Reference are related to the IsReference parameter, which I've written about before. It's my observation that adding a name to a reference plane has no impact on it's behavior in a project. To test my belief I created a small family with a collection of reference planes with various combinations of Name and IsReference parameter values.

The reference plane on the far right is set to Not a Reference and has the Name No 3. Its the only one that is invisible in the project environment. The two on the far left have IsReference values (Weak and Strong) but have no Name either, they still are detectable in the project. I sketched dashed lines from the detectable ends of the reference planes. The dashed line on the far right is sketched where the reference plane should be but I couldn't snap to the end because it isn't detectable there. I also added a dimension string across each detectable reference plane.

I think my beliefs are intact, just adding a name to a reference plane does not alter its IsReference conduct in a project. When we create a new reference plane Revit assigns Weak Reference to its IsReference parameter. If we copy a reference plane, those that Revit lets us copy, it also assign Weak Reference to the copy.

Copy Monitor and Name Changing

I use the monitor part of Copy/Monitor to create a relationship between my existing levels and levels in a linked model. There is no need to use Copy because I've already got a couple levels to work with. In this scenario I'm using Revit MEP and linking an architectural model. I'd like my level name to match the architects. If you use Monitor first and then decide to make your level names match the linked levels you'll get a message like this.

Revit isn't really evaluating or comparing the names. If it was it would realize that I just changed it to match the monitored level. Instead it's just reacting to the fact that the name (my level's name in my file) is now different.

Moral of the story is, if you intend to use the same names it is best to change them before you start using monitoring. If you don't then you'll need to stop monitoring, change the name and then restore the monitoring.

Schedule Name and Header

A few years ago (Aug 08) I wrote a post that explained how to break the relationship between a schedule's name and its header. With Revit 2014 that approach is no longer necessary. I can just use the new Clear Cell button on the header text.

Now the schedule header can be something else and the name we see in the Project Browser can be something else. If you rename a schedule the header will match that name at first, or vice versa. If you click in the Header cell, click Clear Cell and the value is removed but the view name is not. Now put the name you really want in and you can alter either without affecting the other.

We can't use Project Browser organization on schedule views yet but we can control the naming a bit more easily now with this technique.

Revit MEP 2014 Space Naming Utility

This is still a separate download and installation but it is available now from the subscription center.

Why should it be part of the software?

Essential Tool - It is impractical to manage the relationship between architecture and engineering models without it. Many of the other extensions that are available (2014 versions available now too) are idiosyncratic, a small percentage of users will tend to use them. I don't think this one is. The fact that several other companies offer similar solutions as add-ons suggest that this one is at least solid enough for general use.

Development Plans - The utility has gone unchanged essentially since its inception. If it has been kept separate because they are going to do something else really wonderful and make it irrelevant, they've had years to do it. Until it really is part of the next release planning, put the one that works in.

Awareness -  Many people don't know it is available, because it is hiding at the subscription center, and therefore just suffer with room/space management. Most users I meet don't have access to the subscription site let alone know of its existence. Even when it is installed it is not in an obvious place so users who haven't been told about it either stumble on to it or don't use it until someone does point it out.

Complaint Dept. - If it remains an extension because of the fear that users will complain that they've "lost" one of their extensions...well... I sure hope that's not a reason.

I say put it on the Analyze Tab with the other Space tools, call it Space/Room Matching, like this:

Just do it!

Family Type as Type Catalog Flag

I don't see this technique used much but it is a pretty good way to let a user know that a family is supposed to be loaded with a Type Catalog. I was reminded of this by a thread at the RevitForum.org which also pointed to another thread at AUGI.

It's easy, create one "default" type in a family that uses a Type Catalog but instead of "default" use a more descriptive name like, "Family Is Not Loaded Correctly" or "This Family Uses a Type Catalog" or "You Should find the Type Catalog"... get the idea?

When you gaze over a list of families in the project browser you'll see that a family was loaded at least once without the type catalog because your "default" special name will be among the types listed there.

Reusing the Same Grid Names

A reader saw a post by Brok on the HOK BIM Solutions blog and he wrote to me about this tip. His name is Mr. Smith, yeah uh that's his name, Mr. Smith... Well anyway the tip is this. We can use the right click option to insert unicode control character when editing the grid name parameter.

If we choose one it won't print but it will make Revit think that this grid #1 is different from this other grid #1. Pretty sneaky.

Mr. Smith's name has been changed to Mr. Jones to protect Mr. Smith.

P.S. My 2014 prediction is still that Revit will still be called Revit.

Hosted or Not Hosted

The description "hosted" or "not-hosted" that we use for component families can be a bit confusing. Technically ALL families ARE hosted. They are either hosted by a level, a wall, a ceiling, a floor or a face (surface of some element). When we say not-hosted or non-hosted we generally mean that a family is not specifically associated with a certain host element like a wall, ceiling, floor or face. A chair, desk and various other families across many categories are "not-hosted" though truly they ARE hosted by a Level. They can sit on the floor or are free to be above or below it by altering their Offset parameter.

I often think that it is a disservice to spend time calling them just one or the other. It seems more explicit to use a family name that describes what host is required. A family called, "MyCoolFamily-hosted.rfa" might be better called "MyCoolFamily-Face.rfa" or "MyCoolFamily-Wall.rfa" or "MyCoolFamily-Level.rfa". We could reduce it to a single letter designation. For example the families could be named "MyCoolFamily-W.rfa" or "MyCoolFamily-L.rfa". What if the file extension allowed for this subtlety so the names are not affected by it? Extensions for families could be .RFF, .RFW, .RFC, RFF... Uh oh floor and face both are "F"...so we could use S for surface instead of face?

These different placement methods also mean we have to be careful to consider what sort of hosting nature a family has before we start placing it. We have to resort to reading the family name and/or glancing at the ribbon for any placement options to figure out what the family expects us to do. It would be great if a family could be assigned to a primary placement option. For example, light fixtures usually want to attach to a face, not the vertical face option we are offered by default. Ideally we could specify the hosting priority for each family and use the ribbon only to choose an alternative when those rarer situations happen. Maybe the ideal spot for this parameter is in the Family Category and Parameters dialog, like OmniClass and other settings..

Just writing out loud...

Illegal Parameter Names

It is fairly well understood that we can, but should not, use characters in parameter names that compete with Revit's own calculations. These include the addition (+), subtraction (-), multiplication (*) and division (/) symbols to name a few.

We also need to be careful to not use the specific function names either such IF. IF is the same as iF or If as far as Revit is concerned, though normally it is case sensitive.

When creating parameters use names that are not going to confuse Revit's own mathematical and conditional functions.

Family Naming - Don't Worry

Jose Fandos of Andekan posted again in his continuing theme of content related posts. He suggests that worrying about a family naming standard, an all-encompassing one at least, isn't our biggest priority. I agree, I've always preached consistency instead of specifics. Every firm I've met over the years has their own position about file and folder naming for every kind of software they use.

He (Jose) predicts that how we find content in and out of Revit will only get better as we move forward so the actual name of a Revit family may become less important as a means to find one. For example, the add-in Family Browser allows us to organize content logically and the name isn't really the focus (while it, a standard, does help organize the folder the content is in perhaps).

If by some chance everybody could agree on a standard strategy it wouldn't hurt us. I don't think it is a fundamental or major priority over actually having content created. If it gets made with a "bad" name, I can always rename it when it hits "my" library anyway. ;)

No Math Characters in Parameter Names

I've mentioned this before in the context of older posts but never in a dedicated post. Don't use characters that Revit respects as mathematical symbols in the parameters names you create. That means don't do things like this.

Revit will be nice and accept parameter names that include most if not all of them but when it comes time to do something more clever with the parameters you'll regret it. More clevererer? Like using the parameters in a formula, that's clever! You'll get messages like this one.

Easy to resolve, just don't use mathematical symbols in parameter names.