This week has seen the launch of the latest update for Revit. Revit 2024.1 builds out capabilities for design and documentation, interoperability and data transfer, and insights and analysis introduced in recent releases.
Image courtesy of Paul Aubin Consulting.
Check the product help for full documentation for Revit and Revit LT 2024.1 under the “What’s New” tab.
What's your thought on the latest enhancements?
Jonathan Hand
Industry Community Manager | AEC (Architecture & Building)
In our client's case - the add-in noted in the error dialog was one they used ~7 years ago (Im guessing that they formed their template off that project)
I like to call those CAD, droppings. That's why rebuilding templates is an evil necessity.
On the topic of the schema errors...
Schemas are data storage devices (as alluded to previously) that can be attached to any Revit element by any add-in (and yes, by Revit and Autodesk Revit add-ins as well).
Schemas are often attached to the Project Info Element when storing things such as settings, or are attached to entities such as doors or wall Types (or whatever) to track events or to tie entities together for coordination.
Schemas have a limited number of storage value types, and yes, they have a long identifier (also as alluded to previously) which is actually a Globally Unique Identifier (GUID).
Once created the schemas must always contain the same number of entries, each with the same name, and each with the same value type.
If the addition of a new field is desired, or if the developer wants to change the storage type for a field then a new schema needs to be defined. Autodesk reminds all of the developers of this requirement all over the API documentation. Yet even they forget from time to time (a couple of years back they changed a schema definition in a structural utility and crashes abounded until a service pack was issued).
This round of errors are resulting from an underlying change in how Revit stores ElementIds (previously as Int32 and now as Int64) and that is rippling down to storage entities that used the numeric value of those ElementIds.
When an application attempts to load an upgraded Int64 value into a previously defined Int32 container (or vice versa) there is a mismatch in type and an error occurs.
A fix was included in the 2024.1 patch that addressed a good number of the failures, however it doesn't cover all scenarios.
As noted previously, these issues are usually where multiple files with differing versions of the same schema are loaded (and yes, that loading can be as a result of a Revit link, or as part of a family, or as part of a family embedded in a family). This is due to the fact that Revit loads schema definitions into the Application's namespace instead of the Document's namespace.
For anyone that wants to make their head spin, here is a link to one of the first discussions in the Revit API forum concerning this:
There is another one or two after the service pack came out but you can look those up on your own.
-G
Good info, thank you.
I suspect that the culprit in our case was an elevator family downloaded from the manufacturer. We have two buildings on a shared site, so I used two different configurations to create the family. Everything is fine with the first family, but when I load in the second one (which uses a lot of shared sub-components), the error starts to crop up again.
In the short term, always opening with an audit still causes the error but allows us to at least open the project without crashing. I've just deleted the second family from the project for now, perhaps I'll just have to use Types with some visibility toggles rather than a second family. In the long term, hopefully future patches can improve things further but it sounds like third party family manufacturers may have to update things on their end.
Add-ins are the most likely cause, but many manufacturers programmatically create their families and install embedded information so yes, that could potentially be the culprit... as could be an add-in in use by a consultant that then loads a schema into memory as the link is loaded...
I use schemas to store room-to-door associations with the doors themselves for updating our door numbers after rooms get renumbered (our door numbers are based on the rooms they serve) as well as linking our detail views to our detail references in the door schedule so they can be easily updated after the detail numbers get changed (or the sheet number that they're on gets changed).
Dynamo functions can create and store schema data in addition to add-ins.
and, of course, there are many Autodesk Add-ins that use them as well.
-G
Have you found whether it is as a result of a template that this is occurring?
We had to redo a project and I asked our team in our other office location to do it in Revit 2023. I also asked all to put off updating to Revit 2024.1
I do think a linked file possibly caused it as unfortunately, I found that they upgraded the model with links loaded and still in an older version of Revit.
I could not replicate the issue and was not going to attempt to test a bad practice!
Unloading links, upgrading each link one at a time or with a tool like CTC, and upgrading the main model with links unloaded and reloading upgraded links. I do not get the schema error.
I did however uninstall Revit 2024.1 and reinstalled Revit 2024.0.2
Now waiting for the new update or save to upgrade to Revit 2024.1 by Autodesk
PS: our Templates and families are all in Revit 2021 and the Add-ins I use are CTC Manager suite, DiRoots and Guardian.
Yes, it's the process that matters.
2024 or 2024.1... 2024.1 did fix a lot of the schema errors that developers were running into, but the correct process of upgrading solves most issues encountered.
The errors that you show are how Autodesk resolved the schema conflicts as a general rule to keep from crashing (This was implemented back a couple of years ago when the schema errors were caused by Autodesk apps I believe). The issue that was introduced in 2024 was causing a recurrence of the crashing and/or of apps erroring out. So the exception and dropping of stored data was extended to cover more scenarios. It does still fail in some occurrences, mostly because of links (Revit can't "modify" a document that is linked so it can't dump the data to get past it, etc), but also sometimes simply due to what you have open when.
Going beyond the schema errors,
It was really good that the update fixed the repeating detail component issue, but those of us with old eyes and/or screens that are smaller than 30" still struggle to be able to read the properties and/or Project Browser while in the traditional "light" mode and dark mode has just as many eye straining issues for many.
At this point we have pretty much decided to skip 2024 at our firm (unless some great and wonderful thing happens soon). This is the first one that we have even discussed skipping in the years that I have been here. There are simply too many things that could cause a loss of production vs things that would be of enough benefit to outweigh those concerns.
-G
Gary - Im with you on this one. (unless you really need Toposolids).
The schema bug has corrupted some of our customers files, interestingly it may be something to do with BIM360 "upgrades"? (i.e. you cant manually upgrade a Revit file - you tell BIM360 to upgrade the project). As well as this, Autodesk has changed the logic on how shared nested components show within families (for good reason), meaning quite a few of our face-based families don't show in plans like they used to:
Nested Revit family components disappear after upgrading to Revit 2024 (autodesk.com)
One has to be very careful upgrading (unfortunately, that problem wont go away since its changed for good).
I'm pretty sure that everything you mentioned is possible if you don't limit yourself to face based families.
@RobDraw wrote:I'm pretty sure that everything you mentioned is possible if you don't limit yourself to face based families.
I'm not limiting myself to face based families...
Revit often forces it though: An Electrical Engineer links an Architectural Model into theirs and tries to attach a light fixture to the ceiling and... guess what... they can't because Revit does not recognize the ceiling as a ceiling, it sees it as a face. so, either they copy/monitor all of the ceilings (or walls for that matter for wall sconces) in a 450,000sf model and deal with all of the ramifications of that or they use face based families, just like all of the OOTB lighting families that Autodesk created in the "Electrical" branch of family content was created to overcome this limitation (this as one example only).
It would also be nice if I could create a scupper and downspout family that could be hosted to either a wall or to the face of a column (or even the end of a wall instead of the exterior face) without having to have two different families (or doing some cheat like placing a short 1/8" thick wall beneath the area paving to attach my wall hosted family to)
I could go on all day, but this is all beside the point as regards the original post so I'll stop there.
-G
I avoid hosted families for MEP models with linked architecture. We ran into tons of rework and opted for more manual means of coordination. You can't always count on consultants playing well in the sandbox.
@RobDraw wrote:I avoid hosted families for MEP models with linked architecture. We ran into tons of rework and opted for more manual means of coordination. You can't always count on consultants playing well in the sandbox.
...which kinda defeats the whole purpose in my mind. And it's all completely irrelevant to this thread or to my comments about Revit developers maybe needing to reconsider face-hosted families on a deeper level.
There should always be an option and Revit doesn't have many of those (a lot of work arounds to give the appearance of options, yes, but true options, not many. Too many hard coded and/or locked components that limit what we could do with an engine of this nature).
Besides, on most of our projects all of our "consultants" are in house (we're multi-discipline: Arch, Struct, MEP, Civil). We like to think in terms of being a team, whether in-house or not.
-G
When your projects are controlled within a box, it's easy to ignore or dismiss everything outside of that box. If you feel like you're being forced into using face based families and not liking it, you might want to rethink that before finding fault with the program. I just gave you one example of an alternative and you dismissed it. You're limiting yourself and blaming the program.
I am having the same schema errors and major crashes. I talked with Lance @ Autodesk support as well. Trying all the options to try and fix it. Another MAJOR issue is that upgrading a project to 2024, I lost about 50% of the families within my project, and hours of work need to be redone to fix the issue. I was online with a support agent this morning and trying to figure out why I had 10+ crashes yesterday; during the call, my system crashed, and when we went back into the project file all the gating families that I spent hours designing and figuring out were GONE!
We opened the backup file that was saved before I started the call..... and the families are gone from there as well.
This is a new laptop with a clean installation, weird things are happening. Never had any issues upgrading in over 15 years of using Revit.
I did create the backup of the older version. The issues are in the current 2024.1 file that is crashing and losing families. I have even gone into the families and cleaned and scrubbed them to remove anything I can. Even the nested families were cleaned and scrubbed. Bring them in, and it works for a while then crash, and they are gone!
Can't find what you're looking for? Ask the community or share your knowledge.