topic Re: project libraries in Libraries & objects

project libraries

Anonymous — Mon, 26 Jun 2006 22:20:52 GMT

Talkers,

In reading about libraries in version 10, the help file suggests combining the AC 10 library with whatever library you want to use for a project, and making a container file of the combination to use as the project library. Should one extract the AC10 library first, then combine and create the container file? Should that file be 'compressed'? I tried making a container file of my custom library (and compressed it). When I loaded it, none of the items from it that had been used in the project I was working with showed up.

TIA

Re: project libraries

TomWaltz — Tue, 27 Jun 2006 00:41:44 GMT

You read the help?

Wow, I always heard someone did, but I never thought I would actually meet one...

I doubt it makes a difference or is worth the hassle, to be honest.

Re: project libraries

James Murray — Tue, 27 Jun 2006 13:47:34 GMT

brian wrote:
In reading about libraries in version 10, the help file suggests combining the AC 10 library with whatever library you want to use for a project, and making a container file of the combination to use as the project library.

That sounds silly bordering on crazy. The best it could do would be 'no harm' (as long as you ignore the time wasted to maintain it).

Keep the AC library as is, don't mix in your office or project stuff. Your office library (if you have one of any size) can be contained if it's relatively stable, or not. In common usage, 'project library' refers to the objects that are truly custom to a particular project; no other project uses them. The project library should not be contained, because you will be adding things to it continually as you work. (It's a shame they didn't provide the ability to save objects into containers.)

I didn't have any trouble creating or loading an LCF, compressed or not. I didn't try creating an LCF with an LCF in it.

Re: project libraries

Anonymous — Tue, 27 Jun 2006 17:33:24 GMT

I respectfully disagree, but that's just me. We have always culled the AC library and combined it with our own. The reason for this is that we like to control the way our drawings look and that can only be done through diligent library management.

If we only want our people to use 2 specific toilets in our drawings, but we give them the option to use 15 different ones in the library then we have failed them - and they WILL fail us by using the "wrong" parts.

Library parts are too important to leave to the masses to make their own decisions. If we did that then time is wasted, productivity drops, drawing quality is not insured, money is lost, errors occur, etc., etc.

To answer your specific question, I expand the default AC library, cull it and merge our parts into it and then create a container file.

Re: project libraries

James Murray — Tue, 27 Jun 2006 17:50:29 GMT

Eric, if you're doing it, I better stop saying it's silly.

We control (well, encourage) proper usage with modules and favorites. I just can't imagine taking responsibility for the AC library as well as my own. If I had a larger number of users failing to take 'encouragement' I might feel differently though.

Re: project libraries

Anonymous — Wed, 28 Jun 2006 02:06:10 GMT

Better whatch 'em closely. 😉 I bet they're cheating more than you know.

Re: project libraries

Anonymous — Wed, 28 Jun 2006 17:52:47 GMT

Eric-

How do you avoid the problem of duplicate names in the library loading report? Do you change the name of every AC part that you revise into your Office Library?

Or, do you simply never load the standard AC library "out-of-the-box"?

I culled a few important parts out for our library, but I can't imagine doing it for every part we use often from the standard AC library. We use a system more in line with what James describes.

Of course, I'm working in 9 still, and things may have changed...

Thanks
Wes

Re: project libraries

Anonymous — Wed, 28 Jun 2006 18:19:41 GMT

I keep the standard AC library as-is and modify parameters through favorites mostly. I don't edit the code of the GS parts.

Is that what you were asking?

Re: project libraries

TomWaltz — Wed, 28 Jun 2006 18:26:38 GMT

I must confess, I've done the "strip out the useless objects" approach of the Archicad library, but I still keep all the custom object I've done in a separate folder (not PLA or container).

Re: project libraries

Anonymous — Thu, 29 Jun 2006 02:39:25 GMT

Eric wrote:
I keep the standard AC library as-is and modify parameters through favorites mostly. I don't edit the code of the GS parts.

Is that what you were asking?

Well, sort of. I'm not clear on whether you even load the AC library in your typical job...

So do you load the "culled" AC parts as a part of your office library, and then load the full AC library for those times when you need the grand piano part that you never bothered to cull?

I had experimented with that a couple of years ago, and always found that the duplicate library parts/duplicate names would cause confusion.

Wes

Re: project libraries

Barry Kelly — Thu, 29 Jun 2006 06:39:09 GMT

Weston wrote:
Eric wrote:
I keep the standard AC library as-is and modify parameters through favorites mostly. I don't edit the code of the GS parts.

Is that what you were asking?
Well, sort of. I'm not clear on whether you even load the AC library in your typical job...

So do you load the "culled" AC parts as a part of your office library, and then load the full AC library for those times when you need the grand piano part that you never bothered to cull?

I had experimented with that a couple of years ago, and always found that the duplicate library parts/duplicate names would cause confusion.

Wes

Our main library was based on the standard Archicad library (some years ago).
Objects we didn't need were deleted and others modified to do what we wanted.
New objects are added as we create them.

The original Archicad library is never loaded now but if we ever need any objects from it they can be loaded in on a one by one basis or better still copied into our main library for future use.
Macros that are called by objects can make it a little tricky to make sure you have all the parts, but patience and persitence pay of here.

We also create a job specific library if needed but again if we think it is something that will be usefull in other jobs we will add it to the main library.

As new versions of Archicad are released it is a matter of trawling through the new library and pulling out anything useful and either adding to our main library or replacing older style objects.
You need to be careful so that you do not affect existing jobs when replacing objects, so we have main library suitable for each release of Archicad.
The job then keeps it's own version of our main library no matter what version of Archicad it is opened in.
i.e. a job created back in version 8.1 will use the 8.1 library, even if opened in version 9.0 or 10.0

So basically with each new release of Archicad we create our own custom library based on new objects from the new library and our already proven and trusted objects.
We then modify our older objects to make use of new GDL features (such as moveable hotspots).

Barry.

Re: project libraries

Anonymous — Thu, 29 Jun 2006 13:31:27 GMT

My process is about the same as Barry's.

Whenever a new AC library is released:

1. Expand the AC library
2. Copy the AC parts I want into my library
3. Recreate the container file
4. Sync container file to all users' local drives (into the AC installation folder)

I use a completely different folder structure for our libraries (see attached) where the folders are named according to the layer hierarchy. This gives the users a hint as to where the part should go if there is no favorite defined. It also gives a hint as to where the part will be visible in the drawings and helps predict the outcome. Having things organized by CSI division is not really helpful to the people that are doing the drawings - at least not how we do it. CSI divisions are pretty much meaningless to the model as it appears on paper.

Step 4 is automated using sync software of which there are many. Check this thread for some suggestions. By default, AC looks in the location where the app is installed for libraries. If it doesn't find them there it starts looking in the path where it was last loaded. Placing the container next to the app insures it will get loaded even if paths are different for different users/computers/operating systems. Also, placing it on the local drive means it loads REALLY fast. Our library is 250 MB+ and we can open a file AND load the library in 6 seconds.

I have no duplicate parts and no duplicate names. 😉

Re: project libraries

Anonymous — Thu, 29 Jun 2006 14:33:34 GMT

Eric wrote:
I use a completely different folder structure for our libraries (see attached) where the folders are named according to the layer hierarchy. This gives the users a hint as to where the part should go if there is no favorite defined. It also gives a hint as to where the part will be visible in the drawings and helps predict the outcome. Having things organized by CSI division is not really helpful to the people that are doing the drawings - at least not how we do it. CSI divisions are pretty much meaningless to the model as it appears on paper.

I second the opinion that the default library structure is not user friendly. The find feature was a very welcome addition to the library browser. Graphisoft could easily have several versions of the same library available with alternate organizational structures. I now this would be welcome to many new users who stumble their way through finding the correct library part.

I use to limit my libraries but abandoned the approach due to the fact that it needs to be redone with each library release. In addition I would reset the default values to the pens that were appropriate for my output (pre-favorites). I have since migrated to exported groups of favorites which correspond to either specific drawings sheets (i.e. site plan, floor plan etc.) or modeling needs. It takes screen real-estate to keep a reasonably sized favorites palette open at all times but for me is a very fast and intuitive approach to achieve standardized output. Folder control within the favorites dialog box would alleviate the need to have groups of favorites saved out separately. I will cherish the day when Graphisoft responds to our needs of version migration with some type of favorites and/or library migration tool. Currently I upgrade my favorites by having both libraries loaded and use the command-option/cntrl-alt method of transferring parameters between library parts and redefining the favorites. This is a one by one process for each saved favorites of library parts but seems like it could be easily automated if Graphisoft would embrace the notion.

Re: project libraries

Frank Beister — Thu, 29 Jun 2006 14:55:31 GMT

Have you tried to select your objects from the tree "by subtype"?

I wouldn't like to get deifferent sortet libraries. It would be better to improve the subtyp-priniciple, if necessary.

OK, yes this does not work with objects older than 8. But it is something "looking ahead".

Re: project libraries

Anonymous — Thu, 29 Jun 2006 15:27:13 GMT

F. wrote:
Have you tried to select your objects from the tree "by subtype"?

I wouldn't like to get deifferent sortet libraries. It would be better to improve the subtyp-priniciple, if necessary.

I will have to play with that more. It does seem like a good approach. Can objects have multiple sub-types so they appear in more than one location?

Re: project libraries

TomWaltz — Thu, 29 Jun 2006 15:40:10 GMT

Mike wrote:
F. wrote:
Have you tried to select your objects from the tree "by subtype"?

I wouldn't like to get deifferent sortet libraries. It would be better to improve the subtyp-priniciple, if necessary.
I will have to play with that more. It does seem like a good approach. Can objects have multiple sub-types so they appear in more than one location?

No, Subtypes are unique. An object can be either a door or a window or a stair, but not combinations of the 3.

Even within tools, subtypes are unique. Object tools can be 2D symbols or some other such thing, but that's it.