rb-arch

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.

This is frustrating. The software pushes you more and more into the viewports, but then the tools don't work. We're trying to do a panel layout and count the symbols in the viewports and there's no way to do it.

Yes, I see your point but that is not a likely scenario. IMO the most relevant and useful file is the file that was created 3-5 minutes before a crash. For example, it is possible that our WF's would not be saved for 30 minutes, or longer, while working. In that scenario, isn't it also possible (and likely) that the old, original WF wouldn't match the current state of the PF? That's why we grab the back up and re-name because we feel that file will most closely match the status of checked out objects and layers etc. I also think it is impractical to paste work back into a WF from a backup, depending on what was lost. So, my scenario would be: 12:00 I open my WF and check out some layers, do some work for half an hour. 12:27 a backup is created. 12:30 I crash without saving back to the local WF. If I open the original WF again, it will say that I don't have anything checked out. The Backup file will though, and it is only 3 minutes old. This is why we don't use the method you describe, of pasting work back into an original WF. It is impractical and we'd would not think to do it that way. Also, in the scenario I outline above, with your method, I'd have to track down 30 minutes of work in that back up file and ensure I copy it over (which can lead to crashes as well if you've ever tried it!). It is possible I'm not understanding you correctly, but I think I am.

2. We wouldn't recover something that old, but what does happen is you need to remover something in the last hour or so from your local drive's VW backup. We have our autosaves set to 3 minutes, so we typically don't lose much work. However, I do think our practice is to recover the back up file, then save as OVER the local WF, then save and commit. Is that a problem.