Jump to content
  • 1

Export of Saved Views, Stories+Levels and Viewports


zoomer

Question

As I want to transfer as much as possible content from a possibly corrupted file

to a healthy, empty file from scratch,

I'm looking for a way to get my Story settings + Layers default Levels + Levels and

Saved Views into another file.

Maybe that can't work for all kind of Saved Views (?) but it should not be impossible

for things like Saved Views that contain only Class and Layer settings.

I got in my Viewports by the, quite tedious,

Group Sheet Layer Contents > Clipboard Action

(Lost all VP Names again and all Layer Class Settings have to be redone)

Maybe there could also be a better solution.

Link to comment

25 answers to this question

Recommended Posts

  • 1

+1 to the Recover utility.

However, it should not only put everything that is not damaged into a new blank file but also try to fix or at least mark/list problem objects (e.g. incorrect geometry, items not imported into blank document, empty records (because the data could not be recovered) etc. etc.) or give you the option to either decide on an item by item case or to skip those damaged objects if you think they'll cause problems again.

This could allow for a two step recovery, first recover all non-damaged items and then all damaged items in a separate file so that you can check in how far they will still be usable or should perhaps be recreated from scratch.

Sometimes it are the partially recovered items that keep causing problems, so a way to identify them might be useful.

Link to comment
  • 1

Regarding being able to transfer Saved Views between files, I just want to add my two cents:

Let's say a Saved View is created in File A which has lots of classes. In another file, File B, some of those same classes exist, but not all of them. Say you go to import the Saved View from File A into File B, we should be presented with the option of what to do with classes that don't yet exist in File B: either import the classes (giving us empty classes we can then use), or to ignore them, giving you a Saved View which only affects the classes already existing in File B.

(Obviously Saved Views are more than just Classes, but I wanted a clear example).

Not sure if this would be better as a pop-up or as a VW preference / document preference.

Link to comment
  • 1

I the support able to determine and delete all corrupted data from a file ?

As I currently have one file for overhaul at support as it showed some strange

behavior of losing Objects Names.

This was thought to be my new .STA file for future projects.

Of course, to save some work, you will create STA files from an existing project.

And it is not so nice to know that your project file may have the same issues

After deleting/purging everything visible and accessible, it will still contain

3,3 MB of dark matter.

Link to comment
  • 1
There actually is a built in corruption recovery utility now. [...]

However a file that is corrupted in the sense that it is still open-able, but unstable could certainly due with an automated method of full object import, I think I may have requested something similar but the original post functionality would have to be added first before it could become automated, i'll re-mention it.

It's like an automated audit? This begs the question how it determines to become active. Do you happen to know and can you give some insight what triggers this (if you are allowed to share that information)?

Maybe Vectorworks could have an audit tool in the future that can be activated by the user to inspect an open drawing for problem/damaged objects?

Link to comment
  • 1

Many MB you are not aware of coming from can come from VW collecting

RW features in Ressource Browser, each time you try some render things.

An unneeded HDRI Background in Ressource Browser can easy have 30 MB.

These are things you will get rid of by purging.

I have cases where a Background that lost its name can't be accessed/deleted/purged

anymore, even it is not assigned anywhere.

(Like anything that lost its name can't be selected or changed in Ressource Browser or

Navigation Palette anymore in VW, beside there is a way to manually selecting it graphically.

Link to comment
  • 0

++++100

Tangentially related, part of this solution should be a utility to 'Recover' a corrupted file, instead of having to do it all manually.

(Apparently I wishlisted this a while back: Means to repair corrupt Vw files).

Ideally, this 'Recover' Utility should export everything required to reconstruct a file: classes, layers, stories, saved views, SLVPs with Annotations, resources, etc. Everything.

It seems like it shouldn't be too dissimilar from the process used when converting an old version file into a current version, except that it is exporting everything into a new, clean file. Perhaps this could also eliminate some of the problems seen when using a converted file.

I would think that VS or Pythonscript could do most of the work as far as duplicating / exporting all of the Classes, Layers (names, scale, stacking order) and Stories / Levels.

Link to comment
  • 0
  • Vectorworks, Inc Employee

There actually is a built in corruption recovery utility now. However if it WORKS, you will never see any mention of it, it just suddenly takes a long time to open or save an affected file. It's very behind the scenes but has reduced file corruption dramatically.

It used to be a daily occurrence to see corrupt files in the Vectorworks 12.5 / 2008 era in Tech Support, now we get only a handful a year and they're often tied to other catastrophic failure (networks going down, power failure, crashing during I/O etc)

However a file that is corrupted in the sense that it is still open-able, but unstable could certainly due with an automated method of full object import, I think I may have requested something similar but the original post functionality would have to be added first before it could become automated, i'll re-mention it.

Link to comment
  • 0
There actually is a built in corruption recovery utility now. However if it WORKS, you will never see any mention of it, it just suddenly takes a long time to open or save an affected file. It's very behind the scenes but has reduced file corruption dramatically.

Is there any way of knowing what this utility is doing with the hope of manually repairing whatever corruption it is encountering?

eg. I have a file that takes an age to open - every time in VW2016 and probably deleting a troublesome EAP or somesuch would repair the file to perfect health.

Link to comment
  • 0
I the support able to determine and delete all corrupted data from a file ?

As I currently have one file for overhaul at support as it showed some strange

behavior of losing Objects Names.

This was thought to be my new .STA file for future projects.

Of course, to save some work, you will create STA files from an existing project.

And it is not so nice to know that your project file may have the same issues

After deleting/purging everything visible and accessible, it will still contain

3,3 MB of dark matter.

This is why being able to decide on "damaged" objects to be imported into a new blank file or not is so useful. Of course it is no guarantee but it may help.

3,3 MB of dark matter is quite a bit. I'm curious what this could be, but I suspect it is damaged data that the program cannot access/handle and therefore not purge either and simply "ignores" it during a purge. The downside is that it can raise it's ugly face once a tool tries to access this dark matter because it notices its existence in the file.

I've had something similar with AutoCAD Map many years ago where it would crash on opening an AutoCAD Civil file. It later appeared to be some custom data info that it could not interpret but it would not ignore it either. AutoCAD LT simply ignored this data because it was so "dumb" couldn't detect it at all so that is how we could open this file. Maybe we need a "dumb" version of Vectorworks too. ;)

Link to comment
  • 0
Ideally non-used renderworks objects/stuff should automatically be purged upon closing a document.

I regularly have - and want to keep - many unused RW textures in my files: Various texture options for wood cabinets, flooring, roofing, etc. that I may have used at one point in the design and may need to go back to if the client changes their mind.

Link to comment
  • 0

I'm not sure what will be purged automatically.

For my STA file it didn't look like my OpenGL/Hidden SLVPs would need as

much files size as I feared.

But you have to be careful with manual purging.

Sometimes you want to delete unused unnecessary Classes, but not lose

the ones you prepared for later use. Or Render Styles that are not assigned

to any VP but you will need for screen rendering.

Link to comment
  • 0
Ideally non-used renderworks objects/stuff should automatically be purged upon closing a document.

I regularly have - and want to keep - many unused RW textures in my files: Various texture options for wood cabinets, flooring, roofing, etc. that I may have used at one point in the design and may need to go back to if the client changes their mind.

Wouldn't it be more convenient to keep those in a library document alongside your drawings?

It would be a bit more work to re-import them when you need them but if you have quite a few of these maybe to be used again in a possibly far future from now I'd personally rather have them in a separate file to keep the working file size down.

Link to comment
  • 0
Ideally non-used renderworks objects/stuff should automatically be purged upon closing a document.

I regularly have - and want to keep - many unused RW textures in my files: Various texture options for wood cabinets, flooring, roofing, etc. that I may have used at one point in the design and may need to go back to if the client changes their mind.

Wouldn't it be more convenient to keep those in a library document alongside your drawings?

It would be a bit more work to re-import them when you need them but if you have quite a few of these maybe to be used again in a possibly far future from now I'd personally rather have them in a separate file to keep the working file size down.

It probably would be more convenient, but I'm lazy. ;) And I also want to keep it associated with this project file while this project is active. But putting unused resources in a Project-specific Library file like you suggest, is a pretty good idea. I had only thought about a general Library file. Thanks ArtV for the suggestion.

Once the project is completed, I'll export the RW textures that I want to use again into my general Library file.

Link to comment
  • 0
I had only thought about a general Library file.

Once the project is completed, I'll export the RW textures that I want to use again into my general Library file.

Generally speaking I have three types of libraries: general, discipline specific and project specific. The latter contains resources unique for that project or variants of symbols from the other two.

The project specific library is also saved with the project files in case the project needs to be updated in the future, that way I can be sure all resources of that project will be available in original condition.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...