ericjhberg

We have a new issue, never encountered prior to VW2018. Currently we are having difficulty with Plant plug-in object visibilities...I've attached 2 screenshot videos (no narration, sorry) that show what we are encountering, but I will do my best to explain. We have (8) different classes we use to control the internal visibilities of our Plant objects. Currently, these classes are not responding to simple on/off/gray controls unless you go into each plant individually, after changing the visibilities, and then exiting the plant. Then and only then do they look correct. To make things worse, this error is compounded by the fact that as soon as one database worksheet plant schedule is recalculated, all of the active visibilities and buggy visibilities revert to a pre-altered state. I know this isn't the most clear description and I hope the screen captures do it more justice. Ultimately we need this fixed ASAP. This is a bad bug that affects our ability to produce any documents. Plant_Symbol_VW2018_Bugs.mp4 VW2018 Plant Bug 2.mp4

Definitely not true with Hardscapes...which of course is the one we use most often. We try to avoid any duplication of similar objects to minimize conflicts during editing. In my opinion, there is nothing worse than trying to remember how many duplicates need to be modified when something changes.

We often use the Create Objects From Shapes... tool to turn regular polys into plug-in objects like hardscapes, landscape areas, etc. Until recently (v2018) this would destroy curvilinear geometry, but now it doesn't. Great work. Now what we need is the ability, somehow, to run a Un-Create Objects from Shapes to go back to the original geometry from the plug-in created. There currently is no way to do this. You can use the Ungroup or Convert to Group commands, but this often results in way too many resulting objects. For example, a very basic hardscape, ungrouped, results in 3-4 identical shapes overlapping, which is impossible to get rid of on large projects. Just a thought.

Agreed. Fence tool needs some upgrades. It's close, but just needs that extra love...apparently the AUS/NZ version is better though, so there's that.

Have you tried unchecking the box in the Export PDF Settings...see below

That's what I thought...wishlist item...allow for the creation of hyperlinks in worksheets, but probably additionally as an option for a record field. That way you could add that data to a database query for different objects and have it populate worksheets. Thanks Jim!

I don't think it is possible, but I thought I would ask anyway. Is there a way to format text as a hyperlink within a worksheet in VW?

There should be a way to automatically connect an irrigation outlet to any nearby pipe. Since we often work on large complex irrigation systems, our workflow has been to draft irrigation lines as polylines first and get them all correct before converting them into pipes. The reason is that once pipes are created, they cannot easily be replicated through offset methods to show multiple pipes or precise locations. Similarly, we will have often already placed all of our irrigation outlets for the design...thus it would be awesome to select an irrigation head, or multiples, and tell them to auto-connect to the nearest irrigation pipe, or the irrigation pipe of your choosing. THis would autodraw the shortest possible lateral connection in between the outlet and the chosen pipe. I have another very specific workflow example where this would be helpful, but I'll save that for later.

So...it turns out that you can select similar plants by species, but not by using the symbol name criteria. Instead, if you use the select similar by object type, it will now select all plants of a similar species. This is a little counterintuitive to me, but it works. I would think that Object Type would return all Plants, and not separate by species and that by Symbol Name would be a more important selection criteria, but at least the functionality is there. Consider this one a partial fix.

I think align world Z only controls the Z height, which looks fine in your example. It is the Horizontal Shift that appears off. Try entering matching values in the Offset H criteria?

Agreed!

Man, @Tom Klaber if I had to apologize for every time my posts have been bratty on the forum, the feed would be littered with apologies...Thanks for pushing through and fighting the good fight.

I like your thinking Art but unfortunately you cannot reference worksheets at all. They are the only resources that you can't reference and it kinda makes sense...worksheets can only gather information from an active file, not any other.

Wow...I'm glad that this question has brought out the big guns! A couple of thoughts from the novice. Agreed that a large record attached to everything would likely be cumbersome...but what about a small record (15 fields max)? I love this idea. Some way to easily see what items have the record attached vs. those that don't and then a quick way to attach the record to those remaining that need it. What about a future wishlist...like the 'Use at Creation' check under Edit Class(es), that, in addition to the Graphic Attributes, Renderworks, Text Styles, etc., there be a Data Tab that would allow you to select a record format to apply to all items within a class (both retroactively and at creation). I'm excited to see where this goes...

Ah yes, this fun issue...sarcasm implied. Unfortunately this functionality requires you to create separate worksheets for each sheet being queried. That being said I think I just discovered a methodology this morning that may help. Edit the crops of each of your viewports and give the crops a name Create a unique worksheet or database header for each different query Query your criteria for Location is within Crop Name I just tried this in a dummy file and it seemed to work on very simple objects, but I'm curious if it will work for you... Otherwise, in order to quantify per sheet, we have resulted to one of four isolation methods. By Layer - We have often, on manageable sized project, created different designer layers for the information that corresponds with each sheet. For example, we often have TREES-SHEET 1, TREES-SHEET 2, etc. By Class - This is very cumbersome, but if the item being queried is minute, may be worth it. Same concept as layers, just separate classes for the different items. This can easily get out of control though if you have lots of information you wish to parse out. By Record - I have, again on occasion, used a custom record format with a field for sheet and attached it to all objects. From there you can query for objects with a record field = sheet number. By Location - Although you cannot use the viewport name in this, if you create separate shapes that correspond to your viewport crops and name them appropriately, you can query for Location is within Shape Name.

This may be considered a wishlist, but honestly I have no idea if this functionality may already exist somehow in Vectorworks...here we go. Is it possible to set up a default that would automatically attach a custom record format to everything placed in a drawing, retroactively and to all future drawn objects? The reason. We have started to use custom record formats to gain some additional functionality out of certain tools or features, but we can run into difficulty in an office setting where multiple users are asked to know what record to attach to what and to make sure to attach it to any new objects placed. I would love the ability to create a very generic custom record format that covers many of our additional functionalities and ensure that it will be attached to everything in the drawing. I can worry about using other criteria to limit my selections later (usually type, class, layer, etc.). Just curious?

Couldn't agree more. I actually found it a little strange that they did this at all. In the past they have been pretty good about slowly phasing out legacy tools, so it's strange this time that they did a complete overhaul (poorly, by my early estimation) and didn't give users the opportunity to slowing wade in...not impressed.

I have experienced the same thing...so far, not a fan of new titleblocks!

Since the introduction of Project Sharing in VW2016 and many other features in VW, it seems like the company has made a decision of steering users to single file workflows. With that said, we haven't found a way yet to consolidate our complex and memory intensive referenced file workflow into a single file system...at least not practically. I'm curious to what credit VW gives to differing workflows when developing tools or looking at the big picture. While I love the idea of doing everything in one file, we face two large hurdles to practically implement this practice on some of our larger sites. These roadblocks are: File Size - Our work is often broken out into 3 different segments (layout/grading, planting, and irrigation); thus, we have created a separate file for each. We have created a referenced file workflow that combines each of the various files together to generate our documents (schematic, design development, construction document). On large projects it is not uncommon for any one file to top out at 1+ GB, and individually, this already puts a strain on our machines. I cannot imagine combining our files together will result in smaller or more manageable file sizes, so we really haven't even considered it. Layer Management - With our multiple files, each with their respective design and sheet layers, it is also equally hard to imagine combining all of this organization into one file without a better way to organize it. Take our irrigation files alone. Our practice is to put each individual irrigation design zone/station into its own respective design layer. We do this for a myriad of reasons, but mainly, it is just easier to track and document complex systems. That said, it isn't unheard of that some of our irrigation files will contain almost 100 design layers! Similarly, we have worked on projects that have 20 irrigation sheets, 20 hardscape/grading sheets, 20 detail sheets, and 20 planting sheets. If I put all of that information together in one file, there is no way to organize it. I imagine a simple hierarchical or folder system similar to how classes currently sort would help this exponentially. The main reason I bring this topic up is that I have noticed that many of the new features VW has pushed in the past few years are solely intended to function in a single file workflow, but immediately run into difficulties when using a referenced file approach that we currently employ. Take the new Titleblocks for example, or even the old Sheet Borders...how do I use the same titleblock in 3-4 different files while keeping the Project specific data constant and maintaining individual control of the Sheet specific data? Referenced symbol? Referenced Titleblock Style? This works great in theory, but you quickly realize that the Project based data, when changed in one referenced file, does not transfer to other referenced files. I would love to hear more about peoples experiences/struggles with their single file or referenced file workflows. How is it working for you? Cumbersome? Have it all worked out? What else needs to be done to make this practical?

@Vladislav Stanev. I know it has been awhile since I originally asked this question, but I am still encountering it. My latest example is the Irrigation POC Schedule, pulled directly from the VWorks stock reports. It is reporting Output Pressure and Max Safe Flow in units I don't understand. We are looking for PSI and GPM respectively. Is this metric? Do I need to run a conversion factor? Thanks.

I have noticed two bugs related to workspaces in VW2018. One is a hold over from VW2017 and the other is new. They are: When working in the Irrigation Tools for awhile, I lose many of my typical right-click menu options. They just don't appear anymore. The only way I have learned to restore them is by restoring my custom workspace setting. I noticed this in VW2017, but just never got around to submitting it. After saving my new custom workspace settings in VW2018, I have noticed that for some reason, many of the toolbars revert to a squished and ineffective setting at first and I have to widen a couple of panels. This is new in 2018

In my limited playing around, I am quite frustrated by the lack of support for the now legacy Sheet Border Tool. Since 2018 forces us to convert everything into Titleblock Styles, we now have to relearn and refocus all of our efforts on re-creating new custom Titleblocks. I don't mind that they added a new tool, but am upset that they stopped supporting the old one...

Again, I am a little said to hear that the use of 3d polys placed in the Site-DTM-Modifier class is no longer supported as a way of sculpting site models. We spent a lot of time honing that particular workflow...

I had started playing with the new site model in 2018 and really enjoyed the contour editability, but I didn't realize that you couldn't edit the source data anymore...?! This is a no-go for me too! We often have extremely complex source data that I have to manipulate just to create a usable site model. Not being able to do so iteratively will cost us significant time and headache.