Can you please update the latest allowed plugins to include Human 1.2? You are still using 1.1 and 1.2 has come out in August 2019, so more than 6 months ago.
Having to deal with Grasshopper Plugins is already hard enough, so please don’t make us juggle different versions of plugins. Especially when its actually really hard to find the old versions (yes, even on your website I always have to search for a long time, since there is no search).
There are not that many plugins you support, so the least would be to use the latest versions. They are backwards compatible so I am not even sure why you have to use the old versions. Is there a reason?
We will upgrade to Human 1.2 soon, and I will let you know when it becomes available on ShapeDiver.
It would be too risky to assume that each plugin we support is always backwards compatible. It is actually not the case with Human 1.2 because it does not work properly on Rhino 5, which means that we now have to support two different versions depending on which Rhino our systems are running.
More generally, updating a plugin involves checking the changes (potentially backwards compatibility issues, proper versioning…), deploying the plugin to the relevant systems (essentially DevOps tasks) and extensive testing after deployment (existing models uploaded before the change, new model uploads, each in different versions of Rhino when that is relevant). As such, upgrading a plugin is comparable to developing any other new feature on the platform, and as such it is prioritized along the rest of our work.
Of course, it is always good to post upgrade requests on the forum, because that tends to boost the priority of the task .
Thanks @mathieu1 for taking the time to explain. I understand better now and see the difficulty with Human (as it also has loads of forbidden components).
I think the other one on the list for me would be Clipper. That has a new version for a very long time already as well and recently I have seen it fail repeatedly on a model, where it doesn’t fail on our machine. I might make a separate post about it. There the question would also be: How can I debug something like that, where a component obviously fails somewhere on your server but not on my machine!?
As for this specific problem, if your file still works locally with the exact plugin version supported by ShapeDiver, then that is a different problem, I’ll wait to read more about it before suggesting fixes. It might be tolerance issues, referencing local files somewhere, outputs too big for the system limitations…
It probably has to do with tolerances. We have an issue there in our file as well, but not sure what we are doing wrong. It is set to millimeters and tollerance 0.001 units!?
.