Grasshopper 0.9.0005 Released!

A new version of Grasshopper has been released. It has been over 6 months since the last release and this one is loaded with fixes and new features. As always, it has its bugs so use with caution.  Be on the lookout for some videos covering the new features and frequently asked questions! Below are some notes from David Rutten outlining the nitty grity details of the 3 main changes.
Clusters have been rewritten.
Notes from David Rutten:
Clusters in Grasshopper 0.9.0005
Clusters have been rewritten from scratch (again), though this time there are fewer visible changes.
Note that clusters created with Grasshopper 0.8.0066 and earlier are not the same objects as clusters
created with 0.9+. They can co-exist but all the improvements only pertain to clusters made with 0.9+

The three basic features that were missing before are: referencing, entanglement and editing. It is
now possible to have a cluster which references a file on the disk. When that file is modified, the
cluster can be updated. However clustera maintains a copy of the reference file at all times, so
it's possible to retain cluster functionality even though the file has changed. It's possible to
reference *.gh/*.ghx files, but here is a new cluster file format called *.ghcluster which also stores
additional cluster information such as author details, passwords and it is partially encrypted when
a password has been defined.

When a cluster is copied within a single document, the two instances of the cluster will be entangled.
Whenever you change one of them, it will also affect the other. Entanglement does not work across
file boundaries though, so clusters which have been copied to different gh/ghx files -even if that
file is still loaded- will not be affected by a change. The logic behind cluster-entanglement is as
    - Every cluster has an ID. This ID is created randomly whenever a new cluster is made from scratch.
    - Whenever a cluster is saved to a file, the ID is also stored in that file, so IDs are retained
      during save/open and copy/paste.
    - Whenever a cluster is copied, the copy will inherit the same ID.
    - When a cluster is modified, it will also modify all entangled clusters in the same document
   that have the same ID. Then, all these clusters will be assigned a new random ID (but the same
   one for all of them). This way there is no conflict when an unmodified instance of a cluster is
   pasted back into a document.

Clusters can now be password protected. Passwords do not prevent a cluster from being used, only from
being changed or opened. Protection is about as solid as I can make it given the circumstances of a
non-obfuscated Grasshopper.dll and the necessity to store password hashes in the same file as the
cluster object. The only way your password can become compromised is via a dictionary attack. It is
easier however for an informed programmer to steal the cluster document. It is not possible to protect
against this because Grasshopper always needs to able to decrypt a cluster whenever a file is opened.
Passwords are always assigned to all the instances of a particular cluster in the same file.

When a cluster is 'opened up', a new document will be loaded into the canvas. This document knows it
came from a cluster and the Grasshopper main menu will reflect this as well. The cluster input hook
objects in these files will be filled up with the data from the original cluster object, to at least
provide a partial preview of changes being made. When such a subsidiary document is saved, the
original cluster will be updated and the file containing the original cluster will be loaded back
into the canvas. When a cluster document is being edited, there will be a cluster icon on the canvas
that provides some useful features.

There is no autosave for cluster editing, it is impossible to implement this unless I completely
rewrite the way autosave works and the way clusters are (de)serialized.

Since it is now possible that two or more documents are associated with each other (I.e. the document
which contains the original cluster object and the document which is used to edit the cluster) the
close/save logic is a lot more complex than it used to be pre-0.9. When you close a document, all
subsidiary documents will also be closed. You will be asked for confirmation if one of those
subsidiaries contains unsaved changes. If you save a document, all subsidiary documents will also be

    - Clusters can not yet be exploded. This feature will be added someday soon.
    - Clusters do not like to have Text Panels as input or output objects. I do not know why yet,
   but I'm on the case.

Autosave has been addressed.
Notes from David Rutten:
AutoSave and Recovery in 0.9.0005
AutoSave files are now handled differently. They are all stored in a single Grasshopper autosave
folder (accessible via the Grasshopper File→Special Folders→AutoSave menu). The name of each
autosave file is a hash of the original filename+location and therefore not humanly readable
( for example).

When a new file is opened and a matching autosave file is found in the AutoSave folder, a message
will pop up offering this information along with three options:

1. You can choose to open the autosave file instead of the original file, this will not
   overwrite the original file until the file is saved for the first time. Basically, the
   autosave file *thinks* it is the original file.
2. You can also save the autosave file under a different name, after which the original
   file is opened.
   This is obviously the safest approach, as no data is lost or in danger of being overwritten.
3. Ultimately, you can choose to ignore the autosave file and just open the original file.
   In this last case the autosave file is actually moved into the recycle bin before a new
   autosave file would overwrite it, so it is not in fact lost forever.

Data Matching has been redesigned:
Notes from David Rutten:
New Data Matching Behaviour in 0.9.0005
Data Matching has changed because (A) there was a bug under certain conditions and (B) I wanted to
make it more economical with regards to data path growth. The new logic is roughly as follows:

First a master input parameter is identified. At the moment, it is the parameter with the longest
path length. The amount of paths doesn't matter. Input parameters that have Tree access are never
Master parameters (unless absolutely no other parameter is available) and List parameters have lower
priority than Item parameters. In future versions it will probably become possible to assign a custom
input as master. This however is an expert user function and I want to post-pone adding it as long
as possible in order for the default behaviour to be tested and improved.

If all input parameters are list parameters, output paths are no longer grown. I.e. The Reverse List
component should output the exact same data tree structure as it gets.

The master parameter might not be the parameter with the most branches. It is therefore possible
that we run out of defined paths before the component is done computing. If this happens, the last
index of the last available path in the master parameter is incremented on each iteration:

Input  A = {0;0} {0;1} {0;2}
Input  B = {0;1;0}
Output C = {0;1;0} {0;1;1} {0;1;2}

A has a maximum path length of 2, B has a maximum path length of 3, B is therefore the Master
parameter. However we need three unique output paths since A provides three paths, so {0;1;1} and
{0;1;2} are made up on the spot.

It is also no longer possible to apply 'Shortest List' and 'Cross Reference' options to components.
Old components that had these options set still work like they did before, but that should be considered
legacy support. Instead, there are now three components in the Sets tab, List panel called
'Cross Reference', 'Short List', 'Long List' that basically provide the old functionality with a lot of
additional flexibility and options.

I'll put a post on the FAQ forum explaining how these components work and what all the options mean.