Repository navigation
PillScript is a C# script component for Grasshopper in Rhino 8.
Download the .yak below, put it in a folder of its own, and install it from there:
"C:\Program Files\Rhino 8\System\Yak.exe" install --source C:\path\to\the\folder pillscript
Restart Rhino afterwards. The package is not on the Rhino package server, so the Package
Manager will not find it by name. Adding the same folder to
Rhino.Options.PackageManager.Sources under Options > Advanced lists it there beside the
public packages.
Windows, Rhino 8.30 or newer. The editor runs in the WebView2 runtime that Rhino 8 installs
for its own interface.
The component is called PillScript
It was called C# Script, the same as Rhino's own script component, and the two stood side by side
under Maths > Script. A search by name found both, or the wrong one. The nickname on the canvas
stays C#. Saved files keep working, because a .gh file finds a component by its id and not by its
name.
A compile asked for during another compile is not lost
Placing a component compiles its template. A compile requested through the bridge before that
finished was dropped, and the bridge waited two minutes and answered that Rhino did not answer. The
editor's Compile button went through the same path. A second request now waits for the running
compile, and one more compile follows it with the sources as they stand by then. Every caller that
waited gets that result.
Other plug-ins reach the bridge tools without a port
PillScript.Bridge.Entry.Run(tool, argumentsJson) runs one bridge tool and answers JSON text. A
plug-in in the same Rhino calls it by name, with no reference to PillScript, and needs neither
PILLSCRIPT_BRIDGE nor the port. Phenome Link uses it for its pillscript verb, in the first
release after 0.34.1.
Every declared input type receives its data
An item or list input declared as long, float, decimal, Point3f, NurbsCurve, PolyCurve,
Polyline, NurbsSurface or GeometryBase turned the component red with "Invalid cast" and the
script saw nothing. A tree of Point3f, Polyline, NurbsSurface or GeometryBase arrived empty
with a warning. Grasshopper converts an input only as far as its goo allows, and a Number does not
become a float. Item, list and tree inputs now go through one conversion, which narrows a curve to a
polyline, NURBS curve or polycurve, a surface to a NURBS surface, a point to a Point3f, and a
number to any numeric type. An item that still does not convert is reported on the component by
input and type.
Complex numbers reach a Complex parameter
A Complex output went to a Complex Number parameter as System.Numerics.Complex, which
Grasshopper could not convert. The solve opened modal "Grasshopper breakpoint" dialogs, and Rhino
answered nothing until each was closed. Grasshopper's own Complex, the one the template's usings
name, now maps to that parameter, and System.Numerics.Complex travels as generic data.
A check that runs in Rhino
tools/test.js sends each of 38 types from one script to another as an item, a list and a tree, and
compiles every example in the readme. It found the two faults above. It also found two examples that
did not build as printed: the first called a PolyHelper the readme never defined, and the panel
example had no RunScript. Both are complete now. The readme's section on building says how to run
the check.