We have developed a small custom kit that we place in the Speckle/Kits/Objects folder and it works as expected.
Now, we would like to implement a more user-friendly experience involving this kit, which is to create custom components that is used to create the objects in the kit, which is literally also what the “Speckle Schema Object” does, as seen in the picture below. Ignore the input names, they should be exactly the same by the end of this.
In our component, I’m able to fetch the desired type from the kit and use that to create the object, so we don’t need any reference to our kit project in this project, so that’s nice and convenient.
However, what we would most like to do is to distribute the kit together with our component without having to place the <<kit>>.dll in the Speckle/Kits/Objects folder, so only to the Grasshopper Librariesfolder, and then we would instead have to add our kit manually to the KitManager. And after that we of course need the converters to still be able to convert our custom objects when coming e.g. from a Speckle stream.
Would this be possible for you to facilitate? Or is there maybe already a way to do this? From what I could see, there’s no way to do it as the KitManager only fetches the kits from that one folder.
That actually didn’t work for some colleagues. I had my kit in a different folder, and it worked fine, but when we tried to give the kit to some other colleagues it didn’t work. Then we moved the kit from Speckle/Kits/MyCustomKitName to Speckle/Kits/Objects and then the object conversions started working. I did try it again just now, to place it in a separate folder, and that works, so I’m really not sure what was going wrong for our colleagues.
However, this doesn’t address the issue I was raising. I would like to have to avoid placing the kit in the Speckle/Kits entirely. So to add a kit to Speckle from our own Grasshopper components plugin programmatically without having to place any files anywhere.
Understood, or at last, I am also puzzled by why it worked for some of you and not others. Do some colleagues have Speckle installed for Multiple Users and Some for individual users, perhaps…?
However, to get to the root of your question (apologies I didn’t address this), I will check with the more expert team, and we’ll report back.
Not sure what you mean by multiple users, but it could be that those colleagues had the Speckle Manager installed through our ICT system, and I think I’ve installed it manually through your website. Not sure if that’s what you mean, but that’s the only difference I can think of now between their and my Speckle installation.
Yes, that can effectively be the same issue I referred to. Plugins can be installed in your profile or the machine-wide directory. In this case, meaning there are two possible places the Kits directory may be found.
Yes, true, you are right. It is indeed curious; sometimes with no details, I clutch at straws. Nevertheless, someone will answer your actual question asap.
I’m a bit puzzled by this too Custom kits is a rather unexplored feature that may have some underlying bugs we never noticed, as 99% of our users (or more) would just use our Objects kit as-is.
As far as I’m aware, you need the Kit .dll file and at least one converter for your app (another .dll), if you’re following the Objects kit logic, that would be named following the pattern KIT_NAME.Converter.APP_NAME.dll. Just want to double check your colleagues had both files.
It’s been a while since I looked at this, but if you share some more details (or can share the code) I’d be happy to give it a quick look in case I spot any weird things.
In reference to this, here are the 2 locations you can find kits, depending on how you installed Speckle:
I’m sorry to say I don’t think this is possible at the moment. You’re still going to have to copy the Kit files to the correct folder for us to be able to find it.
That being said, you could still have your user’s install “just the Grasshopper plugin”, by packaging the kit files with the plugin, and having the plugin copy them to the right location on your plugin’s first load.
I’ll confess I’ve never tried to do this, so there may be some unforeseen consequences along the way…
This may not be ideal, but would allow you to reduce the user’s setup hassle.
The other alternative is setting up an installer such as ours (using Innosetup or whatever other tool), but if your goal is to distribute this through Rhino’s Package Manager, then this is not an option.
We actually have both the objects and the converter assembled in the same .dll. I suppose we should change that to follow the intended logic.
I will test a bit more with my colleague and check a bit more in detail myself. In any case, it works fine now as long as place it in the default Objects folder, so we’ll do that for now.
Okay I see. I suppose that’s not functionality that you’re considering adding, especially since most users don’t use custom kits?
I do think we might go with that solution of placing it in the correct location once the plugin is loaded, as I don’t expect too many issues with it.
Correct - but I’d be curious to learn more about your use case
What classes and conversions are you adding to your kit? What’s the main reason for doing so?
We use it for calculating MEP demands in a building. So we have a list of spaces (using the Space object), and these spaces are a few different types, so meeting rooms, kitchen, office, etc.
We assign these types using our custom Typology object, which we simply provide to each space. These Typology objects simply contain a list of Parameter objects, which are provided to the Space in order to calculate the demands more specifically using the size, occupancy, etc. of the Space.
So this Typology component (and several other components) are provided to our users as a GH plugin. And at this point, they also need to get the kit and place it in the correct folder, which is the step we wanted to make easier for the user.
Custom kits is a rather unexplored feature that may have some underlying bugs we never noticed, as 99% of our users (or more) would just use our Objects kit as-is.
