rb-arch

Anyone else having this problem? All our iMac's are like this - the status bar doesn't show updates when saving, saving and committing or updating viewports. It is amazing how much more frustration it adds when you don't know how far along it is. My video shows the difference between 2020 and 2019. The link should show a high quality video.

Here's a link showing the disappearance of the status / update bar on the lower right.....

The status bar / message bar update that would show progress for saving, saving committing, updating viewports etc. doesn't work on my Mac. Pretty annoying and I hope they didn't take away that functionality.

Thanks can you point me to some samples?

This is precisely the group in the market that is underserved. We use Artlantis and get decent results, but it is buggy and not well supported. We've been looking for an alternative and there is none. There's no way we're buying cinema 4D to get to V-ray etc. We've tried everything, Twinmotion (bad renders), Lumion (won't work fro Mac), V-Ray (can't get there from VW), etc. For us, it is becoming unacceptable. The Mac users are being stranded.

When?

We're trying to use project sharing in 3 person office. We thought we'd use the new data tags and tag all the objects in the sheet layers. It has been an unmitigated disaster. Now, you can't even update a viewport (elevation or section) without checking out tags on other sheets - it makes no sense. The tags take ownership of everything so it is nearly impossible for two people to work on the project. Even with an entire elevation sheet layer checked out, if we try to generate the viewports it will ask us to check out tags on floor plan sheet layers.

You're going through the same learning curve we did about 4 months ago. In project sharing, it is our opinion that the auto save files are essentially useless. Cutting and pasting changes doesn't really work in practice. As discussed above, we now set our autosaves to *overwrite* the WF. This gets around the cutting and pasting and keeps the relationship in tact between the WF and the PF. Lastly, it does seem to be intuitive to take the backup file and "save as" the WF, but this seems to be a bad practice according to Tolu.

Wow, of course! I think I had that checked on years ago and stopped doing it that way. Since we started using Project Sharing we've never really revisited this tab other than to change the auto save settings. So thank you for the reminder, from a long time user LOL....... 🙂 Lately in our discussions here, we've also sort of agreed that we very rarely get any use out of the auto save back up files because it is just too onerous to cut and paste *certain* types of work. Thanks.

We've had many discussion in the last year Tolu, and you've helped us get things running smoother and I hope we've helped highlight some software issues. One thing I would like to request is and auto save of the WF, that overwrites the WF just like it would if you hit Save manually. Unless you use this software to actually produce drawings I don't think you can fully appreciate what a pain it is to cut and paste from a back up file. We used to set our Autosave to 3 minutes, and when we crashed, we'd take the Autosave file and save it as our "most up to date" WF. For reasons you've explained (technical ones I don't understand), this is a bad idea. If there was an Autosave WF that would overwrite as I describe above, in theory you'd only lose 3 minutes of work (or your preferred setting) and you'd retain the uniqueness of the UUID number for the WF - to keep its continuity. Just a thought from a long time user. Randy

We've had all these problems, and solid operations not reporting to the PF, Legend text going to zero point, walls un-joining, etc. We've also recovered auto save files and overwritten Working Files, but were instructed by Tolu to not do that. Generally, we still find it to be buggy, but when it works it is great.

After countless back channel discussions, we still have the following (serious) problems with SP2. We have already issued drawings to the site that were in error because of project sharing, and I see no fixes to date for the following: Sheet layer work (when a user has the ENTIRE project checked out) is not pushed to the PF and other WF in the office. This happens regularly, and we try to ask "what were you working on", but things fall through the cracks. How do you summarize 3-4 hours of work to a co-worker - you can't. We have a situation right now were sheet re-ordering, viewport organization, and sheet re-naming is stuck in one machine. Nothing will push the work through. We have to remake the project file. Same as above for solid modelling in design layers. In that case sometimes we group the entire design layer and save and commit, and it will push the work through. Walls become unjoined, randomly, and frequently. Legend text, which resides in a design layer, will set itself to zero point font. That makes it disappear from the sheet layers. We had 5 sets of drawings issued to site with this error, which only occurs with project sharing. So, we'll continue to beta test his for Vectorworks, on our dime. Note, we've taken every bit of advice from all parties for network settings, autosave settings, etc. Our network is new and fast, and our workflow is not exotic. randy

We can't even get this software to push basic drafting changes to the machines. It is borderline useless right now - I've sent the files to people here and where I've purchased it and no replies so far.

We're still experiencing significant problems with project sharing, especially point #1 in the OP. Quite frankly, we're sick of being the beta testers for this software. I'd prefer an issue of the software that improved the core commands over improvements to the site model for example. Of course all improvements are welcome but I get the sense that the focus is on new shiny stuff rather than the core of the software. Not good. Project Sharing is critical, and if this continues much longer we'll be faced with a difficult decision.

IMO these soft locks might be the root of some of these problems. There are *many* times when we do our work, save / commit / release only to find out later that there is still an obect checked out by another user. This object will not show up under the main project sharing window (which is should). It is getting confused. What we find is that a user may have an object checked out, but the layer released. In this scenario another user can't check out the layer until the other user does a custom release of the entire file. Maybe we'll start using the colours.