Jump to content

LanceF

Vectorworks, Inc Employee
  • Posts

    64
  • Joined

  • Last visited

Everything posted by LanceF

  1. Of course. Regarding your last sentence, I will mention this: You could try using the Select Connected Components command on the desired valve, inverting the selection, and then locking the selection. I know this is cumbersome and doesn't provide the visual isolation that you would like in addition, but perhaps it could be useful in certain cases in the meantime.
  2. An enhancement request has been made and shared with landmark engineering and product marketing teams.
  3. Hi Eric. Thank you for responding and providing more information. As (I hope) you know, your firm is important to us and we value your feedback. I will file an enhancement request, so that we'll have something formal "on the list" regarding this, to be considered for future updates. I will also start a discussion with the rest of the landmark team about what potential changes or additions could be made to accommodate workflows such as yours. And of course, you can talk to Eric and/or Tony during the summit about this particular issue if you like. Bryan may have some thoughts as well. As I'm sure you're aware, we are constantly trying to improve a wide array of tools, so I can't make any promises about a particular change or timeline. This is a fair request in my opinion. This sort of thing is typically done outside of my department, but the landmark team can discuss who might be able to make something like this, given everyone's current workloads, and what format it might take. I do realize this is not the same thing (e.g., I don't think it discusses layers), but don't forget about the help documentation. Yes, that is how the current tools were designed to work. I will note why you find this to be insufficient for your workflow. Although I think that many of the tools work well on large projects, know that a broader discussion about how to further accommodate both types of users (and others) is ongoing. We often get conflicting requests regarding simplicity vs versatility, both as a result of small vs large sites and as a result of different industry roles, standards, and practices in the multiple markets Vectorworks serves around the world. We aim to have a product that is as useful as possible for as many as possible, and we will continue to do so. Well yes, that wouldn't be particularly great... So feel free to express any frustrations here, via email, or through tech support. We understand frustration and try to keep it in mind regarding the tone of a post. Don't forget about the Select Connected Components command in the Irrigation submenu. It selects everything downstream, and can be used on points of connection, main lines, valves, and laterals. Of course, a selection is temporary, so it doesn't provide an isolated editing environment for whatever was selected. Thank you.
  4. Hello Eric. It is not broken; the system was designed this way. Each irrigation network should be on the same design layer to maintain the data connections between components. Using multiple design layers allows users to place multiple networks on a site (either to experiment with alternative configurations, or for very large sites that would have more than one irrigation system), without risk of accidentally connecting the different networks. Changing layer visibility and modification settings then allows users to easily focus on and modify one system at a time. In fact, with the way the current tools were designed, if some components are maintaining data connections once moved to different layers, we would be more likely to consider that a bug than what I understand you to be saying. When you refer to your irrigation workflow from the past, that must have been with the old set of irrigation design tools, which were practically just representation tools. These functioned completely differently. The objects were not 'smart' and allowed only a tiny fraction of the current functionality. If your workflow is based on these old tools, it is not surprising that you would need to update it for the current tools. The current irrigation toolset was released in late 2016, and this is the first time I've personally heard this complaint. That is not to say that you can't recommend or request a change in designed functionality for future releases. However, we would need more information about your problem to weigh it against the success users have found with the current functionality. For instance, if you really need to stick with a workflow based on the old tools for some reason, please tell us why. It would be helpful to have an example file, and a detailed explanation of exactly what you want to do. A video with narration and the OIP always visible would be helpful as well. Thank you.
  5. Hey Eric. This has been fixed for SP1, but let me know if you run into any similar issues. It is indeed a metric conversion issue, but you shouldn't have to do anything. It should report the values in your chosen units (the same values you see in the OIP). Thanks.
  6. Hi Eric. I'm sorry you're experiencing crashes. Are you using SP2? We believe we've identified the problem, but if you could send us an example file it would help us to confirm. Regarding the speed of recalculation, this does arise with larger irrigation systems. The fix that Vlado mentioned in your previous post was implemented for SP2. There is now an option to turn off autocalculation in the XML file "Libraries\Defaults\Irrigation\IrrigationSettings.xml". Please let me know if this fixes the speed issues. Thanks.
×
×
  • Create New...