Dieter @ DWorks

how many windows appear in the take-off, then? rob For the second window, you also can just use a hybrid symbol.

No one said it has to be a horizontal ribbon. I wonder why people always think a ribbon is horizontal? I see a ribbon as contextual toolbars where when you add one, you have an extra tab, .... A ribbon can be so much more than what we see in Office... Like a customized workflow, ...

I find the "ribbon" interface very cumbersome in every application I've used it in, however a wish is a wish and i'll certainly submit it! The ribbon is just something you need to get used to, but once you do, and if implemented in a good way, it works perfectly!

Or like Visual Studio or any other professional tool 5) A context sensitive ribbon.

What I'm proposing would solve all of this in a better way. Think of it as: - You have stories, which basically will be the same as we have now. - You have a list of level types for each story, each with an elevation relative to the story they are in. (Elements then can bound to these levels. These have nothing to do with design layers. - You have a list of design layers for each story, each with an elevation relative to the story they are in. (These have nothing to do with level types.) Why would this be much more simpler to work with: - You have less design layers, only those you want, and you don't have to think about the connection to level types as there will be none. It will be design layers like we now have, but without the level type link. - You only have one kind of layers in a story. Right now we have two: Those that are attached to a story and those that are attached to a story AND a level type, which makes it harder to keep track of things. - It will be more clear what is what. You simply have a story with reference level types that you can use to bound elements at, and just your design layers to draw, which can belong to a story.

so would the design layer move when you change the story elevation? I think of stories as a way to group design layers together. This seems to keep the concept simple. When you change the story elevation, all the design layers in that story change. I like the elevation of the design layer relative to the story. That's not what I'm asking. Design layers should be able to be in a story so that their height changes when the story height changes, but the story types should be set apart from the layers you use in a story. That way it's so much more simpler.

It would be so much simpler to understand: -You have stories, which have a name and a z value. -You have story types, which belong to a story, and have a name and a z value. -You have design layers, which can belong to a story, and have a name and a z value for their own. The benefits of this simple setup: -people will understand it much more, because it's straight to the point. -you can actually use the z value of the design layer for it's own. -you will not have hundreds of design layers, only the ones you actually need to put in the objects. -objects can still bound to story level types, as they can find on which story they belong by their design layer they are in. -... This can be done, as older setups/files could be converted: -keep all design layers, but remove the story level types. -set the z value of the story level types to that of the design layer they did belong to. This could be so much simpler. It's exhausting to tell the difference and working of this all over and over again, because it causes so much confusing to many.

You always can set the view of a sheet layer viewport to whatever you want to have a "look at" a symbol. I don't see what you are trying to do, maybe mixing 2D views with 3D views perhaps? If so, then use hybrid symbols instead. Please give an example of what you are trying to achieve.

??? But if they are 3D, then they will just render fine in the elevations, unless your elevations are 2D? If they are 2D, make 2D symbols out of your 3D one, once the work, but faster than you do know.

I checked the preference, but still see the caching behaviour and I don't know why. I can see that it sometimes notice the changes immediately, but sometimes not.

Hi, While trying out the Python world in VW, I found out that VW caches the scripts as changes aren't seen immediately. Very annoying to always restart VW after each code change. Can we disable this caching?

I tried some things out, and it seems that importing modules doesn't work with encrypted plug-ins. You will always need to deliver the python scripts and I see now way of protecting the code. Can someone explain how we can protect our code if we want to write python scripts in VW? Encrypting the plugins with px files worked as they just got included into the plugin itself.

What will happen when a plugin is being encrypted? Will those extra modules be included like px file did, or do we have to deliver those modules with the plugin? And if they aren't included inside the plugin, how can we use self-made modules as our libraries over several plugins effectively?

Drawings, 2D and 3D are just representations of the real thing, and communication is Always needed! Apart from the representations, there is also a book with all the descriptions and details. So I don't see the problem...

The user data folders aren't located there and are read/write by default. The best practice for custom libraries for VW is create a new folder where you want it to be. No upgrade/update troubles and all in one place so that everyone can use them.

One of the many reasons the roof tool is not usable in real world scenarios...

The 'problem' you are seeing is just that Windows protect program installations so no user can do harm accidentally. So they are set read-only by default. I find this a good practice, as the user has no interest in those folders. They are only for the program to run. You can however as a user delete and edit those folders and their content in your folder explorer, but you'll have to confirm those action. I guess that not all programs can work with that and see those as read-only.

I suspect that you do not have any write rights on the files. Plus it's far better to create your own library folders.

I can tell from experience that even for a small house, it's much easier to work with stories, because you don't have to remember all the heights and can just bound to your levels, which are named. This makes it much easier to design everything. You have less calculating to do. Edit: It are the level types that are important, stories are just a container for these.

Is the trial already available? I did not get the e-mail saying it is. Please don't tell me that it looks at your location to restrict trial downloads....

Split levels are possible, also the one you describe. I always recommend drawing out a section by hand real quick, and then determine the real stories you need. For these three real-life stories, you will use one in VW because of the overlap restriction. All the rest will be handle by level types, which is very easy to do. You will have more option bounding your objects to those level types. If you need any more help, just ask.

Yes, no more copy, subtract, past-in-place....

So the 3D objects are just being cached then? Let's hope memory usage is done right then and that very large 3D models can be handled...

Apparently, still no roof components, no stacked walls, no wall finishes settable for each room, ...

Projects levels? More like Elevation Bench markers connected to project elevations, they adjust accordingly when Story elevations are changed. Ooh, finally a full-baked integrated implementation.