Components & Parameters

Here is the cleanest way to hold it. A component does something: Move, Rotate, Divide Curve, Extrude, Loft. It has inputs on its left edge and outputs on its right edge, and it transforms one into the other. If the name is an action, it is a component.

A parameter is something: a Number, a Point, a Curve, a Boolean. It holds data or supplies it. The three you will meet on day one are the Number Slider (a draggable number you tune by hand), the Panel (a text box that shows you whatever data flows into it - your window onto the stream), and the Point parameter (holds one or more points). If the name is a thing, it is a parameter.

The distinction is not pedantic - it changes how you wire. Parameters are your inputs and probes: sliders feed values in, panels read values out. Components are the machinery in between. A healthy beginner habit is to read your canvas aloud as a sentence: slider (a number) feeds Divide Curve (an action) which feeds a Panel (so I can see the result). When a definition confuses you, naming each block 'noun' or 'verb' is often enough to unstick it.

There is a subtlety that trips people up: every component input is itself secretly a little parameter. The C, N and K inputs on Divide Curve are internal Curve, Number and Boolean parameters - which is why you can right-click an input and set data into it directly instead of wiring a separate parameter in. So the line between component and parameter is really about the block's primary job: a Number Slider exists only to hold and supply a value, while Divide Curve exists to act, even though it holds small parameters at its edges. Hold the noun/verb split as your everyday reading tool and let that finer point sit quietly underneath it.

Every component has small circular nubs on its edges - inputs on the left, outputs on the right. Each is labelled with a short code: Divide Curve takes C (curve), N (segment count) and K (kinks) on the left, and returns P (points), T (tangents) and t (parameters) on the right. Those cryptic letters are why Grasshopper feels alien for a week - and why the next skill matters so much.

Hover any nub and a tooltip tells you exactly what it wants: its full name, the data type it expects, whether it is a single item or a list, and often the default. Hovering N on Divide Curve reads 'Number of segments'. This is not optional trivia; hovering is how professionals learn components they have never used. Never guess what an input means - hover it.

Inputs can also carry default values and can be given data three ways: wired from an upstream output, set internally (right-click > Set), or supplied by a typed expression. When an input is empty and has no usable default, the component cannot run - which is where colour comes in.

Outputs are worth a moment too. An output nub can feed as many downstream inputs as you like, so a single component's result can drive several branches of a definition at once. Hovering an output tells you what it produces and, crucially, what shape that data is in - a single item, a list, or a tree. Getting into the habit of hovering outputs, not just inputs, is how you keep track of the data as it grows; a component that quietly turned one point into a hundred is something you want to notice at its output, not three components later when everything mysteriously multiplied.

The right-click (context) menu is the hidden control panel of Grasshopper, and beginners under-use it badly. Right-click a component and you can rename it, toggle its preview, disable it entirely, or reach input-specific options. Right-click an individual input nub and you unlock its real power: Set one/many (type data straight in), Flatten / Graft / Simplify (reshape the incoming data structure - Module 3's subject), Reverse, Expression (do quick maths on the value as it arrives, like x*2), and more.

On a Number Slider, right-click opens the range and type editor: set the minimum, maximum, whether it is an integer or a floating-point value, and how many digits. Getting a slider's range and type right is half of making a definition behave - an integer slider for a count, a floating slider for a radius. A slider whose range runs 0 to 1000 when you only ever need 1 to 20 is fiddly to control and invites nonsense values, so tune the range to the real design intent, not to some default.

A Panel is worth befriending immediately. Wire any output into a Panel and it prints the data as text, with branch and index structure shown. It is the print statement of visual programming - your first and best debugging tool. When something is wrong, drop a Panel on the suspect wire and look at the actual data before theorising. Its cousin the Value List (a drop-down of preset options) and the Boolean Toggle (a true/false switch) round out the handful of input parameters you will reach for constantly - together with the slider and panel they cover most of what a beginner definition needs to be controllable and readable.

Components tell you their health by colour, and reading it is a genuine skill. The default healthy state is a soft grey-green - the component ran and produced output. That is what you want almost everywhere.

Orange means a warning: it ran, but something is off - an input is empty, a list is shorter than expected, or the component had to make an assumption. Orange is not fatal; often it just means you have not wired an input yet. Hover the component and a message explains the specific warning. Treat orange as 'read me', not 'panic'.

Red means an error: the component could not run and produced no valid output, so everything downstream of it also fails. A red component usually got the wrong type of data (a curve where it needed a number), or an impossible value. Again, hover it - Grasshopper prints the exact reason ('1. Data conversion failed from Curve to Number'). The discipline is simple and worth building from lesson one: when a component goes red or orange, hover it and read the message before changing anything. Ninety percent of debugging is just reading what Grasshopper already told you.

A fourth state is worth knowing so it does not alarm you: a washed-out, pale component has been disabled (right-click > Disable, or the preview/enabled toggle), meaning you switched it off on purpose so it neither computes nor previews. That is a deliberate tool, not a fault - handy for temporarily muting part of a definition while you test another. Finally, a selected component draws in a green highlight and previews brighter in the viewport; that green is selection, not health, so do not confuse it with the grey-green healthy state. Put together, colour gives you an at-a-glance health map of the whole canvas: scan for orange and red first, and you find every problem in a definition in seconds without reading a single wire.