There is no tag available

[JohanCantryn]

If this issue is not a bug report or improvement request, please check the Dynamo forum, and start a thread there to discuss your issue.

Dynamo version

1.2

Revit version

2017.1

Operating system

Win 10

What did you do?

Tag a room element using Tag.Byelement

What did you expect to see?

A tag should be vreated. It works for all other objects except for rooms.

What did you see instead?

Node is reporting error: There is no tag available

[ksobon]

This means that there is no Room Tag loaded in the model. Please load a Room Tag family into the project before running this node.

[ksobon]

@kronz @moethu I think this node would actually use an improvement. It's a stretch to make an assumption that project would only have ONE tag for a given category. I usually have at least 2-3 room tags loaded in depending on what I am tagging (different tag for 1/8" plans, life safety plans etc). Can we add additional input to this node that let's users specify Tag Type to be used when creating tags?

Also, offset and isOffset seem redundant. If I am not supplying anything (input is null) to offset then it would be logical to assume that isOffset is false. Similarly for the opposite condition when I feed something into offset input. Did I misunderstand something about this component?

[moethu]

@ksobon good point, I will add a type input. We moved the tag node from the DynamoForRebar package over - the offset/isOffset might seem redundant but they are not but obviously need a bit more documentation. https://core-studio.gitbooks.io/dynamoforrebar/content/tag_elements.html If isOffset is false the vector should be the precise position of the tag while isOffset true should offset the tag from its initial position. Maybe this should be split into two different nodes, one by offset and another one by location. what do you think @kronz ?

[kronz]

@ksobon @moethu I've actually been wondering if we should go in the opposite direction with this node, of making fewer inputs. In general with Revit element creation nodes we have tried to make the creation process the most minimal thing want can, using default states, and then using "SetParameter" after creation for anything additional that is needed to alter after creation. For instance, with the structural framing nodes, we started with a crapload of very structurally specific inputs, but realized that it was really daunting fro people to use it. Can we think of tags the same way? What is the minimum we need to get started and then can everything else be altered after creation?

[ksobon]

I get that Zach, but in this case I would compare this component more to FamilyInstance ones. Not specifying a type is like letting users create any piece of furniture and then asking them to change the type by setting it with the parameter nodes. I have had a node in my package that creates tags. From that experience I would say that users are less likely to distinguish between creating a space tag, room tag, multi-category tag or regular tag. You would be best served to overload that component for all these tags instead of also adding all of the overloads for finding a usable type to serve it. Idk, that's just what I have had in my package for a while and people seemed to like it...if anything i would remove all that alignment stuff and offset stuff and throw in some separate nodes for that.

[andydandy74]

@kronz - That's exactly what optional inputs are for - let the user decide if he/she needs it. If a user wants to use the default tag family type for a given category, fine, let them. But that's not going to be a common case, since the reality is that there are almost always multiple family types in any given tag family. So choosing the correct family type is something fundamental. Kind of like being able to specify the scale of a view when creating it ... ;-)

[moethu]

@kronz so what about moving adjustment parameters/settings to a new set of nodes and adding the minimum requirements to the tag node (like Type, View and Element) and two optionals: isHorizontal & addLeader. The adjustment could then be achieved by using the new location manipulation nodes or a new set of nodes allowing the user to define the position within the bounds of the 2D representation in a defined view.

[kronz]

@moethu I like your description. What do you think @andydandy74 @ksobon ?

[andydandy74]

Fine with me. Mind you, type should be optional as well. If the input is null, just use the default tag type defined for that category.

[ksobon]

good to me.

[ksobon]

This never got resolved.

The offset info is still there, and its still confusing. The tagtype info was never added. Is there a plan to get this fixed?