_c_

What is truly saddening me -as most old users- is that old problems are never resolved. New features, new features, new features is all there is. And new features always come out with some devastating flaws. There are exceptions, I'd like to mention them for motivating those who put so much work and energy into VW. If I look at the development of complex features who took their time and released slowly: Subdivision, Data Tags, DTM come to my mind. Title Block had a devastating start, but the responsible engineer stood patiently -bravely, really- his ground and fixed ALL of the issues giving the tool unprecedented power too. This tool is now at a very high professional level and I use it every day without problems. (And that engineer is daily around helping people resolving all quirks they might encounter, I love that.)

That's my only joy in that list

I wish this too.

Hello Juan, VW is getting more than ever unintuitive and cumbersome to work with. How does this fit your declared target? And that's what worries me. Are you sure that you are doing what we want? We have again and again the situation where you implement things that we never cared for and blatantly skip those we all wanted differently. And you didn't know. And you are surprised and sorry. You are clearly going the path of fully generated plans (horizontal sections). As it is now, what your development does to us is just making most works involving anything that is not lines and polys extremely time consuming, insanely complex and there are bucketloads of mistakes at the end too. This comes with a stubborn disregard of our needs, our drawing standards. So I ask, why should we bear with you on this? We want our SI units, our standards to be realisable out of the box. We don't want to cut a section to see if a plan is right. We don't want to add things into annotations if we can do it otherwise. We can't have everything in one file. We create in 1 hour but edit 1 year, always bear that in mind. And we definitely don't want to derive everything from 3D, if we can avoid it. Even the most complex BIM project is very sparing on the 3D modelling. Specially, the large ones. You are leaving us alone fencing with the infinite frustration of VW's 3D edits. Year after year. Slab modifiers, 3D Wall holes, 3D in Autohybrid, 3D in symbols, Extrude along paths. Etc. There is no snap, there is constant view turns and twists. Are you fixing this kind of edit first? Are you making VW more direct? Less dialogs? Less interface scattering? We are left alone with daily work with often cryptical tools that never, ever work as we need them to. Please do finish what you begin, and really do Focus on us.

Hello Thomas, since most times we need to work on permits (LP4) and construction drawings (LP5) at the same time, and this for a long time -perhaps years- we work as for LP5 and load the project by reference old style in prepared files for LP4. These files are set with the attributes are as needed by BauVerVO (previously BauVorlVO). There are world of differences across the two displays, as you well can imagine. It is very fast to change the attributes of a class in a document, compared to deal with all overrides/visualisations etc. Have a prepared class file > New > Import. Done. The display is perfect: colours, line thickness level of detail, hatches, etc. And the maintenance is ZERO. We can then archive the plot file easily as required. The file is always as small as it can be and we can restore the exact content for "Tekturen" or whatever reason. We have some 3-4 display standards loadable by class import. Fare with this system since references were introduced, also on large projects spanning with great many buildings and couldn't be any happier.

Actually I always did this by class. Document overrides, not even class overrides. If you are doing what I think you are doing, you just need black, red, yellow. So your best friend is a dedicated document where the attributes are as needed. If you are doing German permits the level of drawing standard requirements is only achieved with a dedicated doc. I call this plot file.

You can fliter your data visualization by set up class/layer visibility set up IFC as needed and use that set up custom records and use that and any combination of the above (remember that you can add multiple DVis)

Hello, this is one of the power functions of the stair: the widget is not static, it is interactive! You can define winding threads slanted (oblique) threads by clicking on the thread in the widget, where you want them to start. If your Oblique Bottom/Top thread is not zero, the yellow will show you what happens.

Because they see it as the other way around: materials replacing classes, at least a large number of them. And since you can have a material fill use a class (the fill portion of the class, that is. Not the pen), if the classes ruled the materials the conundrum would be total. It already nearly is.

@zoomer, @ComputerWorks given the infos above, you should be very careful with that Marionette script. There is room for real havoc scripting storey levels at the moment and Marionette won't go over Vectorscript. SDK stuff perhaps can fix things.

Then I filed this: [WISH] VS Stories: access to story level list by index The VS access to story levels is not up to the latest story development: It is not possible to fetch levels that are not listed either in the Level Types list or Level Templates list. It is not possible to determine securely if a level is used or not (meaning: has a checkmark in the "Edit Story" list browser listing all levels) there is no direct method to determine if a suffix is used as prefix In the attached file --> The level "test" is present in the story "Story-1", but not in the level templates How can we find it by script? GetNumLayerLevelTypes: INTEGER; won't count it. GetLevelTypeName(index: INTEGER): STRING won't ever find it by index --> "Layerless Level" has no checkmark, is not used in this story. How do I know if it is used or not, by script? In some case one can check if a a design layer is linked to the story, but not here. It is layerless. GetLayerForStory(story: HANDLE; levelType: STRING): HANDLE; won't find a layer, since there is none linked to it Please implement a list of levels story by story, so that we can fetch their name and thus infos using GetLevelElevation(storyHandle: HANDLE; levelType: STRING): REAL; if a level is in usage or not suffix or prefix

So, Sunday, 4:50 AM, we are in lockdown. Let's tackle this. In 2018 I filed this bug report: Story Level Types: eligible for any obfuscation contest Level Types are used in Story Level List Level Types list Level Template list The list of Level Types should always display all Level Types defined in a document (the stories). This isn't always the case (screenshot 1). There are a number of situations where this list goes out of document sync. As a principle I have only files where I have no idea what is in those lists. If the Level Types list is not complete any edit of Level Types whose name is not in the list is impaired (screenshot 2). if the Level Type should be re-used, the user must retype again and again its name. design layers whose Level Type is not in the list don't show that level properly (screenshot 3) no VS-script access The Level Templates list is even more cryptical, I gave up on it totally. It can mix things up to the point of total obfuscation. It seems to mix parts of the Application's default content, past used story levels and God knows what else. (screenshot 5) OUT OF SYNC CASE: DELETION: You can easily delete a level from the Level Type list, it will remain in the stories if in usage, the list wont ever show it again. OUT OF SYNC CASE: IMPORT: You can also import from another file a design layer whose level is not included in the Level Type. The imported design layer won't use that level, but at one point but not immediately the level will show in the Level Type list Screenshot 4a: the properties of a design layer in another document, it uses a Level Type 'FarAwayLevel' Screenshot 4b: the design layer just after import: no trace of Level Type 'FarAwayLevel' Screenshot 4c: close and relaunch the Organization dialog, now it's there Please open the attached document, it contains a story whose list of level types has gone detached from the Level Type list and experiment with creating levels. Measure your own state of comfort and/or confusion. Story Level Type lists.vwx Story levels extreme test file.vwx

Hello Zoomer, thank you... no need to. I don't have them because I remove them. I don't use the German VW, unfortunately. Live in Germany but seldom speak German. International offices are English speaking and I never could learn German enough.

Good to know Zoomer, I will give it another go now. As of having the original USA storey levels, I don't.

I think that one of the misconceptions we somehow developed was that levels are entities, objects. They are not. And one should know, and never forget, that they are NOT needed for exporting a conform IFC file. They were developed as facility for us to draw easier. Go figure. I was extremely reluctant to accept the reverse-offset-from-the-top-measured-backward-from-the-bottom system of walls when it came out. Some of you might not know, but there was a very short period of time where you could define walls exclusively by offset to storey levels: The wall height was only calculated. It was awful. Biplap reacted to our cries of desperation and added some sort of built-in command so we were able to enter a height simply. This is what we have now. I think that we have a number of fixes built in the various storey levels interfaces and that's why we cannot export them or script them. The fixes are performed from within the interface itself. And this means: rewrite the thing from scratch, it should have been done long ago. I stay today to my opinion of that time. Storey levels drive everyone insane. Still.

I told you.

Hello @zoomer, below an extract from my notes from the last time I tried this, VW 2019. This is all bug filed. I thought to do the command in one hour, I worked on it for weeks and then had to abandon. It is a bit geeky, forgive me, but I want to go to dinner 🙂: { as of VW 2019 there is no way to fetch the association status of layerless levels only if a level has a layer (GetLayerForStory), it is possible to determine if it is linked to the story } { Stories can have extra levels, now try to fish them out from the document } { DON'T SET THE ELEVATION!!! } { If you set the Layer Elevation of a layer linked to a story level, then both will be faulty: * the level won't show correctly in the dialog * the layer elevation will be wrong } { the suffix name must build a unique layer name or the creation will fail! } { keep SetStoryElevation after creating at least one layer with one level. SetStoryElevation needs the story to have at least one layer, or it will fail using some weird values } { SetLayerLevelType needs the layer to have at least one level or it fails } { THIS CURRENTLY CAN'T REALLY BE DONE: NO ACCESS TO THE SING LEVELS (VW 2019) } lvlTypeCnt := GetNumLayerLevelTypes;

You can transmit the stories, that's easy, but not the levels. Not completely. There are things that cannot be accessed in Vectorscript.

I found out that for the moment materials cannot be used and removed them all. As stated elsewhere, the level of added complexity is untenable. The attributes are permanently in the way, you fix something in one place, it breaks the display somewhere else. And you cannot use them only for the data, there is no way to tweak that. With materials, we need multiple classes for the same material, we increase thus not only the complexity of what object's attributes are -see screenshot below, 4 ways of setting up a tool, explain each of them to new users- we also inject more classes than before, duplicate materials just for the display. This is exactly what the introduction of materials wanted to streamline. And all this still won't get us a display, since there are still all the overrides and settings of viewports and section viewports. If VW was a simple and visually direct tool for the architect, this is, I am sad to say, long gone.

There is an expectation: you must place the elements in a counter-clock way relatively to the arc. If you don't, it won't work. This is one of the ancient VW pitfalls for new and old users alike. Like we knew or cared about counter-clock or not. Bug-filed, but unfortunately this is the way it will stay, likely forever.

Yes, this is the limit of VW. BTW, a number of us cope with it no problem, but you'll have to split. There is nothing wrong in splitting the content, you'll see that you gain in efficency under many aspects.

Hello, generally that's the point where you begin splitting the content and use references for assembling drawings as you need.

Steven, apparently with the latest version 9.12 you cannot load multiple files any longer. Don't override the old version, should you have one.

The default data file is not supported by a workgroup folder. It is plain ignored. There is no full vectorscript access either, so even that is not secure. I have a command for transferring storeys and levels through xml files and see all strange things happen. I believe that levels and their storage should be re-done entirely in a way that is comprehensible for us. At the moment it isn't.

Hello Stéphane, if I understand correctly what you did, you are exporting one building pro design layer. You assemble the buildings using one singular DLVP pro building, am I right? Should that be true, please mind that while this might seem visually correct, the resulting IFC structure won't be. A multi-floor DLVP doesn't distribute automatically the layers into the proper storeys. TBB_IFC_example.zip I attach here an example of assembling stuff across various files. Please mind that this is a totally simple example, it won't be as easy in the reality. I used "old-style" referencing for clarity (and I prefer it for a number of reasons). There is: a source file with some variants of floor plans (load repetitive content by reference into other files) 1 file for building 1 (export from here building 1) 1 file for building 2 (export from here building 2) if there was a site plan, this would need to be exported as stand alone as well and the option "Export Site Model" to be enabled in the IFC Export settings. everything is assembled in Solibri. Note: I just noticed that Solibri Anywhere 9.12 doesn't allow any longer to assemble files. Use 9.10! I am for some reason kicked out of my Solibri licence and cannot check properly for collisions etc. Sorry if I let some ugly error around. VW is not developed for multi-files projects and you'll soon reach its limits. It can be done, but it won't be fun. About IFC 4: VW is certified for IFC 4 export, import isn't there yet. More here: https://www.buildingsmart.org/compliance/software-certification/certified-software/ Depending on how strict your exchange requirements are, you might be better off with IFC 2x3 and since we cannot import properly what others send us, I definitely suggest you to agree upon IFC 2x3.