Matt Overton

Yes. Everywhere there is an option to replace, replace with duplicate and edit would be super useful. Styles, symbols, walls, roofs, slabs, doors,..., the works.

Something to ponder for the weekend. Slab components work on the assumption that they are there until told otherwise by a modifier. This is useful (e.g. set-downs for bathrooms and edge details for waterproofing) but to me misses an important part of how slabs are thought about. Most the time we have parts of the slab that work in the opposite ways. So things like band beams, edge thickening have a vertical zone in the slab but are generally empty and defined by what is there not what is not there. We can do this now but generally leads to complex modifiers that hard to edit especially seeing we can't split them and basically need to delete and start again for even minor changes. Could we have an option that treats Slab components as empty until a modifier adds to them?

Yes this would be great.

I'd say 2017 is more the problem than the hardware. 2016 runs noticeably better on older hardware than 2013 (and 2014 from all the I've heard). While 2017 is a significant drain on performance and runs worse all the hardware thrown at so far.

If uneditable text is grey and editable text is blue. Why are the uneditable labels blue not grey?

If the single layer had all the function of either layer type then you can create the separation to suit yourself, not the programmers. It's not like the programmers are even committed to the separation given how often you see layer lists that don't demarcate them correctly.

This is great keen to read and follow along.

If the Mac Version used System provided Tabs (instead of the horrible 3rd Party library) then they would work like this. Just Saying.

Duet display would be perfect if the touches were separate to the mouse. Trying to use it for extra screen while on the laptop over summer. This is the most frustrating aspect of it if you use as it touch screen you have to track the cursor back to the main work area. Which is mostly because OS X doesn't understand multi-touch. Still, shows great potential.

Does anyone use Vectorworks Remote? I ask because I thought it would be very useful when using Vectorworks on a smaller screen device like a laptop. Yet It really doesn't seem to allow me to free up much space at all. It seems worse on a larger screen device like an iPad as much of the screen space is just underused. It would be great if we could design the interface ourselves using docked palettes (eg the attached) then push that to the device that is remote. I can do similar with Duet Display how every the way MacOS treats the second display with touches means your cursor keeps being pulled over to the touch screen. So its more a second screen than a touch screen extension to the app. P.S. Also given many of us run multiple versions of Vectorworks at the same time It would be helpful the Remote Installer Disk Image had the version number in the name.

Also check out this thread for previous discussions. https://forum.vectorworks.net/index.php?/topic/44892-demo-plans-and-new-walls

Is there any real need for the distinction to remain between the two and couldn't we just have layers that are functional enough to be both? Certainly, in all the offices I've worked in we adopt this shorthand of layers meaning design layers and sheets being sheet layers. I do recall at least one the VW trainers in the Sydney area always taught the shorthand. So I'm not going to disagree with changing it in the programme for clarity.

These diagrams are perspectives looking straight up from the point of interest so in theory you should be able to set up a camera with the right settings to match. That said havent tried it in Vectorworks since minicad and it didn't work then.

Pre-miniCAD Vectorworks I see.

Holiday card and a teaser for one of our fun projects for next year.

Something like an Image Prop but for text would be very useful in this regards. Not just rooms or windows but wall tags comes to mind. Oh yes another great Tutorial document. Is there a collection of these somewhere?

It would be handy if the Navigation palette allowed us to sort layers by Z height as well as the current options of Name and Number. It would keep the stacking clearer and cleaner. Similarly and even more valuable in the views ports if we could set the layer stacking order to always be by Z height (name and number auto stack would also be handy). That way as we add layers as the complexity of the project demands these layers will fall in to the mostly the right stacking order without user interaction.

There isn't one of our current project this wouldn't be useful for. I don't see this as being any more or less complicated than current day to day and a lot less complicated when our world is complex*. It should be a lot clearer and more direct. Certainly this would much better for dividing simple models of neighbours building up to avoid cluttering the working layers. We could always pitch along side this much needed improvements to other features to help everyone even if they don't use this. Storey styles comes to mind as a way of capturing storey levels better than default does now and would be easier to update to boot. I'm sure there are others this is just the first to come to mind. I personally don't see this requiring a new tab as I think it would be better as one tab but use the hierarchical display within the storey tab. So you can see visually how it comes together. Layers could be assigned to a Storey in the same way they now if they haven't been directly created by this tab directly. *Seriously 24 storey building every floor shorten by 50mm to get a 25th storey in so much fun getting all that right again. Although this was pre-BIM and pre-storeys so the modelling was all about shadows and presentation no elevations or sections.

Why make another interface to show something visually when the majority of the programme is an interface for visual information? Also given this information we need tell others in a visual way why not just let us draw it how we need it and get the computer to work out what it needs from that? Instead of now when we draw it how we want it translate to computer code check computer has shown it right in dialogue interface then go about showing it relevant locations. All the while waiting for changes to mean we have to translate that change (and the next change) and make sure it's co-ordinated across multiple locations and formats. After all the promise of Vectorworks over its competitors was that it would understand us and the language of drawing better to help us get the results we want faster.

The only annoying thing (just to make those missing out feel better) the options for which approach are all the way inside the setting dialogue box on a tab. So you can't group select door and change them all at once. It would be nicer if you could control from object info. Still Dynamic Blocks / Symbols would still be very very useful for many many things.

Doesn't the sheet boarder still use a symbol for it's basic geometry? So couldn't you do the same thing when you are ready to sign add image of the signed stamp to a file specific version of the Titleblock symbol. That way all working projects use the most up to date symbol, signed of projects will be archived with the right Title block embedded in the file. That is how we do it with VAA titleblocks but there is also Stamp Field in those title blocks that can be used for progress stamps.

Must be physic this same frustration has been cropping up more and more although my thinking was more on the lines why can't the Key command just pick the right tool for the job instead of me thinking about. Yes I've been working with slabs and wondering why clip command works if I want to cut 2d out of component but tells me it doesn't work if I use the same key command. I mean all these tools have a system that checks if the context is right why can't a whole bunch of similar commends be on the same key command that finds the right command for me. If if this checking takes milliseconds still faster than me reacting to dialogue box dismissing it then thinking about where command is moving mouse to find the right menu item, after all so many new commands have been shafted with pizza box commands and not used enough to develop twitch. This to me solves the legacy issue as well as the new feature and the old features could be on the same command but the context checking could preference the new in new files. Would also free up a lot of easy key commands for more common uses.

Which means if they fixed the default behavour on one misses out if on rare occasions they really do want that corner. Although can't for the life of me think why you'd want just that one corner and not want all the others as well.

Sorry I meant within the profile space of the extrude. If you have multiple classes in the profile they get converted to a single class 3D object. If the final extrude maintained the the classes of the defining objects we could do interesting things without writing PIO to basically extrude multiple geometries along the same path. Like:- -LED strip lights - we could have an Aluminium carrier in one class and the diffuser in another with a glow texture assigned. -Gutters - basic profile for large scale elevations and sections, detailed linework and polygon intensive geometry for closer views. -have a simple basic cornice for general work then add a more detailed version that is only turned on for presentation and detail views.

Would it be silly to suggest profile could be class driven? I.e. have a low detail and high detail profiles on the same path as a single object. Also options for end caps or mitres, and insertions of symbols along path would be handy. Still will take any improvement.