Hi Everyone!
I have published my first package: Cadence. I was going to wait until I had more nodes in the package before publishing it, but then I found someone needed these nodes.
I know @GavinNicholls is probably going to roast me for publishing a package with only 3 nodes and cluttering up the package repository, but I will try to get more nodes in there soon. The nodes that Iām developing will have at their core a mix of Code Blocks and a few Python Scripts.
The description and keywords of the package need better elaboration, and the annotations and licence declarations of the scripts in the nodes probably need to be better. Actually, I donāt really know much about licences, so I copied an example from @jacob.small and added Apache 2.0 under a properties header with a licence file in the extra folder.
Any opinions, suggestions or pointers for improvement would be welcome.
Crumple began as 2 nodes I think, no worries - just stick at it!
I techically have a 1 node package lurking on there that is waiting for me to feel motivated enough to look into C# for Dynamo if I find my way back to itā¦
The more C3D packages available the better, and I like the package name as well. I like that the package originated in a problem you needed to solve that you wanted to package to share with others as well, commendable motivations.
This is good to hear about a new package, the only things i would add are as follows:
Do add any compatibility information onto the package. eg that its for Civil 3d 2025 and above. This will stop/mitigate someone installing it onto any other software, then creating posts that it does not work.
Do indicate within the description any info on the python engine that is utilised, though i would suggest you move to pythonnet3 package for the python engine in civil3d 2025 and 2026 because this engine becomes the default in Dynamo V4 which is hosted within Civil 3d 2027.
Great first use case and publish! The more packages we have in the community the better!
I agree with @GavinNicholls - it isnāt the number of nodes which make a package great - I have a few āonly one nodeā packages in my toolbox. Side note for Gavin - I keep half heartedly looking for a venue for a Indian Jones themed workshop/presentation called āBecause I hate Snakes: Moving from Python to C# for Dynamo Developmentā, but itās tough to find a venueā¦ BILT Europeās likely the front runner if the timing works out in the coming year, but if youāve got other thoughts on how to get that type of stuff out there let me know.
I donāt want to distract from your new package @ISECnico, so if you have questions on licenses and packages feel free to start a new forum topic on 'how to select a package license - I promise to weigh in with my usual mix of info and opinion.
Haha honestly I need to get back to ZT packages in Dynamo eventually. Mostly been dabbling with add-ins these daysā¦ still use plenty of Python nodes in Dynamo but feeding a lot of AI generated stuff in there vs writing insitu these days - time poor.
Generally stuck using Revit 2025 at the moment where Iāve found Dynamoās stabilityā¦ mixedā¦ to be honest - might return to it once Iāve got up to R26 or R27 as my home base. Hard to get users on board if my Dynamo scripts (and often just launching Player, or it is buried o the second screen until users closes it) crash 'em out.
Was going to try loading up Claude with as much context as I could and see how far it gets too an experiment, so Dynamo packages might be the project I give it.
For zero touch modes, node model nodes, extensions, and view extensions I have found AI assisted autocomplete in visual studio more effective than any tool building larger prompts.
There are three problems I keep seeing with ācomplete buildā tooling attempts.
The first is that there is just too much noise from other languages so you get significant use of made up methods and such. My favorite from my last sampling was something like Vertex vert = new Vertex(point.X, point.Y, point.Z);. A good MCP setup could offset that, but that gets us into problem 2.
Problem two is that configuring a system that gets it all right takes 4x the effort to use the system that does little steps, and the technology is changed so often and without notice so things can (and will) stop working midway though the day. Claudeās recent evolution in the model that tells āgo to bedā is a good example of this. Something changed and no one knows what or why but you have to reconfigure your setup to account for it.
Thirdly is that little changes are digestible to humans. If the inner workings of a method are provided I can read line by line. But when the output is a full solution with 4+ projects and 25 interconnected and cross referenced classesā¦ well no one is reading all of that, so if it works correctly is anyoneās guess, and how to fix the inevitable bug even more so. Likely a new user prompt āhey the code you built stopped working and I can figure out where or why please helpā and a response of āyouāre absolutely right let me delete it all and try againā. That is assuming they havenāt used up all their tokens for the month yet or the service isnāt rate limited at the moment.
And as cool as LLM tools are, those issues coupled with the price and reliability may panning out in the long term. Microsoft has announced that Claude is too costly and is ditching their licenses accordingly. Uber used all of its annual token budget in under 4 months. Costs for the popular LLMs are skyrocketing. And 70% of executives have reached the āconfirm there is ROI or we pull the plug next yearā.
And so I recommend using the tools in baby steps not in big dives. All of that could change any day now, but for now my money is on the targeted use of the tortoise not the full builds of the hare.
100% agree with everything youāve said here, and this is if anything an experiment in identifying the struggles to hold large context and nested reference file structures/instructons. It honestly did better than I expected but it did need plenty of refactoring when it was done. Big shoutout to @john_pierson for making Rhythmās src available, it really helped me understand most of the core concepts I needed to get started in addition to the primer.
I did find with the primer and some sample code from Rhythm (sln/csproj) as well as high level instructions from myself, it got me to the chassis of a project. Iāve had to improvise a few things for now like generating my own pkg.json via my build vs package manager, but in essence have a functional local package built in C# which is exciting. Still deciding on how far back to support, probably no earlier than 2025 to stay away from Framework land.
I do generally converse with AI via snippets and back/forths (as wastelessly as I can, usually feeding in multiple queries at once to reduce overhead), but have been constantly surprised by Claudeās capability for small to medium sized projects I provide it with. Iāll get something up on git later this week, no doubt Iām doing a lot of things wrong (even if itās working currentlyā¦). Iāve done plenty of things where in my head Iām telling myself that I doubt this is the intended/best practice way, but keen to share where Iām at eventually and let the wolves descend, baptism of fire is often my entry point to new things by choice.
Lots of quirks Iāve come across such as the query/create/action being implied by method name in 2027, so Iāve limited my focus to just one Revit for now to come back to the rest of those later. The config system that I got taught by Nice3point (and John) seems like a good way to deal with it.
My package currently only has 3 nodes also as well @ISECnico, no doubt far simpler ones than yours as well! sCrumple is a placeholder, final package name most likely Pickles given the name change.
Cadence. 
I was going to wait until I had more nodes in the package before publishing it, but then I found someone needed these nodes. 
, no doubt far simpler ones than yours as well! sCrumple is a placeholder, final package name most likely Pickles given the name change.