I’m updating some older scripts to the latest version of Dynamo and associated packages. (Revit 2024)
I have just run across a node that is highlighted by monocle as a custom node, but I can’t figure out from which package. The name is Titleblock Types. It’s a simple list of all Titleblock Types in the current model. It outputs a single titleblockType.
The Workspace References pane has an X beside Rhythm, so it makes me think it’s coming from (or came from) Rhythm, once upon a time. I’m not seeing it in Rhythm’s node list anymore though. It also doesn’t have the small rhythm logo before the node name like other Rhythm nodes.
Anyone know where this node comes from and how I may be able to get an updated version of it?
UPDATE:
It IS from Rhythm: RhythmUI.TagTypes
It used to be under the Rhythm.Revit.Selection.Selection category in version 2022.1.2. Looks like there used to be 16 nodes in this category, now only 3 (as of version 2023.9.1).
I am using the built-in Family Types node instead, but I’m curious if the Titleblock Types node was deprecated and if Family Types is the node to use in place of it.
I’m trying to google it, but not coming up with anything.
Do you see the node in the category? For me, the node seems to work, but only because I started with an older script. I can’t create a new instance of it in a new script though since it’s not listed in the package contents anymore.
This is all I see for the contents of that category under Rhythm:
@john_pierson can you shed any light on this for me?
I’m looking on the Rhythm github page, but the last and only release I see is 2022.6.1. So I can’t see release notes for when or why these nodes were removed. If they’re deprecated, is there an OOTB path I should take to replace them?
Not that you’re under any obligation to document any of this stuff with a free and open-source package like this. I appreciate your hard work on this.
@john_pierson Oh no. Is this the end of Dynamo as we know it?
From your post that you linked, it sounds like third party package maintenance is becoming more and more daunting, to say the least. I don’t even maintain any packages, but just managing the different versions of Revit, Dynamo, packages, and scripts is very cumbersome.
That’s what I’m going through now: realizing some of my scripts have stopped working properly as I have tried to keep using the same package and script versions through multiple Dynamo versions. Now I’m updating the packages and scripts for 2024, but that means fragmenting my script library based on Revit version being used. ACK!
It’s difficult enough for me, the one doing all the work and getting my head into it enough to know the whats-and-whys of the things that have to happen. Our typical users are going to have their minds blown having to switch the location of the scripts they use based on the Revit version they’re using.
A small nightmare to navigate.
You can configure the settings to direct them to the respective year by modifying the ‘recent files’ setting if I recall. But if you manage your package library the nodes should resolve to their respective year without too many issues - getting the right package version is the hard bit and many are fairly self managing (Rhythm is especially impressive in that respect). I don’t think this will change much in 2025. Mostly the changes in 2025 will package authors who’re managing externally compiled libraries (zero touch nodes, view extensions, etc.).
Sadly that pain was inevitable as keeping the host applications on .net 4 forever wasn’t feasible - many would say it was overdue (migrating this many desktop tools in unison takes a lot of coordination). I’m hopeful the development team and community can come together to get some guidance together. I know there is already work underway to get some automation into position to scan packages in bulk for some of the common issues which hopefully will prevent some of the pain points.
