- How to rerun tag command to get same tag number on newly-identical windows, even if the system is confused by mirrored window objects. If I change the properties of a set of differing, uniquely tagged windows (in window properties) so that the windows are all identical except for their X and Y positions, running the tag command continues to give them different tag numbers identical to their previous tags, even if I delete the tags before running the command. If I delete the tag numbers of each window in properties, I get tags with a hyphen (-) only. How to rerun tag command to recognize newly-identical windows? My guess is that because I mirror-copied some of the windows to place them, the system is confusing identically-handed windows (not that it has any significance for this window type) despite their handedness reading as identical in properties. How to work around this?
- How to get Opening Elevations to sort/group according to Tag number? They line up in random order with windows interspersed between doors. Possibly related to 1 above.
- How to prevent redundant elevations? Out of my 2 window types, W2 and W3 appear twice, drawn identically; and they are all identical to W1. I imagine this is related to number 1 above.
- How to get Openings Table to recognize tag conditions present in 1 above. It a) can’t get a tag number for the window type distributed among 3 different windows and leaves it blank and/so b) it doesn’t sort the tag numbers properly. I expect resolving 1 will solve this, but let’s make sure.
- Please let me know if the Tag Style used in an Opening Elevations Style can match the different Styles used for the Door and Window tags. I am assuming not.
- How - if possible - to reduce default tag/object spacing? (I have to move every tag closer - I find they are always at least twice as far away as I need.)
- How - if possible - to set default tag orientation to “aligned”? I can’t find it in TagStyles.
How - if possible - to set tag number as black and tag bubble line to grey? Please be very specific. I find that both of those elements respond identically to “color:” in styles>attributes, and to no other settings. This would be a way to get legible text despite the tag text offset bug. Another way would be to fill the shape with a light grey fill, preferably with no outline. The style seems to offer this option, but I haven’t found any setting in that area which has any effect.
I have uploaded the related project.
1. The tag command inserts a tag object that takes by default the following format “%<element.tag>%”, in which the string “tag” corresponds to the property field “Tag” of the object selected. You can see this formula in the Tag properties panel:
When the Tag field of the object selected is empty, the tag shows that hyphen ( - ).
When you mirror a window object, it gets the same Tag field as the original window. So when you insert a tag selecting the mirrored window, the tag object shows the same value. If you want to change that, simply edit the Tag field of the mirrored window and its tag will update.
2. The order in which the opening elevations lay in the model depends on the position of the openings rather than the value of its tag. It is not possible to customize this order, but you can move the position of the Opening Elevations after having inserted them.
3. Openings with the same style, dimensions, opening side and tag field should be displayed as 1 elevation, rather than 1 elevation for each item. If this is not working fine, it might be a bug. Check if this is your case, or send us the model so we can check it out too.
4. Since the “Openings” table style that comes with VA templates group the objects by the “Width”, “Height”, “Elevation” and “Opening Side”, if the other properties/parameters have different values they are not shown in the table (that’s why they appear blank. We are considering showing “varies” or something different than blank or at least give an option to decide what to show.) You can edit how you want to group the properties from the “Field”'s tab, after selecting the “Quantity” field:
Once you uncheck the fields that group the openings in tables, you can include the “tag” field as one of the conditions to to sort the order in which the openings will be displayed in the table.
5. Unfortunately not yet. The tags displayed in the Opening Elevations can’t get different shapes. This is something we could add in future versions.
6. The spacing distance between the object and its tag is automatic, and it’s not possible to customize it. We can improve this too in future versions.
7. This is not possible now. You can only change the alignment settings after inserting the tag. 1 more vote for this request in the wish list.
8. This is not possible either. The label and the text can’t get different colors or attributes. And the “Pattern” attribute is not filling the tag area. We might improve this too.
Thanks for this collection of suggestions for the Tag command. I’ll let you know when we implement them in future versions.
There’s a communication gap for answers 1 through 4. I understand what you’ve explained, but in the project I uploaded to drop box and shared with you immediately after posting that, Francesc (you should have received an alert back then) it isn’t working.
- I was trying to explain that I have several windows that I have made all identical, but they are getting different tag numbers,(it may or may not have anything to do with mirroring them.) It’s in the project which - as I said in the original post - I uploaded.
- thanks - that explains that.
As I was attempting to explain in number 1, isn’t working like that. I uploaded the project when I made the original post, as it says in my post. I hope you received the drop box alert then. I will ensure it’s sent again, but your permissions allow you to check any time.
4) The problem is not what you are responding to. Please see number 1.
I got the file, thanks!
1 and 3 If those windows are getting different tag values, it means they have at least one parameter that is different. When you mirror a Window, the copy gets a different Opening Side. That means that when you insert the Opening Elevation for those 2 windows, a different tag value will be assigned for each window, and there will be also a different Elevation for each one. Make sure both windows have the same Opening Side to generate only one Opening Elevation and get the same Tag value assigned for both windows.
4. Excuse me, I am not sure what you want to get in the Openings table, and in your model I don’t see any table inserted.
Do you want to see the full list of openings with each tag value? or do you want to know why the “reference” field (corresponding to the tag property) appears empty?
Do you mean in the Table, right? In the animated gif of my previous post you can see how to edit the order of items in the table. If this doesnt’ work for you, send me the model with the table style already edited so I can see if there is any error.
One and Three: Please check those windows. I set all their opening sides the same after they were mirrored and they all report that way in Properties… They are identical according to Properties, but they get different tag numbers and different Opening elevations. This is the problem and though I appreciate your many forms of advice that they will get different tag numbers and elevations if they are different, I understood that before I posted, and the problem is that I believe they are not different, according to Properties, so they should all receive the same tag number but they don’t. Is that not the way it is on your systems in the project I uploaded?
Four: There should be a table, but it’s quite small in modelspace. It’s visible in a scaled window on the 24x36 layout. I know how to sort by tag number. I edited it to sort by tag number before I made this post and uploaded it. The project I uploaded should show this.
(I’d confirm all this with the project I uploaded, but at this moment the latest Rhino release crashes projects created with it, on reponening them, if they require the Va plugin. I’ve posted about that on this forum.)
I appreciate your usual prompt input. I hope we can resolve it before the weekend.
I can see now the Table, excuse me for that.
Taking a look at it, this what I assume it’s happening: those windows that are indentical in Properties are getting different Elevations because they have different Tag values.
If you remove their tag values, and run the vaOpeningElevation command selecting those windows, you will see they get the same tag number and there will be only one elevation created. See this test on your model:
Thanks for the gif, between the lines here I may have finally figured out the issues holding back my understanding:
A) VaTag can be run on some objects (like columns), but the elevation command takes its place for Openings. (Sometimes I can get Vatag to work on doors, but it usually results in a muddle, which to me implied that it’s supposed to work.) A1) I assume that this allows the user to override selected Tags in Properties resulting in duplicate Elevation of an identical opening? However: A2) A1 confuses the Openings Table and it lists them all as one window with a blank for the Tag number, which may be a bug.
B) A user can’t just hit delete in the (varies) spot in Window Properties for a group of selected windows and - when the field becomes empty - assume that because the field is then empty the Tags have been reset (as I believe is the case with AutoCAD). It doesn’t work until the user has 1) entered a new value for in that field (I see you put “cc”), 2) entered that and seen the tags all update, 3) deleted that new value in the fields and 4) entered that. Only then can the Tags be updated for new values.
C) Are A, A1, and B covered in the Savoie tutorial? I noticed that the Openings Elevation came first in the tutorial, but I didn’t understand that the tag numbers couldn’t be created if (for example) a person didn’t want to create opening elevations, which imply that the door sizes have been already decided.
D) Opening Elevations are created late in the design game in my experience. In early stages I think it’s better to at least have the elevations to either not exist or be blank rather than have temporary dimensions in them, but the tags are handy for identifying a door in a conversation. The Elevations and Tables could be on a hidden layer, but colleagues like to see that they’ve been considered in the layout, though remaining blank until needed. This could be accommodated if some components could be on a separate (but hidden) layer. Maybe that’s possible in Styles but I know you’ve advised me that some of style settings aren’t connected yet.
A) Yes. In summary:
- The vaTag command can be run on any VisualARQ object, including doors and windows (we are planning to run it on Rhino objects in future versions too).
- Running the vaOpeningElevation makes the Tag field of Doors and Windows be automatically filled with some value, if they didn’t have any. The tag value they get is the same if doors and windows have identical properties, as we have already discussed. If tag values were assigned first to openings, the Opening Elevations would show them accordingly.
- When running the tag command, if the tag field is empty, tag labels show a hyphen ( - ).
- Tags always have this format “%<element.tag>%” but you can modify it by typing any other value or changing the property of the referenced object to display.
B), That’s all correct. We should improve the way to delete or edit the content of fields of different objects that have different values.
C) No, tags are not covered in that video tutorial (they were introduced in newer versions after recording those videos). But you can see a video tutorial of the tag command here: https://youtu.be/RiVE5SM1mLc
Also this post adds some tips: https://www.visualarq.com/support/tips/can-i-put-the-object-dimensions-or-other-information-inside-tags/
The Opening Elevations topic is covered in the Ville Savoye tutorial: https://www.visualarq.com/learn/video-tutorial/4-4-opening-elevations/
In any case, I think you can learn more about Tags from this thread than in the rest of sources all together.
D) Whenever you want to insert the Opening Elevations is up to you. You can add first tags to doors and windows, and later on insert teh Opening Elevations. You can put the tag styles in specific layers, so you can have a better control over their visibility in the project. But this is not possible (so far) for the text and label separately, as we have discussed.
This isn’t working for me in a situation where I am simplifying the number of different openings and looking to refresh the tag numbers to reflect fewer window types and common heights for all the doors. I’ve uploaded the project to dropbox.
Step1: Delete tag text and Create uniform window type A:
Step2: Delete tag text and Create Uniform window type B:
(one of the window tags didn’t reset but that’s the least of the issues)
Step3: Delete/Reset tag text and Create Uniform Door Heights
Step4: Delete Reset Tags (leaving the non-reset tag out of this.):
Step5: Run VaTag on the openings doesn’t work (and that gif won’t upload) So I tried with just the doors. It doesn’t work either. Running the tag command on openings has never worked for me. This is one of the main reasons I started this thread.
I’ll upload the project to dropbox.
What is exactly not working with the vaTag command?
This command just insert a tag object (the text enclosed in a curve), and it shows the value of the “tag” property of the tagged object. But it won’t generate tag numbers automatically. If you change the properties of a door or a window, you then need to change the “tag” property inside door/window properties. This is not automatic… yet.
If I delete the tags and the tag values and start all over, shouldn’t it recognize similair door types and give them all the same number? As with opening elevations? In the final gif, it just shows a blank.
No, VisualARQ doesn’t generate the tag values automatically. If two doors are identicall, you need to assign the same tag. If you then change any properties of one of them, you’ll need to modify the tag.
The only command that does something automatically is vaOpeningElevation: if will generate a tag string for all non-tagged elements, but if any element is already tagged, the tag will not change.
That’s a surprise, I can finally work with this now that I understood the limitation to the Tag command. It may be a natural assumption to many users\ that the Tag command, which only has to create tags and not entire elevations, would at least discern similar opening types.
Yes, I understand that automatic tagging is something expected, but it not as easy as it sounds.
First, each architect (or architectural firm) has its own rules for tagging. Some use
D1 (Door 1) for doors and
W1 (Window 1) for windows, while other use more complex reference numbers like
D1L-F1 (Door 1 Left Open - Level 1). There many other options, like use the manufacturer reference, door sizes, etc. Implement an automatic tagging that only works for a small numbers of users is not a good solution. We need to find a way to define some automatic rules for tagging.
Second, not every architect may consider two windows are equal: Some architects doesn’t take into account the elevation from the floor, while other do.
Third, many architectural firms like to use the same reference for the same windows, even when they are used in different documents or even in different projects. In this case, the only solution that come to my mind for automatic tagging is to use an external database (for example an excel file), where all possible windows are stored with their tags.