attribute manager and materials hatchings appends

[Anonymous]

When I append my materials list from another file's materials (in this case the CStone materials), the Textures append but the Vectorial Hatchings do not.

All of the CStone attributes that were appended had their Hatchings set to Brick; i had to go to each individually in the OPTIONS/ELEMENT ATTRIBUTES/MATERIALS to set the Hatching correctly.

Why in the world would GS not allow the Hatching to be carried over when appending a material list?

[Laura Yanoviak]

Did you also overwrite the Fills from the source file? My guess is the ID of the desired Fill in your source file differs from the ID of the Fill in the appended file.

[Anonymous]

I checked back at the Source File >> Material Settings > Vectorial Hatching section are displaying the appropriate pattern. All of the CStone materials appended into the target file with Common Brick hatching pattern.

I redid the Append for the CStone materials and this time they came across with the correct hatchings.

Two [sic] possible things going on here:
1) the computer did it
2) brain fart
3) electrical short between the keyboard and the floorboard

[Link]

4) ArchiCAD did it, because it associates attributes by ID, rather than by name.

If you Append your fills, or even if you Merge these assigned to 3D elements, ArchiCAD will bring in all the attributes, but it runs deeper than that.

Each attribute has an ID. If the ID of the hatch (fill) is already taken in the host file, ArchiCAD will simply assign the merged fills the lowest available IDs. However the material still assigns the hatch by ID, so they no longer correspond.

As Laura said, if you Overwrite the fills, the ID will be overwritten and the link between material and hatch will remain. The downside is that the existing fills will be overwritten too and lost.

So you need to exercise caution. Analyze both your files first, and alter one of them prior to merging them.

Cheers,
Link.

[Anonymous]

I need to append more textures and patterns to another file; I have looked more closely at the attributes of the target and the source files and I do indeed need to alter one of them before appending as they would duplicate a material based on their ID #.

I am finding that I cannot alter the material ID's (assuming that is the sequential number with "#" at the header). I have tried as many ways as I can come up with to edit the ID# so that it is sequential following the last ID of the target file that I want to append to, but that field is un-editable.

Can you elaborate on altering the ID# of the source file; or is that the best approach?

[Laura Yanoviak]

46cruisair wrote:
Can you elaborate on altering the ID# of the source file; or is that the best approach?

OK... are you ready for some fun?

Open the Attribute Manager, select the Attribute who's ID you want to change and select 'Append' to move a copy to the right-hand panel. Now, select the Attribute on the right and hit 'Duplicate' until you reach the desired ID number (I usually make about 10 copies, and then select those 10 and make 10 more, and then select those 20 and make 40 more, etc. if it's a high number). Each duplicate will be renamed with an additive suffix (2), (3), .... (?). You can either save these duplicates as an .aat file, to import into the necessary file, or select the Attribute with the desired ID, and 'Overwrite' to the list on the left. Rename the original Attribute (assuming it may be in use), and rename the duplicate Attribute with the original's name. Done.

[Anonymous]

Thanks for describing the methodology > my reaction is "you've got to be kidding."

GS needs to fix that operation. What do you suppose the problem is with at least allowing the edit of the ID# field and putting in a routine to check for a identical ID# and alerting of the duplicate? Geesh!

[Laura Yanoviak]

46cruisair wrote:
Thanks for describing the methodology > my reaction is "you've got to be kidding."

It's really not that bad, once you've done it a couple of hundred times...

[Anonymous]

When I need to control attribute IDs I use an aat file I created called "hundreds of dummies" (attached) No, the file name was not intended to be a comment on the creators of the attribute systems in AC - I'm sure there weren't hundreds of them.

My technique is not much different from Laura's (there aren't a lot of options) but this file does help with the process. I also use it to force IDs to arbitrarily high numbers to ensure that my custom attributes don't conflict with standard ones.

[Anonymous]

Matthew wrote:
- I'm sure there weren't hundreds of them.

then maybe we can call it "a few special dummies"

- just for fun.