Lately we see this warning message appear, in BIM 360 hosted projects, when clicking the Save button (local) instead of the Synchronize with Central button.
Wednesday, April 14, 2021
Wednesday, April 07, 2021
A team was trying to override the appearance of the DWG layers after linking the file to their Revit project. Usually the reason for this not working is elements are not assigned to color or line pattern BYLAYER in the DWG.
In this case it wasn't working because the DWG was not within View Range's Primary Range, it was in the View Depth zone. Projection and Cut linestyles work inside the Primary Range and the <Beyond> linestyle is used for elements within View Depth.
Good catch Mia!
Friday, April 02, 2021
If you've found rogue RVT links in your model it might be Transfer Project Standards (TPS) and View Templates to blame. When you need a View Template from that other project you're working on you run the risk of adding RVT links to the project's database. You'll find them listed in the Manage Links dialog but if you try to reload them Revit will tell you there aren't any instances placed.
This happens when a View Template manages overrides to those linked RVT files in "that other" project. Just remember to check Manage Links after using TPS (reports, haha); otherwise this Gotcha will Getcha.
Hat tip to Alexis Kotzambasis for identifying this issue.
Friday, March 19, 2021
We've been running into this situation lately. Linked Revit models start using an individuals collaboration cache location for the path instead of the project's BIM 360 location.
At first it seemed that we could resolve it easily by applying the update for Revit 2020. Most of the active projects I deal with are still based on Revit 2020.
It appears that a fair number of firms are deploying "even" years and skipping the "odd" years. The larger the scope of deployment seems to have some influence over that choice. I've been working with 2021 in smaller situations though, wishing it were true everywhere...I digress.
Autodesk acknowledges the issue and has this ARTICLE to contend with it.
Wishing it were that simple, we are still running into it. Naturally there is another ARTICLE that mentions they are still researching the issue but that using Force Relinquish (BIM 360 Manage Cloud Models option) can cause this situation too. This requires us to clear the collaboration cache for a user who has forced us (haha) to use Force Relinquish. We are still in the diagnosis phase ourselves so we're not convinced of anything yet.
The article also tells us that using Force Relinquish should be a last resort and not recommended for routine use. Autodesk article says,
"This is happening because somebody has used Manage Cloud Models to force relinquish that user from that link, which breaks the link in the host model for the affected user."
"Note: Force Relinquish is a destructive operation and should be used sparingly! It is intended to be used as a last resort when the user to be relinquished is unavailable for some reason."
"If someone has been forced out through Force Relinquish, then all the changes that they have not synced, become orphaned and lost. While the central model will be unaffected by the use, people can lose work (and have to close and reopen the model which will be slow)."
"It is better for the user to open the model and use Relinquish All Mine to relinquish their permissions rather than using the Manage Cloud Models dialog."
Okay, that's fair. However the new named user subscription based model "forces" this option on us (not haha) at large because we can't pretend to be another user anymore. As soon as we log off to become that user we lose our Revit session too. Catch 22
It would be nice if employees didn't quit and go elsewhere or earn a dismissal. It would be nice if 3rd party applications didn't need to borrow a workset on our behalf and then refuse to return a workset without our knowledge. It would be nice is 3rd party applications that do automation didn't require their own username to run quietly in the background and then fail to return a workset from time to time.
That world is where we can find pink unicorns with diamond encrusted saddles, at least I think that's where they are, I could be wrong?
Right now clearing a workset conflict in Revit Server projects is not nice. BIM 360 at least has Force Relinquish...but now we're told you really shouldn't use it because it might wreck your linked model paths. It starts the kind of internal conversations that make EyeTee license management "heads spin". Nobody wants users to start sharing log in credentials do they?
Thursday, March 18, 2021
I read THIS post at RFO with interest naturally. The thread is about losing dimensions when linked files are updated. A subtle development in the thread is that radial dimension and linear dimensions are affected differently when a link is unloaded. Aaron Maller noticed that, mentioned it (in the thread) and asked someone at Autodesk about it. They looked into it and replied with:
Originally Posted by Autodesk Team
Here are the details. This is caused by the inconsistency between linear and radial dimension internal design.
For linear dimension, it handles “Unload a linked file" as a special case of dimension references not visible in the current view, while for radial dimension, it handles the unloading as invalid dimension reference, and thus it requires deletion of the radial dimension when unloading.
We will see how we might improve the radial dimension to follow a similar behavior pattern.
The emphasis was added by Aaron. Okay, good to know. For now, radial dimensions are at great peril if they are referencing a linked project. Best bet is to avoid dimensioning to linked elements anyway but especially so with radial dimensions.