new family type for Door Hardware...

[hand471037]

I would love to see a new family type for door hardware/accessories. It could be hosted by door families, so that you can place it on a door, and it would stay with that door. This would let you, say, switch from one type of panic bar on a nice blumcraft door to one of a different design and have it update in 3D w/o having to make several door families...

[christopher.zoog51272]

I would love to see a new family type for door hardware/accessories. It could be hosted by door families, so that you can place it on a door, and it would stay with that door. This would let you, say, switch from one type of panic bar on a nice blumcraft door to one of a different design and have it update in 3D w/o having to make several door families...

ooohhh Very good one, jeffery!!! :D

[bclarch]

It would also be nice if you could assemble hardware sets which could be applied to specific doors as a unit. The sets should also be tied to schedule. Some offices have separate hardware schedules and some integrate them into the door schedules. Both options should be available.

[hand471037]

We're one of those offices. We do a lot of interiors work, and as such, deal with lots of door hardware. If those items, like closers, signage, panic bars, etc. could be door-hosted and schedule-able then that would rock. :)

[Steve_Stafford]

I agree, very good idea Jeffrey!

[hand471037]

And just guess what I'm working on right now... ;)

[Nic M.]

Could this be extended to windows to?
ventilation units
sings
muntins
Glass opaque / non opaque

[Martin P]

Sorry to be the voice of disagreement :? , but I dont like the idea of trying to have options in either the model or in families, I like separate files :shock: . I think it would just add another level of complexity to things.

I agree we need families for families though - (generic models that will whatever you ask them too in other words!) but I think they ought to be generic and user named rather than having loads of different specific types, like door ironmongery, window parts, etc etc.....

sorry!! I hate it when somebody disagrees with my wishes!!! :oops:

[PeterJ]

I think Jeffrey's wish, which is a great idea (sorry Martin), can be partly accommodated at present by nesting generica in the door family, but this is bit of a kludge and probably involves using shared parameters. It would be really elegant if it were possible for a family to host another family and then to nominate whether the hosted families attributes were then scheduled in any schedule that the host appeared in.

Does that make sense?

[Vincent Valentijn]

I would love to see a new family type for door hardware/accessories. It could be hosted by door families, so that you can place it on a door, and it would stay with that door. This would let you, say, switch from one type of panic bar on a nice blumcraft door to one of a different design and have it update in 3D w/o having to make several door families...

you gotta be kidding.. I think Martin's got a point.. though I'm not against options at all. If you ever tried making stuff like door/window families with nested families.. I get scared even thinking about adding more complexity to something that's shaking allready.
I'd say
1 - family creation isn't that easy right now, let's first make that better.. it's too ambigues.
2 - nested families won't schedule so.. nice to have hinges and locks 'n stuff but.. what's the use if you can't pull out that info quick 'n easy (you'd have to manually -re-attach- parameters.. so if you go from 2 to three hinges you'd have a problem and stuff like that). So let's add 'nested families in schedules' to the wishlist first (though I've put it on the development team's formal requests list before the summer allready.. together with sweep output. Let's hope it is granted for 6)

~ for those that follow the discussions here.. this was something I needed to do for a customer-system. From your reactions I gather you think it would be great to have too huh? :lol: So that is (part of) why I need the API so bad.. if Revit won't make it - :idea: we will make it for ourselves, that's our thought :!:

way ahead by miles :twisted:

[christopher.zoog51272]

If you are doing real door schedules you probably already have added this extra level of complexity. We already have shared external parameters (yes/no) for closers and panic hardware , as well as a hardware mark and info, for our doors. This is controlled by the type pull down. Why would it be any tougher or more complex to associated a real modeled closer family to it. It would be nice to see the hardware on the doors without having to make a gazillion different families. This is the same beef I have with revit forcing us to have separate window families for each different mullion configuration.

I still think it is a good idea

[Martin P]

I think the part I dont like about the wish in particular is that the new family is used in the model and placed on a door family, then sticks to the family - and mostly that because of that it would ahve to be specifically for doors, then you get have to get one specifically for windows and so on - a more generic family that you loaded in to the family that scheduled I would like, and I must admit that being able to switch to different versions of this component parametrically would be good and better to use than different files... not sure what I was on about there :screwy: (was thinking about different versions of a building in one file wish that has been on beofre I think??)

yeuch! I hate disagreeing with somebodys wish....

[bclarch]

yeuch! I hate disagreeing with somebodys wish....

Keep the disagreement coming. As long as things don't get nasty, healthy debate forces those involved to more thoroughly examine their position in order to justify it. This can lead to a clearer understanding of the issue or even new insights that weren't initially anticipated.

Back to the issue. I think that Jeffery's suggestion has merit but it also does have the potential to make managing the model more complicated. If the idea could be implemented in a clean, easy-to-manage manner I would be in favor. Then, just as with any feature, each user can determine whether or not it fits their particular way of working.

To complicate things further, I wonder what having all of the hardware sets in a model would do to rendering times?

[hand471037]

This suggestion has more to do with the model than the schedules. We already have a huge list of shared perimeters that refer to door hardware, and this works well. What I was thinking however is twofold; first have it be where changing the door's hardware from, say, a panic hardware bar to a standard latch, within the schedule also will change that door in the model so it displays with the different hardware; and second to be able to swap and update the door hardware just like any other family.

I understand that I could make types to address this too, or nested families, or host generic families to the doors via the 'moves with nearby elements/pick host' tool. I was just thinking that it might be faster to have a family that could be hosted by the doors, that would be indentical in thought to the wall, floor, and ceiling hosted families.

[Andre Baros]

Maybe it would be easier to have a generic-hosted-family and a separate Hardware Category. This would let you create Hardware Families (important for scheduling and modeling) and designate what they are hosted by, ie doors, windows, mill work, walls, etc. plus it would expand the current functionality to allow anything to be hosted anywhere. ie lights hosted by millwork, lights hosted by doors, doors hosted by millwork, etc.