Christiaan Posted September 27, 2018 Share Posted September 27, 2018 (edited) 1. Update/render viewport in a file containing workgroup reference of model file 2. Notice a wall join that's become disconnected 3. Go back to model file and rejoin wall (despite the join looking perfectly fine in the model) 4. Go back to workgroup reference file and update workgroup reference 5. Re-render viewport 6. Notice that join looks fine now, but another wall join has become disconnected (usually at the other end of the said wall) 7. Go back to model file and rejoin wall (despite the join looking perfectly fine in the model) 8. Re-render viewport 9. Continue game of wack-a-mole while simply trying produce some "5 minute" final renders on a tight deadline Edited September 27, 2018 by Christiaan 3 1 Quote Link to comment
0 Vectorworks, Inc Employee Matt Panzer Posted September 27, 2018 Vectorworks, Inc Employee Share Posted September 27, 2018 Hi Christiaan, I have to agree with you on this. Have you managed to get a reproducable case? If so, can you submit a VB on this and send me the bug number? I'll make sure it gets sent to the right place and I'll add my 2 cents in a comment. Quote Link to comment
0 rowbear97 Posted September 27, 2018 Share Posted September 27, 2018 @Christiaan I'm curious about your use of the workgroup reference rather than project sharing? Have you tried or have experience that you would be willing to share. I have worked with other clients and we historically done projects that reference our modeling into what I call sheet files but with the advent we have switched to project sharing. Now, project sharing has its issues as well and can be frustrating but it does limit the number times you have to go back and forth between files. Best of luck and thanks in advance for your opinion. Quote Link to comment
0 JMR Posted September 27, 2018 Share Posted September 27, 2018 I've been going over this same problem with tech support. For us, it occurs with project sharing. User 1 has completed nicely joined walls and has set up rendered viewports. All looks fine. User 2 refreshes these changes to his working file. Now, some wall joins have seemingly randomly opened. This user cannot render or publish any sheets because of this. User 1 still sees everythig connected. User 2,3,4 all have different(!) open wall joins. Resolution: Users commit all changes, User 1 saves a copy as vwx and re-shares it. What if user 1 went on a holiday? The problems occurs intermittently, I'll try to send sample files to tech support when it next happens. Quote Link to comment
0 Jim Smith Posted September 28, 2018 Share Posted September 28, 2018 I noted that in 2019 that joined walls appear joined, and were joined when created, but for many walls the components don't seem to join. To get components to join I have to re-join the walls then component join the walls as the component join tool gives an error message that the walls are not joined? In 2018 I was able to get components to join 80%-90% of the time with a simple "Join" command. - Glitch? - Enhancement? - New setting? Quote Link to comment
0 JMR Posted September 28, 2018 Share Posted September 28, 2018 We are still using 2018 btw. For us the components were ok most of the time, it was the wall join itself that cracks open. I've noticed that dwg export reveals any inconsistencies in wall joins; even if all looks fine in vw, the dwg sometimes displays weird lines and not-joined walls. Then one has to go through the joins again and check in dwg again. 2018 joins components fine most of the time...now if that's gone in 2019.... Quote Link to comment
0 JMR Posted October 10, 2018 Share Posted October 10, 2018 A sample of our project sharing daily "life": One workstation displays joined walls, another workstation open wall joins. I've bug submitted this. This is a serious issue that needs a fix asap, as it destroys all drawings displaying walls and thus prevents publishing. I'll probably get told I need training in PS. Quote Link to comment
0 Vectorworks, Inc Employee Matt Panzer Posted October 10, 2018 Vectorworks, Inc Employee Share Posted October 10, 2018 While I did not see a bug from you on this, I did track a similar one down and gave it a nudge along with my two cents. Quote Link to comment
0 JMR Posted October 10, 2018 Share Posted October 10, 2018 Well it was submitted today under my actual name, not this nick. The screen grabs in the attachments are the same as above. Thanks force the nudge, appreciated! Quote Link to comment
0 Amorphous - Julian Posted October 10, 2018 Share Posted October 10, 2018 Totally agree with your points @christian We should consolidate our frustrations and vote up one post to get the attention of Vectorworks. You've probably voted it up, but this is one I started: And I have another productivity issue of our use of titleblocks, which I will be posting up on troubleshooting board. (takes ONE MINUTE just to replace the style with another!) At the end of the day, my office productivity is really dragged down by Vectorworks, and it is really unacceptable. We would greatly appreciate someone from Vectorworks coming out to say to us: 'We understand productivity is important, and we will make it our priority to improve productivity with Vectorworks' Honest truth is: WE CANT AFFORD TO HAVE ARCHITECTS SITTING AROUND WHILE 'WAITING FOR VECTORWORKS TO FINISHING THINKING!!!!!!! It is the true situation in our office. The above combination of bold text, ALL CAPS and underline cannot sufficiently emphasise the gravity of the situation and our frustrations at it. 1 Quote Link to comment
0 Amorphous - Julian Posted October 10, 2018 Share Posted October 10, 2018 Per my post immediately above. Slow titleblock operation is another giant grievance we have: Quote Link to comment
0 ericjhberg Posted October 10, 2018 Share Posted October 10, 2018 I couldn't agree more with the sentiment of this post and some of the frustrations. Every tool VW develops is powerful at its base, but when you put them to use in actual real-life scenarios, they often fail to meet basic productivity standards. This is something that every professional on this forum should be pushing VW to get better at it. Ultimately we all want VW to thrive and beat its competitors, but that only happens if we can ALL thrive using their software. Just one of many other similar occurrences/workflows: 1 Quote Link to comment
0 JMR Posted October 10, 2018 Share Posted October 10, 2018 It seems the understanding of the concept of "professional" is currently completely lost at the HQ. I have used several CAD packages in the past and while they were not as flexible and their scope of functions was not as wide as that of VW, none of them suffered ANY major reliability, stability of performance issues. Indicative of the issues with current VW is that my employees are starting to get seriously pissed at the constant crashes, slowness and PS problems. One of them already left for another office using another software package that is much more popular over here. This is a development I cannot afford to continue. Unless the quality and the performance of the software is improved rapidly, I have no choice but to switch to other software. The mainstream competitors are double in price and subscription fees, but that has no meaning at all if we factor in the time spent now fighting with all the astonishing bugs that should never be seen at the users' workstations. 4 Quote Link to comment
0 Vectorworks, Inc Employee Matt Panzer Posted October 10, 2018 Vectorworks, Inc Employee Share Posted October 10, 2018 3 hours ago, JMR said: Well it was submitted today under my actual name, not this nick. The screen grabs in the attachments are the same as above. I cannot seem to find it. Do you have the VB# or Title of the bug? I think I tracked down your full name but found nothing. Can you send it to me privately? I'd like to nudge it as well. 3 hours ago, JMR said: Thanks force the nudge, appreciated! No problem! Quote Link to comment
0 JMR Posted October 11, 2018 Share Posted October 11, 2018 @Matt, Thanks, I re-submitted the files and also sent you a direct download link to the files. I don't know what went wrong with the initial submit process. Quote Link to comment
0 JMR Posted October 19, 2018 Share Posted October 19, 2018 @Christiaan; Can you please confirm that you were not using project sharing when this issue occurs? Namely, we only see this with project sharing, also some other practices reported this. If it occurs with non-PS files then the seed of the issue is elsewhere than PS. I talked to the local distributor and he suggested different resources on different computers might be at play. This sounds logical, but everything looks the same and this de-joining occurs with no-one touching the walls or wall styles. I also tried to open the pf with 2019 SP1 and the resulting WF displays open walls joins...but one of the open joins has disappeared(!). I really want to find the reason for this so it can be fixed. We might be doing something wrong ourselves but I just can't figure out what. Quote Link to comment
0 Christiaan Posted October 19, 2018 Author Share Posted October 19, 2018 (edited) Hey guys, yes, this occurs when we're using Project Sharing. On 9/27/2018 at 5:25 PM, rowbear97 said: I'm curious about your use of the workgroup reference rather than project sharing? We're using both. Because of file size and lag. We're working with a large model (of a city) and have a multitude of Sheet Layers. So we separate out the building we're designing into a separate file to ensure that work on this is as zippy as possible, and then we reference this into the main file. Both files are Project Sharing files for teamwork purposes. Edited October 19, 2018 by Christiaan Quote Link to comment
0 JMR Posted October 19, 2018 Share Posted October 19, 2018 Ok thanks! Pondering this further: It is as if the wall styles thought they have been changed, even though they have not. This can happen with regular files as well but only if the wall style is changed to something completely different and the program doesn't know how to join it any longer. In the PS case there has not been any wall or wall style operations. 1 Quote Link to comment
0 Christiaan Posted November 5, 2018 Author Share Posted November 5, 2018 Anyone know if this has this has been dealt with in v2019? Quote Link to comment
0 JMR Posted November 5, 2018 Share Posted November 5, 2018 @Christiaan: At least for the project that was started in 2018 has the same problem in 2019, please see the image a couple of replies back. One join had connected, two joins remained open. 1 Quote Link to comment
0 Vectorworks, Inc Employee Christopher Graye Posted May 29, 2019 Vectorworks, Inc Employee Share Posted May 29, 2019 Hello everyone, We have finally been able to find and fix this bug. See my post here for more information: @Christiaan 1 Quote Link to comment
Question
Christiaan
1. Update/render viewport in a file containing workgroup reference of model file
2. Notice a wall join that's become disconnected
3. Go back to model file and rejoin wall (despite the join looking perfectly fine in the model)
4. Go back to workgroup reference file and update workgroup reference
5. Re-render viewport
6. Notice that join looks fine now, but another wall join has become disconnected (usually at the other end of the said wall)
7. Go back to model file and rejoin wall (despite the join looking perfectly fine in the model)
8. Re-render viewport
9. Continue game of wack-a-mole while simply trying produce some "5 minute" final renders on a tight deadline
Link to comment
20 answers to this question
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.