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!

[Lingwisyer]

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.

[Stefan Videnov]

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

[Barry Kelly]

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.

[Stefan Videnov]

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.

[Lingwisyer]

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

https://community.graphisoft.com/t5/Graphisoft-Insights/Tip-of-the-Month-October-2023-Mastering-Attr...

[Stefan Videnov]

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. 

[runxel]

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 :

[Barry Kelly]

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.

[Stefan Videnov]

/deleted duplicate comment/