Software and technology related pointers and help for end users and support teams.
The instructions found on this blog saved me about 57 mouse clicks the other day. Maybe not 57 precisely, but a LOT OF CLICKING.
Basically you get into Windows WMIC and tell it to find all the software from the vendor “Autodesk” and remove it.
One tiny snag I hit was that it forced a reboot after one of the uninstalls. Just logged back in, ran the command again and voila! A ton of Autodesk software was gone!
Kudos and big thanks to the original author over at Prosoft.
Let’s say you need to align something to the center of a circle or arc or ellipse, or vice-versa, you need to align the center of a circle or arc or ellipse to something. When you are in the ALIGN tool and try mousing around the center, nothing shows up. You also cannot override your snaps to find it!
Calm down! It’s gonna be OK. Select that circle (or arc or ellipse) and check out its Properties. See that parameter? CENTER MARK VISIBLE.
Turn that guy on, and then you can align to it!
Put this in the category of “The Missing Revit Manual” in the same chapter as “View Discipline“.
Turns out, Wall Function isn’t just an extra parameter to filter by. We just came across this one. When you change the Wall Function to FOUNDATION, it forces the placement of those wall types to be “Depth” and not “Height”.
Did you even know that was a thing? I would say that 99.99% of the time when a wall is placed, it is assumed to go in the positive Z direction, or in other terms, “up”. The good old Options Bar lets you change the placement from “Height” to “Depth” meaning you can make your wall go “down”. Who changes this? Does anyone ever change this?
Anyway, if you change your Wall Function to “Foundation”, you can ONLY use “Depth” which can cause some hilarious errors as you place a wall.
I am confident some of you knew this already, but it’s news to me and it was news to everyone who I talked to in real life (or “offline” as the kids say… they don’t really say that).
The HELP file has nothing that lays out what specifically happens when you change the Wall Function. I guess it’s time to dive in and see what else might change when we adjust that previously-thought-innocuous parameter.
When is a Text Type not really a Type?
Sorry, bad riddle. This is one of those stupid seemingly insignificant inconsistencies within Revit that I 1) forget about after a few weeks and 2) when I remember I scratch my head and say “Really?”
I love View Templates. The new ones that actually do what they should do. Not the old passive ones. It helps keeps documents in line and looking sharp.
Did you know you can assign a View Template to a Schedule? You can. Pretty smart that you can set some line weight and gridline and text settings. Well, mostly.
Mostly.
Turns out the Text Type that you assign to Title Text and Header Text and Body Text gets about 90% of the settings pushed through.
For some reason, the schedules have decided to ignore the Width Factor from the Type. It just leaves it at 1.
I know a lot of firms that like to squeeze info on there and have dialed their width factor down to .9. I know a couple that like to play with fire and have set it at .8! The maniacs!
Below is a screen grab showing simple annotation text on the top and to the right and the same word from a schedule; all three are using the same Text Type.
Whatever your level of text shrinkage, the schedules don’t care. This frustrates me. It poo-poos all over the idea of a View Template and leads to head scratching. I am already losing my hair, I don’t need bizarre incongruities like this leading to more hair loss.
I want to preface this by saying that I never lie to end users. But here’s some advice that I’ve picked up over my almost two decades of doing this: sometimes you have to keep the magic alive.
If you are general IT support, or if you are specifically BIM support, it often helps when folks pay no attention to the man behind the curtain. This might seem deceitful, and a good argument could be made that it is, but on a practical level you often have a fix for something that on the surface seems really easy, but you know from experience that there’s that one step that people always miss and then they are just going to call you anyway, doubling the time it would have taken to fix it.
So, sometimes, I don’t offer up the information about how I did something. If they ask I would tell them, but I try to be a little obtuse. And this is a tricky line to know when you need to hang onto certain tasks and what tasks you can safely give away. And it might vary per user too, it’s your tricky job to be able to know what to dole out to whom.
As an example, I had a user today ask me about a particularly slow model. The file was tiny (Revit speaking) and there was no reason for it to be so slow. I made a detached copy and did a couple first run fixes, figuring out that a simple Save As made the darn thing pretty zippy. So, I had my fix.
Saving a new copy of a Central File successfully has a lot of steps, and I wasn’t sure about the experience level of some of the users involved. So, instead of simply saying “Go ahead and just save as a new copy,” I said, “let me try a few things.” Innocent, true, and implies that this is a tricky IT task that requires a hydro-spanner and possibly a flux capacitor.
In the “First Word of STAR” universes, I fall way more in the camp of “Wars” than “Trek”, but I am often reminded of a quote from Mr. Spock in The Wrath of Khan:
Saavik: You lied. Spock: I exaggerated.
And that’s how it goes. I took the numerous steps to make sure everyone had synced, verified no one was accessing the central file on the server via Windows management, opened a detached copy while maintaining worksets, renamed the original’s extension (just in case), moved the backup folder for the “old” central file, saved the “new” model in the same place with the same name as the old one, then did one last sync to relinquish everything. Then I told everyone to get a new local.
Simple, easy steps, but enough little steps that someone could easily miss. Especially that last sync. That seems to be the one that throws people off.
And guess what? The file opened way faster after that.
So just keep in mind that another part of your job, one that isn’t written down anywhere, is to know when to let someone in on the secret and when to keep the secret to yourself.
Another one slips through the cracks or user’s minds. Again, funny what gets forgotten or overlooked through the years. It’s critical for trainers to not only teach new features and procedures, but also remind folks of lesser used but critical functions.. and sometimes it’s not a reminder at all.
You probably have a HUGE model with a TON of stuff in it (or even a TONNE of stuff, depending if you work in metric) and sometimes you load in a family or have a view and you just can’t find it.
Do you remember what it’s called, or even part of its name? You’re in luck!
Right-click on anything in the project browser and you get an option at the bottom of the context window to Search…
Type in part of the name of what you are looking for and it will go thru the entire model and find views, schedules, families, etc that match up with that phrase. It will NOT start over at the top, so start your search as high up as you need to.
We sometimes have content that gets placed and Revit shows us the message that even though you placed the element, you can’t see it.
The typical user will then try to place it seven more times and ignore reading that Warning each time. Exceptional users will often place 20 instances or more before reading it. Yeah, you know who you are.
There could be any number of reasons the element doesn’t show up, right now I want to address a work around we have for items that are typically placed just above the View Range of a plan, but we REALLY want to see on that plan. Tack strips come to mind. You want those placed up around 7′. The top of our View Range is right around there, too. There’s a good chance we aren’t gonna see that Tack Strip by default. And that’s because it is out of the View Range.
So, we cheat a little, and give Revit a little morsel for the View Range to grab onto. In the family we drop a model line that goes “low” enough to definitely go past the Cut Plane in the view. Then, uncheck the VISIBLE parameter for that line. Reload, and like magic the element shows up in the view. The model line is invisible, so you don’t see it, but it’s there, so Revit considers it part of the family and will include it in the View Range where appropriate.
For the few times that we need it, this has been a safe easy way to get these items to show. Of course, there are dozes of other reasons it might not show up. Just don’t keep clicking after you see that Warning box. Please.
Chalk this up to a quick little reminder. I find it interesting what the experienced Revit users in our office either don’t know how to do, or have just plain forgotten. It’s a good reminder about how complex Revit can be. It is also a reminder that I can definitely not know things or forget things as well. For example, what did I have for breakfast? No one knows!
Someone asked me about getting some drafting views out of a project in a 2013 model into a 2014 model. The basic idea would be to use INSERT VIEWS FROM FILE, but these models were really big. Add to that, the extra memory needed for an upgrade, and we had a recipe for a PC that would catch on fire.
Time for a third wheel! In my mind, I had the idea about using a “tertiary” model: transfer the views from the 2013 model into an empty 2013 project, upgrade that file, then transfer again in 2014.
Not bad, but the user came back and said “really? There isn’t a better way?” Before simply emailing the reply “Hey! Who carries the BIM Stick around here?!!” I thought they were right. That method kind of sucked. And there was a tickling at the base of my brain about a feature I had never really looked into. Maybe it’s time to research and not assume that I know everything.
Being in IT, and being in BIM support, one has to have a refined set of techniques for discovering new concepts, an expansive set of tools one uses to explore new ideas, and an organized method of testing each one and documenting the results.
I started right-clicking around in Revit.
BAM! What is this I see? “Save to New File…” right there in the context menu.
Yup. I bet a lot of you know about this. Some of you may not. It’s a cute little function that will let you export the selected Drafting View (or Views) into a teeny tiny Revit file. No extra garbage. No transferring into a tertiary file. This was my tertiary file.
Simple after this. Just open and upgrade this newly exported file in 2014 (a procedure that took WAY less time due to file size) and INSERT VIEWS FROM FILE to get them in there.
This will only work with Drafting Views, sadly, but it should be helpful getting that little detail out of that old project.
And don’t forget that no matter how long you’ve been working in Revit, you probably don’t know everything.
It’s that joyous time of year again! The time when the “first” service pack comes out for my favorite design software and I start thinking about deployments!
I wrote a very detailed deployment article some years back, and most of it still fits, however I have been able to tweak the code slightly. Here is a quick overview of what we found to be most effective:
Since we are in a domain setting and our users don’t have admin rights, we removed the UAC for workstations through a GPO.
A fantastic tip from the outstanding blog Up and Ready helped me track down the individual software packages for the Suites that we have. I like having an individual deployment for each piece of software, so I can give User A Revit and AutoCrap, but I can give User B Revit and Max, and then give User C only Navisworks. When you create a deployment from the Suite, you can specify only one piece of software, but the package that gets created is HUGE and has a lot of extra crap. Fortunately, you can use your Suite license on each individual software that the Suite includes. So, download the individual software package and create deployments from those to save space.
I then use the Autodesk utilities to create a deployment, after tweaking our Revit.ini file. This is much better than years ago. It’s clean and the importing of the Revit.ini is really nice. It’s a tad annoying that I have to install “vanilla” Revit first, edit my options, and then track down the Revit.ini file to use, but it’s not horrible, and it works. Possibly it would be better to have a utility that only creates a Revit.ini file with no Revit; some wizard-y thing. Eh.
Again, I am using the remarkable AutoIT script editor to create two “wrapper” files: one we call “net” and one “local”. If you do some IT, this utility is gold. Get it. Now.
The “net” wrapper gets assigned through a GPO to a scheduled task that kicks off whenever someone logs in to the appropriate PC. “Net” will check to see if a little .txt file exists on the C: drive. If it doesn’t, then it goes and copies “local” to the C: drive and runs it. A little note about the text file: it’s here to see if the installer has run. We could check to see if the Revit.exe exists, but this way I can copy the .txt file to individual PCs that we may happen to want to skip this install, but not put in their own OU.
“Local” wrapper has all the info from the installer shortcut created by the deployment. Its main job is to pretend it is a user with admin rights, then run the install. Once it is finished, it write the .txt file to the PC to say “Hey! I’m done!”
We have had a high rate of success with this method. It allows us to deploy a nice tweaked version of Revit and not spend too much time messing with it. If you would like to get a copy of our “net” and “local” files, fee free to take a look below.
;create the place to keep the local file – will skip if path already exists
DirCreate(“LOCAL WRITABLE PATH TO SAVE THE LOCAL FILE”)
$MSoftPath = “LOCAL DRIVE LOCATION TO STORE TEXT FILES”
$LauncherFilePath = “NETWORK PATH TO LOCAL WRAPPER FILE”
$LocPath = “LOCAL DRIVE LOCATION TO STORE LOCAL WRAPPER FILE”
; the file that gets written after installer runs so it doesn’t run again
$TxtFileName = “REVIT_15.txt”
; local wrapper name
$LauncherFileName = “rvt15-local.exe”
; checks if the text file exists
If FileExists($MSoftPath & $TxtFileName) Then
;text file exists, so nothing to do
Else
; no text file – rock on
$LocLauncher = $LocPath & “\” & $LauncherFileName
; copy the local file down
FileCopy($LauncherFilePath & $LauncherFileName, $LocLauncher)
; run the local file with admin rights
RunAs(“ADMIN”, “DOMAIN”, “PASSWORD”, 1, $LocLauncher)
EndIf
; warm up the network
DriveMapAdd(“”, “UNC PATH TO DEPLOYMENT”)
;setup.exe and the deployment ini file can be copied from the shortcut
;that gets created with the deployment
;as can the arguments – below are what I get from mine
Local $ProgramFile, $argFile, $command
$ProgramFile = FileGetShortName(“PATH TO DEPLOYMENT\Setup.exe”)
$argFile = FileGetShortName(“PATH TO DEPLOYMENT\RVT2015.ini”)
$command = $ProgramFile & ” /qb /I ” & $argFile & ” /language en-us”
;this is the actual installer
RunWait($command);MsgBox(1, “Title”, $ProgramFile)
;write the text file – note that the file gets written even if the installer fails
;this is so the PC doesn’t keep trying to install again and again – track down the issue
FileOpen($TxtFileName, 1)
FileWriteLine($TxtFileName, “Revit 2015 Installed”)
FileClose($TxtFileName)
Enjoy! Hope this makes your installations a little happier!
If you’re like me, you get annoyed with extra software getting installed on your user’s PCs without your control. I like streamlining deployments as much as possible, I do all I can to keep users from installing software on their own, etc.
With the 2015 branded software, Autodesk introduced the Autodesk Application Manager. In theory, a cute little piece of software that can let you know when your Autodesk programs are out of date. In my environment it’s another memory suck, another pop-up, and another phone call from a user. My users simply cannot install the updates on their own even if they knew about them. They don’t have admin rights.
Luckily, according to the FAQ, if I don’t want it for a network deployment I can just uncheck the box! Perfection!
(Cue ominous music)
My AutoCrap deployment and my Revit deployment did this wonderfully. Uncheck the box, no Application Manager. And then I got to 3D Max Design…
Of course we had a problem. The deployment wizard said I couldn’t have Max if I didn’t install the App Manager.
Well, I wanted Max. There are some notes in the FAQ about editing the setup.ini file for a non-deployment installation, but I worried since I wasn’t doing a stand-alone install, this wouldn’t work.
The workaround I opted for was to tweak the Application Manager settings before the deployment. Like a lot of the software, you can first install it, set it up the way you like, and then save the settings to apply to your deployment. So that’s what I did.
I got Application Manager installed on my machine and tweaked the settings to tell it to not start on Windows start-up, to only check for updates once a week, and to not show any pop-up when it finds updates. Not ideal, but it should at least stay hidden mostly from my users. Mostly.
Once that is done, you export your settings as a tiny .ini file. I put mine in the same location of the deployment, just in case.
When you created you deployment, under the options for Application Manager, you can then import this .ini file to suck up those settings.
VERY IMPORTANT!!!! When you export your settings to an .ini file, there is a setting for “Files Location”. The default is the current users Windows Documents folder. The installer will NOT re-interpret this as a variable username and will deploy with the precise path that’s in there, so BEFORE you export your settings, change this to some universal non-user specific file location.
Design Tech Field Guide 