I saw this from @john_pierson
I saw that John later changed it into Categories.ProjectionLineWeight, but my question is
can i use this in designscript for every zerotouch node (calling a zerotouch node)
has it anything to do with that (being zerotouch)
and can i also use arguments to define inputs for the node this way?
Is it documented?
Thnx,
Marcel
Hi @m.rijsmus ,
yes this has to do with it being Zero Touch. You can call any zero touch node in DesignScript except for those with UI (dropdown nodes for example). Also yes, you can define the inputs in DesignScript.
You only need to specify the namespace if there is ambiguity (a class with the same name in different namespaces).
Thank you @Mostafa_El_Ayoubi
on the sideline
for calling nodes in DesignScript, would the method -PackageName-,-Node-,(Arg1,Arg2) be the better way to go?
Replacing Rhythm.Category for Categories as @john_pierson did, would possibly give new Namespace collisions?
I think the change from category to categories was probably a way to avoid namespace ambiguity. John is a very nice and thoughtful guy! 
I guess putting the name of the package is probably a good idea, that way you know where it comes from. But for some reason it doesn’t work with all packages… My guess is the namespace doesn’t always match the package name (I’d like to be corrected if i’m wrong here :D)
Let’s wait for John to wake up 
In the meantime i tried some codeblocks too and i saw the same thing happening.
Is this functionality of calling nodes Dynamo 2.0 stuff? or does it work in Dynamo 1.x aswell?
I tried both version because I was curious about that too. Both seem to behave the same.
Hey,
Thanks for the insight Would you mind talking me through what I’m seeing here? I don’t quite get the logic of where RevitElements has come from, and why Rhythm doesn’t work…
Cheers,
Mark
Edit, changed to unresolved as this is getting interesting
I know I know, but I get scared of updates… What if everything breaks?! 
2.1 has my new packages in it… Do you think the change is from the updated package rather than new Dynamo?
Yep pretty sure about it!
I understand the fear of package update … But if you keep up you only have small adjustments. The longer you wait the scarier!
This is from 1.3 :
Sorry, to chime in, but…
It seems to me that the naming in designscript is powered by the class, and namespace used in the c# coding.
e.g.
(I know the Canary package is not replaceing values, it is my own package and attempt to understand and learn C#, so bear with me as it is solely representational atm).
That said the changes to the naming in node to code seems to be powered by the naming standard used in the c# coding. And if there are several different packages using e.g. “List” as the static class then you need to specify which to use.
If the developer named the static class e.g. “AndenPrivateClass” as seen below there would be no need to add the package name as there is no conflict/problem identifying what we’re dealing with.
I know it is possible for the authors to control this naming even further but I have not reached that part of my C# knowledge/training as of yet
And lastly excuse my crude coding, have only been dealing with C# for a few hours so far and going from Python it is a lot more strict
So, how do i work with this knowledge.
How can i call (zerotouch) nodes in DesignScript?
Is a generic description -on how to do it- even posible?
What are the rules?
Most times it can be expressed as “most safe” to include as much of the information as possible, on the of-chance that another package in the future will contain the same naming.
Node to code will give you a viable solution atm. But you can add e.g. packagename if this is what the author have used as the namespace. Unfortunately, as there are no “standard” as how people are coding the nodes there is no real “rule” to follow, sorry. 
Below an example using the same node as your original post.
But my bet would be that 90% of the developers out there will follow this logic… (Unfortunately if they do not include migration files when changing layers/nodenames there is little to do but write it out again).
I’d be careful with that though because package name isn’t necessarilly the same as namespace as @Jonathan.Olesen says . Here’s an example :
Unfortunately I cannot install DynamoMEP to test… (Or it cannot load the .dll) (Dynamo 2.1.0)
But, are you not missing DynamoMEP.Revit.Elements.CustomRoom.ByPoint(pts)
?
I’m sure you’re right, and I appreciate the cautionous note, this comment is purely for my own understanding, and arguments sake
Oh, well, there you go, the exception that proves the rule 
I often go with whatever Node2Code generates, which typically will give you the simplest method to call the function. My renaming was actually due to the conflict causing crashes when using Node2Code.
In regards to how this is established, taking a look at the XML documentation from Rhythm and Dynamo MEP, you can clearly see that DynamoMEP is using the same convention as OOTB Dynamo. while Rhythm starts with Rhythm.
