Obviously the user won’t get a helpful error if they feed in, 22 or a bool… But apart from that,
[question 1] what is the point of defining the input of a node?
[question 2] I’ve tried to do it for this node by writing :
str : String[ ]…[ ] and I tried str: String and some variations of DSCore.String[ ]…[ ] too… but none worked.
How would I do it for this node so I can input a string or a list of strings?
(Ps. Yes, I am aware of the Bumblebee package for Excel but like to use the OOTB Excel nodes also.)
the //ToolTip is a comment in design script which tells the user about the input if they hover over it.
The nameInCamelCase should start witha lower case value and have no spaces or special characters in it. This is the only requirement for the input node to work - everything else is optional.
The Class needs to be a recognised design script class, such as string, double, int, Curve, etc…
Note that this can include custom classes (i.e. something from say BumbleBee), but that can cause errors with users who don’t have that package installed so careful with this.
The StructureFlag enforces the node to work with a collection or single item. It can be any of the following:
if no value is provided then the node will expect a single item of that class
[] = a list of items
[]..[] a list of lists of items (as deep as it may go).
The =defaultValue is a line of design script which will be used if no value is provided. The node will not execute and will remain in a function state if no default value is provided for any input which isn’t provided, or if the default value is disabled.
Not at my PC to check so there might be some typos here. But all the same let’s try breaking down this sample input:
//The name of the moose
mooseName: string = “Marvin”
The tool tip will tell users that the value should be the name of the moose.
The input name will display mooseName
The class for the input needs to be a string
No structure is defined so if a list is provided lacing options will apply
The default value is “Marvin”
Another example to look at:
//The shapes to apply the moose to
shapes: Surface [ ] = Rectangle.ByWidthLength(1,1).Patch().Translate([0,5],0,0)
The tool tip will tell users that the value should be a set of shapes to apply the moose to.
The input name will display shapes
The class will be a surface
As a list is set for the structure no a single list will be treated as an object
The default value is a pair of 1x1 rectangles one at the origin and one at 5,0,0.
Just a mistype. It should be lower case for system types (str: string[];).
The other option you have is to use python to determine the input structure and return a matching list or single item. You also have list levels available in the graph workspace to tell the node what to expect. Defining a specified input structure is typically, though not necessarily, reserved for when you must have a specific structure. It’s to ensure that the user doesn’t provide an invalid input. If you don’t know what the input structure will be then it’s sometimes best to just let the user define it with list levels.
Correct; however the need to specify isn’t very uncommon. In fact some of the other threads which @Alien has posted indicate is a desire to build a bounding box around a collection of geometry, which in turn requires the list version of the Geometry class (or Surface, or whatever else) to prevent the node from processing each geometry separately.
The odd duck is having to specify []..[]. At that point I typically assume the structure has become unnecessarily complex as a first step.
Agreed. It’s nice to have a specified type for valid inputs, but I think too many people miss the fact that doing so is also specifying a structure and that can sometimes over-constrain or over-complicate the input condition. Unless the node requires a very specific input structure or class, my general opinion is that a good input name and a solid node description go a lot further than a specified input type and structure.
but like to use the OOTB Excel nodes also.)
