This blog is Part 2/3 of a three part blog series covering the Dynamo Core 2.13 release: Please read Part 1/3 first. 

TL:DR

• Visually reimagined and refreshed Dynamo experience, introducing a modernized user experience, fresh color scheme, tonnes more information at your fingertips and clarity towards both paradigm and approach to how Dynamo works; nodes, wires, authoring behavior and the UI experience have all been jazzed up [Part 1/3].
• Implementation of two Dynamo Interactive Guides for First Time Use Experience and Packages, with more to come[Part 2/3].
• A refreshed Package authoring and download experience [Part 2/3].
• An expansion to the Workspace References extension to include local definitions and external files [Part 2/3].
• We now have a richer way to handle installed packages via states and resolve conflicts [Part 2/3].
• New Unit nodes [Part 3/3].
• More seamless Python 3 Autocomplete [Part 3/3].
• Performance improvements to Search, the scaling of graphs and the Virtual Machine improve Dynamo use [Part 3/3].
• A swathe of security updates [Part 3/3].
• A new node that groups curves together [Part 3/3].
• 35 bug fixes, with a particular focus on Crashes to improve stability of the overall Dynamo experience [Part 3/3].

Phew… a monster list! As usual, there is a whole bunch more so please do check out the release notes!

 

So, what other cool stuff can I do with Dynamo 2.13?

A modernized Package Experience

We have modernized both the Package Consumption, and the Package Authoring experiences, bringing their aesthetics up to our new standard and adding more clarity and information into both. We have also added in more granular control to the Package Management features, allowing you to control what loads, when and from where with much more regulation than before. #AllTheBellsAndWhistles

Package Consumption

Downloading a package is now a quick-hit experience, surfacing at your fingertips all salient information, with a new extension that brings deeper package information, and authoring a dynamo package is visually restyled, has more information around the optional fields, and automatically now attributes license and author data.

Let’s orient ourselves with the newly restyled and reimagined package use experience:

• [ 1 ] Pop-up dialog boxes for Download Confirmation and Dependency notification have been restyled. Blue color denotes information, while yellow denotes warning.
• [ 2 ] High level package information showing any host dependencies this package may have. In this case, nodes inside this package require Revit to be ran.
• [ 3 ] High level package information showing the package name.
• [ 4 ] High level package information showing the package author's username.
• [ 5 ] Restyled download banner experience shows download indicator when downloading, and informs user what package and version were installed.
• [ 6 ] Installed packages show greyed out with a tick, while packages able to be installed still show up highlighted in green with a plus icon.
• [ 7 ] Filter by and Sort by icons set next to Search bar; Filter by allows you to filter by host dependency, and Sort by enables you to sort by votes, download count etc., in ascending or descending order.
• [ 8 ] High level package data points shows the Publish date, Vote count, Download count and Date last updated.
• [ 9 ] Clicking on the View Details button takes you to a new Package Details extension.
• [ 10 ] High level package information shown at the top of the Package Details extension to orient users.
• [ 11 ] Description field. Information here is at the discretion of the Package Author.
• [ 12 ] Licence field will take any stipulated license, or default to MIT should one not be filled in by the Package Author.
• [ 13 ] Version and Package Requirements table contains all information of previous releases, and enables you to understand if they have any host dependencies, python requirements or depend upon another package. If this package depends upon another, you can click through to that package from here.
• [ 14 ] Install any previous versions of the package.

 

Package Authoring

Creating a package is now a more comprehensive experience, enabling all the good things that it did before and a few new things. Beyond a funky restyle of the entire experience, that brings you more clarity, cleaner ways to interact and a more modern theme, you can now also add a directory of contents rather than only being able to manually add files and add accompanying markdown documentation for nodes inside your package. All the existing license fields now properly attribute defaults into the pkg.json file (The manifest file that ships with your package #ChecksAndBalances), giving you and your package legal weight. Please note that Packages can still only be published from a host environment that contains authentication, such as Revit or Civil 3D.

So, let’s explore the modernized package creation experience:

• [ 1 ] All existing fields have been restyled and modernized, ensuring that they are clear, articulate, cohesive and discoverable. If you are unsure what any of these fields do, be sure to check out the Publishing a Package chapter in the Dynamo Primer.
• [ 2 ] The existing More button has been changed into an expander to match the new modern style of Dynamo, better showing its intent and purpose.
• [ 3 ] The Add Directory button will prompt you to select a directory and pull in all directory contents into the Package Contents field, enabling swifter package creation than before. Waaahooo!
• [ 4 ] The Reset button resets the Markdown Files Directory field back to blank, stopping markdown documentation getting bundled into your package.
• [ 5 ] Hover help text information buttons have been provided for in-context clarity around what the markdown files do.
• [ 6 ] You can now add documentation to your package that surfaces on a per-node basis via the package creation user interface. You can read all about what this is, and how to do it in our Create and Add Custom Documentation to Nodes wiki entry.
• [ 7 ] The existing Licence field now has more detailed information, stating that the MIT license will be default should the package creator not specify one. If no other licence is specified, the MIT licence will be automatically entered into the pkg.json manifest file under the licence key.
• [ 8 ] The existing Copyright Holder field now has more detailed information, stating that if left blank, the author’s username will be used. If no other name is specified, the author's username will be automatically entered into the pkg.json manifest file under the copyright holder key.
• [ 9 ] The existing Copyright Year field now has more detailed information, stating that if left blank, the publishing year will be used. If no other year is specified, the year at point of publish will be automatically entered into the pkg.json manifest file under the copyright year key.

 

Package Management

We have also expanded your ability to manage your packages, enabling more granular control of what is loaded, and when, and introducing package states that paint a clearer picture of what that package is up to via the Preferences Panel.

Uninstall in Dynamo is complex. Package assemblies: files whose contents must be interpreted by a program, in our case Dynamo, can only be unloaded or deleted from your computer when Dynamo and any host (If Dynamo is in-process, such as Revit or Civil 3d) is closed, releasing them from memory. Until that point, they are “in use” inside of the Dynamo memory space… and Dynamo doesn’t want to let go. So we introduced package states that indicate what each particular package is up to, and hover help text indicates what those states mean, enabling you to have more granular control over your Dynamo experience. A particular package causing you trouble? Then simply unload it for your next session. Can’t see why nodes are not showing up in the Library? Then your package may be in an Error state.

Dynamo will now help you resolve package conflicts, alerting you if there are conflicts loading packages from different locations: i.e. you have two different versions of the MeshToolkit package loading, one from a custom path and one from the default package location, and give you the option to install top level package even though it’s dependencies are the wrong version; while previously possible, technically, this was really hard to discover and users were most often blocked, so we also improved our messaging around this. Please note that this doesn’t guarantee a package will work, as Dynamo still needs correct dependencies to run a package.

We also enabled toggles to en-masse disable loading of Built-In or Custom packages, enabling you to swiftly debug problematic packages, or turn off entire ways in which Dynamo will load them. Disabling the Custom Packages toggle will stop you from being able to download packages from the Package Manager, greying out the install button and providing a warning message how to resolve. This is a less heavy-handed way of managing packages, where in the past you would have had to get creative with Package Search Paths, or literally move your packages into a new location temporarily.

Let’s jump into the additional package management features:

• [ 1 ] The Add Path button was restyled and shifted into a cleaner alignment. All primary actions are now left aligned.
• [ 2 ] The Disable loading Built-In Packages toggle will stop Dynamo from loading any Built-In package on restart. If you change this toggle inside of an active session, any package unloading will take effect upon Dynamo restart, and any package loading will take effect when the Preferences Panel is closed.
• [ 3 ] The Disable loading Custom Packages toggle will stop Dynamo from loading any Custom package on restart. If you change this toggle inside of an active session, any package unloading will take effect upon Dynamo restart, and any package loading will take effect when the Preferences Panel is closed.
• [ 4 ] Hover help text information buttons have been provided for in-context clarity around what these toggles do.
• [ 5 ] Package state tags show all currently active states in your Dynamo session, and are selectable to filter the list of packages to match that tag, with a default selection of All.
• [ 6 ] An Error state indicates that a Package failed to load, and gives you an error string as to why. In practise, this could mean you are trying to load a package that depends on another host program: i.e. Revit or Civil 3d, and are unable to as you are outside that host context.
• [ 7 ] The Scheduled for Delete state indicates occurs when you choose to delete a package, but Dynamo still has it loaded. So you need to close Dynamo for that package to be released and then subsequently deleted.
• [ 8 ] A Loaded state indicates that a package has successfully loaded, and can be used like normal with your Dynamo session! #HappyDays.
• [ 9 ] The Scheduled for Unload state indicates that this package is still usable in the current Dynamo session, but will be unloaded after the next Dynamo restart (Note: Unloading means this package won’t be deleted, but simply won’t be loaded next time you open up Dynamo). You will need to enable loading of this package to have it surface inside the package list again.

 

Introducing Interactive Guides

We are incredibly excited to introduce Interactive Guides, a new approach to allowing you to explore aspects of Dynamo, interactively, and contextually inside the application. Knowledge is power and all that!

We have two interactive guides to date, the Get Started guide; a succinct exploration of the Dynamo user interface and its components, and the Packages guide; A walkthrough of what Packages are and how to get them, walking you through step by step on how to install your first package. Note: Please have your Library open for this guide if you tend to close it as we have a known issue that prevents us from automatically opening it up for you. Working on it!

These are the first two interactive guides we have implemented in product, with the intention to deliver more and cover all salient aspects of the Dynamo experience to empower you, our awesome user base, with all the knowledge you need to succeed. The guides are short by design, targeting ten or less dialogs to orient you, while providing links out to external resources for deeper reading, such as the Dynamo Primer.

Let’s explore their general make-up together:

• [ 1 ] The Interactive Guides are accessible under the Interactive Guides sub-menu under Help.
• [ 2 ] Two guides are available at the time of writing this blog post; the Get Started and Packages guides.
• [ 3 ] Every guide will feature contextual dialog boxes, that point towards the topic in question, allowing you to see the feature of Dynamo with the guide content context.
• [ 4 ] Each contextual dialog box will have a body of text that is succinct, short and to the point.
• [ 5 ] Every guide has dialog boxes that appear contextually, oriented via chevron arrows.
• [ 6 ] If you exit a guide, you will see a notification dialog pop-up which explains that you can return back to this guide later via the Help menu.
• [ 7 ] Every guide will create a darkened overlay across all non-relevant Dynamo interface elements to draw your eye to what is important.
• [ 8 ] Each guide will have a page number carousel at the bottom, enabling you to go back and forth at will and showcasing what stage of the guide you are in.
• [ 9 ] Links out to external information are embedded in dialog content where relevant.

Expanding the information in Workspace References

 

On the back of the hugely popular first phase of the Workspace References extension, we have also beefed up what it can do by expanding the functionality of the Workspace References extension to include local definitions and external files. Not only do you get to see what Packages are missing from your workspace, but you can now see all other references that are required to run your graph. The second phase of the Workspace References extension is informational, showing to you what other things need to ship with your graph to have it work the same way you have it working, be in Revit content, images, Excel workbooks or local definitions.

Local Definitions captures any dynamo specific files that are local to your machine; think local Custom Nodes or local Packages, and External Files are external documents, not Dynamo specific files, that are referenced inside your graph space: Such as text files, images or Excel documents.

So let’s explore this extended functionality to see what’s fresh:

• [ 1 ] All sections now have hover help text associated with them, showing at a quick glance what each of these expander sections does.
• [ 2 ] The new Local Definitions expander section collects all dynamo specific content that is not a package installed via the Package Manager. It is computed when the graph is saved and does not serialize into the .DYN file, being informational only.
• [ 3 ] The new External Files expander section collects all external documents that are referenced into the Dynamo graph. It is computed when the graph is run, and does not serialize into the .DYN file, being informational only.
• [ 4 ] Certain file types have unique icons, such as Excel or Image files, and all other file types fall back upon the blank default icon. When in doubt, increase the size of your Name column to see the file type extension.
• [ 5 ] Both the Local Definitions and External Files sections come in a collapsable expander, enabling you more granular control of what you see. All three expander sections are able to be open at once.
• [ 6 ] Unlike the Version information captured in the Packages section, all information in the two new expander sections will show file size instead, giving you understanding of not only what to ship with this graph, but how big it will be also.

 

Other epic things in the Release…

This blog is Part 2/3 of a three part blog series covering the Dynamo Core 2.13 release, focused on Lowering the Barrier to Entry, putting Information at your Fingertips and Honing the Rough Edges. Read Part 1/3 here and Part 3/3 here!

 

Ok, more blogs are cool, but I want to explore Dynamo 2.13 now! 

Dynamo 2.13 will be made available in our host integrations at a future date and can be explored right now through the dynamobuilds.com website or the Github build page – available in the Sandbox version of Dynamo.

 

The Dynamo Team