Hello to the entire community, like many others, I’m facing the fact that many of the scripts I developed are no longer compatible with Revit 2025, which is a serious operational issue.
I’m turning to the forum to learn about the tools currently available to address this issue.
I believe Python is no longer an option, and if so, what are the foundations for working in this new phase?
Design Script, any portal that shows, in an intermediate to advanced way, how Dynamo 3.0 to 3.3 works.
And all the resources that can be modified as a result of this new phase called Revit 2025.
Awaiting all your responses, thank you all in advance.
Don’t forget element IDs changing in 2024.
Also the Python changes were communicated as coming in 2021, so there was more heads up there than there was with forge type ID.
To me the biggest issue is people need to set aside time to maintain their graphs rather then just building new. Those who update year to year and take a systematic and methodical approach don’t have as much of a hard time as those who delay for over a year (2026 is out after all) or those who only deploy every other version.
Next big issue is firms not managing their Dynamo environments. Much like your families get updated year you year your custom nodes and packages should as well.
And the last big issue is everyone tests their work manually, sometimes even having to build a model first which replicates their intended starting condition. Instead we should be building the data set with the graph and using journal playback to keep testing as close to if not entirely automatic.
1 Like
Honestly having put it off for far too long, C# comfortably deals with all of these things. Python to a degree can bridge versions with various checks and logic branches.
As others mentioned forgetypeids were flagged for a while, but it wouldnt have been obvious unless you consulted with the apidocs or used a method that returns a warning about it i think.
The elementid changes can be dealt with in two methods in C# (id to int, int to it), forgetypeids vs parametergroups/types is a bit more work. In dynamo i would build scripts per version if i had to scale it.
Reference of dealing with elementids:
If dynamo is your platform of choice, developing zero touch nodes offer the most control in the lobg term.
All good points @GavinCrump.
However I would like to point out that Python CAN take advantage of the type of work which the C# libraries utilize, but it takes moving stuff into an IDE and decoupling the .py from the .dyn and thereby adding more complexity to the task of environment management (the .py now has to be deployed to all users, or you have to systematically build the .dyn and deploy that on each update).
1 Like
Yes, but python 3’s int treats all ints as long. So shouldn’t really be noticeable unless you are doing something odd.
1 Like
True. But that is a double edged sword as Python 3 should be used both before and after the element ID change, which means you’re either getting ints converted to longs and working in the post element ID change or getting an error in the pre-change builds around receiving long but needing int32.
The world has sadly been made far more complex then it ought to be…
1 Like
With some Python Built-in Types (int, str, ) there is a conversion/cast which is done automatically according to the type of the parameter of the .Net method or constructor.
2 Likes
