"D1 Metal" vs. "D1 Commercial" Doors?

[Brandon-W_DWa]

Does anyone know the difference between these default library pack objects? Same goes for door pairs. "D1 Commercial" appears to have a few additional Door Leaf options, and they are named differently than the leaf options for "D1 Metal" (Graphisoft Support confirmed this, but said the Community is the appropriate place to ask this question, even though a similar question has been asked with no real answer). I'm creating company template favorites and/or mapping values, so I'd like to know which one to use, if either is better than the other. Thanks!

Operating system used: Mac Apple Silicon 15.7.4 Sequoia

[Barry Kelly]

You would be the best person to answer that question.

Which object works best for what you want to show in your plans?

Barry.

[Ignacio Azpiazu]

It shouldn't be a game of find-the-differences. A comparison table would help a lot. 

comparison table

[Barry Kelly]

@Ignacio Azpiazu 

Sorry, but what does the original question have to do with Adobe Express?

Normally I would remove a post like this as spam.

If it wasn't for the fact you have 1000+ posts, I would have removed it.

Or is it just an example of a comparison table?

If so, how would this be done for each individual object in the libraries?

Barry.

[Ignacio Azpiazu]

[It is an example of a comparison table. I looked for examples for different types of GS subscriptions but couldn't find one immediately. I first went for different MacBook Pro models but the table was huge.]

Normally when a product line offers different products for a similar function a comparison table is provided, as opposed to just letting the user go figure it out. It could be done for similar objects. At some point GS commented each new object added to the library. 

If you add to that the similar-but-not-quite doors in the different libraries (INT, USA, etc.), the dedication required to make sense of which way to go with doors (finding the differences among the zillion multi-layered settings), or the adventure of just going with whatever without fully understanding the implications, are a bit of unnecessary pain. 

[Brandon-W_DWa]

@Barry Kelly For what we need (simple) doors and their associated frames to look like, both objects would do the trick.

However, I want to avoid unnecessary errors and headaches in the future. What if one door behaves slightly different when scheduled? What if one door could have it's frame be different materials on each side? (I wish). What if one door will eventually be retired and removed from the library entirely? These are the things we need to know when setting up a template for 30 users, and Graphisoft should be the one to communicate this (exactly to @Ignacio Azpiazu's point). My number one rule for troubleshooting is that I shouldn't make any assumptions, so I was hoping my question in the GS Community would prevent me from having to do that.

[GG_rakurs]

Also, the trouble with doors and windows is that they're flexible and sometimes not flexible enough, but you cannot know until you stub your toe into a rigid edge of an object.

I like to create windows with the same principles (frame width, depth, general geometry, materials, pens) and if an object just barely cannot do what I need, then I have to redo all the little things again. That's why I mostly use Variable Window, but even that object has limitations and there's Variable Double Window... There should be a "master" door and "master" window object which would replace most of the objects in the same folder.

I feel like almost all of these could be replaced with a "Variable Door" type object. I really hate having to redo all the settings when I realize I have to change the door type. And no, I really despise that functionality to be turned over to "favorites" because that's honestly just a crutch and a workaround.

Transom? Yes / No

Left sidelight? Yes / No

Right sidelight? Yes / No

Arch: Frame? Transom? Door Leaf?

That's just awful that we have so many different specialized objects. It should be favorites who should be specialized, in my opinion. Not the objects themselves.

[Ignacio Azpiazu]

---

@GG_rakurs wrote:

I really hate having to redo all the settings when I realize I have to change the door type. 

---

 [Independent of the whole discussion, just in case:] The settings shared between both door types will transfer if you pick up parameters (syringe extract) from the door instance you like and then inject them (syringe inject) on the new door type in the object settings library view before placing it.

inject parameters to different door type

[Lingwisyer]

While having one door cover most of the options would be convenient, it would make scheduling difficult as you would then need a new object parameter to differentiate each door type. While it is possibly to schedule by an objects parameter, 3rd party and custom objects would likely not contain this specific indentification parameter creating possible conflicts. This convenience is offset by Ignacio's point, in that injecting parameters is quick and simple and is even usable, at a baseline, between objects from different libraries.

Ling.

ps. It is not actually that hard to create your "Variable Door" since the the top level object is basically doing the options you are asking for. You would just need to make the booleans user definable as well as link the various combinations to their sub-type.

[GG_rakurs]

When I do schedules, I use IDs to differentiate doors and windows as well as other objects, so I don't have an issue with multiple doors sharing the same "master object." Not only that - schedules can show unique entries, as well as lump together some settings.