Good news. I finally figured out the issue. In hindsight, the fix should have been fairly obvious… but it took me quite a while and a bunch of logging in order to figure things out.
First, I have pushed a new version of Hops/Rhino.Compute (0.16.20) to the package manager. This new version has much more robust logging and it’s been streamlined across all of the various projects (ie. Rhino.Compute, Compute.Geometry, and Hops). I would recommend logging into your VM and running the update script to update your version of Rhino.Compute on your VM to the latest version. I would also recommend adding (if you haven’t already done so) an environment variable on this machine called RHINO_COMPUTE_DEBUG
and set the value to True
. This will enable a more verbose logging to occur which could help troubleshooting in the future. Then restart your VM.
Secondly, I would then log into your VM under the RhinoComputeUser profile and launch Rhino and the package manager. I would recommend updating your installation of Hops to use the latest version of the plugin (0.16.20). While you’re doing this, make sure that the URL in the Hops preferences still matches the URL you’re using when sending a request to your VM (same instructions as before). Also, double check to make sure your API key is correct. These two things still need to be in place to get the nested Hops definitions working. Once, you’ve done all of that, I’ll explain what the actual fix is in order to get nested Hops definitions working.
The key piece that I was missing is that file path for your nested definition needs to be able to be found on your remote VM. For example, you had a file called GH-B.gh
and inside of that you had a Hops component pointing to another file (somewhere on your local computer) a file called GH-A.gh
. When I was testing, the location of GH-A.gh
was C:\Users\username\Downloads\GH-A.gh. However, when this file was deserialized on the remote VM and it went to look for this file at that location, it couldn’t find it. Now, there was a silent bug that I found (and fixed) which was not telling you that it couldn’t find this file. Instead, nothing happened which is why it was so hard to uncover why it wasn’t working.
So, the fix here is to go to your local machine and reassign the Hops component inside of GH-B.gh
(ie. the one pointing to GH-A.gh
) to a file that can be found on your remote VM. For example, I created a directory on my local machine called Rhino Compute Files
at this location C:\Users\Public\Rhino Compute Files. I then logged into my remote VM and created a directory at this same location. Inside of this directory, I copied the GH-A.gh
file. Now, when you open GH-C.gh
, it will send the request containing the file GH-B.gh
. When compute deserializes this file, it will detect a Hops component pointing to the GH-A.gh
file located in your C:\Users\Public\Rhino Compute Files directory. It will find it, and proceed to make the appropriate calls to make the proper computations.
So ultimately, the issue came down to rhino.compute not being able to find the file of the nested Hops definition. The improved logging in the latest build of rhino.compute also helps troubleshoot this issue. Please test this on your end and let me know if this works for you.