I am currently attempting to create a shared parameter using Dynamo. However, based on the attached Dynamo file and the snapshot provided, the graph is returning a null value.
Hi @RaymSanz i dont know that node..but seems its expect a family document, we have a ootb for convert current document to family document, and in 25 its specgroups, and spectypes and not PG, there are ootb for that as well
Hi @sovitek , thank you, it is appreciated.
I tried as per your snapshot, but I still getting warnings as shown below and I have attached the dyn file too;
I made my tutorial back in 2019 using orchid i think, very old now. At the time erfajo hadnt added the condense system in so list combine worked nicely. I honestly never got orchid to really work as intended since then, which is what motivated me to make my own familydoc nodes.
At this point all i have left to add to effectively displace orchid is createsharedparameter and createtype. Addsharedparameter is in there if the author is in fact trying to add existing parameters vs create them add to the sp file.
åh ja, never tried that one, for shared family parameter i use yours;) or my own as goes in 2 step first add to txt file then create the parameter, thats how i like it…PS but my example was just for familyparameter as i dont have that node from orchid…
Hi @Gavin, thank you for your reply, much appreciated. Yes, this is based on your tutorials (and thanks again for all your videos, they’ve been incredibly helpful!). @sovitek At the moment, I’m having some trouble with this part and currently testing it in a blank Revit project to isolate the issue.
Yeah - doable with the API but dynamo uses here tend to break down over time due to lack of maintenance. Doubly so when you get into bulk efforts I guess I was thinking more about bulk efforts which these topics inevitably turn to.
As such I think it is better to manage using the UI as the two commands (load family, save as library) are right there and quite easy to perform in bulk.
The break downs due to maintenance happen on the add-in side too, but Dynamo solutions have proven particularly problematic. The root cause is that the APIs have changed pretty much every other release since 2020 (2020 forge type ID and spec type ID, 2022 group type ID, 2024 had FamilyManager.AddParameter changed, 2026 had… actually I think it is stable there), and that is before looking at the Dynamo, .NET, and Python changes. For internally developed tools and paid apps these get addressed by the developers pretty quickly (the tools I build for myself have to work in my environment; the paid solution has to work in the customer’s environment), but Dynamo solutions… it’s tough to force things at scale.
That said the Dynamo for Revit team could address this by providing nodes for such. A well placed PR on that repo might even push them to do so…
But for now, if you can use the built in features of Revit to get the same result, why not do so?
I guess to me it’s a hack of sorts, which i tend to avoid where the API offers pathways that are more intentional. I use them here and there but usually when the API has gaps, e.g. temporary ifc export to get linked elements in view.
I’ll see what I can do, but so far found only a few pain points RE API changes when it came to families. Mainly forgetypeids, the core methods themselves are generally the same from 2020-2026 currently.
I get that there are ‘alignment points’ in there and some API deprivations and additions don’t have to be made on any given release, but this certainly is one of the more troublesome aspects of the API in the last half decade. I also appreciate the effort to get a working for the community.