Grasshopper 1.0 Beta 4 available for download

A minor upgrade is available that fixes a few serious bugs. The internal version of this release is 0.9.0069 and it can be downloaded from the usual location.

Fixed bugs:

Cull Duplicates would fail if the first two points in the list were coincident within tolerance, this is fixed.
Enabling Cluster Content Preview would not take affect until after the next solution, this is fixed.
Adjust Seam component would result in awkward curve domains, this is fixed.
Local parameter expression replacement was case-sensitive, this is fixed.

David Rutten

david@mcneel.com

Replies to This Discussion

Permalink Reply by Danny Boyes on January 27, 2014 at 12:49pm

BTW the McNeel change log hasn't had any entries for a while

Changes

Grasshopper 1.0 (0.9.0069) (01/27/2014)

Bug Fixes

None

Permalink Reply by David Rutten on January 27, 2014 at 1:03pm

We updated to a new hosting/download system and we sort of decided not to bother fixing it as GH is about to become part of Rhino. It will no longer need a separate log then. In the meantime you can use the Version History feature in the GH help menu. I actually like it better anyway as it's always updated so you can always easily see the changes no matter what version you have.

David Rutten

david@mcneel.com

Permalink Reply by Danny Boyes on January 27, 2014 at 1:56pm

One thing it lacks is the ability to search it.

You have to copy to a word document in order to look back at when items were changed.

So i've been just copying each release to a to an existing one.

EDIT: I should have phrased that as a Wish.

Permalink Reply by David Rutten on January 27, 2014 at 2:22pm

David Rutten

david@mcneel.com

Attachments:

SearchVersionHistoryLog.gh, 14 KB

Permalink Reply by Danny Boyes on January 27, 2014 at 3:13pm

Nice!

Permalink Reply by Arend on January 30, 2014 at 2:59am

[Edit: ooh I see that my local version is being kept in sync with newer versions. Awesome.]

Nice! Any chance of an online version? Would be helpful in submitting bugs. (Actually, just posting the announcements of a new GH version in a seperate forum would help, it's a pain to search for the changelogs in the forums).

Permalink Reply by Luis Fraguada on February 13, 2014 at 6:27am

From version log of 0.9.0068:

All expressions inside parameters now use 'x' as the variable instead of the nickname. Old files should be converted automatically.

This is great and all, but the Math > Script > Evaluate component does not abide by this behavior as it it's own component. This has been a bit confusing for my students. Can this be standardized across all Expression Editor based operations?

Thx,

Luis

Permalink Reply by Danny Boyes on February 13, 2014 at 7:23am

Hi Luis,

...expressions inside parameters...

Components like Evaluate, Expression, Format, etc. don't have "expressions inside parameters" as these components are able to work with multiple parameters.

I must say though I'm struggling to adapt to the new way... I'm sure it will stick in my head some day soon :)

Permalink Reply by Luis Fraguada on February 13, 2014 at 8:38am

I understand the statement David made. My request was for there to be a standard, not one behavior for one thing, and another behavior for another when they are in fact, two heads of the same beast. In other words, why change it? Some of my students use full names for the inputs, and they know to change the input name when they want to express the input.

Perhaps there is a good reason to change it. If there is, please let it be said.

Permalink Reply by Danny Boyes on February 13, 2014 at 9:00am

It seems you hit the nail on the head with the full names reference.

Personally I preferred it the way it was as it made far more sense when you hovered over it... as I never used full names

For example on a Domain Component I would have "-A/2 and B/2". Now you have "A as -X/2 and B as X/2" before I think it was cleaner and clearer

Permalink Reply by Luis Fraguada on February 13, 2014 at 9:04am

Yes, I never use full names, and what you mention of the hover over is creeping me out too.

Permalink Reply by David Rutten on February 14, 2014 at 1:13am

The reasons for changing it were:

You now never have to know what the name of a parameter is before you change the expression.
You can now rename a parameter without fear of it breaking the expression.
You can now use names with characters that are invalid variable names (spaces, dashes, brackets, braces, start with a number, dots, empty string, etc. etc.)
Even variable names that were valid might still conflict with existing function or constant names.
You can now copy expressions from one parameter to another without having to modify it.
You can now switch between full names and regular names without having expressions break.

I take your point about it now working differently for expression components and internal expressions. They've always been somewhat different, as inputs for expression components allowed naming like "My first parameter (t)", where only t would be used in the expression, but now they are very different.

David Rutten

david@mcneel.com