Where do duplicate attributes (1) come from?

[wkrt-hs]

In most of our projects we have duplicates of attributes with an appended number like (1).
In some projects, they even extend until numbers like 20 or so. Most of those projects are teamwork projects and use hotlinks.
No matter how we try to reproduce the creation of those duplicates, it doesn't happen, but in our everyday workflows at some point they seem to be generated automatically.

Do you have any hints what actions could cause such a behaviour?
I'm sure they are not created by manually duplicating attributes in the attribute manager.

[Xandros]

This points to attributes having the same ID, but different settings like name or content - e.g. you have a composite named A-Composite with the ID 3 in both your main file and your hotlink modules, but they differ in the layer thickness. So each time you click on update on a hotlink file it will create a duplicate attribute for those attributes. This also happens in layers for example, having the same ID but someone added a single space to this layer in just one file instead of all associated files.

It's a longstanding wish to be able to intuitevly synchronize attributes - and GS already put it on the roadmap:
https://graphisoft.com/product-roadmap/easier-attribute-management-with-intuitive-folder-and-list-vi...

https://graphisoft.com/product-roadmap/centralized-attribute-management

But for now you'll need to manage clean attributes via attribute manager.

I'd recommend creating / editing attributes exclusively in your main file (since this is the place, where its all coming together) and export it from there via attribute manager:

https://help.graphisoft.com/AC/26/INT/index.htm#t=_AC26_Help%2F025-1_AttributeManager%2F025-1_Attrib...

two more hints after you managed to clean your files:
1. Always export and import by Index

2. Never include all associated attributes - since they are also creating duplicates. In my experience this ticked box is just necessary when ex-/importing layer combinations, but that's not the issue here.

[threeA]

hi,

can it be that you are using elements from other project files?

then these will probably be attributes with the same name that vary slightly and are created when you copy them in. these "new" attributes are then created with higher index numbers.

i hope it will help

[wkrt-hs]

In general I am familiar with Archicads attributes behaviour, also watched the recent video by @scottjm: ARCHINTENSIVE 2023 - The Dark Side of Attribute Chaos | Skewed.

But still I'm not able to reproduce the somehow automatic creation of duplicates.
Following the steps described by @Xandros doesn't lead to duplicates, my host file will just keep using the host attributes by name without applying the changes made to the hotlink attributes - as expected.

The closest I can get is when appending attributes with same name in the attribute manager, but that's nothing that is happening in the background and could lead to duplicates up until (20).

[Barry Kelly]

Attribute management needs a big overhaul - hopefully sooner rather than later.

Some attributes have associated attributes.

i.e. surfaces have fills, and building materials have surfaces and fills.

I have found that you may successfully create a new building material - overwriting by index number.

The building material may well be a new index number itself, so all works well.

But if the 'include associated attributes' option is ticked, then the associated attributes will also be overwritten as well.

It should know the associated attributes already exist with the same index numbers, and ignore them.

But I suspect that because it has created a new building material, it also creates new associated attributes.

Because the name and index numbers already exist, it creates new ones and appends the name with '(1)'.

I may be wrong about that as I haven't paid super close attention - I just delete and replace all duplicate attributes with the proper one.

Barry.

[scottjm]

Are you working in a teamwork file?  I’m pretty sure the (1) is due to importing an attribute by index (and maybe copy paste too) but the associated attributes not being reserved too so it’s forced to append.  

[Erwin Edel]

We moved to having a 'module workspace' within our PLN, from where we select or marquee the area around the 'modules' to overwrite the module everytime we need to make changes. So we never edit the .MOD files directly in a separate AC session. This means we have only one PLN file and no issues with attribute management for our highrise projects.

Projects with multiple family homes (each having their own PLN) still require rigorous management and I typically keep all the files open and as soon as I add a new attribute or change an existing attribute in any one of them, I save that file and use the attribute manager in the other files to bring it in.

This is slow going sometimes, but the headache that will come when you accidentally have different attributes with the same internal ID number is worse.

[wkrt-hs]

Yes, I observed this behaviour in teamwork projects (but can't say if it's limited to teamwork, because we have few big non-teamwork projects).

Forced appending because of not having attributes reserved seemed like a hot trace, but I wasn't able to reproduce that either.
The "<< By Index" button is disabled when the corresponding attributes aren't reserved. So maybe somebody clicked on "<< Append" instead, but this shouldn't be something that happend 20+ times.
Also, as stated in your video on attributes @scottjm, copy & paste is neither adding new attributes nor overwriting existing ones if same name & index already exists.