willofmaine

I guess now, maybe having reinstalled Dropbox, it's at least faster. Maybe 4 or 5 minutes instead of 20. In all cases, Dropbox appears to start with the full 200 MB, but maybe that's to be expected with "incremental" backups. (The original 200 MB plain .vwx file takes about 20 minutes to upload). But, it still seems like 4 or 5 minutes is quite a lot of time to Save & Commit after having only added a couple of circles and moved a rectangle (in my test working file)??...

I've installed Catalina. I've uninstalled and reinstalled Dropbox. I've recreated the project file from scratch. I've created brand new project files from small test projects. All to no avail. No matter what I do, Dropbox syncs the entire file with each and every commit. At one point I'd changed the backup location to my local drive, but then changed it back again. That (or something) resulted in a couple of .bak files, along with the file in the Vectorworks backup folder. Each of the .bak files (whatever those are) were a full 200 MB. Searching on Google for "Delta Sync" mostly gets me results for Smart Sync, or maybe an explanation of what Delta Sync is. But nothing about how to enable it.

Updating to Catalina does not seem to have helped. But at least a call to Vectorworks "Priority" Tech Support resulted in - for the first time ever - my having to leave a message with a promise from them that they would call back within one business day.

I did switch to SMB, but to no avail. But, also based on Jim's article, it looks like the current Mac OS is recommended. I'm on High Sierra (I've developed an aversion to what has often seemed like downgrading to the latest, "greatest" Apple OS...)... And it looks like Vectorworks 2018 doesn't run on Catalina, so, last night I "officially" switched to VW 2020 (transferred Libraries, etc.). So, I am apprehensively moments away from upgrading to Catalina; hopefully that will resolve this issue!! I can check everything off in that general Dropbox guidelines post you referenced. And your explanation of how to create a new project file - we are very much on the same page! Again, thank you very much for your thorough responses. I will let you know how it goes with Catalina.

If this PVA Jim guy is to be trusted (ha ha), it maybe looks like we should indeed be using SMB instead of AFP: see his post here.

Maybe the Network Protocol at Project Sharing Settings should be "Share Project File using SMB only" instead of "AFP" (currently selected) (whatever those are...). Might it be the backup file getting replaced (it's located in Dropbox in its own folder next to the project file)? Only problem with that theory is it's set to backup after every 5 commits, and we've only committed twice today, and both times were similarly problematic... Can I just delete the project file and create a new one from scratch (from a current, up-to-date, refreshed working file)? And, for the heck of it, maybe following some communication with the rest of the team... ... ...

I just had to commit the file again, and Dropbox is syncing over at least 190+ MB (file size is 204 MB at Dropbox). Also, oddly, there is no blue Dropbox syncing icon adjacent to the file (though the container folders do have them, and everything else has their green checks as expected...). It's looking for about 20 minutes to update. Did I miss a setting somewhere? This is not super ideal... Thanks!

I'd estimate something like 20 minutes, but, maybe more telling, when I checked it at a certain point, Dropbox was still syncing a substantial 80 MB or so...

So... I just committed changes to a project file so that I could release everything, but, for some time the team had no access to the project file (and Dropbox was syncing for a long while). I'd assumed that when committing changes, only the changes would be written to the project file. Is that not the case? It sort of seems like the entire project file is being overwritten (200 MB = time consuming...). Otherwise, the ability to release things individually is going well!

I found a Renderworks Camera sort of far away... like in another galaxy (literally: at x,y,z = 3.228'e97'!). Is trillions of trillions of miles too far???... (a file I inherited!...). So far, deleting the camera seems to have resolved the issue, so, Thank You!

Ha ha! Yes, that is a joke. "Time will tell," as they say, and time, years of it, is telling me that there's no interest in and/or ability to fix Vectorworks. Sorry if that may sound harsh, but, the combination of issues such as those represented by the attached images, and the frequency of such issues, is beyond discouraging. The tremendous investment I've made in Vectorworks, which is far beyond just financial, makes jumping ship incomprehensibly unappealing. Oh well, back to work. Maybe I can realize at least a few hours of billable work during my next eight hours with Vectorworks.

I (still) really wish that solids appeared as, well, solid red, instead of hollow, at the cut planes of clip cubes. VWIS051 And, maybe more, I especially wish that everything at the cut planes was snapable. VWIS051 And I also wish that we could snap to the geometry of symbols when the clip cube is on... (but this was "submitted to engineering" by Tech Support in December of 2014, so I'm not holding my breath...) VWIS039

This is why I use Vectorworks "smart" objects less and less. And less. I could have modeled what I want using a pair of roof faces and solids faster than it's taken me to not be able to figure it out and to read the first half of this thread...

I've never been able to comprehend the relationship between image size, resolution, and the marquee in Vectorworks. And I guess now, finally, I know why! Evidently there isn't one...

Yes, I've always done that. I've got one image that I'm exporting as three separate images that need to re-align on a website. While we're talking just a few mere pixels, it's enough to make the images visibly misaligned. And the variations are entirely inconsistent, to boot. So I need to go into Pixelmator, stretch this image a pixel or two that way, stretch that image a pixel or two the other way, etc., and then I need to deal with the tiny blank spaces that result. Well, at least it's not just me, I guess. Five years. *sigh*

It sure would be some swell if, when exporting images, the selection marque actually and accurately and consistently and the same each time exported what was selected, without grabbing extra pixels and without stretching and distorting each image ever so slightly and nonsensically differently with respect to adjacent images also using the same marquee points.

Thanks so much for your thoughtful & thorough response! It all makes sense now. In a nutshell, all changes need to be saved and committed before items can be individually released. If only that "Do you want to commit or discard all of your changes?" message made that clear, or, even better, included options to either "Release only these objects or layers" or to "Release all checked out layers and objects." Thank you!

I'm new to Project Sharing and, so far, I think I understand most of it. Except for whether or not all items always need to be released simultaneously... If you commit and save the changes you've made to a working file, that doesn't seem to affect what you've checked out. But if you release an item, such as a layer or an object, it seems necessary to both commit all the changes you've made in the working file and to release all items that have been checked out. This seems consistent with Vectorworks Help, which says that when releasing an item "All layers and objects you have checked out are released" (see here). So, okay, but... What, then, is the purpose of releasing objects based on criteria? What's the point in selecting certain items to release, if all checked out items have to be released together anyway?... What am I missing?...

Thanks for your reply! Yep, I did make sure the Guides class was off. I guess deselecting "Draw Site Border" would have worked, but, for whatever reason, doing that seems to make it so that the site model can't have a solid fill in Top/Plan view. While that can sometimes be desirable, why is the site border linked to the model's fill?... There actually was a coincident border object, but, removing it didn't resolve the issue. Ultimately, I just set the site border's color to white. It looks like the Site Model Attributes for the 2D Site Border (at Site Model Settings > Graphic Properties > 2D Site Border) can only initially inherit a class's properties when "Make all attributes by class" is selected, but they don't subsequently remain linked to that class's properties, including its visibility settings in viewports. I didn't check "2D Triangles" in viewports, but, its attributes seem to remain linked to a class as expected. So it kinda seems like a bug... VWIS198

Site Model Settings > Graphic Properties > 2D Site Border. I put the site border in the "Guides" class so that it won't show in my site plan viewport, and I click on "Make all attributes by class." But the site border (which I'm assuming is the line at the perimeter of the site model... ... ...) doesn't go away (though it is the color of the "Guides" class as it should be). When I double check the model's settings, the attributes of the 2D Site Border are correct... except that they're no longer "by Class." But that's maybe a secondary issue. Mostly, how do I make my site border go away in a plan viewport?????

Here in the year 2020, I still wish that surface hatches, at least optionally, were NOT snappable. There are too many invisible snap points as it is; snapping to every particle of a stucco hatch seems entirely unnecessary... ... ...

When creating the wall components of wall styles, and when setting the component's Fill Style to use the Class Style, I really wish that the component's color would automatically also default to "Class Style" when the class it's being assigned to has anything but a solid fill assigned to it (such as a hatch). Otherwise, trying to override the component's fill in a viewport - say to replace a hatch with a solid color - only results in the solid fill being applied, but not the desired color, because the component's color is still its default white color (i.e., while the hatch can be made to go away, the color white can't be changed). The hard-learned workaround is to remember to change the component's Fill Color to "Color by Class" before setting it's Fill Color to "Class Style." The challenge going forward will be remembering this workaround... ... ... Please make Vectorworks more intuitive!!! VWIS131

This seems to persist in VW 2020 SP3, but much more difficult to replicate. The floating data bar now seems wise to the problem and scurries much faster to stay out of the way of the cursor. For all intents & purposes, we'll call it "Resolved!"... ... ...

It seems the "extraneous and disconnected wires in networks" of my original post have been resolved!! But with testing to verify, a couple of new issues: Marionette Object Disappears after Editing Script (VWIS194): https://forum.vectorworks.net/index.php?/topic/70049-marionette-object-disappears-after-editing-script/#comment-344473 Marionette Network Symbol Misaligned and Difficult to Select (VWIS195): https://forum.vectorworks.net/index.php?/topic/70050-marionette-network-symbol-misaligned-and-difficult-to-select/ I've posted these issues in "Troubleshooting" because it seems more likely that they're Vectorworks graphics issues rather than specifically Marionette issues...

After changing the drawing scale, it seems that Marionette network symbols and they're bounding boxes are completely unrelated, and sometimes even misaligned such that it's difficult to select the network symbol for editing. See attached video. VWIS195 03-Network Symbol Misaligned-1080-02.mov