Loading Kits in GH

hi hello hai :wave:

Been stuck on an issue with using kits with the GH connector that I could use some help with. Each time I drop a component down that utilizes SelectKitAsyncComponentBase it immediately drops an error message with “no default kit on this machine”, which is crazy cakes cause on my machine I have kits located in the default folder location.

:arrow_down_small: proof of existence

I’ve done some debugging to see what’s going on, but it hasn’t lead to much discovery.

  • At first I thought this was an issue with some additional kits I have on my machine where the reference to Speckle.Core2.dll might have been different, but looked into that and saw that everything lined up.
  • Removed all kits besides Objects and still seemed to hit this issue.
  • Loaded the connector from the manager and the csproj (both in COFF and disk) with no luck there
  • I put together a quick test that follows some of the grasshopper logic for loading kits and that worked perfectly. I’ll drop that test below :arrow_down_small:
Simple Test
[Test]
public void PleaseWorkAndGetKits()
{
  var kits = KitManager.Kits;

  Assert.IsNotEmpty(kits, "kit manager should have some shit in it");

  foreach (var k in kits)
     Console.WriteLine(k.Name);

  var dk = KitManager.GetDefaultKit();
  Assert.IsNotNull(dk, "that lil shit should be there");
  Console.Wr

I was wondering if the issue could have come from the way I was referencing ISpeckleKit, either with the nugget Speckle.Core vs a direct project reference. I put together two new test projects, one that uses the nugget ref and the other with the csproj. Both work with the test above, but had no impact on the grasshopper connector.

So, this is where I am, nice and stuck in the *.dll hell :skull:. Any help and/or general positivity is much appreciated.

Oh! As a side note, one thing I did find during the debug process was a possible bug when calling KitManager.Kits. If a kit is installed on a machine but doesn’t implement the getter for Types it will return a null item that is then trying to be pushed into a collection with ToList().

_AvailableTypes = _SpeckleKits.Where(kit => kit.Value != null).SelectMany(
kit => kit.Value.Types).ToList();
1 Like

hey @haitheredavid, sadly I know this issue, it been popping up at random times.

To be honest I’m not really sure why this happens. Usually a full reinstall of the connector does the trick to get the kit manager to work again 🥲

Another thought, could you have mismatched installed versions of Rhino and Grasshopper connectors? Could you try with just the Gh connector installed?

The resason being that the Rhino SpeckleCore2.dll gets loaded before Grasshopper, so any mismatch will cause trouble.

1 Like

@AlanRynne thanks for the response! Happy to have your help :smile_cat: I have tried re-installing the connector from the manager a couple of times without any luck, I’ll give it another go this morning and see if anything changes.

Seems like this did the trick with that error! :tada: However, a new issue has come up :cry: It looks like none of the additional kits are being loaded into the converter now.

I step through some of the lines and found that the KitManager is trying to cast each local kit to ISpeckleKit and those casts are returning null for everything besides the default object kit. Could this be caused by mismatched versions of the SpeckleCore2.dll ?

edit: I misspoke about the casting error, I no longer was receiving it once I removed the rhino connector and built the grasshopper connector

I guess the other Kits are referencing a different version of SpeckleCore and are probably missing to implement some interfaces, hence the nulls…
Try using the latest nuget? We make new ones with each connector release.

1 Like

@teocomi I misspoke in that last comment, after removing the rhino connector and building grasshopper connector I was no longer receiving that error during that cast. I stepped through the lines again today and notice kits was able to cast and store my other ISpeckleKits, I’ll edit that comment!

I did discover the issue thou :tada: The dropdown menu that gets populated with the available kits + converters is hard coded to load kits for rhino6, and I’m currently developing on rhino7. I changed that parameter to Applications.Rhino7 and everything started working :smile_cat: :skull:

edit: seems like you can access the rhino version pretty easily with RhinoApp

1 Like

Ah! Nice find, and sorry for causing you headaches!
Will, add a ticket and fix it asap :boom:

1 Like

For what it’s worth this lil getter seems to be doing the trick within the SelectKitAsyncComponentBase parent.

  protected string GetRhinoVersion
    {
      get
      {
        var versionNum = RhinoApp.Version.Major;
        switch (versionNum )
        {
          case 6:
            return Applications.Rhino6;
          case 7:
            return Applications.Rhino7;
          default:
            Log.AddBreadcrumb($"Rhino{versionNum } is not supported");
            return string.Empty;
        }
      }
    }
2 Likes

Hey @haitheredavid, sorry for the headaches :sweat_smile: Just got back from my vacation.

So the reason the kits are hardcoded to load only Rhino6 is because our Grasshopper build depends directly on the Rhino6 converter (instead of building 2 different .gha for 6 and 7 independently).

I haven’t checked the GetRhinoVersion getter yet, but off the top of my head, this may cause problems if a user only installs the GH connector, as they’ll only get the Converter.Rhino6.dll, and hence will have no default kit :sweat_smile:. I’ll try to test my theory sometime today.

Anyway, we’ve had talks about splitting the Grasshopper build for each Rhino version (just like our Rhino and Revit connectors work), which should also fix this problem indirectly.

Meanwhile, if this fix has no downsides… I’ll be happy to add it!

1 Like

Hi @AlanRynne :wave: welcome welcome! Hope the vacation was relaxing :waffle: :sleeping:

Thanks for this information, that makes a bit more sense of why it’s hardcoded to Rhino6. I think the lil’ getter I wrote would fail since it would require the namespace of Rhino. Unless there is other people hitting the same issue, I think this lil’ getter can stay put in my fork rather then cause headaches in the main one.

Out of curiosity, is the reason for directly relying on the Rhino6 converter and not a GH converter mainly to reduce repeated code since most grasshopper objects are mutable to rhino objects?

1 Like

Exactly! But we might consider breaking things down a bit more using shared projects (like the Revit one).

1 Like