**Much thanks to Rajaa Issa, from whom much of this page has been shamelessly lifted.

Scripting with Grasshopper

Grasshopper functionality can be extended using scripting components to write code using VB DotNET or C# programming languages (more languages likely to be supported in the future).  Here, we will be focusing on the VB DotNet language, as it presents the smoothest transition from Rhinoscript.

The script component in Grasshopper has access to Rhino DotNET SDK classes and functions which are what plugin developers use to build their plug-ins for Rhino.  For more information on these classes and how to use them, see our Class Dictionary Page.

General Component Flow

In Rhinoscript, the exection of a script happens a single time.  Essentially the script is run from the top to the bottom of the code; while one may create loops and call functions to control the program flow, the script as a whole only executes once.  Grasshopper, on the other hand is constantly re-calculating a definition. A single component is accessed over and over again and will execute for every piece of data that comes through it.  This occurs with every grasshopper "event" (a slider bar is changed, a piece of input geometry is moved, or the "refresh" button is pressed).  For example, we know how the manipulation of a slider bar can seem to create a little "animation", with the geometry in Rhino reacting in to the realtime parameter changes.  This "animation" is created as the grasshopper model solves itself again and again - recalculating the resulting geometry and running our scripts up to 24 times per second.  With this in mind... code carefully and give your computer a rest!

TODO: diagram of grasshopper component flow vs rhinoscript

The VB DotNet Script Component

    Like any other component in the Grasshopper universe, the script component has inputs and outputs.  Unlike any other component, however, we will ourselves be defining what the script component does and how it works.  So, we'll be needing to define what sorts of things flow into and out of our script component.  Think of the script component as a little world unto itself within the larger world of your grasshopper model.  The only communication that your component is allowed are the little spouts of inputs and outputs that you allow.  Lonely, I know, but you can see why it's so important to define your inputs and outputs well.
   


    Grabbing a script component (which may be found under the "logic tab") and dragging it unto our canvas, we find that by default a script component has two inputs and two outputs.  Here's how that breaks down:
    

    Inputs

        The input parameters on the script component (as with all grasshopper components) are the little spouts on the left hand side.  Anything that we wish to use inside our script must be provided via one of these spouts, so defining them carefully is important.
        
        x: the first generic input
        Y: the second generic input
        
        We can do several things with these inputs while working out here in the main canvas to ensure a comfortable working environment within the script.  First off, we can change the names of these inputs to something more appropriate to what kind of thing we expect to flow in here.  Next, we can decide if this will be a single object or a collection of objects, by checking the "List" checkbox.  Finally, and most importantly, we can provide a "Type Hint" indicating what type of object we expect to be provided.
       
        
        Also, if two aren't enough for you, you may define as many inputs as you wish by using the "Input Manager".
        
       
        
    

    Outputs

        The output parameters on the script component (as with all grasshopper components) are the little spouts on the right hand side.  Anything that we wish to pass from our script to the rest of the grasshopper world must be provided via one of these spouts.  Defining them carefully, however, really isn't that important, as much of that business will take place inside the script itself.
        
        A: Returned output of type object.    
        
        So, by default, our component will return one object (or list of objects) called "A".  You may rename this output and add more outputs via the "Output Manager" in much the same manner as above.  You'll notice that you cannot control what type of object will flow out of here, as that mess will take place inside your script.        
   
Also, if one output isn't enough for you, you may define as many outputs as you wish by using the "Output Manager".

    Special Outputs

        out: output string
            This is the one in/out parameter that we have no direct control over.  Here, we will receive messages from grasshopper when we do things wrong in our code, as well as messages from ourselves that may give clues as to what's going on when things get sticky.  It's a good idea to connect the "out" parameter to a text component (found in the "Params" tab) so that you may see messages and debug information easily.  This is the setup in all the screenshots above.