Can't Delete Toposolid Points and Guardian

 A quick follow up post on my prior post about deleting toposolid points. Scott Brown isolated the issue his team was having to their use of a 3rd Party tool called Guardian. When they disabled it they could delete points as expected again. If your firm uses Guardian too then check in with them about an update to see if it has been resolved yet.

Revit 2024 - New Home Screen

With the recent updates to 2024 we now have an option for a new HOME screen, presenting more options for how to preview and find projects. So far it's working pretty well for me. I noticed today that some projects are "not found" while using it however. Those same projects turn up in the old Home while not showing up in a search in the new Home screen. At first I thought it was related to the number of characters in the project name or the use of special characters but so far that isn't the case.

Ah the quirky stuff...

2024.1 Schema Warning

Glynnis with IDEATE posted information at the Autodesk User Forums that you should be aware of if you're using 3rd party tools and are going to deploy, or have deployed, Revit 2024.1. Ironic that this update is the one that has caused a potential disruptive issue since many firms wait for this point release to deploy. I've taken her initial post and copied it here, go read the entire thread for any more recent commentary. Thanks Glynnis!

There's been a lot of chatter about the Schema error that was landing in a post about What's New in 2024.1 so I took the good suggestion from @RobDraw to start a new thread here.

What is a Schema?

I welcome other people's input on this, but from my perspective, a schema can be best thought of as a blob of Revit metadata, held in Extensible Storage workset, that has a unique GUID. This blob of data is most often used by 3rd party developers but is also used by Autodesk (or companies acquired by Autodesk). The structure of that data, per each GUID, needs to be the same. If a developer alters the data structure, then a new GUID is needed to avoid the error.

What causes a Schema error?

In order to experience a Schema error, you need to have two files (or a file with a linked file) that have the same schema GUID but with a different data structure. Whichever file is opened first 'wins' within the active Revit session. This makes solving these problems REALLY hard because the file that displays the error is not necessarily the file with the 'problem' schema. It's also why this problem seems to be squashed sometimes and then resurface later. If you only ever open one Revit file at a time within a session of Revit, you'll never see the error.

What's the New Problem

The new problem seems to relate to Revit files that are upgraded to 2024/2024.1. The 11 July Revit 2024.1 release notes show that in there were changes made to the API to try and fix an outstanding schema condition. It feels like that change may have created some new conditions. We have an open case with Autodesk on this issue.

This is the latest schema article on this at Autodesk

Autodesk Revit schema issue article

Phasing and Replacement Windows

Over the years people have often complained about trying to document replacing existing windows with modern windows but maintaining the existing opening. This means swapping windows with families that are the exact same size. This is related to the wall that Revit creates to infill a wall that has a demolished window. You may have encountered this warning message?

That message appeared when I attempted to place new windows in the New Construction phase after demolishing the existing windows first. I was careful to set up views assigned to different phases and phase filters so there wouldn't be any display conflicts.

I got interested in this issue again recently because of a thread at the Autodesk User Forums for Revit Architecture. A fellow member was sharing how much trouble Revit has been giving them trying to do this kind of work. After some back and forth I narrowed it down to one window family and another member realized that family uses a void to cut the hosting wall in the family itself versus the usual opening.

This led me to write some hypotheses for testing purposes. I wrote:

Hypothesis A: Within phasing we can replace Existing Window A with New replacement Window B using the exact same sizes (same size opening dimensions) IF they both use an OPENING in the family to cut the host.

Hypothesis B: Within phasing we can replace Existing Window A with New replacement Window B using the exact same sizes (same size opening dimensions) IF they both use a VOID in the family to cut the host.

If either of the above are false then...

Hypothesis C: Within phasing we CANNOT replace Existing Window A with New replacement Window B using the exact same sizes (same size opening dimensions) IF one uses an OPENING and the other uses a VOID, in the family, to cut the host.

I did some testing using the latest release of Revit, 2024.1 and I determined the following:

Hypothesis A is TRUE

Hypothesis B is FALSE

Hypothesis C is neither

I find that I can replace a Void based window with an Opening based window but not the reverse. Also any alterations to the hosting wall in the project; such as length adjustment, or top/bottom offsets, attach/detach will place the void type window at risk of being deleted. Weirder still is that it might not delete all of them, one or more.

It seems that the short answer is: eliminate window families that use a void to cut the hosting wall IF you intend to place identical sized windows in phased projects; to demonstrate existing window replacement without altering the existing openings. Windows created this way will not work for this task. A logical next hypothesis is to anticipate similar behavior in door families.

I speculate that this warning happens because an opening cuts fully through the host while a void (or combination of voids) might cut more and/or less of the host as it travels through it. I suspect that the infill wall can't abide the shape a void might create and that in turn means a void won't be viable as a window to alter the location of the infill wall. I think it's similar to curtain walls only supporting non-rectilinear panels with the system panel families.

I'd love to hear that the developers will test this against their own experience and expectations. I know that a lot of people rely on voids to shape the opening in a host wall to match a variety of actual construction techniques for openings. To eliminate voids in families as an option for this kind of project (replacement windows (and doors?)) is not ideal. They'd probably have to revisit the entire logic of infill elements where demolished hosted elements occur. Perhaps leave it up to us to fill in holes?

Topography Links and Using Tag by Category Makes Revit Angry

This one is subtle, like so many Reviteristics.

A team is testing the Revit to Civil 3D relationship via BIM 360 and Autodesk Desktop Connector. I don't think there are enough moving parts for this equation but I digress. A user reported that Tag by Category (TbC) causes Revit to crash.

We narrowed it down to linked Topography. If any exists then TbC gets dicey. Here's what we know so far:

• Topography link Not Loaded status > Topography category visible in active view > TbC crash
• Topography link Loaded status > Topography category NOT visible in active view > TbC NO crash
• Topography link Loaded status > Topography category visible in active view > TbC NO crash

The team's project has two different linked topography sources so there are two of them in the Manage Links dialog. I haven't tried with just one present yet.

I'd be curious to see if anyone else can corroborate our situation. I've submitted crash reports (several/many) as I worked on this so perhaps Autodesk will find some lurking evil to contend with in the meantime.

Happy troubleshooting...

Revit 2020.2.1 Hot Fix Posted

Regarding my last post - a Revit 2020.1 Hot Fix is now posted.

Of specific interest...Autodesk writes:

Issues Resolved:
Fixed an issue that resulted in the loss of family data in some workshared models when family definitions had not been recently modified. This fix does not repair models which have encountered loss of family data, for more information refer to Family Corruption in Revit 2020.2

Revit 2020.2 Corrupt or Unusable Families Issue

Autodesk posted an article describing a particularly unpleasant bug/issue that started to appear shortly after 2020.2 was made available. This is the text from the article. If you're using 2020.2 pay close attention, you don't want to catch this bug. They've removed the 2020.2 download until they've resolved the situation.

Issue:
The Revit team has identified a defect with Revit 2020.2 that affects a small percentage of customer projects. In order to reduce the likelihood that customers come across this issue, we have temporarily removed the Revit 2020.2 updates while we work to provide a build that remedies this defect. For customers that have already installed Revit 2020.2, please see the FAQ below. We apologize for any inconvenience this issue may have caused.

Solution:

Q. What is the issue?
A. A change in the way that Revit 2020.2 processes families can cause family content to go missing from workshared central models created in previous versions if the families have existed in an active project for a long time without being modified. The defect results in the deletion of the family content from the central model.

Q. Which versions/models are affected?
A. This issue affects only Revit 2020.2. Previous versions are not affected.

Q. What models are affected?
A. The issue can affect workshared models that were created or upgraded in Revit 2020.0 or 2020.1 which are then repeatedly modified in Revit 2020.2. This issue can impact central models stored locally, on Revit Server, or in Revit Cloud Worksharing. The following models are NOT affected:
Non-workshared models
Workshared models created and exclusively modified in Revit 2020.2

Q. What if I have already installed Revit 2020.2?
A. If everyone on the project team is working in 2020.2, there are a few one-time operations you can take in a Revit 2020.2 build to prevent the issue:
Rename all families in the project (e.g. FamilyX to FamilyX-2 and then back to FamilyX)

OR

Save the model as a new central (must be a new file, not Save As to the same location)

OR

Reload all families (including company, Autodesk, and 3rd party families) in the project

OR

Move the entire project team back to Revit 2020.1
If the team is working on mixed versions, we suggest first getting everyone onto the same version. Working in a mix of Revit 2020.2 and earlier versions can reintroduce the issue to model(s).

Q. What is Autodesk doing to resolve the issue?
A. The Revit team has reproduced the issue and is actively working on a build that does not contain this defect. In the meantime, we advise against installing Revit 2020.2 until the Revit team provides an updated build. To reduce the likelihood that customers come across this issue, we have temporarily removed Revit 2020.2 updates from Accounts and the Autodesk Desktop Application. Due to backend constraints a full install of Revit 2020.2 continues to be available from Accounts.

Q. When will a fix be available?
A. Thanks to the support of our valued customers, the Revit team has been able to reproduce the issue and has identified a fix. In the next few days we will be thoroughly testing the fix. Assuming all goes well, it will then take the team a few more days to make the build available in Accounts and the Autodesk Desktop Application.

Q. Revit 2020.2 has been available for months – why didn’t Autodesk communicate anything previously?
A. The Revit team was first made aware of a possible issue by our customers a few weeks ago. Since these kinds of issues can be difficult to reproduce from scratch, from the time a concern was raised we have been working closely with those customers to reproduce the issue. We were finally successfully able to reproduce, and therefore confirm, the issue at the end of last week when we took action to limit the availability of Revit 2020.2. We have been working diligently to clarify the full scope of the impact and the possible workarounds in order to write this communication.

Q. Why didn’t the Revit team discover the issue during pre-release testing?
A. Unfortunately because this issue requires a combination of model creation and modification of families in a previous version and then extensive modification to the same model in 2020.2 it does not lend itself well to typical testing practices or automated regression tests. This means that unfortunately, despite rigorous Revit 2020.2 testing, we were not able to identify the issue before it affected customer models. We sincerely thank the customers that escalated the issue to us so that we are now able to take appropriate action.

Q. What actions will the Revit team take to prevent this kind of issue from happening again?
A. After the Revit team resolves the immediate issue, we will be holding a retrospective to clarify how the defect occurred and what specific actions we can take to prevent similar issues in the future. As much as possible we will look to create automated tests to cover this kind of situation as that means that every future Revit code submission will be scanned for similar problems.

Keynote Legends and Keynotes not Updating 2018.3

In Revit 2018.3.2.7 I am seeing and getting reports that keynote legends are not updating to show the current state of keynote tags visible in views. The existing workaround to force a refresh by turning on/off the Annotation Crop Boundary works but is entirely impractical to expect a team to open every sheet and do that task for each and every view on a sheet.

This past Knowledge Network post seems relevant. A portion of the text at that article suggests...

Workaround:
There are a few ways you could work around this behavior, and the best method will vary depending on the model geometry and number of affected tags. Here are a few options:

Temporary fixes (these will restore the display keynote tags, but future view changes will clear them again): 
Temporarily adjust the location of the Cut Plane so that is above the affected elements (this will restore the value to the tags) and then restore the original cut plane location. Note: Some customers have noted that for views with dependent views, this process is required:

1. Open the parent view and adjust the cut plane upward.
2. open all sheets containing dependent views belonging to this parent view to refresh the keynote tags.
3. move the cut plane back to its original position in the parent view.

(Note: this may not work for some elements such as Duct; in that case, see the Non-temporary fix below.) Recreate the affected tags manually.

Non-temporary fix (This will prevent future changes to the view from clearing the keynote tag): Adjust view or elements so that the cut plane is above the affected elements. (This could be done with a Plan Region.)

We really need this fixed ASAP!!

Color Fill Calculation Failed is Back

This warning appeared quite a bit with Revit 2016 and patched in subsequent updates.

I've clicked Restart to no joy and I've submitted the error. I've done the Edit Color Scheme and Cancel process described for Revit 2016 with no joy either. Hopefully it will get sorted out again.

Imported or Linked DWG Appearance as Generic Model Broken in 2017

Using Revit 2017, I have a 3D DWG file for some framing that I want to use as a coordination reference within a project file. Initially I linked the file directly to the project but that approach (unfortunately) doesn't respect the cut plane of a plan view which, for example, means cripples above a header show up in the plan view too (header as well).

I decided I'd use the old create an in-place Generic Model family trick.

If you're with me so far you're probably expecting what I expected; to find that Revit regards this imported 3D geometry as generic model (cuttable) category information, giving me the look I wanted. However, when I clicked Finish Model the linked file disappeared entirely.

I thought for a moment, "Am I just imagining that I could do that? I swear Revit used to do this?!?"

Hmm, I decided I'd create a component Generic Model family instead and use Import CAD. This way I could replace the source CAD file if necessary.and just reload the family later...if necessary. Also thinking, "...maybe it'll work this time, this way...?" Nope...

I gave in, I did a quick search using Revit Help and noticed a result called "Regression Revit 2017 - Cutting 3D DWG with section results in inconsistent model display".

NUTS! ...at least I'm not crazy (about this at least)...

Well I'm writing to declare that it's not just an issue in section views. The damn thing doesn't show up in a plan view at ALL.

It works as I remembered in Revit 2016...project is in 2017 though.

I did try creating the family in 2016 and let Revit upgrade it in the 2017 project...no joy...busted. I also created a Specialty Equipment family (in-place too) and it shows up in plan view but since that category doesn't cut...it's missing the point, my reason for traveling this road in the first place.

sigh ... next service pack, update release, patch...(whatever they're going to call...)

Revit 2017 - Align Padlock and Wall Core Centerline

If you think you're going crazy because no padlock appears when you try to align and lock a Wall by its Core Centerline, you're not crazy (not about that anyway). Revit 2017 seems to have gotten distracted and doesn't turn on the padlock when using Align on that portion of a Wall. Damn that's subtle!! They are on it though. I imagine it'll be fixed once an Update Release (Service Pack) is made available.

Group Editing and Ceiling Hosted Elements

Aaron Maller let me know about an unpleasant bug he's encountered in both Revit 2015 and 2016. If you're thinking, "Boy I'm glad I didn't listen to Steve's rant yesterday." Point taken... It's the exception though, not the rule.

Simple steps to reproduce the issue:

• Create a new project
• Create a ceiling
• Place at least two light fixtures (faced based or ceiling based)
• Create a Group (of the ceiling and both fixtures)
• Copy the Group to create several instances
• Edit the Group
• Swap or move one fixture
• Finish the Group

Where did the other fixture go? It (they) is (are) Excluded. If you select the Group you'll see Restore All Excluded appear on the ribbon. If you use that tool you'll find the fixture is no longer hosted by the ceiling though. It will report in it Host parameter.

If you'd like to avoid this issue then:

• Edit the Group
• Make the changes you need
• Select all the fixtures
• Nudge Up and Nudge Down to put them back in the same spot
• Finish the Group

The copies should be intact, no excluded elements.

I've also found that I can use Save Group, edit the Group in its own file and then use Reload to refresh the Group in the project. This doesn't seem to suffer from the same affliction. Take it slow if your project is using a lot of groups with ceilings. The issue doesn't seem to affect elements hosted to walls, not in the testing I've done so far at least.

Here's a video example of what happens and using Nudge to avoid it.

Quirky Roof - Roofing Around

A recent thread at the Revitforum.org asked about this roof form.

Don't worry about the dimensions. I used them to make sure a roof would work if I was "careful". I later messed around with it a bit to see if I could reproduce the error the original poster described, like this.

The other day I was discussing roofs with someone and I brought this situation up. I used the arrow keys to nudge walls around and thought the result was worthy of a quick video to demonstrate how different proportions affect the roof outcome. It's certainly quirky, maybe even "buggy"?

Thin Lines and Printing Sheets

Reading reports (at RevitForum.org) of the Thin Lines feature affecting the output when printing from sheet views. In my own quick test I'm seeing the lines of the titleblock being printed respecting Thin Lines being on which isn't good.

The model views appear to be printing correctly, just the title block's own lines seem to be affected. When I printed a model view using Thin Lines the result was the same as with Thin Lines off. In other words, working as we've come to expect, the Thin Lines feature had no impact on printing. Or, we've not noticed it before.

When we use Temporary Hide Isolate we get this dialog to ask how we want the feature to be regarded. If Thin Lines is meant to be able to get printed then perhaps the same sort of warning/option ought to be offered?

Any readers that can confirm this too? Seems like an undesireable "feature".

Suppress Spaces Revisited

In Revit 2012 (wrote about this earlier) we had the ability to shrink imperial dimension values a bit.

The upper dimension shows what 2012 did when Suppress Spaces was checked. The bottom shows unchecked. In 2013 we lose that. In my earlier post I missed/forgot that Ryan responded explaining what changed. Rats, I don't like the change, I want my old suppress spaces back by golly! This is what we get now (using my best Craig Ferguson accent, "It makes littul sense tah meee").

Undo History Gone

Recently learned of a couple reasons that you can find that your undo history has been cleared out. It involves projects that use worksets. When you do something that causes Revit to take ownership of a workset first, in order to do what you want, like deleting a view, Revit clears out its Undo "stack".

In the case of a view if you borrow the view first and then delete it the undo stack remains intact. To borrow it first you'd have to select the view's annotation symbol, right click and chose Make Workset Editable. You can do the same thing in the project browser over the view name, choose Make Workset Editable too. You could also alter a parameter and reset it or use the Workset dialog to make it editable.

Same thing happens if you delete a family from the project browser without borrowing it first. To do that you can click Make Workset Editable via Right Click on the family in the project browser too. A component family will Make Workset Editable while a family's type will offer Make Element Editable. The workset it refers to is the family workset found in the Workset dialog when you select the Families "Show" filter.

It isn't really intended to happen that way. Optimistically we could see a fix in a future update but more likely not till another release.

All Capital Letters

Saw a request recently to change the "Grand Total" (title as Revit calls it) that appears at the bottom of Revit schedules from Sentence Case to Upper Case.

My first reaction was to wander down the path of reminiscing why we use upper case in documentation at all. Going back to hand drafting and reducing the number of characters to master for simplicity and consistency sake. Whenever something like this comes up you can go the route of justification/explanation, "Well, here's why Revit does it that way. I know you don't feel better, but at least you know why though?" Alternatively you can just go the route of apologizing, "Nope it doesn't do that, sorry!"

Something like this request both seems like such a tiny thing to fuss over and still such a tiny thing for the developers to overlook. Why can't we change the "case" of such automagic labeling?? Surely it can't be hard? If we add in localization, making Revit use a different language, there are some examples of where users are stuck with the English text even though the rest of the words on the documentation aren't. I seem to recall the word Scale for the view scale is/was one of those.

If you really want to get your way, you can, not hard...just isn't automatic, you'll have to keep after it. Alter the schedule so it uses the Totals Only option. Then at the bottom of the schedule add a text element that says "GRAND TOTAL". You've got to move this as the schedule expands/contracts. Remember to check it before printing.

Maybe someday they'll make it possible to change these "little things"? Definitely a Dept. of Reviteristic or perhaps Dept. of Quirky or Dept. of Subtle. Heck all three work for me!

[Added: 1/10/2012] Paul Aubin mentions in a follow up POST that we can use a font that only has upper case characters. That's a trick that a few people I'm met or know from the user forums on the "internets" have used. Assuming you can find such a font that is acceptable it might just work. Remember you've got to make any downstream users also have the font.

Elevation Update Update

A comment showed up on my earlier post regarding elevation tags that don't update in stand-alone project files, which reminded me that I never posted this information though I intended to do so.

Steve Faust with Revolution Design let me know back then that the Elevation Fix utility they created is kind of a follow up to your blog post showing the problem. It was developed primarily by Nick Kovach who posted the ‘problem solved’ comment. You can find out more about their solution as well as downloaded at their SITE.

These are the previous three posts (October 2011):
Revit OpEd: Elevation Update Update
Revit OpEd: Elevation Update Update Updated
Revit OpEd: Elevation Tag Update Not Happening

Show Title Option

Revit viewports have a parameter called "Show Title". The Type Properties dialog offers us "Yes", "No" and "When multiple viewports". This post deals with the wordy one.

The "When multiple viewports" option is meant to make it easier to leave off a view title when you are only putting one view on the sheet. Most of the time the sheet title is the same as the viewport title, like for overall plans. Seems a bit redundant to put a view title on too?

Unfortunately using it means we have to give up the option of having the viewport title extension line snapping into alignment with other viewport extension lines. I'm referring to the line that shows up when you check the box for "Show Extension Line".

If you are used to these lines snapping into alignment with one another, they won't when you use the "When multiple viewports" option. I captured a short video to help see it in action.

Show When Multiple Viewports

When you put a view on a sheet, its viewport has a parameter (Show Title) that determines when we see a view title. There are three choices; Yes, No and When Multiple Viewports. The third option (When multiple viewports) will cause Revit to only show the view title when there is more than one viewport on a sheet.

An interesting thing happens when you actually use the When Multiple Viewports option, we lose the snapping sensitivity that the view title line has when adjusting the length/position of the line. I've created a short video that shows it in action since it's easier to see that way.