This is the latest thread, on our door library, as we have made more changes to resolve some critical errors we found. As before, i will copy and paste the notes from the v3 thread, and edit them accordingly. Here is the video on what had to change for v4:
These doors are built for R2015. Specifically, they were created in 2015R2, but i dont think it matters. Specific changes from the v3 doors (2014) to the v4 doors (2015 with corrections) are loosely shown in the attachments.
---- (Copy/pasted/edited thread follows below) ----
EDIT: First important part. The way they work is you only place the ones that say DOOR at the beginning of their name, obviously. You dont place the frames manually, or the panels, even if you want a panel-less opening. Our schedule uses a Filter for "Panel 1: Type" set to (parameter exists), which will always be present in a Beck Door. We have a VG Filter in every view in our template, and in every view template: It selects all of the Panels and Frames (non Parent Families). That way they can quickly turn off panels and frames, tag all door using Tag all not tagged, and turn the frames and panels back on.
1. They arent idiot Proof. All the frames and panels are Shared. They depend on you not trying to put a panel in as a frame, and vice versa. I dont mind this. They also depend on you knowing that a Double Egress door requires a particular frame, and that it wont work if you use the wrong one. For some of the doors that now require *special* Frames and Panels, ive moved JUST those doors' Family Type Parameters to be Type Parameters, as it makes them keep the right selection.
2. Many of the panels are actually the same file, just with a save as done, and the parameter values changed. This is intentional. We schedule the Panel Type and Frame Type, and in revit, having a Family name and a Type name the same means they schedule as "P02" only, instead of "P02: Px." So we have a lot of these families which are technically the same family, just with different variables typed. This is even more obvious now, as ive seperated out the Panels Materiality in to different families. This is because they come from different places (A HM panel and a Wood Panel dont come from the same vendor). Its one thing to have familiy types for alterint dimensions, but this way if someone decides to model in something additional that is very "this panel manufacturer" specific, we dont have to resort to hackish yeses and no's to hide them. It also makes it easier to start using the API to check for situations we dont want (Panels named with WD on the outside of a building, etc).
4. Swings are nested as well. They are now nested right in the Parent (Action Family) as they should be. I hated my old setup where i had them in the panels. This is much better.
5. There are more Parent Families, since we moved to a more Action-centric style, which is what im sure most of you did after seeing the backwards crap i had in the old doors. (v4 has a bunch more Actions (Parent Families) that we have had to build this year. Vertical Bi Folds, Revolving doors are back, Residential Closet Doors, and so on).
6. The Frames all start with F, or with NF (no frame). The Panels all start with P, or NP. There are a bunch of panels and frames starting with O, S, X, etc. These are ALL for use in the Commercial Sliders. Hard to explain the logic behind them, but they work perfectly. The Commercial Sliders have their own Door schedule, as i used different Shared Parameters. This was an intentional move, since we buy them by *Unit Size* and they are specific models, and we dont want to make people think we are ordering custom sized Sliding doors, by showing Panel Sizes.
7. There are a lot of parameters im sure most people dont care for (reference the Blog post about Throat By Host), but we use them, ergo they are there.
8. Hardware still isnt nested. Architectural QC doesnt want to show it. We might put it in for viz purposes in a future, but not right now. They open and close just for viz purposes right now as well. So there is a *plan* opening parameter, and a *model* opening parameter. The 3D Space protection follows the Plan Opening, since thats what is assumed to be on drawings and in documentation. The model opening is just a toy for images.
9. Same is true for Accessibility. Ours is being handled by seperate families, when shown. QC doesnt want it in the content and automated, so its not there now.
10. A lof of things in these *new* doors are being handled in our Project Template. Obviously in the door schedule only the Parents show up. Also the Placement Lines dont show up in Documentation Views, and the 3D Space Protection Swing Clearance ONLY shows up in Export 3D Views. So they will- of course- look silly in a lot of views if you load them in.
----- (Copy/Pasted/Edited thread ends here)
New notes: Ill include a video showing what changed from v3 to v4, as it was largely just some math mistakes, and some parameter names.
Download Link for the v4 Doors, a sample file with the doors in them, and the Door Schedule accompanying them, is here:
In addition, ill post a video of what i was planning for 2016, which is some very simple symbology to show up in Plans, if and when we got data round tripped from our Door Hardware consultant via the API. After showing the hardware video to the Principal in charge of Dallas Architecture, he said he would love to see it completely done and functional before New Years. So it will be happening in V5 this weekend, actually. Its a very simple system: 3 Filled regions in a Detail Family (didn't want to use a GA and deal with it covering stuff up at certain scales) that's nested in another Door, that's nested/shared in the Parents. (Detail family cant be shared and placed in a 3d family, and thus cant be filtered out, but a shared door with the detail family can). The 3 FR's are tied to 13 hardware options that we export in a specific spreadsheet, and send to the consultant.
This is NOT information we show in our real Door schedule. Our schedule shows a Text field for Hardware Set, and thats it. The hardware itemization happens in the specs. But, this way we can get graphics for it, which can help coordinate low voltage power, which we really care about. The video of this is here:
(Video moved from Screencast since we used up my monthly bandwidth. Holy Christ)
(Dont laugh... I like the Transformers Score)
EDIT: After Gordon messaged me about some confusion, i wanted to clarify the *Versions* a little better. This is just an "Aaron Internal" thing, no one actually knows what versions are what:
V1: These were never posted. My original Shared/Nested Doors and Frames.
V2: These are the ones i posted from Revit 2011, when i rebuilt the Beck Door Library for the first time after coming on board in 2010. That thread is here somewhere, locked.
V3: These are the 2014 variants i posted last year, that completely rebuilt the Beck Library: Swings moved to Parent families, Panels gained Materiality, and so on. This is the thread we just locked, the 25 pager.
V4: These are the doors currently posted in this thread.
V5: These are the same as the current v4 doors, but with the new parameters and new nested Hardware symbology. Thats a little confusing, since i titled the Screencast video "v3..." But thats because its an internal (for the most part) video, and that was the 3rd variant of the Hardware Symbols. So effectively.... That video is V5.3. LOL.