Matt Overton

Could just get the staff member to put their iPhone in something like this and just use facetime. https://www.amazon.com/Action-Mount-Extender-Smartphone-Smartphones/dp/B00V73H02U/ref=pd_lpo_107_tr_img_3?_encoding=UTF8&psc=1&refRID=MDG7WDF9P80KF1JF0PR1

If you use the "Plug-in Manager" to set a default class for the drawing label then they insert in that class even when created inside a viewport*. *wasn't sure if "Create Detail Viewport" but after checking it seems to. Now it would be great if the installer had an option set empty default class to None without needing to go through everyone.

I take it then that this should be considered a bug in the wall, slab and roof styles that they don't respect the users choice to Use class attributes at creation not a wishlist item?

Pining None and say the half a dozen of the most recent user selected classes at the top of list could be very handy. Like it is with other very long lists like Fonts.

This and I Agree with Jim Smith. The number of classes generally increases with the complexity of the project, we work hard to keep it down but it happens. The number of line styles is generally static to project size (5 solid various dashed, would be under a dozen 80% of projects). Being able to control lines from one spot would be a massive improvement. Some version of line styles would make it easier to tweak line weights to different scale drawings. We could keep heavy line the same weight while making the lighter lines relatively more bold. In a way not possible with a single scale factor. Oh so left field - Even better would be to embed behaviours in them so we can leave it to the Computer Automated Draftsperson to handle the complexity the computer needs. If we had line styles then part of the style could be a control how that line diminishes with distance from viewing plane (section cut, perspectives and elevations)? So super heavy lines for ground plane could fade really quickly. While say a bold line used for Solid elements might not fade at all and stock and light lines for window details could have linear fade. Bingo - nice looking elevations/sections every time.

In the hopeful case that the engineers are building a system that can auto-display and dimension Storey Levels in veiwports. Would it be worth considering that building grids should also be an organisation system similar to storey levels and layers instead of a graphic element we place? - Then the same code would take care of drawing them on page for us. - Like levels we could then define object relative to a grid or offset from grid (like a column could be X= grid A , Y=grid 1 + 200 , Z = storey 3 slab) Might help with the rounding issues as well. Given this is how we always avoid the problem in large drawings anyway. Dimension critical stuff off the grid allow the float to occur between.

I wonder if the objections to "drawings" would be a lot less if the double handling of information the computer already knows was lessened to significant extent and we could mostly concentrate on telling the story.

Might take a bit of tweaking to get the density of tags right but I can see how we would make use of this. Would be useful if class over rides allow it to be turned off on selected viewports.

In that case I'd still use layers. Lots of layers keeps most classes on by default and easier to manage. So, isolate the effected wall(s) on to new layer and then generate the options as duplicate layers. Once the options are presented and decided you can save an archive copy of file then clean house in the working file. I wouldn't call it best practice it feels like there is a better solution. With new xml text files, project sharing system and the like it feels like we should be in line to tools like GIT that the engineers to handling versioning in the code they use to write the software.

Also, the interaction of project sharing and Layer creation could use some work. The operation shouldn't fail and revert just because one of the affected sheets/Viewports is currently checked out.

Better still use the section viewport checkbox so we don't need to hunt multiply places to find why it hasn't worked.

Yes very much in support of a clean slate set of shortcuts. Move common commands to easy shortcuts. Also, like your suggestion of a category shortcut with refining key. Would help create a fairly logical set of shortcuts. I'd add it would be great if the computer could maybe get the right secondary key based off context. Thinking for commands for clip, join,... where there is a different command for solids vs 2d planes.

A 3D crop would be useful for working with architects who insist all sections should run through the ridge. Then disparage the software when the selected section doesn't run through the right features of the building. We could tweak a section without changing the section line and avoid going through in plane walls, or make sure it goes through the most useful part of a minor detail like a floor hatch.

Why is if I a drag a door out of wall it keeps its orientation, but I then drag it back in it flips 180º?

Have to do a lot more testing in order to get my own confidence up. Would certainly be useful if we can prove it works or find why it doesn't.

Best take so far is the attached. Circles are set at 10º intervals and in principle it's working. Seems the camera is fairly adverse to pointing straight up in the air. So you have to manually set the 3D view, also it's hard to set the view field so not confident yet its showing all it should. Also, have to play with perspective so see if I can't get circles evenly spaced like a lot of the diagrammes do. Heliodon.vwx

Also useful is to add "-------" as a default storey layer then every storey has a divider when created. Yes ultimately would be better the have navigation pallet do the sorting without the busy work .

I agree VW could be far more helpful in many ways when it comes to drawing numbering and set organization. I mean if we didn't have to have unique numbers it would also make re-ordering a drawing set significantly easier as you could just re-number a drawing where it needs to go then renumber the rest to fill the gap.

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.