Jump to content


  • Posts

  • Joined

  • Last visited


96 Excellent

1 Follower

Personal Information

  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Couldn't edit my post for some reason; scratch the above, you have multiple sections of the same wall style, they'd all be wrong if it was the Core.
  2. Where you have the two wall styles end to end, you can use the corner (L) join mode. I tested your example though (in 2022), without using a join, and the slab tool still worked . . . so maybe check both Wall Styles have the same / desired Wall Components selected as their Core.
  3. If you want the stud and gypsum to remain at their default construction heights, deselect the 'Follow Top Wall Peaks' option in the Wall Component Settings, or in the Wall Style itself if you want this as the style's default behaviour. You don't need to do this before you reshape a wall, the stud and gypsum will reset to their default heights once you deselect the Follow Wall Peaks option for each component.
  4. No good solution unfortunately. What I typically do is create duplicate Structural members and have a separate class for the modified members. Then you can pull data and display either where appropriate, using viewport overrides. This has been on the wish list, as are many good things, for some years now.
  5. Ok, they’ve got two now, should be fixed twice as fast. 🙂 Where do you see the VB number after you submit? Yep, I’ve used it as a plug-in for many many versions. Strange that it’s ok in the script editor, then crashes VW.
  6. I’m moving to 2022 and have a problem with a very basic tool/macro/plug-in created via the Custom Tool/Attribute... command and the Double-Line Polygon Tool. It makes a quick ground line plug-in that has worked ok in previous versions, but it hangs 2022 every time it’s run. In the attached file the script has been re-created with 2022, but it still crashes Vectorworks. Any clues? macOS 13.0.1 - VW 2022 SP5 Hanging.vwx
  7. The associated line is separate from the tool’s symbol contents. My default is to execute all tools while in the None Class and simply set the Repetitive Unit Object’s Pen Type to None in the Attributes Palette after creation. Alternatively, you could have a container class for the Repetitive Unit Tool with the Pen Type set to None and either draw them in that Class or set them to that Class after creation.
  8. Yeah, that’s an extensive piece of work and a fantastic overview in itself. His details, dates and connections, almost certainly, will become the basis for further investigations and work on his subject, not to mention the general history he has captured there.
  9. Thanks @jeff prince, the critique in that series was a worthwhile and pretty relevant read. The scope is huge though, perhaps a little too broad for our BIM orientated brains? Still, I believe some of his investment fund observations are contextually relevant to Nemetschek’s own foibles and strategies as a holding company. After making my way through most of the series, I’m thinking the conclusion of bias in this thread was based on Part 2 in isolation? If so, I’d urge anyone thinking this is unpaid advertising (for either camp), to keep going . . . All 7 Parts are linked here: https://bigdataconstruction.com/history-of-bim/ The overarching motivation for the series isn’t particularly obvious in Part 2 and one of his primary hopes, being a truly “open” . . . BIM exchange format, one that behaves effectively and as efficiently as a single file format (like RVT), isn’t discussed until the subsequent Parts. Part 2 was more about building his argument for the fact that, in an open market, efficiency wins, and that in terms of market share percentages, base on the Zigurat institute’s observations of search data, it likely is winning!
  10. Thanks @Tom W. I wasn’t aware subscriptions had been available for a couple years already. The snapshots were interesting, I have no idea what the VW numbers or market share are like here (au). Perhaps as @line-weight suggests, these are closely guarded secrets.
  11. @Tom W. would you be able to add a link to the page where the graphs are published? I don't think we have an equivalent page for the Australian market, but I have always wondered what the numbers are like here.
  12. Christiaan, that sales data will be interesting to watch, can you post where it’s recorded? Uncertainty over when subscription revenues will supplant traditional revenues is most likely the reason NV “can’t predict” when they will retire Service Select. If subscriptions go gangbusters, I expect we’ll see Service Select retired at the short end of ndavison’s estimate. And if uptake is sluggish, then they’ll probably hold off until their subscription revenues have met some magic number.
  13. I think the impression from the marketing, like the graphic @MarcelP102 posted above and your much earlier comment that @Art V responded to, was that the subscription model equated to continuous development, or that it might “bring forward” new features in a more timely and continuous manner. But the annual cycle will effectively remain as it currently does, it’s just that the new features scheduled for a particular release will no longer arrive as they have previously (mostly in SP0). They will instead be spread out and/or delayed throughout the cycle of future releases, until they're ready and stable for a service pack. The Chief Revenue Officer (ndavison) put paid to the earlier concept in this post . . .
  14. Yeah. Or to be specific, more viable for the usage / download patterns of an all year round, somewhat transient user base. The software will need to be stable across every quarter, not just the latter SP’s, to properly service the expectations of subscription users.
  • Create New...