topic Re: Attributes acting weird in Project data & BIM

Attributes acting weird

Stefan Videnov — Wed, 19 Aug 2026 08:39:05 GMT

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!

Re: Attributes acting weird

Lingwisyer — Wed, 19 Aug 2026 01:18:17 GMT

Objects do not care about the attribute name as it is stored by it's Index. The name is only relevant if the index is not found. There is a post around here somewhere which has a flow chart for this. Odd that only some parts of your windows change... Regarding a change in behavour, I think in AC28 or 29, they changed how attributes from Hotlinks that were missing were brought into the host file. I have not confirmed this, but it would explain a few odd cases I have run into.

Ling.

Re: Attributes acting weird

Stefan Videnov — Wed, 19 Aug 2026 07:11:37 GMT

Hi,
Are you sure that Objects (incl. Windows/Doors) must act differently? Archicad is supposed to use an attribute with an existing name.

Re: Attributes acting weird

Barry Kelly — Wed, 19 Aug 2026 07:48:47 GMT

I will back Ling up and say that Archicad has always used the attribute index number.

We as users only get to see the name, which can be confusing.

It is important if you are copying & pasting between files or hotlinking files, that the attribute index numbers are consistent between all of the files.

Check in the source file and the main model that your surface _L2.1 gevel kozijn does indeed have the same attribute number.

If they do, that is good but your problem will need further investigating.

Maybe the source and main files are using different libraries?

If they don't match then that is probably the issue.

But then the question is why it the sill using the same surface and the frame is not - but the sill and frame are supposed to be the same as each other?

That brings me back to library issues.

Barry.

Re: Attributes acting weird

Stefan Videnov — Wed, 19 Aug 2026 08:24:42 GMT

Hi Barry, thanks for answering!

I believe what you are saying is not true,
Here's an excerpt from the Graphisoft Help Page: https://help.graphisoft.com/AC/28/INT/_AC28_Help/080_Collaboration/080_Collaboration-57.htm

We never had synced up Indexes, we were always relying on keeping the names the same.
I just checked the files we had in v27. The mismatch in the indexes is also observed there, but refreshing the modules never put the matching index Surface instead of the matching Name surface.

=> It is possible that there are mistakes in the library objects, but we do use the same libraries as in 27.

Re: Attributes acting weird

Lingwisyer — Wed, 19 Aug 2026 08:31:19 GMT

Now that we have brought up Modules, are you Hotlinking mod or pln files?

Scotts presentation about attributes and related tip of the month:

https://community.graphisoft.com/t5/General-discussions/Build-Together-Centralised-Attribute-Presentation/m-p/575820

https://community.graphisoft.com/t5/Graphisoft-Insights/Tip-of-the-Month-October-2023-Mastering-Attribute-management/ba-p/576973

Re: Attributes acting weird

Stefan Videnov — Wed, 19 Aug 2026 08:36:33 GMT

I'm familiar with Scott's awesome video, we're trying to follow the practices whenever possible. In theory I do understand how attributes should behave.

We're using .mod files.

Re: Attributes acting weird

runxel — Wed, 19 Aug 2026 08:36:34 GMT

I think you have to separate the issues here:

Ling and Barry are not wrong here at all. Everything in Archicad is based on IDs. All elements only hold a number as a reference or pointer to the actual attribute. (There is a technical reason for that too, string evaluations are just prohibitively expensive computational wise. Integers rule!)

So that part will not change! If your window references the material at index 567, that's it; it's fixed, this number is literally the only thing that is saved with this element. It will not care about names.

The other part of the issue is the greater topic of attribute handling, especially when hotlinks are involved.

Just watch this important video by the great @scottjm :

Re: Attributes acting weird

Barry Kelly — Wed, 19 Aug 2026 08:37:03 GMT

Thanks for pointing that out.

Seems that hotlinks are treated a little differently to simple copy & paste.

I just checked the 29 help and it says the same.

I rarely use hotlinks myself and when I do they are all files from the same template with identical attributes.

Except for user created attribute that would have a unique number and very unlikely to have the same name as an existing attribute.

If you say this is only happening since version 29 then maybe there is a bug.

Teamwork can also play havoc from what I have read in other posts.

But the question still is, if your frame and sill are the same materials, why is only one of them changing?

It is very hard to say without have all of the files at hand.

I would say this is something to get your local support involved with.

Barry.

Re: Attributes acting weird

Stefan Videnov — Wed, 19 Aug 2026 09:04:42 GMT

/deleted duplicate comment/

Re: Attributes acting weird

Stefan Videnov — Wed, 19 Aug 2026 08:56:26 GMT

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 😃

Re: Attributes acting weird

Stefan Videnov — Wed, 19 Aug 2026 09:04:20 GMT

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?

Re: Attributes acting weird

runxel — Wed, 19 Aug 2026 10:07:02 GMT

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.

Re: Attributes acting weird

Stefan Videnov — Wed, 19 Aug 2026 11:16:46 GMT

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.

Re: Attributes acting weird

runxel — Wed, 19 Aug 2026 14:18:44 GMT

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.

Re: Attributes acting weird

Stefan Videnov — Wed, 19 Aug 2026 15:11:37 GMT

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...

Re: Attributes acting weird

Ahmed_K — Wed, 19 Aug 2026 16:33:17 GMT

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

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).
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
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,

Re: Attributes acting weird

Stefan Videnov — Fri, 21 Aug 2026 08:05:00 GMT

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.