Jump to content

_c_

Member
  • Content Count

    1,692
  • Joined

  • Last visited

Community Reputation

738 Spectacular

About _c_

  • Rank
    1000 Club

Personal Information

  • Location
    Germany

Recent Profile Visitors

2,060 profile views
  1. _c_

    2021 Public Roadmap

    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.
  2. 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.
  3. 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.
  4. 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)
  5. 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.
  6. 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.
  7. @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.
  8. 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
  9. 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
  10. 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.
  11. Good to know Zoomer, I will give it another go now. As of having the original USA storey levels, I don't.
  12. 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.
  13. 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;

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

√ó
√ó
  • Create New...