Why do they call it the Attribute Manager?

[Anonymous]

Seriously, why? You can't do any serious 'management' of anything with it.

In the near decade that people have been asking for a fix for, or better implementation of, the attribute manager, it appears that nothing has happened.

Has anyone got any idea how I might get editable access to the IDs of attributes? As far as I'm aware, the only way that I can change the IDs of attributes is to start with a clean file and bring them in one by one in the order I want them and then propogate that attribute file out across the whole project, and THEN reassign the attributes of every single element - a primitive and ineffective solution for any project, let alone one that has been running in documentation for over a year, using over 20 individual files, various hotlinks, and countless critical fills, surfaces, complex profiles, and composites... I'm at my wit's end with this, it has been a long drawn out battle to maintain consistent attributes across the project but, alas, it has finally beaten me and I just can't see a way out of this without starting the whole thing from scratch. I'm sure you can all relate to the feeling such a thought invokes....

Are there any third party tools, or something, I don't know what, that can get into the demented mind of archicad and edit these attribute IDs?

[Anonymous]

what's the difference, from an attribute perspective, between hotlinking a .pln versus a .mod?

[Barry Kelly]

Nick00R wrote:
Seriously, why? You can't do any serious 'management' of anything with it.

Really?
I use it nearly every day to maintain consistency between my old jobs and my latest template

Nick00R wrote:
In the near decade that people have been asking for a fix for, or better implementation of, the attribute manager, it appears that nothing has happened.

In 17 we now have the 'Delete & Replace' feature for most attributes which is brilliant if you want to kill something of and swap it for something else.

Yes I am sure it can be improved especially when it comes to multiple files (hotlinks) - a central attribute file loaded like we do for our libraries is a much wished for request.

The trick with multiple files is not to go around willy-nilly creating different attributes in different files.
When a user creates a new attribute it automatically assigns the next highest attribute number to it.
So if you have say 54 walls then the next wall will be '55'.
Problem is if you create a new rendered wall (55) and you colleague creates a new timber frame wall (also 55) then you will have problems if you every coy & paste between the files or hotlink them together.
Which is the real wall 55?

You must be very diligent and try to only update attributes in the master template.
Then immediately inform inform all users to update their attributes with those from the latest template.
Or as you open old files then update those too.

This is easier if you are a one man show and also easy if you are not hotlinking a lot of files.
But it works well for me in an office with 100+ users (we don't do a lot of hotlinking) but we do regularly open our old standard plans and update those.

Maintaining a template helps a lot and eventually you should find there is less and less need to create or modify attributes.
I guess it depends on the type of work you do too though.
Is a template effective or do you start every job from scratch setting up custom layers, composites, lines, pens, etc., just to suit that job?
Templates make life easy - you can have more than one - it's just more work to maintain.

I have to go now but will come back later with a couple of tips that helps to keep attributes in check even when multiple people are creating new ones in different files.

Barry.

[Anonymous]

Thanks Barry,

I did learn, the hard way, many years ago how the attribute creation and substitution process works, and have since insisted and practised due diligence to ensure attributes are created once and updated across all files associated with a project. However, in this case, the damange is already done. What annoys me is that it only takes one slip up and, on a large project, your attributes are shot, with no tool in place to take control of the attributes and manage them properly. I understand how the attribute management tool should be used, but in this case the thing I need most is to be able to access and manipulate the IDs - the one thing the management tool won't allow.
Aside from the obvious fix of having an attribute file that can be managed centrally and linked into various projects/files, I feel that being able to manipulate the IDs of these attributes is pretty critical also.
Anyway, regardless of what I'd like, it is what it is - I was just hoping for a small miracle I think, in the form of a magic add-on or something that could get me access to the IDs so I can manage the attribute substitution process myself and get the whole thing fixed back up...
Assuming that's not the case, I think the delete and replace function is probably my next best solution. Though, I'm not sure how I would go about the process on such a large project.

Does archicad treat the substitution process the same regardless of whether you're hotlinking a .mod or .pln?

[Barry Kelly]

OK I'm finally back.

There is only one difference between a PLN and a MOD file.
PLN contains all attributes - whether used in the file or not.
MOD files contain only the attributes used for the elements in the file.
So no extra layers, pens, composites, etc., - only those used.


Now for the little trick I employ.
In my template I create on new attribute for each type (layer, pen composite, etc.) and I manipulate the index number of that attribute to be much higher than all the other numbers used.

For example I have 73 composites.
I create a new one (that is useful or you can just duplicate the last one and give it a silly name like "ZZ_dontuse").
Now keep duplicating it to increase the number - say to 300.
Now delete the originals and the duplicates but leave the one with the highest number (300).

Now if anyone creates a new composite it will automatically get the index number 301.
Should I ever need to amend the template then I will create a new composite (it too will be 301) or you can use the attribute manager to bring it in but I will then manipulate its number to be higher than the main group (73) but less than my high number (300).
So I could make it 74.
I usually Overwrite 73 to the right hand side then Append the new composite so it will become 74.
Delete 73 and the Overwrite 74 back to the left hand side.
Being a template the newly created composite (301) shouldn't be used so you should be able to just delete it.
But if it is being used then you can use the "Delete & Replace" feature in the composite settings dialogue.

So now your template can be amended like this at any time and Overwrite these attributes into a user file then only those core template attributes will be updated.
Any user created attributes will be untouched because they all have unique higher numbers.

The other tip I employ with this one is I tell all my users to DUPLICATE an attribute if they want to modify it.
This ensures the duplicate gets a higher index number and the original remains untouched.
If ever attributes are updated with the AM then the template ones will update but the duplicated ones will stay as they are.


Of course this doesn't help if you have one user create attributes in one file and another create new different attributes in another file and then you try to merge those two file together.
But that is why any new attributes that are to be a part of more than one file must be added to the template and then distributed to the other associated file via the AM.
Roll on the need for a central attribute file.

When ever you have linked files you can't have people making attributes unless they do it via the main file.

I am not sure if we will ever get a feature where we can just change the number for an attribute.
Yes we can change the name (or what makes up the attribute) but that is only because the index number remains constant.
I am pretty sure if it was easy to change the number then Graphisoft would have allowed that.

I'm not sure if any of this makes sense but it's what I do and it works for me.
I have a standard template that all jobs a based on and it is so far developed that uses tend not to have to make too many of there own attributes thank goodness.

Barry.

[Anonymous]

Hi There,
I'd like to make comment about the difference between a PLN and a MOD.

A few years ago I had the misfortune to be part of a project team that completely stuffed the attribute stack in a major project. Admittedly we were unaware of the importance of managing the attributes when we started the project and that's why it went so wrong. ( I had 20+ files, 20+users and no Teamwork capability at the start. The project was also in documentation for 4 years. All hotlinked so the worst framework for Attribute control)

As a result of trying to figure out what went wrong, I performed a number of tests with various methods of inserting data into and between files. As a result I can state that there is a difference between all forms of attribute creation depending on the attribute and how you connect the data.

Sometimes it recognizes software ID as the sole defining factor. ie information will be placed on a different layer name in a linked file because the ID is the same but a different layer name occupies the slot.

Sometimes it recognizes the wriiten name and ignores the software ID. For instance it creates a new layer name with a ...(2)... added but the rules for software ID where this layer is placed in the attribute stack vary depending on how the information is linked/inserted. ie. one method uses the lowest free ID slot but the next adds them in the next highest number in the used stack, avoiding empty slots.

To illustrate my points I've attached a document outlining how each atttribute type reacted given a particular type of input. These tests were done in version 13-14 but I've tried some basic Append/Overwrite tests in version 16 and the same reactions occur. Version 17 may be different but I have yet to run any tests in that version.

Effectively what this means is that to 'standardise' a group of working files once the Attribute Stack is corrupted requires a sequence of activities specifically tailored to the data being manipulated and to how complex the attribute system connection to documentation is. A Master Attribute Stack is then created which allows firstly for the manipulation of the current data and then for the assessment of future 'variations' in te Attribute stack. Believe me they will happen regardless of how diligent you are. ie refer library system impacts in the document for which users have no control.

I too would welcome a Attribute Management process/GUI but I'm a realist. It won't happen soon. Even if it did, 90% of the staff that operate in my files are non-technical and are bound to do something, in the interests of speed, that will circumvent any system I have in place. The requirement is to be able to identify the annomally early and effectively manage it's 'compliance' across all files. It can be done but as everyone knows it's not easy.

I agree with Barry's method but unless you understand the way Archicad is working when data is inserted you can't manipulate the documentation process to manage this. In my view no data in any form should be inserted into a working file until it's been inserted into the Master Attribute files and the relevant attributes populated through all the project files. This effectively creates a container to take the information within a predefined set of attributes. This is particularly inportant for me as I work on $100-250m + hospital projects exclusively and multiple file enviroments.

My next challenge is IFC attribute control from Revit Structure, Architecture and MEP. Onward we go until Graphisoft deals with this issue.
Cheers
Neil.

[Laszlo Nagy]

I am going to send Graphisoft your post and the PDF file you linked as I believe it is very valuable in showing the inconsistencies of attribute behavior and management.
I trust they will find it very useful if they decide to address these issues in the future.