Howdy folks!
Today is a super exciting day for Dynamo for Civil 3D. We just released the Civil 3D 2025.1 update, which has over 1,100+ new nodes! If you’ve been around for awhile, this is exactly what you’ve been waiting for 
New nodes, new sample graphs, a totally fresh Dynamo home experience, new icons, better node documentation, important bug fixes…and more on the way 
Get it now!
Wow! Great job! I really admire the effort that was put into this update. I have one question. How will the popular packages Civil3DToolkit and Camber work in this version?
Hi, Is there any help or note or tip and trick for the graph creator to know that he is using a unique node of version 2025.1? I need to differentiate between graphs I create for multiple versions and then only for version 2025.1.
GREAT JOB!!
@zachri.jensen If we find nodes that we miss such as “Paste Surface”, where should we adress this need or issue?
Generally speaking, third-party packages require maintenance over time to ensure proper functioning as the host product evolves. This is the responsibility of the package authors.
In the specific case of the Civil 3D Toolkit, it will require an update because there are naming clashes with the new nodes in the core product.
Putting on my non-Autodesk hat now…
I haven’t had time to test anything from Camber yet, but my expectation is that the nodes should continue to work.
cc: @solamour
The preferred route would be the Civil 3D Ideas board. But if you mention something here on the forum or on the Infrastructure Futures portal, I won’t ignore it 
Best bet for now would be to check the release notes for a list of new nodes, but that would be a bit extreme and likely not of much use in this case as there are so many.
My recommendation is to author in the oldest version you support and test in subsequent builds. John Pierson recommends the other direction where he starts in the newest and works his way backwards. In both cases generally the process is to author in one extreme and test all other versions you want to support. This is because it is not just ‘new’ or ‘deprecated’ nodes which you have to deal with, but also nodes with changed behavior (Curve.Offset) and changes in environment (.NET version, Python, Windows, add-in conflicts, etc.) and similar issues to deal with which are only exposed by tested your code.
As Jacob said, there isn’t anything logged into the .DYN file, nor is there a central “Node per version” repo (Albeit we’ve talked about it, and want it! Just #jugglingNineMillionThings)
Good point
I also added a comment to the forum about 2025 Alfa regarding a strange info message.
Will add suggestion about the ”paste surface” node.
Hi @zachri.jensen, great job as usual! The new nodes that you mention, to be able to define new block definitions specifically. Will they only be available in the 2025 version or will any of the new nodes make their way to 2024?
I’ve finally installed it yesterday and can’t wait to start using the new version, it looks great!
Thanks for all the effort!
One question:
Is it safe to say that all the functionality of the camber package has found its way into the new nodes or are there areas where camber exceeds the new OOTB-nodes?
Another questions, a bit unrelated and maybe I’ll start another dedicated thread but since all of you Autodesk-wizards are here:
Is there news about the state of CivilConnection? I’ve used it a few years ago when my Revit-skills were quite low but it’s a great tool and I’d love to incorperate it more now that I have a vague idea about what I’m doing in Revit.
The github hasn’t seen a lot of activity and there’s no release for 2024 and 2025. Do you know if there are plans for CivilConnection?
2025.1 only at this time.
Hi @SampaKadabra,
The new nodes and improvements mentioned here will only be available in Dynamo for Civil 3D 2025.1 and above. We do not plan to backport any new features.
Putting on my non-Autodesk hat here… 
No, there are still areas where Camber has more nodes than what is available OOTB. Some notable examples are styles, labels, data shortcuts, etc.
I do not know about plans for CivilConnection. Sorry 
I’m not much of a complainer by nature, but it is Friday afternoon, almost 30 degrees Celsius outside and I face several issues with Dynamo 3.2 and Civil 3D 2025.1 Dynamo… So let me throw a couple of complaints here.
Unfortunately users can’t make a choice which Dynamo version they want to run. If you install 2025.1 you get Dynamo 3.2. On the other hand, this way it is certain that users always use the latest version of Dynamo. But from a software development and continuity perspective, it is really bad to also change the API. Not only between 2024 to 2025 (which is at least a bit explainable), but it is extremely bad if it happens between 2025.0 and 2025.1!
What happened? Well, my package ‘Arkance Systems Node Library’, but also Camber and C3DToolkit, use dot NET Framework 4.8. For Civil 3D 2025 they actually should have been upgraded to run with dot NET 8. Happily these three packages also worked in Civil 3D 2025, regardless of the .NET version. That was great, so we didn’t have to feel any stress, or think about version numbering (would the package become an update or a new package because an updated version wouldn’t work in 2024 anymore).
But now with the 2025.1, functions in the API are suddenly deleted, and others are renamed! For example, the Autodesk.Civil.DynamoNodes.GridSurface does not exist anymore. And the Autodesk.AutoCAD.DynamoNodes.Document.Layers is named Autodesk.AutoCAD.DynamoNodes.Document.LayerNames now. Just two examples to make clear the issues I face here, because now my package, but also the C3DToolkit, won’t get loaded in Dynamo anymore.
I am pretty sure the 2025.1 update has killed more packages.
I can understand that there must be some improvements, and LayerNames is symantically better than Layers, if strings are returned. But it is a horror when such changes are done in a .1 update instead of a new year release.
Probably someone would think: “Hey, then you open your code, make some changes and there you go!” Would that be so easy…
Now I am forced to build a new package, and somehow restrict that to 2025.1 (but I can’t prevent that someone will install the package in an older Civil 3D). And how will scripts be backwards compatible? Maybe someone has a reason to work in 2024, or stick with 2025.0. They can’t exchange graphs anymore, and it is really hard to explain why that is, not every user is aware of the details of different versions.
So please. Don’t remove API functions, don’t rename them, and don’t change their signature in a Civil 3D .1 or .2 update! There are also other ways, like mark functions as depricated and add new ones next to them. There wasn’t much development in Dynamo for several years, couldn’t Autodesk have waited a while until Civil 3D 2026.0? Or is adding hundreds of nodes to the core at the same time a discouragement to support custom packages anymore?
Thanks for listening and sorry for the grumpy tone. After the weekend I will be fine, I promise…
Hey Anton,
Thanks for taking a look at the new update. I hear you, and I appreciate your passionate and detailed response. The situation is tough, and we had to make some hard calls that resulted in some breaking changes with this major release, but we strongly believe that this sets us up for a much stronger, more robust, and consistent future for Dynamo in Civil 3D.
As you noted, some nodes have been renamed. This was done to (a) improve organization of the node library to better align with users’ mental models and make it easier for beginners to find nodes, and (b) improve consistency by aligning with node naming conventions. We have included automatic migration for all renamed nodes so that graphs are backward compatible. However, the majority of nodes are Zero-Touch nodes, which as you know creates a tight coupling between the node’s business logic, visual representation, and appearance in the library. This has significant pros, but one of the cons of this coupling is the suspectibility to breaking changes when the node library is treated as an API. You can find a full list of the renamed nodes (20 total) in the release notes.
I hear you; it’s incredibly frustrating to not be able to choose a Dynamo version when you are in the know and can make informed decisions, but the alternative for the majority of Civil 3D Dynamo users is a harder path also. Both approaches of integrated fully vs. choice at the user level come with pros and cons.
Waking up to your package having breaking changes is painful - we get it. We feel your pain as we internally hit this all the time - and truly try to mitigate this kind of pain as much as we possibly can within the constraints of technology, time, and resources that we have. I’m happy to work with you in this to help resolve as much as I can, because I recognize the wonderful and rich contribution to the Dynamo for Civil 3D space that you have put out there with your Arkance Systems package. What can I do to help now? Please note that a rollback is not viable.
We also wanted to set the strong foundation for the future of the entire landscape of Dynamo for Civil 3D, and delaying it further would exacerbate the problem with a larger and larger user base. We had good intentions to get this out at the major release of Civil 3D 2025, but due to some unforeseen issues had to delay to the first point release.
With regards to the prevention of users installing the wrong package version, @solamour and the Dynamo team are actively working on modernizing the Package Manager right now so that authors can include compatibility information for packages, so that when a user clicks “Install” it would simply get the correct version, irrespective of what version of Civil 3D is used.
I’ll admit this mistake, Anton, and I do apologize. There were no nodes in this category and so it was mistakenly combined with the base class. I’ll make sure that we get this corrected.
