Latest wip Grasshopper load conflicts 51 errors

Serengeti (Rhino WIP)
1

Hi,
Just installed the latest beta and I got this error message when I opened Grasshopper.

GHfailLoad
GHfailLoad.jpg740Ă—420 213 KB

3

@DavidRutten can you shed some light on this?

4

I see this too. I suspect it might have to do with having Kangaroo2 installed in the Rhino 5 libraries folder and this conflicting with Rhino 6 shipping with Kangaroo.

5

HI All,

I also get the same error, and before seeing it I get this Kangaroo warning:

image
image.png954Ă—707 35.3 KB

6

Probably. @DanielPiker asked me to provide him with a mechanism to mark specific GHAs as Rhino5 only, but that isn’t finished yet.

2 Likes
7

Thanks, I see this too and filed the issue last week as https://mcneel.myjetbrains.com/youtrack/issue/RH-40588 for future reference. In the meantime, clicking Replace All and then OK to the next message should let you use the latest Kangaroo 2.

8

I’m now working on two changes to the GHa loading logic in Grasshopper 1.0 for RhinoWip;

  • GH will specifically ignore Kangaroo2.gha installations, so hopefully by next Wip this problem will just go away for Kangaroo2.
  • However since it is possible other plugins will suffer from the same problem, there will be something individual users can do to inform GH1 on RhinoWip/6 that a specific gha file ought not be loaded. This something is not some slick UI somewhere, instead you have a create a file with the same name as the plugin but with the extension *.no6. So, let’s say you have TotallyAwesomePlugin.gha installed and it works in both Rhino5 and Rhino6. Now you want to upgrade to the newer version which is Rhino6 only, so you install that somewhere else. Now however there are conflicts, because these two gha files define components with identical IDs. So you place a TotallyAwesomePlugin.no6 file next to the old gha, and Rhino6 will no longer complain about conflicts. It doesn’t matter what’s in the file, it only matters that it’s there.
1 Like
9

Can’t you just determine which component is the most recent based on figuring out which version of RhinoCommon the component references?

10

That would require loading it first, and also constructing the components inside the assembly to figure out if conflicts exists. This in turns means I have to first run the plugin initialisation classes and they might do all sorts of things that you might not want to happen if you’re going to ignore the plugin (like license checking).

Of course you can limit the collision detection to assemblies with the same name, but already there’s a problem since Kangaroo is called Kangaroo2.gha for Rhino5 and Kangaroo2Component.gha for RhinoWip.

Since this is such a transient issue I didn’t want to pour too much time and effort into it.

11

I was thinking you could look at assembly Guids and in the case of a conflict inspect the RhinoCommon reference number. That wouldn’t require any class construction.