Jump to content

rb-arch

Member
  • Content Count

    84
  • Joined

  • Last visited

Everything posted by rb-arch

  1. Excellent! Finally some good news. Regarding the fans, we have mid 2015 iMac 27" machines loaded with RAM and TW make the fan go but we don't mind pushing these machines hard. We've batch rendered in Artlantis (all 5 machines) for years and the fans crank away like a render farm!, no issues. The fan is doing its job. RB
  2. I wonder if there's going to be a VW plugin for Twinmotion 2020.
  3. Glad we're not the only ones. Rather than new features, I'd prefer stable software. It is stuff like this that makes me re-consider the subscription service. We still have project sharing bugs from 2018 that aren't resolved.
  4. I wish they'd fix this. It really does take away from the user experience and updating (renders, shared files, viewports etc.) is way more annoying. You have no idea what is going on and then you can easily refresh, or re-update because you didn't think you clicked it the fist time. This basic stuff drives me nuts.
  5. 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.
  6. Here's a link showing the disappearance of the status / update bar on the lower right.....
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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
  13. 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.
  14. 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
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. Hi, to clarify: 1. OK. 2. What happens if your WF crashes and you need to recover your work and then commit save to the PF? If you can't use an autosaved back up of a WF what good is it? Maybe I don't understand what you're saying. 3. I understand what you're saying. Sometimes though things don't release so easily, even with custom release, so being able to override that from another user is handy. There's only 3 of us so it isn't a problem, but I could see it being one in a larger office. Maybe we'll try to make only one administrator just to see if it improves things. To be clear, when this all works it is really great. When it doesn't there is a significant risk of missing drawing issues / problems on printed sets that make their way out for construction.
  22. We get that all the time, on all our machines. Particularly with saved views.
  23. Today we've had the section line instance duplication bug - one of our favourites. The lines get duplicated and it adds random section viewports to sheet layers.

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

√ó
√ó
  • Create New...