line-weight

What would be rather useful behaviour for walls is something that I'd also like to apply to site models: any solids that intersect them (even if they are not symbols "in" the wall would automatically subtract the volume. It would be useful not only for things like quoins and other external decorative elements but also eg. joist ends. I think in the vast majority of cases where you draw a solid that intersects a wall, you want it to fit in a hole/recess in the wall, not vice versa. It would also save a lot of time fiddling around with hole components for objects that don't really need to be inserted as a symbol. Hole components would remain useful for certain applications of course. In fact thinking about it there are many object types where this auto subtraction would be very useful. For example slabs, where a column passes through them, or roof faces where a flue pipe emerges. Like walls, in 99% of cases you want the volume subtracted from the slab/roof object not the thing passing through it.

All sounds very similar to where I usually end up.

A question that commonly raises its head! Sometimes I use wall styles when modelling historic buildings because I find it helpful, at least as a starting point, to have the various buildups set up in advance - where it makes sense to make assumptions. For example, I'll have styles for 1 brick, 2 brick and 3 brick thick walls, based on the relevant imperial brick sizes. And variations of these with plaster on the inside surface, and so on. It can be a quick way of testing whether assumptions about buildup match (or broadly match) what is coming out in the survey measurements. There can be advantages in having the majority of walls styled if you want to subsequently change textures etc. But of course that advantage gradually fades away if you have more and more styles.

Very much so.

I don't see much benefit in attaching quoin stones as a symbol within a wall - unless it was possible to specific that they were attached relative to the end point (so that they would move if the wall was shortened/lengthened). I would just make them as a standalone symbol placed in the relevant location. But wall joins are a bit of a weak point anyway - there are things I'd ive higher priority as potential improvements.

i think we're talking about the sort of scenario where you perhaps have repeating elements, like these grooves, captured all within a single symbol, that run the length of a wall but subsequently you shorten the wall length.

That looks to work for the OP but it does have certain limitations, which would or wouldn't be significant depending what was being modelled. For example if some of the slots are not full height but sit above or below the cut plane, or if they are intersected by the cut plane but don't extend right to the bottom, they are all going to need different 2d components, drawn manually. And I think the "fill" problem might pop up as an issue in some of these cases. In the example below I think I need at least 3 different symbols. If I was using horizontal sections I think I'd just need 1. Depending on what was being modelled, and how editable it needed to be, the horizontal section approach would have advantages if, say, I wanted to change the profile of the slots, because I'd just change it in one place. (Red line on elevation indicates where I want the cut plane)

I recommend trying a horizontal section viewport. I would not call it a workaround as such. I find it gives much better results in this kind of scenario.

This is what I was about to suggest. Also - if you decide to go with Horizontal Section Viewports - it's probably worth considering just modelling these elements as 3d solids rather than trying to force the wall object to do things it isn't very good at. That's what I'd most likely be doing. If you are sticking with Top/plan, isn't there a setting somewhere that determines the height of the cut plane for certain objects - could it be that adjusting this would give you what you want?

By this do you mean a copy & paste of the camera itself, from one viewport to the other?

I have a workaround method to sort-of get a hole right through (and keep it as a site model object) - I think mentioned in one of those other threads.

Unfortunately the rotation is rather crucial! I don't think adding RW cameras to viewports helps in this issue. If it were the case that I could define a single RW camera and then tell multiple viewports to use it, then the problem would be solved, but for some reason (and anti intuitively) that's not how cameras work in VW.

A version of that script that would let the user select the source viewport, then bulk select a number of destination viewports, would be a rather handy thing! One of the most annoying things about having to duplicate or copy-paste viewports in order to replicate a viewpoint is that it constantly messes up any attempt at having viewports named in an organised way. A typical use case: I have an "existing" and "proposed" version of a design. Maybe I have "proposed" options A, B and C, with different versions created by layer or class, and then selectively shown or hidden. All four viewports want to be looking from the same viewpoint, for a fair comparison. But if I want to change the viewpoint of all of them, I have to re-duplicate them all, rather than just changing it in one, and copying to the others.

Thanks, that's interesting to see - would it still work if drawing 2 had no camera attached to it? (edit) To answer my own question, yes still seems to work if I delete the camera.

If it was scriptable then you might think the eyedropper tool could do it ... but it can't unfortunately. At the moment what I end up doing is duplicating the viewport whose viewpoint I want to replicate, then using other means (such as the eyedropper tool) to transfer other properties to it (eg class and layer visibilities and so on). It's a messy way of doing it though. I've long thought it's a strangely missing functionality from VW. Unless it's me that's missing something.

If I have 10 sheet layer viewports, all of which are rendered views taken from the same specific viewpoint, there is no way I can set things up so that I edit that viewpoint and it replicates across all viewports - is that right? I don't think a "camera" can link to more than one viewport, and I don't think there's any way to define the viewpoint in a viewport style. ....or is there anything I'm missing?

It's nowhere near as easy as it should be! You might want to have a look at a couple of recent threads on a similar theme: One problem is that the relevant tools are a bit of a nightmare to use. The other issue is that if you want to cut the "ground" around foundations & footings that spread out as they go downwards.... you basically can't.

(This request may well have been made by others already. Ignore if so.) I can tell a saved view to "restore data vis", ie. make certain DVs active when I activate that Saved View. However, I can't directly tell it which DVs - as far as I can see, I have to activate the saved view, turn on my DVs, and then "redefine" the Saved View making sure the "restore data vis" box is ticked. Similarly, what DVs are associated with what Saved Views isn't shown in the Organisation dialogue, as far as I can make out.

Thanks once again! This appears to work fine. Rounding is not a problem - because any numbers I give it will have no more than 4 decimal places. Thanks for your help. This will save me a lot of time in the long run.

So: I have confirmed this is what happened: my HD had about 40GB free when I started a session in Vectorworks. The amount of swap memory used gradually goes up and up - it's got to about 36GB and this means that in combination with other applications (using about 2GB) there is less than 2GB left on the HD and Vectorworks tells me there's not enough space on disk to save the file I'm working on (I have to go and delete a couple of backups to make it work). Is that what's supposed to happen? Shouldn't VW know when it's nearly used all of the space on disk, and stop adding swap files at some point (or remove old ones)? Does this count as a "memory leak" or does VW make some assumption about the amount of space it can use on my HD for swap files, some amount that is higher than what I commonly have available?

I've realised that I think I want ConDateNum and DemDateNum fields to be a number with 4 decimal places, eg. 1870.0322 or 2025.0407. I've tried fiddling with various things in the script (the bits that look like they specify whether those fields are integers or numbers, and how many decimal places they have) but without success...can you point me in the right direction @Pat Stanford?

*bump* Any GIS experts out there able to answer this?

I can confirm, this works - thanks. Agreed that a better solution might be to rename the classes so they don't contain asterisks.

Thanks again! This worked perfectly again. It successfully acted only on classes with names beginning "**buildings". I realised that actually I might want to run it on all classes beginning with "**". So I swapped "**buildings*" for "***" but as I expected might happen, this resulted in all classes being selected, presumably because it simply reads it as three wildcards. Is there an easy way around this? I tried various things like ForEachObject(Execute, ((C='**buildings*' OR C='**roads*'))); without success.

@Pat Stanford - I've done a trial run of this and it did its work on 33,000 objects in maybe 20 seconds or so. At first sight, it seems to have worked perfectly. Thank you. Any problems are down to me not being 100% consistent in my naming, or using terms that aren't numbers. I see that the record format fields are text fields - and this lets them be populated by things like "1950?" or "now". In order to use the DV I'll need to make these into number fields, and make sure that only numbers go into them. I think I might need to investigate doing some kind of batch-renaming of my classes prior to running the script. That's for me to work out. I have one question... in your notes in the script you say: {Script assumes that every object in the file should have the record attached.} {If this is not the case then edit the criteria in the ForEachObject line} {to limit to just the objects requried.} I probably don't want the record attached to every object in the file, and just want it attached to classes within certain "parents". In the case of my examples, **buildings-streetname-streetnumbers-XXXX>YYYY I'd only want it attached to classes whose names start with **buildings- Can you tell me how to set that as the criteria?