Project data & BIM
About BIM-based management of attributes, schedules, templates, favorites, hotlinks, projects in general, quality assurance, etc.

New colour table <-> old library parts?

Anonymous
Not applicable
The Hun version of AC10 arrived in summer to our office.
Before AC 10 I always tried to get people in the office use the newest version of AC but now after trying it for two weeks I can only suggest to stay at 9.0. (While some workmates are still using 7.0...)
I will not go into details why I hate version 10 but I can tell why I decided to stay at 9.

From 6.5-9 the colour table was always the same, eg. I'm used to that pen 96 is the default grey hatch pan, 91 is the white for background of objects etc...
And now what shall I do with the office library and old librarys wich have hundreds of objects with default background pen 91?
- Shall I change the 2D presentation's color every time before placing an object from the old library for not having the background purple?
- Or shall I open, change the default bg. colour pen and resave hundreds of objects?
- Or shall I switch back the AC 9 color table and load Library 9 forever? (If I wanted to use the new 10 library all it's backgroud pens are red...)
The new colour table causes compatibility problems at loading old librarys for older projects, eg. there is a large hospital in Bp, we have been designing reconstructions and new buildings for more than 10 years for it. Of course it is important to merge and modify the old plans at a new project because the old and new buildings are alway connected and some parts of the old buildings need to be changed also. The first plans began with library 5.0, actually I need to load at least 3 different librarys for all the buildings: 5.0, 6.5, 7.0 and of course for my new building I want to use the newest library the 10. I'm used to having problems with duplicate library parts, but now with the new colour table it is impossible work!!!
Is there a smart freeware program or API which can change the default pen colours in library objects automatically? This is Graphisoft's bug... they should offer a solution.
Zoltán
13 REPLIES 13
Anonymous
Not applicable
Why don't you use your current (AC9) pen settings in AC10? Any project started in 9 should retain it's original settings. You can also use Attribute Manager to copy pen settings between files.

Most firms have long established pen standards which they have no intention of changing. I agree that that there is no good reason for Graphisoft to change the defaults (and plenty of reasons not to) but there should also be no reason that anyone needs to convert to the new defaults.

Perhaps I don't understand the problem. Is your new AC10 library set to the new default pens? If so this is a serious issue and GS should provide a version of the library that does not require you to change your pens. I am a strong proponent of setting and maintaining office standards and if GS is making this difficult then I'm very much on your side. In any case you should not have to change your existing libraries standards unless you decide that it is worthwhile.

There is a much larger issue of attributes management that needs to be sorted out and I agree that GS should not be tinkering around the edges while the larger issues remain unresolved.
Thomas Holm
Booster
I think Zoltan has a very valid concern. I've also found different default color table assumptions in the later issues of the default libraries.

(I mean: Standard thinnest black pen, standard next-thinnest black pen, standard grey, standard medium-thick black, standard white, standard fill foreeground and background color, etc)

And I have found no way to batch change the library part colors to match our standard color table. Which means we have to go though and open every library part manually to adapt them to our standard, every time a new library is released. No small work. Therefore we often skip that and do it in project work instead. But that's a lot of extra work in each project.

We would like a utility with which you could batch-change any folder full with library parts to the current standard. And I'd like GS to inform us of the delivered standard pen table of every library. I don't want to have different pen tables for library parts.
AC4.1-AC26SWE; MacOS13.5.1; MP5,1+MBP16,1
Anonymous
Not applicable
I guess we here in the states have been saved from this nightmare. The default pens in the libraries are still much the same but seem to have been adjusted in some place to match my standards. I understand the seriousness of your problem since the older libraries here were not so conforming and were more of a pain (though not as bad as the situation you seem to find yourselves in).

A reasonable temporary fix would be for GS to produce such a batch tool as you describe, but I suspect that it would non-trivial to produce. It might be simpler for them to redo a version of the library using the old pens. Perhaps it should be the task for whoever decided it was a good idea to change them in the first place

In the long run (version 11???) it would be much better for pens to be defined as globally named parameters (these could still be mapped to the existing pen numbers). This way the user/manager can set all the standard pens by their application/function and pen setting will only be of concern in exceptional cases. I will (re)post this to the wish list later today if I can get the chance.
Thomas Holm
Booster
Matthew wrote:
It might be simpler for them to redo a version of the library using the old pens.
Well, this isn't a good solution either - many of the "new" options simply weren't there a few issues/years back.
Matthew wrote:
In the long run (version 11???) it would be much better for pens to be defined as globally named parameters (these could still be mapped to the existing pen numbers). This way the user/manager can set all the standard pens by their application/function and pen setting will only be of concern in exceptional cases.
Well, maybe. But to make that work to solve the issue about library part's default settings, that requires that we first agree on what the globally named parameters are and how they apply. Not a trivial task either. While I think my standard pen table is the best in the world, my old age and long experience has taught me that only a few others agree....

I think what we should wish for in the first place is something I'd like to call a "library pen translation table". This should be used globally within a library. With each library, Graphisoft should declare what pen table is used in the library, and how it is used, that is explain what standard colors/pens are normally used to what purpose. They should also, beside the library's pen table, also supply this translation table, one for each library.

As a user, you should be able fill in this table to map the pens of your current project/drawing/whatever pen set to the library parts. AC11(?) would then draw the library parts on screen and publish and export using this translation table. You would never see it after it's originally set up - everything would look as if it was using your project pen table the way you intended. I think this is the only way to accommodate all the needed flexibilty without having to customize library parts.

It should also be a good way to handle older libraries without making them incompatible. AC11(?) would understand and use such tables with all libraries, new and old, without changes to the libraries, and older versions would still work as today, and even be able to use newer library parts (saved "back").

Perhaps somebody with a better organized brain than mine 😉 is able to formulate this wish in way that doesn't get drowned in the current flood of meaningless polls!
AC4.1-AC26SWE; MacOS13.5.1; MP5,1+MBP16,1
Karl Ottenstein
Moderator
Zoltán,

Graphisoft was made aware of this issue during alpha and beta testing and did not feel it was as dire a problem as most of us felt.

We US testers all but demanded that old and new library parts be pen-compatible, and so the US pen table maintains the legacy pens of 1-10, 91, and the gray ramp at 92 onwards so we can use old parts and AC10 parts with similar results.

(GS was moving white from 91 to 11 or so, as I recall, which may be how it is in the international pen table and which really raised our ire as far as existing library parts ... and even those purchased at Objects Online...nothing would have displayed correctly.)

If indeed the international pen set has been changed and the intenational library parts use the new pens, unlike the US library which uses the legacy pens (1-10, 91, etc.) then we really have a mess if any of use choose to share library parts or modules.

During testing/development of 10, GS told us that they would work on a translator that would remap the pens of old library parts to a new pen mapping. Unlike Thomas' idea, this would be a static mapping, converting one library to a new one. Thomas' dynamic mapping is a great idea, too. I have heard nothing about this translator (or anything else) since the testing days.

Regards,
Karl
One of the forum moderators
AC 27 USA and earlier   •   macOS Ventura 13.6.6, MacBook Pro M2 Max 12CPU/30GPU cores, 32GB
Anonymous
Not applicable
Thomas wrote:
Matthew wrote:
It might be simpler for them to redo a version of the library using the old pens.
Well, this isn't a good solution either - many of the "new" options simply weren't there a few issues/years back.
I was suggesting this only as a stop gap measure such as we have here in the US library.
Thomas wrote:
Matthew wrote:
In the long run (version 11???) it would be much better for pens to be defined as globally named parameters...
Well, maybe. But to make that work to solve the issue about library part's default settings, that requires that we first agree on what the globally named parameters...
I think my use of the term "global parameters" has (understandably) led you and Karl to misunderstand my meaning. The globals defined by GS would only be a starting point which could be expanded with user defined global pen assignments. This would of course require that starting set to be reasonably complete and sensible for most purposes (this shouldn't be too much to expect but... )

These globals would form the foundation for a dynamic pen setting table which would be a prerequisite for the mappings that you are talking about. This is exactly why I have been going on about this for years. I thought I had posted a wish similar to this a long time ago but I can't find it now. Perhaps it was in the VDT.
Thomas Holm
Booster
Matthew,

I think your idea is very good in principle. However, i'm too scarred by incompatiblility issues, also towards other "legacy" applications (read Autocad) to think it's a good idea.

I like my translator idea because it's simple and yet solves the issue, also the one above. It could be implemented as a simple tab- or comma delimited text file with two columns. No XML needed, even. And no changes to library parts, just to how the application reads them.

Now I've even thought through how to implement it with several libraries and folder hierarchies.
Like this: AC11? reads only the first translation table (lets call it a .ptt file, lacking better) of this kind that it encounters in a folder containing library items. (it will be the users task to oversee that only one exists) That table.ptt will apply to the parts in that particular folder. If no such file is found, AC11? goes up and searches the next level in the hierarchy and so on until a table is found. This way, you can have one pen translation table that applies to all libraries, or if you like all the way down to an individual table for a single library part in it's own folder (probably slooow). If no table is found, it will work just like today.

(And please note that I'm not saying Graphisoft has screwed up the INT and European pen tables. I'm just saying they are different from what I want, and have changed sometimes. As a simplistic person, I some years ago decided to always use the standard Autocad pen table [no 1 is red 0.25mm, no 7 is white/black 0.5mm etc etc]. This is because it resolves [with KEEP INDEX NUMBER translators] most of the problematic translation issues in cooperation with consultants).
AC4.1-AC26SWE; MacOS13.5.1; MP5,1+MBP16,1
Anonymous
Not applicable
Thomas,

I guess I didn't read your previous post carefully enough. I see your point about having a simple translation table within the library (or perhaps the ability to assign one in the Library Manager).

I still think that there is a larger issue with pens and attributes management in general, but that does seem to go beyond the issue at hand of library compatibility.
Andy Thomson
Advisor
Has anyone used Cadimage's Object tools to globally rewrite library parts pens? I thought it was supposed to do that, but maybe it just changes the 'outermost' pens, ie. not the 'object' spens and materials' but the ones you specify in the larger object attributes panel...

Personally, I would like to find a way to do batch rewrites of GDL objects.(an omni outliner task?)

As for pens 91, etc. I usually make pen 91 white in any case, and preserve the fill pens for Empty and Air Space while rewriting every other fill and adding all of my own custom fills - so it preserves working with legacy parts, plus all my weird custom objects collected over the years.

I am beginning to think taking mattters into my own hands (batch rewriting) is my best option for maintaining a stadard across numerous releases and versions of ArchiCad - but preserving some legacy pen and fill position doesn't seem too painful to me. BTW, Thomas, I do believe your pen table is the best in the world. Well, second to mine anyhow 😉
Andy Thomson, M.Arch, OAA, MRAIC
Director
Thomson Architecture, Inc.
Instructor/Lecturer, Toronto Metropolitan University Faculty of Engineering & Architectural Science
AC26/iMacPro/MPB Silicon M2Pro