Taproot

We migrated one of our projects to v.2019, but after running into a number of bugs, have backsaved it to v2018 as it is more stable. The file, however, now appears to be corrupted. In 2D, everything looks OK, but in 3D, the walls vanish, reappear, or display distorted depending upon which direction the model is viewed from (and none of them are actually correct) Is there a tech I can send the file to - to determine if there is an easy fix. I could try copying all of the data into a new file, but the likelihood is that the problem is in the data and wouldn't go away. Here's some screen shots of the behavior. The first one shows all 3D info hidden, except when your cursor runs over it a ghost appears. The second shows some kind of weird parallel universe where x-ray vision has been implemented (partially)...

We're seeing the following behavior: If we do an action - say move a wall. Then, with a different object selected we hit "Undo" - the software breaks down. Here's an example where I moved a wall and then selected a car and then thought to undo moving the wall. It moves the wall back on-screen, but creates a ghost object where the wall actually is. From here on things get messy. You need to cut and paste the wall to reset it to work properly. It may just be walls that are affected by this bug, but it has resulted in corrupted files for us where we've had to go back to an earlier saved version. We've duplicated this on both of our workstations. This one is nasty enough, that we're likely going to resume using v.2018 until SP-1 comes out.

I did try this, but I found that I had to add each sheet one by one. Shift or Command clicking wouldn't work for multiple select. So this option seemed a little tedious. Perhaps you could check if that is normal behavior or just my experience. OK, I'll dive into this deeper. It sounds like I just need to rebuild my titleblock with the new standard fields. Speaking of which - what are they? Is there a list somewhere or should I just use Pat's script to determine the field names for criteria, reporting, etc.? I'm not sure what happened to them. They worked initially. I've uploaded them again. Thanks for your help.

I can confirm this behavior as well. It will save your view location on the sheet layer itself, but if you are on a design layer and save ... the next opening will bounce you to a sheet layer.

OK, file sent via Private Message. Is there a detailed guide to titleblocks for the current version? I've gone deeper and I can't quite make sense of how it is supposed to work. Our Titleblock predates the Manager, so I'm used to thinking about it as a symbol with fields that attach to records. The records are then reported to a schedule / worksheet. Now, it seems like the Manager has added some additional layers to that process and it's not very clear how to work with them. For Example: In our titleblock , we have an "In Project" field with a Yes/No list of options. When it = "Yes" the sheet is included in the Drawing Index, when "No" it is ignored (but still present and can be added to the set at a later date). In 2019, this field doesn't seem to function. Here's a screenshot of the Titleblock manager. When managing the sheet data, some of the fields are in italics and some are not. I assume italics designates my custom fields and standard text are system supplied fields. Is that true? I've had erratic results. Sometimes the italicized fields will show up in the manager (as they do in this screenshot). At other times they will not. Continuing on: I've placed the new titleblock "Issue Index / History" worksheet in my file. Editing the Criteria to filter display results no longer seems to work. If I limit the criteria to my 'Taproot Titleblock' records, zero results are found. So, the actual criteria is either controlled somewhere else, or my data is being captured by the manager and filtered so that not all of it comes through. I'm a little stumped ... guidance would be appreciated. I don't know why the images disappeared. I've attached them again.

This definitely helped me. I assumed that it was the "Outline" that was being used for the massed plant ... I didn't realize that it was the "background." Thanks!

We're just starting to transition our template file to 2019 and have discovered that for some reason the software has duplicated all of our titleblocks. I discovered it when experimenting with the "Create Sheet List" command. In the attached screenshot, I've deleted the duplicate for the first sheet, but you can see all of the other sheets are copied. It looks like the solution is to manually go through each sheet and draw a marquee around the titleblocks and manually delete one. FYI: We ran into this issue last year as well, but just accepted it as a nuisance.

Hi Jim, I'm not sure how that would help - as the problem in not persistent given once the preference is toggled on/off. Subsequent re-launchings of VW have shown that it still works correctly after the first change. I did try and disable my monitor, restart, etc. But it uncalibrated all of my resolution settings and in general just made a mess of my equipment ... after 15-20 minutes of getting everything back to normal again, I'm loathe to do it again unless it would really benefit you.

Here you go: Mac Pro.spx

After installing 2019, I found the zoom rendering speed to be slower than v.2018. Instead of a jittery zoom experience, it would freeze and jump to the end of the zoom. Fortunately, the problem went away once I went to VW>Preferences > Display and toggled the "Navigation Graphics" setting. It was set to "Best Performance", but once the setting was changed, all modes now work correctly and the problem hasn't returned. Posted in case anyone else has this problem.

Humorously fact and fiction aren't that far apart: I actually programmed one of my mouse buttons to simulate hitting escape multiple times ... it has extended the life of my keyboard AND it deselects the text tool without driving me crazy!

Hit escape a bunch of times and then shake your keyboard to make sure it's working, Then hit escape a bunch more times ... sounds like a bug.

We're seeing our elevation viewports display all kinds of inconsistent rendering behavior. It appears that a portion of the viewport is rendering over the top of another portion of the view. Re-rendering the viewport will sometimes correct the issue, sometimes the artifact will move somewhere else, and sometimes it will remain. Usually if I re-render enough times I can get a clean view. This started out as an occasional bug, but is increasing in frequency. Attached are the same viewport (rendered twice). You can see the artifact in the upper left.

Jim - That's excellent news! Mac@Stairworks. With your handle I can totally see your interest in the stair issue. I think Markvl was drawing attention to the voting issue not working very well. I find myself in agreement. Not to diminish the legitimacy of fixing any one thing, I think systemically there is room for a big shift in how user input can be leveraged to improve the product.

I've never really understood the voting thing. Usually, it's a topic without any context. Since there are so many things that can be improved, the one in front of me usually seems like a good idea. That doesn't help with prioritization very much. How do I know if I want this thing more than that thing unless I see them side by side and have to make a choice? In my opinion, the Wishlist Forum should: Collect a wide range of input Consolidate that input into categories Provide feedback to the product developers and the users as to where the areas of interest are most significant Solicit more detailed feedback and consolidate general wishes into actionable improvements Provide some record of improvements so that everyone involved has enough faith in the process to invest energy into it. Currently, I think #1 works. There's a wide range of input represented. However, it breaks down from there. #2: A random search to see if someone else has already drawn attention to the item you are thinking of is pretty ineffective. Perhaps they used different terms or spelled them incorrectly? This can create a lot of redundancy and reduces the ability of users to build off of one another's experiences. Instead, the forum could offer a list of categories with nested options so that users could drill down to the issue(s) that interest them. A graphical approach would likely be the most effective. Areas of significant activity could have color or emphasis added. #3 As some areas become more significant, they could change status i.e. get bumped up from "Wish" to "Under Consideration". #4 Items that are "Under Consideration" would then receive more detailed feedback from the users - which could be augmented with input from the technical staff as to what is or is not possible. Hopefully, contradictions in requests could get ironed out prior to inclusion in product development. #5 In most competitions, there's a judging body and a "People's Choice" category. VW should consider adding a "User's Choice" category to their development cycle. For example, the company could develop a number of the top ten items selected by the users for improvement each year. That would incentivize user input and engagement in the process / product. Once the items were selected, the users could be notified ahead of time, so that while most of the product development honored corporate secrecy, we would be able to look forward to a few features of significance.

Gadzooks! My goodness you went into this deep. I have experienced this bug in multiple files. The latest one had no ground plane objects, so I don't believe it's related. I had suggested that the muntins 'disappear," but more accurately, it's that the glass pane visually moves in front of the muntins. They are still there, they just look "underwater" behind the glass. Obviously, I've checked to ensure that the muntins are thicker than (and proud of) the glass. Your conclusions seem sound. Hopefully the programmers can isolate the cause.

I don't have a small file, but here's one that exhibits the error. I've shown (3) saved views all from the same viewpoint at different zoom levels. You'll see the muntins blink in and out depending upon the magnification. This behavior is consistent across multiple files. Muntin_Error.vwx

Just poking this thread - as I see in VW 2018 SP2 this bug still isn't fixed. Jim - is this on the fixit list?? Thanks.

Full agreement here. I would love to see more visual hierarchy and intuitive use of graphics to communicate instead of row upon row of text settings. Personally, I would be happy to see a year of product development where the emphasis was on enhancement rather than expansion. Don't add anything to the program, just refine and polish up everything that is already present.

Gadzooks - Great news! I'll install SP#2.

Gadzooks! Thanks for taking the time to confirm this and develop a work around. I think we'll follow your advice for now and either just clip a hole in the roof slope or use the skylight tool to do it. I think the "troubleshooting" forum where this is posted is designed for bug submittal. Let me know if you know something different.

Gadzooks, Yes, all classes are turned on in the VP. Our template was created prior to 2018 and brought forward. I've tried this in a new blank file as well, and the problem persists. I'll attach it to this note. Thanks for looking into it. Skylight.vwx

We've found some challenges with transitioning from 2017-2018. Today it's skylights. Create a roof, insert a standard Velux skylight symbol from the default libraries and then display in 3D. It looks good, normal, etc. Then create a viewport to display the roof with said skylight. Even with every class turned on, the skylight disappears. Return to the drawing layer and it's back. Enough back and forthing and the skylight will eventually disappear on the drawing layer as well. It's still there ... mousing over it will reveal it's lines but for all practical purposes it's invisible. It's not a class visibility issue so ....? The problem persists in a new empty file. Drawing Viewport Drawing (after a while)... Using 2018 service pack #1 Mac Pro ....

Plus one. There are so many products, specs, manufacturer manuals etc. that we could link to in PDF documents. Worksheets / schedules are the best way to organize that information.

Jeremiah, The 1/2" discrepancy comes from the "Reveal" depth specified in the OIP for the counter top. See image. If you set that number to zero, you will find the issue resolved. I think that you'll also find that resolves the overlap problem you are having between drawers. It looks to me like the reveal input compresses the rest of the settings. My advice would be to avoid it and account for any top reveal with a custom counter top.