Dynamo Blues: 10 Things to Avoid in Your Script and How to Fix Them

TADEH HAKOPIAN: Hello, and welcome to my presentation, Dynamo Blues, 10 Things to Avoid in Your Script and How To Fix Them. I'm Tadeh Hakopian. Let's get started.

A little bit of our session today, this will be around the Dynamo environment that Autodesk has for Revit. It's a great software. I love it. I've been using it for years, but it can give you some headaches.

So in this session, we'll talk about the 10 big things that can cause these headaches, these script errors, these problems a lot of people run into for strange behavior in Dynamo, signs of what that problem looks like in your script, in your environment, what to look for an error, how to fix it, And the kind of documentation, information you need along the way to get help understanding how to solve these, and also, how to help yourself for any kind of related issues, because there's more than a few things that can go wrong with Dynamo. But when you think of the world of programming in general, you have to be a problem solver. So we'll go over 10 things today, and we'll give you some good lessons to learn for future problem solving outside the scope of this discussion.

And for the specific learning objectives, we'll talk about the 10 common issues people run into with scripts and templates, and how to reduce those error rates. Learn about Dynamo's errors and warnings, and how to troubleshoot your script. Learn how to diagnose problems with your script on your own to resolve bugs, and talk about the kind of documentation and resources available to everyone to figure out how to solve these problems on their own.

So about me, I am Tadeh Hakopian. I've had experience in large-scale design construction projects and AC for 10 years. I've done lots of data, BIM, and VDC work. And of course, working with Dynamo a lot since my projects are so big, and they have a lot complicated parts to them, I have to be as efficient as possible. And using something like Dynamo to script my solutions in these kind of prototype [INAUDIBLE] tools goes a long way in that regard.

And I've learned a lot of lessons myself of what to do and not to do, learned a lot from the community. So these lessons I've learned myself, learned from others, learned from community. So I'm going to share that with you today so you don't have to repeat the mistakes I made. But first, let's talk about basic concepts.

And my own experience, like I mentioned, I worked with Dynamo for quite some time, going back, I don't know, 2017, something like that. And I've done a couple of sessions. These are all my talks I've done over the years at Autodesk University. If you want to do some refreshers, I got Dynamo Super Powers, Part 1 and 2. These are about all the cool packages out there to help you become more efficient with Dynamo. So you'll want to give that a look and see what's possible for you to use in Dynamo. Because you have, out of the box, has built-in stuff in Dynamo, and you have all these awesome community projects as well. So that's most Part 1 and 2 is about.

Deploying Dynamo for Your Company. This is a big topic because we may be all comfortable with Dynamo on our own, on our own computer, our own machines, but how do you do that for your entire company? And [INAUDIBLE] I had to [INAUDIBLE] a couple of years ago and have a talk about how to do that yourself, lots of great information there. And for more advanced users, if you know Python, I did a session on Dynamo and Python coding to take advantage of more efficient script layouts, and even tapping into Revit API with Python. So a session there, all on Autodesk University.

And if you like the Forge web tools environment with BIM 360, I got a talk for you as well on there. I got lots of talks for all sorts of things, so check it out there. So that's been my experience over the years and the kind of content I have. And there's tons of great things on Autodesk University outside what I've talked about. Everybody has some awesome resources on Dynamo, BIM team, and Autodesk has awesome resources, the community has a lot of awesome resources. But this gives a sense of what I've been up to for the last couple of years.

And a couple of key terms and concepts, it's not going to be an exhaustive review, just to get you warmed up for this talk. We have OOTB, out of the box. These are the features that come packaged with every Dynamo install that you can use within Revit. So if I want to say out of the box, OOTB, that just means built-in, default stuff in Dynamo, not extra.

DLL, dynamic-link library, files that use their programs to run code. And Dynamo uses these as standard for running and loading nodes, those little boxes that you connect wires to. So if I say DLL, that's all that is, it's just files. And list, a list is a sequence of values from a dataset.

So just to kind of get you warmed up, and again, you can learn more of these on the official learning resources at DynamoBIM.org. Highly recommend, I will keep repeating that URL as we talk because it's really awesome. Just to kind of get you warmed up on data types, again, it's going to be hard for you to solve problems without learning anything to do with data types.

There's text, which is strings. There's numbers, integers, Booleans, nulls, which is nothing, lists, again, a list of values, and the geometry itself. Be familiar with this. We're not going to spend much time explaining in huge detail what those are. But if you don't know how these work, it's going to be hard to solve some of these problems. And the better you are about the data types in Dynamo and how they work, and these are common data types in programming in general, the easier it will be to solve your problem. So I highly recommend that you guys check out data types, and learn these really fundamentally to really help you along the way.

OK, with that out of the way, here are The 10, the Birth of the Dynamo Blues. And to give you a preview, of something that we're getting into, we'll talk about these 10, Revit Software, Dynamo Software, custom package dependencies, DLL files unavailable, messy scripts, version control, or no version control for that, or your script is too big. Your input category is wrong. Your data types aren't converted, and fixing bigger problems with reboots. So that gives you a sense of what we're going to talk about today.

So starting with our favorite topic, number one, Revit. And Revit, of course, is what most people use Dynamo with these days. Of course, you can use Dynamo with Civil 3D, and FormIt, and all sorts of other plugins. And if you really are savvy about it, you can take the open-source environment Dynamo and make your own custom interface with any other application you dream.

But most of us interface with Revit when it comes to Dynamo, and in Revit, it's version locked per year release. And that goes for the same with Dynamo plugins and any plugin that works with Revit. It has to be designed for the release year. So you have to be careful with this, because over the years there's been some big changes in the Revit environment itself that will then affect any plugin like Dynamo.

So if you ever feel like things aren't working, the Revit versions aren't working with Dynamo, well, probably because you didn't realize which Revit version you had installed. What works on Revit 2018 may not work in Revit 2022. For example, this is just a screenshot, a map of the Revit API categories.

There's a lot of stuff in Revit API. It's kind of scary how big it is. So be aware if things change in the actual Revit API, the application programming interface, which is kind of like the way Revit actually works beneath the UI. That means anything like a Dynamo that tries to interact with that API will also change. So if you have a script that works for Revit 2019 fluidly, it may not work with Revit 2022.

For example, in this case, we see on the left here, Revit 2018, and four categories, and Revit 2019, four categories. See how the Select Walls in the categories are a little different? Well, the API changes over the years, change the way things like Dynamo interact with Revit, because Revit changes its categories, it changes the way it defines those categories, and what those categories are called, therefore, Dynamo will change. And if you use something like this, Dynamo won't be able to interact the way you want it to with your script versions, so the nodes will behave differently from one version to another.

And if you're not aware of this, this is how a lot of software works, these breaking changes, is what they call it, where big updates happen, and the way things you build on top of those programs behave differently. So you have to be careful about that. And the way you figure that out is keeping up with the API changes.

So here's the solution is to read the documentation. Again, if you're doing a lot of scripts for things like Revit or any other software that works with Dynamo, be aware of the API changes. These are published.

For example, this is the Revit API documentation. It tells you what the parameter changes were changed. You can see the classes at the bottom there, what they did. This gives you an idea of what changed, and maybe you have to go back and fix some of the nodes you're aware of that has these changes, or at least be aware that these happen. So if you do run into an error with your nodes in Dynamo, you can reference the actual core changes.

Why did I bring this up on Revit in the first place? Well, you can save a lot of struggle if you know that the actual core software you're interacting with is just different. No matter how much you modify your Dynamo script, it doesn't matter because this baseline here is different.

There's a great pro tip here I've got for you is to look at The Building Coder blog. He has a lot of great information about what changes in the Revit API environment and being able to track that. So do your best and keep track of those changes, whether they're annual release updates or service pack updates.

Cannot emphasize this enough. We're starting from some very basics here to avoid the wasting your time on things that won't really change if you don't know the basics, which takes us to our next basics. Number two, Dynamo for Revit. Because Dynamo itself, it's software, and for Revit itself, it's a type of plugin. So the problem you have here is you didn't upgrade Dynamo.

Your scripts won't work if you don't upgrade them. Here we have an example. Some of you might run into this before when you open up Dynamo. You select Dynamo in Revit and it asks you which version, 1x or 2x?

At this point, you should probably uninstall 1x, unless you're working with a really old version of Revit for some reason. I just have 2x. Because just like we talked about, Revit as a software changes, and its API changes, and things that-- the inner workings change. Dynamo does the same thing in its own type of software.

There was a big shift from 1x to 2x that basically breaks all the nodes, or I should rephrase that and say, the nodes from 1x do not work on 2x, and vice versa. So if you haven't already migrated or are aware of this migration, move on to 2x. Because I believe, if I'm not mistaken, I think 2018 or 2019 is the last version 2x works on. And you should be on newer versions of Revit than that.

And these are examples that changed in Dynamo 2x, where the basis for all the scripting and XML became JSON. As you can see in this handy-dandy graphic from the Dynamo BIM release on 2x, that's what it looks like, very different. Those are two different file formats. That's a breaking change.

That's why if you try to open up an old script from Dynamo into another Dynamo session years apart, guess what? This might happen because that's what it looks like. That's what the files look like inside those scripts. So be aware that you have to always keep Dynamo tracked and updated as well on top of Revit.

Check your file history. You can easily check out the version of Dynamo and see if it's 2, or 1x, 2x, 2.3, 2-point whatever. Dynamo always changes. There's regular releases of it, big releases of it. The Dynamo BIM blog has a lot of great updates. There are awesome articles about what changes. They just released 2.15. Pretty sweet, huh?

So always be aware of what changes. They have some huge changes sometimes. Don't get lazy. Pay attention so that you don't end up, again, going in there, pulling your hair out wondering, why won't my script work? Did Revit change? Did Dynamo change?

Leading up to next thing that more people have run into, number three, Package for Dynamo for Revit. So we talked about Revit. We talked about Dynamo. What about the packages? And the problem here is you have package problems. You run a script and things don't work.

And if you already have figured out your software environment, you're good about all that, the script might not work because you don't have special nodes from a specific package. And if you don't have these packages installed, then your computer won't run those scripts because it's not installed. Just like we talked about making sure your software is updated, you have to make sure the specific packages are updated.

And packages are basically the files that you can install for Dynamo that are custom made outside of the general Dynamo installation. So Dynamo, when you install it, or comes with your package of Revit, has a bunch of nodes always in there out of the box, just always there. And they'll change them from time to time, tweak them a little bit, but pretty much the same nodes, geometry nodes, list nodes, what have you, Revit nodes.

But as you guys might have seen, there's lots of great custom third-party packages that you have to install separately. They do not come with Dynamo. And if you get an awesome script that looks like it solves all your problems miraculously, great. But you have to make sure it comes with the right third-party packages that you also have to install.

And the way you can figure that out is this awesome handy-dandy unresolved question mark that just tells you the DLL file or whatever is out there. Not very helpful right away, but at least you know it's not there. And if you have a lot of packages, third-party packages not installed, and you run the script, you get these yellow boxes. That's a type of warning.

Warning means, hey, this looks kind of funny. An error means this is not working whatsoever. Warning means, maybe you should take this and look at this. That's the difference. Warning is like, I think the computer is trying to do its best to interpret if it's a bad thing or not. And if it's just kind of funny, not sure, take a look at it, warning.

Error means we can't even work on this. This is bad. It's broken. That's what warning and error means. So if you see this yellow one, that means, hey, I think something's wrong here. We need to resolve this. Here's my best guess Dynamo is trying to give you to tell you what to do.

And in that case, you can see if this Family.GetNested exists by just typing it into the search in Dynamo and see if it exists whatsoever. If it doesn't exist, guess what? It's a third-party package you have to install. And if you don't know what it's called, the third-party package, and you have this name, you have to search it online, find out on Google where this came from, and do your best to find it. Maybe email a friend who worked on this before.

It sucks. It's called dependency hell, where one thing is dependent on another, dependent on another, and you find out about this unresolved stuff. Again, if it's out of the box and you're using the correct Dynamo version, it shouldn't happen. But if it's a third-party package, this happens frequently.

And just an example, here is Bimorph Nodes, just one of many third-party packages. Bimorph has a lot of great stuff in it. And here's just a list of the custom nodes they have. So if you have to use Bimorph, you have to install Bimorph to use any of these. And should you have these in your script already saved in that script and you open it up and Bimorph is not installed, you can't use any of these.

So either you have to know what these are called per Bimorph, or just take some time to learn it. So it's kind of a hard thing to figure out right away if you're not familiar with these packages, and what they're called, and where they come from. So my solution here is use the vanilla, out-of-the-box Dynamo whenever possible. That's what it looks like on that library panel, Dictionary, Geometry, Math, Revit, Script.

These are the things Dynamo always comes with. Usually when you're crafting a script, you're going to default use a lot of these anyway. So try to do your best to use as many out-of-the-box scripts as possible.

This is especially true when you're experimenting. I try to find a solution to a problem, maybe not sure where to start, when to end, start here. Make it easy on yourself and don't use too many third-party packages until you get to a more advanced level with the script. And when you do want to use a third-party script and the out-of-the-box nodes don't work as well as you want them to, or they don't solve the problem the way you want to, or it's a little more convoluted to use the scripts or the notes in the default environment, write them down.

Share for people. Sharing is caring. Write down, with Revit or Dynamo notes, what you used. Simple note, as you see on the screen here, that whether the parameter is for grids, or you need a third-party package, please write down in your notes. I'm screaming here, as you can see the text, write down notes so people know, oh, get this third-party package, or, oh, this input's for this purpose.

I cannot emphasize this enough. Dynamo itself these days already has a lot of great documentation properties on the side panels, but also write down nodes and make it as obvious as possible so you don't waste time trying to reverse search it on Google what they Get.Nested parameter is referring to or, which node that is. It saves a lot of time and headaches, especially for myself, where I might have made a script a year ago, forgot about it, opened it up, and I forgot what I installed and my computer is different. So make sure you write these notes down. It saves you a lot of time and hassle, I cannot emphasize that enough, for any part of the script whatsoever.

And also, try to get as much done as possible. [INAUDIBLE] nodes that just default install out of the box for anybody using it to avoid, installing too many things. Because that too requires tracking. Third-party package managers, too, have updates all the time, and they too might have breaking changes. So always install everything as frequent as you can to make sure the versions are up to date and in good order.

Next, what's in your computer? What I'm talking about here is your problem is your DLL files are in the wrong place. This is more package problems that could effect both third-party packages and your own just vanilla packages, or I should say nodes in Dynamo. It looks like, no matter what you did, you took my first three steps advice and it still doesn't work. And it says here, cannot be resolved.

And it could be possible that those DLL files, all these packages, nodes, and the null nodes they're referring to are just in the wrong place. This happens, especially if your configurations might not be reviewed lately. So the cause, for example, here is, if you go into Package Manager, or Preferences, Package Manager, Library Search Path, you can see where all your packages are pointing to.

And you can see here, they could be in roaming. They could be in different folders. You can actually put them in just about any folder on your computer. So it could be possible that the file paths that are pointing to either your vanilla, out-of-the-box Dynamo nodes, or your third-party packages are just in the wrong place.

So always figure out you're pathing to the correct area. Otherwise, you'll end up with these unresolved issues of DLL nodes. Again, DLL means just the files that the packages and nodes are made out of. That's what those nodes are made out of, DLL files. They could be in the wrong place.

No matter what you do to fix them and install them, if the download folder or the repository you see here in the search paths are in the wrong place, or are not pointing to the correct place, yeah, not going to work. Everything will be unresolved. So be mindful of that, especially if you're trying to do this consistently across company and you're trying to point the same folder for the same set of packages for dozens of users.

And be mindful that this will change. These paths would be for each version of Revit and different versions of Dynamo. So you can have Revit 2021, 2022, 2023, each point to a different path, and each one of those point to a different version of Dynamo if you installed different versions. This can get annoying, so try to do your best to avoid mixing that up.

So a couple of quick solutions. Modify it yourself, like I mentioned, is option one. Just figure out if your path is pointing to the right direction. That's an easy solve. First of all, if you know where the paths are, do your research, figure out which folders those actual DLL files for your third-party [INAUDIBLE] those nodes are.

You can also, if you just give up, and quit, uninstall Dynamo, and reinstall it, that can solve a lot of problems if you're just having a hard time. Or change the path to a whole different directory altogether. You can change them and just put them in a folder where you know where all the folder contents should be. That's a little more advanced, but it's possible to just path it to a different directory altogether that you don't have to too hard about it. You know where it is.

And also, check the option of RoboCopy. Again, this is more of a advanced deployment company wide, where you could take somebody's set of embedded third-party packages and nodes that you want to use for everybody in your company, or just yourself for that matter. Use the RoboCopy option to then copy them from a dedicated embedded resource folder into the same exact directory for everybody using the same files.

This is great if you're trying to use the same Dynamo environment for multiple people. There's a link to that, how that works in RoboCopy. Again, refer to my talk on deploying Dynamo for your company that I linked up earlier about how these things work to help make sure you have a consistent environment. But do be aware that even if you're in good order with the versions of everything, Revit, Dynamo package, you name it, the folders could get changed, mixed up, sometimes with mistakes, sometimes due to some update. That's totally possible.

OK. Let's say you figured out all your software issues. So how do we then take care of our scripts and staying in good order, number 5? And your problem you have here is a messy graph.

This could be a functional graph but it's a disaster. It's easy to forget what happens when, what's connecting to what? It's hard to read. You might have spent many hours making this work and you're not sure what actually does important work, versus what are dead ends? We've all done this.

We're all guilty of this, making messy graphs that are hard to read. And that's a problem in and of itself because they're so disorganized and hard to follow, it's hard to fix it. And you might be just left starting over, and you're just kind of wasting your time.

And if you try to troubleshoot these, this could be an obstacle all on it own because you have to reverse engineer what you did to even troubleshoot them. And sometimes we have a lot of useful, important scripts and graphs like this, and we've all seen that. And it's not very helpful.

It's one thing if you're trying to discover a process, start from scratch, and just see what you can solve and just real quickly work. We've all been there. But if you find a solution that you like so much, don't leave it like this. Don't do that to yourself, don't do that to your friends. Think about your family.

Think about all the people you care about and clean up a little bit. And again, make it so it's future proof, that if you ever have to open it up again, you put those notes in there. You know which packages you're using. You know what you're trying to achieve, data types are organized. So the cause of all this is your beta version or file version. You have an if it works, it works mentality. Why should I care? And you have those standards. You have to have some standards for yourself.

So my recommendation for a solution is use a template file with standardized layout. Make sure you can group your nodes, label your nodes, and have some useful ways of figuring out what does what. There's packages for this. Dynamo has been a lot better over the years about being able to categorize and study, and being able to list and label what's inside your graph environment, so take advantage of these things.

Have a simple system. This is a simple system saying, OK, here's what review looks like in a graph. It will be this color. Here's what inputs look like, which is a violet color. Here's what sets and outputs look like. So everything that does a certain function has a certain color, and if it's a work in progress, it's gray, meaning, hey, this is still experimental.

It's a simple thing to grab a bunch of nodes and color them based on templates, just like in this example. Somebody had a template here, grouped them together. Easy to read, lots of notes, standardized. It doesn't take you very long to figure out what's happening here. Not a lot of confusion. Much faster to review, then it's much faster to hand this off to somebody else and say, take a look at this. It's all there. If you have any questions, let me know.

But do read this, so much easier. And again, if you're trying to use Dynamo in a way that's consistent and helpful to your operations, this is what you got to do to make it work. And what's really great about this is, with Dynamo, when you open it up, you can actually open up a default node script, or I should say graph script, that has all these baked into it. So instead of starting with a blank environment in Dynamo, which is the default situation, you just open up a saved template file with everything we just showed you.

You can have that as your default file from a default folder, and just open it up and start working with that so you don't have to put that in every time. It's going to save you a lot of time, standardization, notes. And if you give it off to somebody else to work with, they get the sense that there's a structure to follow and they're not just going to create a spaghetti chart of a graph.

So take care of your resources and assets. There's no point spending hours trying to find a solution that's very valuable. In an environment like Dynamo, we'll try some exploration and testing, and then just forget how it works 3 minutes later. Spend 5 minutes cleaning it up. It's not going to kill you.

So number 6. Let's say, for example, you took care of all these great things, organized it, make notes. How do you keep track of changes? That's another blues, how do we know we're using the right file in the right way?

Well, problem is you might have an out-of-date graph. Your graph is the wrong one, your file is the wrong one. You don't know what's the actual most recent version of the file. You didn't know, where did it go? Which folder is it in? Whose computer has the right version? Is it on a server? I think we've all asked these questions before. Did I leave it in an email somewhere?

So this is the point where you start really making sure we managed the resources we have correctly to avoid running into a problem of having an old, out-of-date file. And the cause of this problem is you have no version control. And if you don't know about version control, it's a simple breakdown. It's just a way of tracking changes over time.

If you use Microsoft SharePoint, they have version control. Most cloud file-sharing services have version control telling you, on this date, at this hour, this person modified this file. And it gives you a log of all the changes.

Well, in computer programming, they have this thing called version control and it's called Git, G-I-T. And the quick breakdown is there's a main file called main, and that is the file everybody should ever refer to as the key file, the one we should all use. And anything that is being modified separately from the main, like a copy, that's called a branch.

And if you want to take that branch, that copy of the file and bring it back to the main, you merge it to main and commit all the changes to it. This is very, very common in computer programming. And that's how they keep track of potentially having 100 people work on a code base. And then, having 100 different versions of the file, that would be a disaster.

They just say, OK, we're going to have the main be the production, finished control version, and everything else feeding into that. And this graph shows you how that works. If you want to learn more, look up Git, G-I-T, or GitHub, G-I-T-H-U-B. Because GitHub is an awesome system, and Dynamo itself has a GitHub.

So if you actually open up Dynamo in Revit or any other the software, you see in the bottom right there is this GitHub repository. And you can see and open it up, click on it. It'll take you to a hyperlink and show you Dynamo's GitHub, which is where Dynamo lives. And yes, you could copy this and make your own Dynamo because it's open source.

So the point I'm making here is Dynamo uses version control to manage their own files so that when they release it to you, you have the correct version of Dynamo and they have their house in order. So it's already part and parcel of the Dynamo environment. You can see how they organize their space.

So I highly recommend researching the Git system, GitHub. GitHub is free. And what's really, really cool, I bring this up for a reason, is there's a thing called DynaHub which you can use to manage your scripts through GitHub with Dynamo. And it's a package you can install, and it runs as a utility in your Dynamo environment. How cool is that?

There's an entire Autodesk University class that I have linked here. Dynamo GitHub Adopting New Innovative Repository. I highly recommend you guys check that out. You can do it yourself through other means, but this is probably one of the best ways for specifically visual scripting, which is a little different from text scripting, as you get in most programming.

This will save you a ton of headaches. What it does, it connects your scripts to a GitHub repository so that when you save something, it goes to online GitHub. So if anybody else wants to get the latest version of the script, the main, they know where to get it from. All they have to do is make sure they have this installed and they can grab it from there. Or you can just share the link to the GitHub. It's its own website.

This will be very helpful if you have to share files over time, avoid having too many copies around. I tell people-- what works here is tell them, if it is not on the GitHub, if it's not on some kind of version control system, it doesn't count. This is a great way to manage things and make sure you have the latest version in the right place with logs of changes so you know where it is.

And again, no excuses. There's a utility for it, free. Everything's free, and this is a great way to control what changes over time. I highly recommend you guys check this out to avoid the disaster of looking for an old script that you cannot find. This solves a lot of those problems.

So let's say you are master of version control and you organize your graphs and they're beautiful, and you installed everything correctly. But you might be thinking sometimes, why is it taking so long to run the script? You feel like you did everything right. You organized your script, but why is it taking so long to run?

It's probably not a coincidence. Sometimes you have a problem of a script taking way too long to work, maybe 30 minutes. I've been there, where I run a script, it looks pretty straightforward, but it just takes forever. And I thought my computer needs to crash, and I just said, you know what? I'm going to take a lunch break, come back, and it finally finishes a while later. But you might be in these shoes where you're wondering, what is happening here?

Well, the cause is a couple of things. It's usually because your script is monolith. Maybe there's too many things packaged in one environment, like you see here. Now this script you're seeing here on the right is just an example, but I would say it's not necessarily hard to follow. Everything's grouped properly, like we talked about in your standards. Not hard to see where everything's flowing to. It's a bit dense there with the lines, but reasonably well thought out, right?

But it's just too long and complex for what it does as a script. There might be way too many steps. Your Revit file itself might be very, very big and it takes time to process. Remember, this is kind of a series of steps here, where you're writing this script. It then compiles and runs in Dynamo, and then Dynamo talks to Revit, and Revit talks to your CP or your Windows, which then talks to your CPU to get these things done to operate all these steps, multiple layers.

And if you have a big Revit file, this could take forever. Thousands of objects to go through, thousands of categories, thousands of things, so be mindful that maybe you're asking your computer to do a lot of work. If this is all purely text programming in a traditional computer-science environment of running through some iterations, it could take seconds. But because we have so many layers to run through, so many different software layers, this could take a long time, so be mindful of that.

And also, your computer might not be fast enough. Your processor might be a little slow, especially a laptop is going to be less powered, so it could be your hardware. So looking anywhere from the way your script is organized, to the software environment of a big Revit model, to the computer hardware, there's a lot of reasons this could be slow. So be mindful, it could be multiple things because it's all the eggs-in-one-basket solution.

Break up your script. Break up your script in smaller parts to run in different chunks so that if you can finish up one big process, stop. And then, run the next one, stop. As long as you can compile it so you get an end result that runs through Dynamo into, say, Revit, and then, you finish something, then you open up the next script and run that, you can get a lot of work done faster that way because it's just fewer things processing all at once.

And this is a good way for you to take a big, long complex script, apply all those standards we talked about, make sure everything's nice and organize, refactor it, meaning making your script and code more efficient, and reduce the complexity. It's also a great way to make your script run more efficiently, and potentially isolate a breaking problem where you may run to a warning or error depending on the model you're working with. So instead of breaking the entire script and having to sort out 500 nodes and figure out what happened where, it might be 10, 20, whatever nodes you have in a smaller script that's easy to sort through a problem, that if you have multiple different scripts to run through, maybe only one of those files has a problem and everything else is running smoothly.

So you don't have to make zero progress. You might be able to make a lot of progress through each version of that script. And maybe you have a series of sequence of two, or three, or five scripts, only one of them has a problem but you don't break the entire chain of editing you're doing with one or two errors in one big chart. And you can then marginalize these scripts, like this diagram here is a good example of that.

Did you know you could take a script itself, a full-on script that works, and make it into a node, and then put it into another script? So that's a great way to make something packaged more efficient. And you'll discover that by breaking up your scripts into smaller chunks, and finding what is working very quickly that can become its own little node, and what should probably be separate on its own file. So if it ends up being a little more breakable, a little more complicated, a little more editable, it needs to be separate.

So think about just refactoring, breaking it up, being able to isolate them so that it's easy to run through a big, complex script on big, complex models. Dynamo is really great and awesome software, but given the number of different steps it has to go through to actually get anything done and process, breaking it up is very, very helpful and manageable. I promise, it's not as bad as you think it is.

OK. So all that management, we get to, finally, inputs and outputs. This is really important for just day-to-day work, no matter how big your script is. The problem is, your data types and inputs are not working. Sometimes your nodes just won't run properly because your source inputs don't work. And that usually means your inputs are incorrect.

And as you see here, inputs can be a simple thing. You'll see here a number at the top there is just a number, and the watch node says, cool, I have a number. That works. And you can put in a bunch of numbers together for an X,Y,Z coordinate system. That works. So as long as your inputs work, everything else works. But if that's the first thing that doesn't work, it doesn't matter how well managed the rest of your script is, everything will break.

Now we're getting into a little more nitty gritty. And the cause is usually the data types are not defined. Like we mentioned earlier in this talk, the dropdown options may not be stable. For example, here we have Category Window, and we can get all the categories of that window element out. Maybe all the things in, say, your Revit model that's a window, they'll say, OK, here's every single object in Revit. If there's hundreds of them, that's a window.

That's a list, right? So this is a common issue. This is a good example, where sometimes the category of a dropdown menu is wrong. You might think you set it to a correct category or you took it for granted as a correct category, but you may need walls instead of windows. And even if the rest of your script is beautifully organized and efficient, if that input is wrong, if you don't have the right input, nothing else is going to work.

So the solution here is just to hardcode the category into your script. At the top here, we have that same situation with walls to All Elements of Category, where it's selected, but that might only save for your computer. It might remember that for your computer session in the memory, but it may not work for a different computer or a different user depending on the environment.

So in the bottom here, the category will not change. If I use a code block and spell it out with a string, walls, and use something like category.ByName node as a bridge, then give me exactly walls. That will never change, again, assuming Dynamo's API doesn't change, assuming Revit doesn't change. We have to make some assumptions here that it shouldn't change, but that's how we make sure, if we only ever want walls, it should never become anything else for a certain type of script, or any other kind of category, hardcoding.

There's lots of opportunities like this in your own scripts and environments to make sure you're hardcoding things so you never have to go in there and check yourself. And this is something to be mindful of if you have people who want to use these scripts to do some kind of useful work that aren't really savvy at Dynamo. They can open the script that you give them and run it, but they may not be able to figure out what's wrong.