Grasshopper

algorithmic modeling for Rhino

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

Views: 3808

Replies to This Discussion

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

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

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.

--

David Rutten

david@mcneel.com

Attachments:

Nice!

[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).

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

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 :)

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.

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

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

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

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service