Don’t Forget You Can Search!

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.

More Workspace Fun

Thought I would drop an update on my growing collection of Lego Architecture sets. Added a couple more over the last few years and had to spread out the space. It’s kind of meditative for me to dive into a model. And they ALWAYS have all the pieces. Sometimes I think it’s not there, but it is.

Detail Groups

Seriously? You’re still using Detail Groups? Stop it. Just, stop it. I’m not kidding. Make a component. I have witnessed Detail Groups murder a model. I can never forgive them for that.

Seeing Something That Is Up Way Too High – Without a Stepstool

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.

Yeah. THIS window. You know 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.

Moving Drafting Views Around

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.

Again, the BIM Stick

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.

Random Blog Stuff

One – I apparently suck at OK’ing comments.

Two – I cannot find a theme I like.

/sigh

My Heart Breaks a-new

Another new Revit, another disappointment.

Yes, I know new features lists have been out for a while and people have been using 2015 for some time now, but some things just… the hurt is TOO MUCH, you know?

Seriously, now that View Templates are working like they should, and have been for some time, why must I still rely on the antiquated Phase Filter?

Just give me access to the Phase and Phase Demolished parameters in my View Filters! While we are at it, open up all the parameters to the View Filters!

Yes, this is a total recap of a previous post, and yes, kudos to you for remembering that, but this has got to be one of my biggest pet peeves at this point. Keep Phases. Dump Phase Override and Phase Filters. Give me one place (granted, it’s a BIG place) to control what my views look like.

Revit Deployment Time

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.

NET

Local $TxtFileNameLocal
Local $TxtFileName2
Local $LauncherFilePath
Local $LauncherFileName
Local $LocPath
Local $LocLauncher
Local $MSoftPath

;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

Local

#RequireAdmin
; text file to create after installer attempts to run
Local $TxtFileName
$TxtFileName = “LOCAL DRIVE LOCATION TO STORE TEXT FILES\REVIT_15.txt”

; 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!

Cloud Credit Chaos

So, this has happened twice now. Autodesk has lost my Cloud Credits twice.

I think I understand the changes that Autodesk made to the credits since they were introduced; the migration from overall pooled to individuals having 100 credits, the introduction of having to buy “shared” credits, etc. All I can do about these changes is whine, of course. We have a couple of individuals who eat credits like candy, which forces me to buy more, even though we have dozens of other users with their 100 credits sitting there, untouched (and yes, we could cheat and have the candy-eaters just login with the non-eaters 360 account, but that is obnoxious). It’s a business decision that Autodesk made, and it I want to play in their cloud, I have to follow their rules.

But when something stupid happens, I get a little ticked off.

We had an individual who tore through the credits, as I expected. We bought a BIG batch of Shared Credits. Late last year I got a frantic email from this user, stating he was doing some rendering, but the amount of available credits was reported at none. Zip. Nada. He was confident that the day before, it was reported at over 2,000. Whoa. That’s a LOT of rendering.

Honestly, my first guess was that he was mistaken. Luckily, the Autodesk site has reporting tools that you can look at to see what the credit usage is. So I logged on, expecting to see a long list of renderings from this user over the last couple days that will show all the “lost” credits. But, when I got there, the reports weren’t working right. It showed no usage, which I knew was wrong. My theory on what happened quickly changed.

Long story short(ish), we got in touch with Autodesk support, got some semblance of the reports working, figured out how many credits disappeared and had them restored. The problem is, this took about a week. I could have bought more credits, but really didn’t want to give any more money to Autodesk until they got the rest of my money back. You see, 1 Cloud Credit equals 1 dollar. So this was over $2000 that was missing. Nothing to sniff at.

I assumed this was a one time event. Spoiler alert: I was wrong.

Flash forward to just a couple weeks ago. Same user. Same email. Same missing Cloud Credits. This time, the reports were sort of working, and it report that this user had used 600 credits, which is WAY lower than it should be. Reached out again, track down my invoices for when I bought the Shared Credits, send them in, wait a week, and get my missing credits back.

Here’s the thing: Autodesk could never precisely tell me what happened to the missing credits, and my reports show that I never purchased any AND now my reports show that nobody has any credits, when I know they should all have 100, used or unused.

Support has been as helpful as they can on these issues, but they shouldn’t be issues at all. Something seems VERY broken with however they are tracking the usage on the Cloud Credits. I now have to plan to go in weekly to check the status; not to see how many have been used, but to see if it’s broken. It needs to be fixed.

Autodesk Application Manager Annoyance

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…

If Autodesk had pants, they would be on fire right now

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.

Change this path before exporting your settings