[Vectorworks 2018 Project Sharing Corrupting Files]

It is not possible to migrate Working Files, only Project FIles. It needs to be a project-wide decision to migrate from 2017 to 2018.  All 2017 work needs to be committed from all working files, ideally with Commit and Release so nothing is outstanding. Then the Project File should be migrated to 2018. Afterwords all users should create new 2018 Working Files.

• If a user opens a 2017 Working File with 2018, Vectorworks will ask to save a copy as a new ordinary 2018 VWX file.  The original 2017 Working File is left alone.
• If a user opens a 2017 Project File with 2018 (as if you were trying to create a new WF), Vectorworks will alert that the project must be migrated.
• Migrating will move the original PF into an "Old Version Vectorworks Files" folder, and create a new 2018 PF with the original filename in the original location. That new PF will have nothing checked-out...any outstanding stuff is thrown away.
• If a user opens any 2018 file in 2017, Vectorworks will complain that it is an unrecognized file.
• In order to migrate a 2018 Project File back to 2017, you need to open one 2018 Working File, and Export As a 2017 VWX file. Then open that withVectorworks 2017 and convert it back to a 2017 Project File.

We need more information about the specific problems and alerts you are seeing. Sending us copies of the PF and Working Files involved can help.  Also, how many people are involved and how many are Admins.

 

If an Admin has released things, recovery depends on what else has happened.  If those items haven't been changed, perhaps they can just be checked out again in the same file, and then committed. Recovery is somewhat painful if someone else already checked them out and committed changes to those items. To avoid losing work, the original user needs to essentially create a new Working File, check the items out, and copy/paste from the old file anything that needs to be recovered or merged.

[Teaser Tuesday - Unicode Support]

By analogy you can put text in a Word document, or text in a PDF; the person you hand it to needs to know what file type they're getting to know whether they can handle it.

 

Essentially UTF8 starts with one byte for an ordinary character (so is somewhat compatible with ascii) and it grows to 2, 3, or 4 bytes as needed to fit a specific extended char. UTF16 starts with 2 bytes and doesn't ever pretend to be ascii.

 

https://en.wikipedia.org/wiki/Unicode#UTF

 

[Teaser Tuesday - Unicode Support]

Unicode is the ability, UTF-* is the format of the bits and bytes to make it happen.  No real difference in what they can hold, only in how it is represented internally.

[LAYERS AUTOMATICALLY BEING CHECKED OUT]

Hi Hassan,

 

It is not just the user that owns a layer, but also the Working File (.vwxw) you were using when you did the checkout.  This looks to me like you are using a different .vwxw file now than you were before.

 

If you plan to discard a Working File, you should be sure to Commit and Release everything in it.  If you work with two Working Files at the same time, in each file you will only be able to work with the items you check out in that file.  

 

If your original file that owns this Line on the C-Cellar layer is gone, you will need to get an Admin to do a release of everything that you owned in that file.

 

Hope this helps.

[G-Drive vs Dropbox for Project Sharing]

If you were on the same local network, Dropbox has a "LAN sync" option that allows some peer-to-peer syncing instead of waiting for a changed file to go all the way out to the DB server and back again.

 

But, you said you're not. My belief (with no testing to back it up ) all 4 supported services are going to be about the same. There are some benchmarks out there, but they probably won't match your real-life experiences. Vectorworks re-writes the entire file every time you do a save (or commit), so it's the full file transfer cost every time.

[Teaser Tuesday - Direct Editing of Sections and Elevations - Vectorworks 2018]

18 hours ago, line-weight said:

 

Seems like this can do stuff that clipcube can't, while clipcube does stuff that this can't.

 

Is there an intention to converge into one mode that can do all the good stuff rather than these parallel ones?

Yes there is overlap in capabilities, but they're also built around different workflows. I can't really answer about future plans...I'm still focused on this years release!

[Teaser Tuesday - Direct Editing of Sections and Elevations - Vectorworks 2018]

20 hours ago, cberg said:

Apologies if this was already asked.  I only skimmed through all the posts and responses.  Does this function work with flattened design layer viewports? 

Yes!

[Teaser Tuesday - Direct Editing of Sections and Elevations - Vectorworks 2018]

18 hours ago, JimW said:

I do not believe it affects it at all, it's left as its own edit mode, but I will check.

 

 

The feature is geared toward when you have a large number of section or elevation views already established and you want to fine tune them in-place, as opposed to bouncing back to the design layer, enabling clip cube, lining it up the way you want and then making the edit, then going back to the sheet and updating the viewport.

If you're mostly used to editing in the design layer and utilizing clip cube already, this feature won't affect your workflow much at all from what I understand.

Clipcube only works with wireframe or opengl, and it only works with a simple section - nothing with staggered section line.

The new Edit doesn't use the CC and you can have more complex sections than just the cube.  And it will automatically show the model in a fast/good approximation of your viewport's render mode, so you can work effectively in HL or other.  It also allows you to navigate to annotations and back without things shifting around underneath you.

Other little things: it works with DL sections as well as SL.  It's simpler without all the various options you see on the dialog for Edit Design Layer. 

[Teaser Tuesday - Direct Editing of Sections and Elevations - Vectorworks 2018]

34 minutes ago, Christiaan said:

 

Still pretty far away from what your demo is displaying Jim. The line quality is much sharper and blacker than default OpenGL. It's very crisp, so I assume there's no creasing angle set.

 

I really like it too. Apart from the fact that it appears to show lines between floor levels where one wall meets another.

Right, it does show more lines and seams than true hidden-line. It's meant as a very fast, interactive approximation of HL that you can actually work in.  I think the performance is very nice.

[Project Sharing - bugs]

Hey Jeremiah. I'm going to try to restate what I hear you describe, and you can correct me where I go wrong.  Sounds like you've been using regular VWX files in dropbox, and you've recently started using Project Sharing files (perhaps by converting one of those VWX files) in dropbox. I don't know if you have tried using PS files via server or desktop to be able to compare the performance with and without dropbox.

 

Many actions you take in the Working File will trigger an update to the Project File. Not just commits (and their periodic project file backups), but also changing the 'status' of items, like checkout/release. Each one of those changes is going to trigger dropbox to sync the Project File to the cloud. Combine that with your Working File saves, autosaves, commits, and refreshes, and those will trigger the Working File syncs between your local dropbox folder and the cloud.  Some significant portion of the slowdown you see might be dropbox itself eating into your cpu cycles and into your network traffic.  You don't mention mac vs windows, but you could pop up the windows Task Manager or the mac Activity Monitor to get an idea of whether this is an issue or not.  You can look at both cpu and network activity there. (I personally prefer to keep my Working File local instead of in dropbox, so it doesn't count against my dropbox quota or use any of this extra network bandwidth.)

 

Next, I'd like to take a look at any crash files you have (.crash on mac, .dmp on windows).  You can upload them, or if your Vectorworks Preferences for 'Error Reporting' are set to upload crashes then you can just tell us the last 6 characters of your serial number and we can find them.

 

Hope this helps