shorter

Don't confuse 'Status' with 'Issued for'. Status Code is a uniquely ISO19650 construct that bears no relation to the actual use of the document, i.e. for planning, or for approval. For example, a drawing could be issued 'For Costing but the Status Code could be 'S2'. 'S2' alone is useless in defining the purpose of issue, so we woud normally back this up with a 'reason for issue' clearly noted on the drawing, if not in the revision/issue record too. Note: the above is not an 'official' approach but the one that we adopt because of inadequacies in the status code system. We have a similar issue with revision/issue numbers. We would use P01, P02, for preliminary issue, and then T01, T02 for Tender Issue, and C01, C02, for construction issue. Other than P0n, etc, the other two are not catered for under ISO19650. If you are not careful it is possible to issue the same drawing twice with the same revision/issue number, but with different status codes!

Which is why you need to turn it off, I suspect.

@lk642 you will find this oftens happens if you copy walls from one file to another or copy and paste from one layer to another, or if you have layer wall height or storey defined walls insode symbols. Delete Wall Peaks should fix the wall heights in these scenarios.

Exactly. If a window goes down to the floor, for example, do you include or exclude the bit of floor created by the window 'niche' in your area calculations?

Or do you mean: DRAFT WORK IN PROGRESS INFORMATION APPROVAL TENDER CONSTRUCTION RECORD COSTING ?

unable to reproduce, as is so often the case.

Crash.

And ditto when processing the changes.

When you use the TBM to modify multiple sheets, in multiple files, at the same time, it updates references in the files being loaded. Could we please have an option to suppress this? Thanks.

Framing Member...

That’s what the ‘add prefix’ option is for when you import a DWG.

Use filters, @Christiaan use filters…

Not necessarily.

Use both layers and classes.

This will break something.

Styles are not ideal tbh because they often conflict when referencing. A simple tick-box 'Make Default' in the 'New Storey' dialog, when creating a storey and associating the storey levels, would be sufficient.

All this is showing it that out of the box, software rarely works as we need it and some thought and preparation of content and having a strategy matters more. Sadly we find this is rarely the case and users end up confused by what 'should work' but doesn't because they have used content out of the box. In their defence, Vectorworks engineers cannot possibly know what we need. We have just spent over 300 hours building 500 objects for a client because the out of the box content, along with content from other sources like BIM Object and the NBS BIM Library, does not do what they need, and more importantly is not ISO19650 or COBie compliant.

Me too. Exactly. There are 'omipotent' levels that are always the same on all repeating floors (Vectorworks, show me a building type where this is routinely NOT the case) and instances, where we need to edit a bespoke level.

Sorry, I should add that the invisble record does not purge from the source file. It can be purged from the recipient file, ie the file into which the source file is referenced.

No. Only rebuilding the file deletes it.

Further to the storey levels comment... Just tested in 2023 and one would 'logically' expect any storey level set by 'default storey level' to be editable when changing the 'default storey levels', or is that too obvious? I have a 10 storey template model. I have storeys. I have storey levels set by our default ISO19650 compliant UK Residential project template, which annoyingly we still cannot import from another file... grrrrr The storeys are for FFL, SSL, etc. I want to change the SSL level for each floor. The steps should be... 1 Select all storeys. 2 Click 'Default Storey Levels' 3 Edit Default Storey Level, e.g. SSL 4 VW edits the SSL level in all storeys selected.

We use a mixture depending on the file and the project. A simple assignment of storey to a layer is good for minute adjustment of levels across the model, without using a plethora of storey levels, i.e. letting the storey define simply the FFL of each floor. In reality once floor levels are set, they don't vary much and if you are dealing with large scale rwsidential, there are only a few different floor to floors we use whcih are dependant on brick dims. The ground floor level though often needs adjustment and this of course changes the entire model. You can avoid this though by going back to the old drawing board approach of modelling at 0m, but issue drawings stating that Ground Floor FFL = 0m = 35m AOD, etc, so if the ground floor FFL changes, the model remains where it is. You simply adjust the reference elevation and coordinate this with your consultants. The inability to change all storey levels in all storeys, though, is an absolute pain on larger projects and more time consuming that adjusting layer elevation! Creating a content library that simply sets walls to anticipate layer elevation and layer wall height is a very quick and reliable solution and avoids the issue @Ryan Russell mentions, I think, where the OOTB walls are looking for specific storey levels, particularly inside components and if they don't exist cause the wall to remain 2D, and this causes much confusion (we have had lots of supprt queries related to this one despite us saying 'don't use the OOTB content!').

Unlikely...! The only objects left in the source file were symbols. Of course, it would not be beyond the realms of possibility for the invisible record format to jump on to a symbol, but there were definitely no title block borders in the file, to the extent that once we had copied the data from the file into a fresh file, by referencing and binding, the record format magically disappeared. Yes. I would not be able to replicate it on demand.

You have to buy Revit, export IFC, imprt IFC, check Revit file and then issue. We offer this service if you are interested.

We have been victims again of a 'bug' caused by indescriminate importing of DWG data. Somewhere along the line someone probably imported a DWG containing a drawing we issued a few weeks earlier, i.e. a consultant did what we ask them not to do and send our data back to us in their DWG. Never understand this particularly when it is quite categoric in all BEPs I have ever read, and in all our CAD data exhcange protocols, that you simply do not issue data you did not author. Anyway, the hidden record format 'Title Sheet Border Data' or somesuch, remained in a file that was referenced to a number of files containing title block borders and has corrupted the title block, removing data because the rogue record format was out of date. It is a common issue with resources. They tend to conflict if you don't manage them properly. Ordinarily, we know how to fix this but in this case the issue was peculiar. Ordinarily, we can edit the resource and ensure it is up to date. However, in this case we couldn't. The Title Block Border record format is invisible, and only edited via the Title Block itself. It kept telling us it was referenced even after we had removed all references and purged, insessantly, and there were no title blocks left in the file. Anyway, after a couple of hours or detective work, we found the errant files and rebuilding them freed ourselves of the scourge and we we able to stabilise the sheets. While the invisible record is a pain, and we were able to fix it, the issue I have is not that it's invisible or that we spent two hours of our lives that we are not going to get back caused by the original malfeasance by the autocad user, my grievance is with the way Vectorworks will think something is referenced when it isn't. If I create a file A, and reference it to file B, I would expect any resource placed in file A to become a referenced resource in file B. However, in some cases, a resource in file A, that is 'inactive' or 'not in play', i.e. not placed in file A, becomes a referenced resource in another file. Why and under what circumstance would you ever want that to happen? If I reference a resource I do so deliberately and with aforethought. I do not want resources referenced 'by proxy'.