ericjhberg

I am also running into this problem. For some reason VW doesn't realize that it is standard practice to rotate viewports... They don't allow the north arrow to rotate with the viewport or be smart enough to understand that the viewport is rotated. I don't mind a smart north arrow that realizes georeferencing, but it should also be smart enough to understand the concepts of rotated viewports. This is DUMB! @Tony Kostreski....I'm tagging you on this one...figure it out.

@bgoff I am fluctuating between 2020 and 2021. It may be fixed in the newest SPs, but I haven't tested it again. When I said changes to the design, I meant something like if the Input/Design pressure changed, and thus pipe's resized or the output pressure changes. The corresponding data visualization doesn't change to show any changes in pipe size or output pressure...I just stayed the same as when the data visualization was first applied.

Just an FYI, depending on version, there is also a data visualization bug associated with Irrigation Objects that may, or may not, be solved yet. I have submitted the bug in Beta testing and still haven't determined if it's fixed. Essentially the bug is that once a data visualization is set up, say for pipe size or for output pressure, the data visualization appears correctly upon first setup, but as soon as the design changes, the visualization doesn't dynamically update or change with the changes in parameters. The only workaround I have found was to save the data visualization, remove it from the current drawing, and then re-apply it from the saved visualization library.

There should be an option to Lock In Place for Site Model objects, similar to Referenced Viewports. I can't tell you how many times I'm panning around my site model and accidentally grab it and move it...sometimes without noticing. Of course, you can Lock a Site Model, but that doesn't allow you to perform updates to it either.

Yes, This functionality should be extended across ALL of the Site Modeling tools/objects, including Site Models, Grade Objects, and Site Modifiers, in addition to the current capabilities of Stake Objects.

This tool should also have the ability to essentially extrude custom curb profiles along, allowing for monolithic curb and gutter and other configurations. The tool should also be hybrid in nature, allowing for 2D visibility settings and 3D visibility settings.

@jeff prince This is exactly what we're looking for, even if I did hijack the post...apologies. Thanks.

@Pat Stanford I think this could work okay, but I'm not sure if it works as a long-term repository of the WUCOLS data. The WUCOLS data is static, per plant, for each region. It just makes more sense to me if this could be added to the Plant Database for long-term storage of that particular data. We could do the additional record strategy if we're storing the Plants, pre-created, in a Library file (which we do already), but it seems secondary to the Plant Database.

@bob cleaver I would like a way to add/reassign/classify custom fields in the Plant Database for each of the 6 different WUCOLS regions. An example would be Quercus agrifolia WUCOLS Region 1 - North-Central Coastal = LOW WUCOLS Region 2 - Central Valley = LOW WUCOLS Region 3- South Coastal = LOW WUCOLS Region 4 - South Inland = LOW WUCOLS Region 5 - High and Intermediate Desert = INAPPROPRIATE WUCOLS Region 6 - Low Desert = MODERATE With this data entered in the plant database, theoretically you could then set up a worksheet to just query the correct WUCOLS Region field and all the plants in the project would then display their WUCOLS rating for that region. Our current workflow is similar to yours where we use COMMENT to adjust the WUCOLS given the current project's location. But if we then use that same plant in another project/region, we have to change the WUCOLS information to suit the project for each plant. The suggested workflow would simply be changing the field query to the correct region, all plants would update. For WUCOLS research, this type of database customization would also be extremely effective for searching for compliant plants in the database/VW as well, generating a "potential" list depending on WUCOLS and other criteria.

Agreed. Additionally, in WUCOLS a plant can have up to 6 different WUCOLS classifications depending on the designated climate zone, so ideally I would like to be able to reproduce all 6 designations in 6 different fields and then just have a worksheet query the one specific to the given project. We currently work across 3-4 of the different climate zones within WUCOLS, but also want to store ready-to-use plants. Without this, we are constantly changing the WUCOLS information for every project depending on the climate zone.

Thanks @Tom Klaber!

Mind sharing?

Works well on a Mac...much more difficult on a PC.

Please, please bring back the changing colors. We now operate across (3) versions of the software depending on the project...and with 2021 release, they are ALL black. It is TERRIBLE.

@Tony Kostreski...There should be a way, within the plant database, to Add Custom Fields. Since this is controlled through FileMaker, it may be possible, but I have no clue how to do it. This would be extremely useful in mapping local customizable features (i.e. WUCOLS data) here in California or wherever.

We ran across an error in the Irrigation Catalog for one specific, albeit very commonly used, irrigation component. Under Outlets, Sprays, Rainbird, R-VAN Series Nozzles, the R-VAN24-360 nozzle does not have the correct Performance data tied to it. Instead of the radius ranging from 19 ft - 24 ft based on varying pressure input (see Screenshot 2 attached), the Vectorworks catalog only displays a range from 16 ft - 18 ft (see Screenshot 1 attached). This is an important fix because this is a common standard manufacturer product within the shipped VW library and cannot be easily edited by users. By not allowing for the full radius, this is disincentivizing this particular, solid performing product. I am completely capable of creating an alternative custom outlet type to correct the issue, but this shouldn't be confused for a permanent fix to this error.

Unfortunately, as @Boh mentioned, storing additional data with a callout in the Database is not currently possible. We end up doing a lot of copying and pasting. Fortunately, if you design your callouts correctly and attach the extra record, manipulating the extra data from a Worksheet is actually pretty quick and effective. Sure it would be great to have that data already populated, but it isn't a dramatic extension to add it from the worksheet, using it to populate the drawing after placing callouts. This is enticing. I haven't tried a Callout Plug-in Symbol before, but I like the possibility here. We are in the process of switching over to Data Tags. No we cannot store info in a database, but for symbols, we can store favorites with a saved custom record data attached that can be saved in Favorites and easily added to projects and tagged. This process, using data tags to callout objects with particular records attached, has another huge benefit. When querying in a worksheet, you can actually pull information about the objects themselves (i.e. qty, area, volume, etc.) and not the callouts pointing to them.

This is exactly what we do. We have created a Custom Record Format that we attach to all of our callouts, then, in addition to the Keynote Number and Keynote Text fields that are part of the Callout Plug-In, we can also report in worksheets all of the custom information we also need.

@AlanW...thanks for posting this, 2+ years ago. I must have missed it. How would I adapt this to work for symbols or other object types that I need to send to surface?

@Vlado beat me to it. He helped us with this a while ago. I should have posted the update @samgbickel @Vlado...any chance this will become a more forward facing option? Perhaps in the Irrigation Settings dialog? Thanks.

I also have noticed this and it is frustrating. It does have to do with active layers...sometimes, but not always.

@rowbear97 In my experience there are so many bugs related to Rotated Top Plan. I tell everyone in our office to avoid it unless absolutely necessary. I wish I could provide specific examples, but honestly there are too many to mention. Then you add the general buggy-ness of hardscape objects...as I have railed on for years...let's just say I am not surprised by your issue. For a truly rectangular application like this, I would start from a perfect Rectangle and notate it's rotation angle. Then, once converted to a hardscape, you should be able to use that same rotation angle to control the angles of the scoring?

@tekbench Thanks for confirming...I kinda gave up too. I'm not surprised that VW hasn't figured this one out. My experience is that they rush tools to the market just to say that they can manage Point Clouds and then wait years to provide them the full functionality needed to make them practical and useful to users. This is just one of many examples of this.

I love this as a general basis for a rule of which pipes jump which. +1

Hi @jeff prince...thanks for promoting the pipe jump concepts. As for your workflow question about drip emitters...the short answer...no. This is also a huge missed opportunity IMO. Vectorworks has the capability now to marry Plant Objects with Irrigation Tools, but hasn't taken it that far. As far as I'm aware, they really have ignored the irrigation tools since they were originally developed. I do have a workaround that helps...a little. You can Save the Emitter you want to use as a plug-in style select all of the plants you want to assign individual drip emitters duplicate them, ideally into a temporary separate design layer or your irrigation design layer Then, change the plant grouping so that they are all INDIVIDUAL PLANTS Finally, you can use the command Modify>Convert>Replace with Symbol to replace the plants with the desired Emitter plug-in style. The problem with this is that you still have to hook them all up to pipes, which is time consuming in itself. This is the main problem I currently have with the irrigation tools. While replacing old-school workflows with digital calculations and BIM functionality the logical next direction...at least for now the workflows often come at a significant efficiency and time loss for the designer. We spend hours hooking up pipes, when previously we could fly with "dumb" pipes and emitters, and then do the calcs necessary in a relatively quick fashion. Granted, if the design changed, it was a huge pain in the ass, but design changes with the irrigation tools are still cumbersome. @Bryan G. is the irrigation go-to, so I'm hoping that collectively we can push some of these ideas through to make the irrigation tools better, but I have to admit, my success rate on getting wishlist stuff incorporated into new versions is abysmal.