line-weight

Ok, I think there is some kind of bug here (at least in VW2025). If I place a stake and choose that option first, then I get BNG co-ordinates. But if I place a stake and first choose lat/long, and then change that to EN, it doesn't give me BNG co-ordinates it gives me a version of the lat/long values

Yes, I seem to remember on other threads discussing this, that some people with loads of memory (like 96 or 128) were still seeing it fill up and start going into swap, until restarting VW. That was in the context of being told that the problem is simply that you don't have enough RAM, which I don't think is the fundamental problem. Having loads of RAM just allows VW to engage in bad behaviour for longer, before you start noticing it.

Yup. Basically yes. That's right in principle. However I had hoped the tool would do some of this work for me, given that it offers the two "reference" points in addition to the main survey point. Additionally there is always going to be a bit of error, so I'm looking for a best fit, and this seems like something a computer should be able to calculate for me. There's another thing though, which is that as far as I can work out, neither the "Stake" tool or the "GIS Stake" tool seems to be able to report BNG co-ordinates, but the "Survey Point" tool can (not that it's very easy to figure out how - you have to know that you need to choose "Cartesian Coordinates"). This particular project, the survey I have is geolocated with reference to the BNG. I could go through the process of marking points with one of those stake tools, and trying to do the conversion to a different co-ordinate system myself, but that's then massively prone to me doing something wrong. I'd much rather the Survey Point tool marks the correct points using BNG co-ordinates and then I check directly against that. Not easily in this case unfortunately.

Well, I have come to the conclusion that this is not possible - you just have to adjust the rotation by trial and error until you get as good a fit as you can. Seems odd to me as it ought to be possible to provide two or more known points, indicate what points they should match on the drawing, and compute a best fit.

I have been convinced for some time that there is something wrong with the way VW uses memory. Specifically that it just uses more and more and doesn't seem to give it back. See previous threads such as this one or this one. It's never officially recognised as a problem. I'm working on a file at the moment. The drawing size is 280MB. I looked to see what the memory usage was - 36GB. This is on an M1 mac with only 16GB RAM so much of that is in swap memory. If I quit vectorworks and re-open the file, the initial memory usage is 5.6GB. Is it really plausible that an excessive number of undos (I looked, mine is 100) is responsible for that 30GB extra? 300MB per undo on a file size of 280MB?

That's sill thickness (beneath frame) not distance from sill to sash.

Another option might be to use a glazed door object instead because they have no frame at the threshold. I also don't know what "apron" or "casing" means in this context though

The scenario is this: - I have an existing drawing. - The drawing grid is NOT aligned to true north. - I have already georeferenced it to "near enough" using the Gelocate tool. That lets me set a rotation of the globe behind my drawing, using visual references. - I now want to precisely geolocate the drawing, using points 1, 2 and 3 within the drawing that I know the exact BNG (British National Grid) co-ordinates of. I have tried to do this using the Survey point tool. In the SP tool I can specify my three points - the main survey point (using my known point 1) and the two reference points A and B (using my known points 2 and 3). The diagram below indicates the result (exaggerated for clarity). The main survey point matches my known point 1 and that's fine. That point in the drawing will now report the correct BNG co-ordinates. However, the rotation of the globe is not quite correct, an inevitable result of me doing the original geolocation visually based on satellite images etc. So, survey points A and B do not exactly match known points 2 and 3. Everything needs to be rotated around the main survey point, by the angle I've indicated in blue. How do I do this? I can't go back to the Geolocate tool because it's disabled now I am using a Survey Point. Is my only option to unlock the Survey Point settings and manually change the "angle to true north" until I get as close a match as possible?

It kind of seems a sensible strategy for any company competing in a market dominated by one big player. Make it dead easy for people to get invested in your file ecosystem, etc.

Affinity announced their "big news" today. They aren't going to a subscription model as such. Instead the core apps are going to become entirely free, and you pay for a "premium" plan if you want to use a bunch of new AI stuff. This seems vaguely encouraging. The question becomes: what's their commercial incentive to keep the free apps good? Is the idea that you get lots of people bought into your ecosystem and then upsell tje customers who can afford it, to certain specialist bits? I can see the logic of that especially in the context of being in competition with a behemoth like Adobe. It means that even if you decide to pay for some of the paid features, presumably you still have files you know you can always open in the free app. Not so much the feeling of being held to ransom. The video editing software DaVinci works a bit like this I think. The free version is pretty full featured. If you have a captive customer base - that is, people for whom it would be a massive upheaval to move to a competitor (financial costs aside) - it seems a much friendlier approach to getting money out of them. Hello user - you're tied into our world - let us persuade you it's worth paying for this or that thing, but we aren't going to make it all or nothing, we aren't going to suddenly lock you out of doing things you could do until now unless you start paying up monthly at a price you have no control over.

I'm about to embark on trying to export a georeferenced file (to DWG or DXF). It's important that it is correct. My drawing has been georeferenced by the VW georeferencing tools which I don't entirely trust. It is not drawn with true north matching file north, so there is a rotation involved and it's this in particular I want to make sure is translated properly. What's the best way to verify that what I've exported is correct - to re-import it back into VW and check everything is as expected? Or is there an external application that can be used? Also, would it be normal when doing this to choose a couple of points in the model, and tell the recipient what co-ordinates these should have? So I say the corner of this building should be at X1, Y1, Z1 and the corner of this one at X2, Y2, Z2, and ask them to check that this is the case once they import?

You may need to post a file for people to look at.

The roof face itself needs to remain as a VW parametric object, so it can't be converted to a mesh like this. The skylight itself, it is interesting to see that making it into a mesh object allows this kind of stretching. The question is though, does this create a true solid object or just a hollow shell? Generally we want proper solids with fill attributes for sectioning purposes

I think what you suggest would work. I can't remember why I haven't done that. It's possible that it's something like I have built the side portions as proper extruded solids, because these are what show up in sections, but the corner pieces are extracted from a manufacturer supplied model and remain as hollow meshes. Or maybe the thinking was that if I needed to adapt the symbols to a different system I could just adjust each of the component symbols and it would then easily update across all my size variants. Haven't used them for a little while, would need to dig them out to remind myself. Of course, all this is exactly the kind of problem that would be solved by a proper, functional, parametric object. Perhaps Revit users get those.

I ended up building my own rooflight symbols (as it happens, Fakro rather than Velux). In fact each rooflight consists of a symbol each of the 4 corners, plus a straigntforward(ish) extrude or set of extrudes for the middle part of each side. If I want to make a new symbol for a rooflight with different height/width then the adjustment is made by changing the extrude lengths and the more complicated corner portions remain the same. This way I can make any size rooflight within a certain system, and have top, bottom and side profiles (which are usually all quite different) show up correctly in detailed sections. Downsides are that the rooflight frames get join lines when seen in elevation but I just live with that. All of the officially supplied symbols I've found to be useless in practice. Custom modelling takes quite a while but I've been able to re-use across a couple of projects.

I don't even attempt to have VW cut an opening based on a symbol insert - I just manually make an opening and put the window assembly in the right place. I also am usually using at least two roof face objects (and internal one and an external one) at the stage where I am showing any kind of construction detail, so that I can make the hole in each layer where it needs to be. Normally they are offset and different sizes. I can see @Tom W.'s strategy making sense if you have multiple similar rooflights of course (I usually have a bunch that are all different).

Is this solution for when you want to select multiple objects that are co-incident with one another? I think the question is how to select multiple objects when each of those objects is in a different place, but co-incident with something else.

I've wondered about this too! It's a pain if you want to do something to multiple objects that are coincident with other things... End up having to deal with them one by one.

That 70p per hour rate assumes that someone (a) spends their entire working day, every day, working within the vectorworks package and (b) of the time spent working within VW it is all doing billable work. Neither of these things match reality even for junior members of staff.

The hours of my life that I lost to working out what catalogs do, I will never get back. My advice would be just don't go there.

Yes I'm in the process of understanding the curb tool. As far as I can see, the standard method for a dropped curb is for the whole dropped curb area including the sloping portion of pavement behind it to be modelled as a symbol which is inserted into the curb. This is not really what I want for the kind of situation I show in my screenshots in the OP because I am looking to model existing conditions each of which is somewhat unique and irregular. What I really want is to insert a line of curb stones and have it control the elevation of the surface immediately in front of and behind it, so that in most places the height difference is the curb height, but in some places it's the same. It appears that this may be possible using the curb as some kind of site modifier but I've not got that far yet.

I have to say that I never feel solidly in control of class visibilities - and also the settings that determine the what class the next drawn object will appear in (including whether or not attributes are by class). In the case of the latter, there have been discussions about this before I think. It is quite probable that VW does everything entirely consistently, it's just that there are so many settings that can change things inadvertently. So technically it's user error, but it's actually very difficult for users to keep track of everything that is happening. On top of all this there is the whole thing about what happens to new classes - whether they are turned off or on in pre-existing viewports, saved views and so on. It's just one of the downsides of having such a highly configurable software I guess.

I'm often a bit unclear about this too. However I just tested it - for me, clicking through to the design layer from a viewport, with "display using VP attributes" ticked takes me to the design layer with the classes turned on/off as per the viewport settings - as expected. If I then exit the viewport back to the sheet layer, and then go directly to a design layer, the class visibilities don't match what they were in the viewport. This, again, is the behaviour I think I want and which makes sense. In practice I seldom go directly to a design layer, and instead mainly use Saved Views as my primary method of navigating around the drawing. In a saved view you can decide whether or not to save class visibilities. Some of my saved views do save them, some don't (intentionally). This does occasionally lead to classes being off/on when I don't want them to be, because I forget that a certain saved view will change class visibility.

Ah, interesting. A regular surface hatch (ie not one trying to imitate colour fill) would do the job in many cases.

To expand on this, this (as far as i know) applies to both class overrides and data vis. Of the two examples just above, one works by using a shaded background render, and one uses stacked viewports, with a hidden line viewport on top of a shaded viewport. For me this is one of the frustrating limitations of data vis - 90% of my output uses hidden line in one form or the other and if I want to do some kind of colour highlighting it has to be done with one of these methods, which are liable to affect the overall appearance of the drawings and/or involve some overhead in extra stuff to manage. For this reason I quite often just resort to adding colour highlights in annotation space.