Hi everyone!
I have two elefront components in my hops source file.
For both I get an error message like this:
e.g. Object reference not set to an instance of an object.: component “InBlock”
Is hops not compatible with Elefront components for placing blocks?
Does anyone have an idea how to solve this problem or an idea for a workaround?
Thanks a lot in advance!
Best!
Leona
Hi Leona -
There is no native support for blocks in Grasshopper 1 and, as such, Hops is not designed to support workflow that involves blocks.
-wim
Without seeing your definition it is hard to say exactly what the problem is.
ScatterAssets.3dm (244.3 KB)
ScatterAssets.gh (27.3 KB)
I want to scatter Enscape assets. But the two Elefront components (marked in pink in the script) cause the following error message:
That specific message means that there is code in elefront that would need updates in order to properly run in the environment that hops uses to compute results.
Hops launches hidden copies of Rhino/Grasshopper and calls these to solve the external definitions. This is what we call a Rhino.Compute. These copies behave slightly different than the standard Rhino/GH environment where user interface exists as well as active Rhino documents.
When Hops launches the hidden copy of Rhino, does that copy also replicate the document that was active when the Hops script was triggered?
I’m asking because:
Based on the error messages, the Grasshopper script is trying to list the block definitions in the document, and then create an instance of one of those blocks. If the new copy of Rhino doesn’t have those same block definitions, then Elefront can’t create the list (error message 2), nor find them to instantiate them (error message 1).
If it is replicating the active document, then yeah something else is happening and it seems like we need to take a look at how Elefront is interacting with the Rhino.Compute process (which we will be doing anyway).
Thanks for the information Keyan.
There is no RhinoDoc at all when running the definition remotely via compute so these components will not work. I wonder if there is a better way to report errors so users know this is not going to work.
Interesting. Perhaps there could be a component that packages certain aspects of the document (Layers, Materials, Block Definitions, Dim Styles, Annotation Styles…) into an object, which is then passed into Hops, and either deconstructed or used directly.
Hops is really a client that makes calls to another process either locally on the same computer or on another computer to solve a definition. This other process is called Rhino.Compute. We could package up the Rhino document is send it to the other process to be opened and inspected, but the overhead of making these network calls is potentially massive. This is something I’ve tried to stay away from while developing Rhino.Compute, but I’m open to suggestions of code contributions that would make this work.
