Do you have the “Include pre-releases” box ticked?
Dear Jeremy,
Thank you! I missed that one.
Have a nice day
1 Like
Annoyingly, searching for “Grasshopper 2” in the package manager doesn’t find it, searching for “Grasshopper2” does.
2 Likes
Check box “Include pre-releases”
2 Likes
There have been no significant changes to GH2 since its release, and many key core algorithms are still missing. When will the new kangaroo appear in GH2? Can you tell us the latest progress of GH2?
In that case I’d like to understand your description of significant 
. Note though that GH2 is not yet released, it is still in alpha state, and is nowhere near to being a replacement of GH1
Improved or new features since release include but not limited to:
- File Dependencies
- Viewport dragging
- Regular data editor
- Meta data editor
- Meta data display rules
- Meta data mixing rules
- New special objects such as Pins, Relays, Groups, Value List, Groups, Complex Picker
- New data types such as tuples and deformations
- Hundreds of components
- Interop with GH1 (unfinished, but partially working)
- Auto-backups
- Autosave
- Sandbox mode
- File comparison (although I think these last 4 aren’t part of the current alpha yet)
Things still to be done before moving into Beta include but are not limited to:
- Hundreds more components
- Adding undo to a lot more actions
- Finish the GH1 interop (I’m working on this at the moment)
- Create a decent expression editor
- Add data pickers to a lot more native data types
- Adding panel display to a lot more native data types
- Unify and standardize text → data parsing
Things to do before Beta can become a proper release:
- Find and fix places where the code still locks up the interface for a significant time
- Find and fix performance issues with viewport and canvas display
- Find and fix bugs
- Add a metric ton of content to the documentation
16 Likes
What aproach is taken here - inbuild diff function, and/or “stable” text format useful for external diff tools and version handling?
//Rolf
1 Like
I’m still working on text-like comparisons between files, but it’s sort of tricky because many changes to the actual file bytes do not actually matter in terms of differences. For example the order in which certain fields are stored is kinda random.
So far I’ve mostly focused on visual comparisons, enhanced with some coded overlays:
The *.ghz file format really isn’t designed for human consumption, even when converted into a textual representation, so trying to present differences on this level needs some serious thought lest it ends up unusably detailed/geeky.
9 Likes
Component to view html file like Panel will be very useful
@DavidRutten how many people besides you are working on gh2 at the moment?
My subjective and unqualified thoughts are that this appears to be a highly complex project (gh2 as a whole), that needs a rather big team of developers in order to get this ready within a reasonable timeframe.
Looking forward to the anaglyph 3d, too!
I get occasional help with specific problems I run into or when I need something from Rhino, but there’s only one full time developer on GH2. We have a professional linguist on call for UI and documentation language use, but she’s been busy with another project for the last year so that part has fallen behind development.
@AndyPayne and @kike are working on GH1 features and things like Grasshopper-In-Rhino-In-Revit. @curtisw and @dan are mainly responsible (in the positive meaning of the word) for making sure GH1 works on Mac. Furthermore curtis is the driving force behind Eto which is how GH2 can be cross-platform without almost any platform-specific code. @stevebaer or @DavidEranen help out whenever I need Rhino display features. @eirannejad and @Alain are involved with the Script editor for Rhino8 and by extension also the script component for GH2. Finally @will is just generally very helpful, especially whenever I run into git or nuget issues (which is embarrassingly often).
Without them the project would be dead in the water, or at the very least significantly worse or delayed.
26 Likes
#1 - [DIFF] - A first approach, the 2.0 version - if running out of time - would be to place all the “stable” data into a first big text chunk (tagged for easy extraction), thus one can still do a meaningful visual DIFF directly on the (unpacked) files.
#2 - [VCS] - And, also provide with an internal command (including a save option) to export the stable (DIFF-meaningful) data parts into a separate file altogether. The point would be that such a file would not be flagged as “dirty” in Version Control Systems if data hasn’t changed (no UI state or positional stuff in this file).
That would actually solve the critical aspects, although not super convenient. Or perhaps not so inconvenient at all. I would be Very happy with such a approach (and you could spend more time & effort on core functionality instead of messing up the file format).
Deal? 
//Rolf
How to find if a component is not native in grasshopper? Usually adding components by double click and there will be many same icon and or same name which hard to be separated.wish for a overly flag or overlay color
1 Like
The GH2 Alpha was in Rhino8 WIP. How about the release version? Which Rhino version will I need for that? 7, 8 or even 9+? (Thus, does it make sense to upgrade to Rhino 8 from a GH2 perspective?)
Every component really should reveal what plugin (Name + NickName + Guid) it belongs to, including the file name of the installed plugin file.
This info could be appended to the help-info (and cached in the component) when the component is placed on the GH canvas the first time.
Checked and confirmed plugin names & ids could even be part of a security scheme. Think , think, think.
// Rolf
2 Likes
At least the current WIP version of Grasshopper 2 still loads in the release version of Rhino 8.
1 Like
It would be really cool if this textual representation is “nice” from a human reader perspective and would allow roundtrip engineering between the textual and visual variants - with optional textual layout clues (perhaps even in a separate file) and auto layout in cases where one favors conciceness of the textual representation (and the user doesn’t want to write layout descriptions by hand…).
Besides the mentioned comparison and merging capabilities this would also be much nicer for certain editing and refactoring tasks which would be much faster in a capable text editor.