Attributes acting weird

[Stefan Videnov]

Hi everyone,

INFO:

In Teamwork we have a complex Main Model file where 5 different models are united. Since we transfered from archicad 27 to 29 we observe a mishap of the Surfaces in our Windows. We decided to continue working with the old 27 libraries. We are not using an Attributes file, because of the added complexity. We are following a strict naming convention and we didn't have many problems prior to moving the project to 29. The involved surfaces have been set since the beginning of the project and we started encountering the problems only recently. Nothing has been reindexed or renamed. We always reserve-all and sync attributes when updating hotlinks. Because of the complexity we decided to sync attributes by name and not pay attention to the indexes. 

I believe what we are experiencing is a bug, but I might be missing something

THE PROBLEM:

In our Source file the window uses a surface named _L2.1 gevel kozijn for all windows components: Frame, Turning part en Surface Sill
Screenshots Source model surfaces:

However in our Main Model the surface suddenly is switched to _Surrounding green buffer, but only the Frame and the rotating part . The Surface of the Sill has remained the same _L2.1 gevel kozijn

Screenshots Host model ( Main Model) surfaces :

You can see that the window has the grass surface^

The issue comes from the attribute indexes. 

Index of the  _L2.1 gevel kozijn surface is 657 in the source:

In the target file _surrounding green buffer has the same index.

Obviously, In MainModel Archicad has started pulling the index of the Surface instead of the Name, but I do not think that is normal behavior.
It doesn't explain why the Surface of the SILL has remained the same.

Can anyone explain this behavior?

I fixed the issue with these mismatching windows by reindexing all the involved attributes in both files, but yesterday we got the same mismatch in another building. 

Thank you!

[Stefan Videnov]

I did send the files to local support and they escalated to graphisoft. 
Graphisoft didn't give me a satisfying explanation so far, i'm following up on that

we're observing this effect so far ONLY with Windows and ONLY with Surfaces and ONLY in 29.
No other mishap of attributes has been observed, regardless of the fact that most of our indexes are not matching between source and host and.

Thank you all guys for trying to help 😃

[Stefan Videnov]

Runxel, thanks for replying 

I'm pretty sure you are also wrong, unless I literally can't read. Please read the excerpt from the graahisoft guide I posted in my previous comment. 
I am familiar with Scott's video. Even further - the video explains what happens when we sync attributes, not what happens when we update hotlinks. 

Additionally here's a reply from graphisoft's support I got through my KeyMemberEdition help:

Even if you aren't wrong and Archicad looks for Indexes, this doesn't explain these 2 things:
- Why no issues in 27?
- Why no issues with the Sill? Why does the Window Sill still look for Name?

[runxel]

Well, it depends (sadly). Are you using .mod or full fledged .pln as your hotlinks?

For .pln you are right, that when an attribute got renamed in the main file a new attribute will be created on load time with the (old) name from the incoming hotlink and inserted at the lowest, freely available index. All references in the hotlink will be rewritten on-the-fly to use exactly that new attribute.

For mods this doesn't happen (there is just not any information in that file besides the index to begin with).

That's obviously very confusing and I also don't think that's good UX – hopefully we will see some changes being implemented that allows for indices to remain stable and the ground truth. (@James B)

Why some surfaces are affected and others aren't in the same element? I don't know. Maybe you indeed discovered a glitch there.

[Stefan Videnov]

I would really love this to be true, because it would explain certain things but it doesn't explain:
- Why would the problem appear in 29 and not in 27?
- Why am I seeing this only in window elements?
- Why only Surfaces?
- Why are only SOME surfaces in the windows affected?

Please, believe me when I say that we were using the current workflow for more than a year without issues. Most of our attributes do not have matching indexes between Source and Host. I also don't think you are right, because freshly imported mods DO bring  the full attributes in them, including textures and names..

Our workflow is to export .mod files through the publisher which then get refreshed in the Main FIle.

[runxel]

---

  schrieb:@Stefan Videnov

 I don't think you are right, because freshly imported mods DO bring  the full attributes in them, including textures and names

Well, I tested it just then before I wrote, so.... 🤷🏻

But I did not use the Publisher – and yes, if you use the Publisher, everything comes back again. I just used the option to save the current selection as mod and there no attribute came with it. I should have been more precise.

I think a mod saved from the Publisher is actually a full .pln with just a different file extension, adding to the confusion. The file with the same content, but saved with "save from current selection" is also much smaller.

[Stefan Videnov]

This is so frustrating, that not only that I don't want to deal with attributes anymore, but I want to actively forget everything I know about them.

It is safe to assume that this is a bug where some specific windows request the ID for some of their surface instead of the Name. This might be related to 29. 

I'll start reindexing...

[Ahmed_K]

Hi @Stefan Videnov  ,

I ran into exactly this kind of index-collision pain, so I built a small standalone tool to see how attributes are organised across several files — and to fix the mismatches cleanly.

How it works

1. Export the attribute XMLs from each file (Options → Element Attributes → Attribute Manager → Export), then load them into the tool (drag & drop, runs in any browser, no install).
2. It compares the files line by line and flags every index as:
   • Unified — same name at the same index everywhere
   • Collision — different names sharing the same index between files (your case: _L2.1 gevel kozijn ↔ _Surrounding green buffer both at 657)
   • Displaced — same name sitting at different indexes
   • Partial — an attribute missing in some files
3. For each conflict you pick an action: keep, fill the gaps, consolidate to a shared free index (600+), realign onto an existing free index, or mark for deletion.

Then you export the corrected XMLs back

• Each file is exported with the old conflicting attribute renamed using a 0001 A supprimer / remplacer suffix.
• In Archicad's Attribute Manager you append by index, then use Delete & Replace to swap the old attribute for the new one — so your placed elements keep their settings instead of silently picking up another surface.

For your exact situation you'd immediately see that index 657 holds two different surfaces, and you'd move _L2.1 gevel kozijn to a free slot so both files finally agree — which is precisely the "reindexing" you said you're starting to do, but done in a controlled, side-by-side way.

Happy to share more details or walk through the workflow if it helps.

A special BIG THANK to @scottjm  for his great videos on this topic, they helped me a lot, 

[Stefan Videnov]

I came to the conclusion that It's a bug where Archicad 27 Windows do not act as they should in Archicad 29.
Windows get very confused about their textures. Sometimes the textures go missing, sometimes they don't get transferred properly through hotlinks.

Basically do not try to finish monolith library projects in newer versions with the old libraries.