v2009 - Something wrong

[Chad Smith]

There is something seriously wrong with v2009.

I have a project which I have windows of all the same type, but showing me 2 different windows graphically. Even when each of these are selected individually they still both show the same window type.

[twiceroadsfool]

Out of curiousity- How did you load the window types in the project?

Ive seen this as well, with wall types: If i loaded a wall type inside a model group, then loaded a DIFFERENT wall type that had an INDENTICAL name, which was also in a model group, it let them both in. It was strange...

[BigBadBIM]

Here's silly question; Are those windows? Or Curtain walls?

[Chad Smith]

The windows are Window families and were made using swapable nested families. Some were in groups, others were not.
This was just the start of it. After posting the above yesterday, I found that the entire project was riddled with the same problem, but it was only confined to Windows. Took me the entire day to get this mess fixed.

[dbaldacchino]

Do you have any instance parameters that could be contributing to the differences?

[Chad Smith]

All parameters which dictate the look of the window are Type.

[dbaldacchino]

I knew you wouldn't miss that, just checking :) So the parts that look different are nested families? I haven't really used windows much in projects and definitely not to that level of complexity.

[Andre Carvalho]

OK Chad, you are not the only one who found this. I had a window family formed by shared nested families (lites). The type parameter switched the lite families, so I could have one main window family and change its lite appearance by changing its type. It worked fine when editing the family but when loaded into the project I had the same problem as you: two windows of the same family, but different types showing as if they were the same type. However, selecting the window in elevation or in a 3D view and changing anything that would move the window (like the sill height for instance) - or even using the Move command to move the window a little, would make the right type shows. Note that the types were already set. I just moved the window... I couldn't figure that out and had to insert the windows with different types and later go through each elevation to "move" a little and make them show the way they were supposed to.

Andre Carvalho

[dbaldacchino]

This is surely a bug and I'll keep an eye out for it. I wouldn't say that the technique of moving a window to force an update is in line with "revise instantly" ;)

[Chad Smith]

Andre is correct. I had a very similar issue listed here (http://forums.augi.com/showthread.php?t=84096)and here (http://forums.augi.com/showthread.php?t=84185), in which the graphics of the nested component were correct, but the sizing and location were not. It wasn't until I changed another parameter, that the components displayed correctly.
In the issue in this thread, the components are just wrong, as though there has been mis-linking in the Revit database.

I think after this ordeal, I can fairly safely say to stay clear of shared nested families as there is comething seriously wrong with them. Autodesk should just disable this check parameter until it is fixed.

I hate to say it again, along with others who say it too, but Revit needs a complete year long release dedicated to just bug fixes, because the list of workarounds for bugs is ever growing.

[dbaldacchino]

oh wow, I thought that the problem might be with nested families in the family. In fact I was about to suggest to try sharing them so the family will look and load those within a project. What happens if you make them not shared and load them directly in the familly?

[D_Driver]

just chiming in,
yes there is some weird thing going on especially with nested families being driven by a family types parameter.. will track it for reproducability later today or next week. I have seen this every also

[twiceroadsfool]

Ive had some serious issues with editing Nested and Shared families, and it crashing 2009, but ive heard its a known issue, and the workaround is to edit them in another session of Revit, then reload them. BUT, not sharing them families simply isnt an option. I use a ton of nested and shared families...

[Chad Smith]

What happens if you make them not shared and load them directly in the familly?
This is what I ended up doing. My window families combined file size tripeled after doing so. Shared families are so efficient.

[D_Driver]

Chad, could you post a file with just a wall and a window (parent)? I was testing this out and saw something that made me go Hmmmm...

[davidcobi]

I've had a similar problem in 2008. I have windows with nested detail components. If I group the window everything is fine, but as soon as I link the group my detail component gets relocated in elevation. If I go into the linked project and change a type parameter and then save, then reload the linked file the problem resolves itself. If I bind the file back into the group the problem resolves itself.

It's like some nested detail components flip along the reference plane they are locked to.

[rganter.97143]

Same problem here, we just did a lot of work setting up our own doors with nested shared panel families, only to notice that the nested panel sizes don't always update with the door sizes although the parameters are properly linked. Moving a door will sometimes update the door, sometimes not. I second the idea that the next Revit release should be a "bug fix release".