I have a simple GH definition that has internalized geometry. When I call this definition using hops I see the geometry as input but the internalized data is not recognized. Looking at the forum it appears that there shouldn’t be any issues with this. Is there something I’m missing?
This is a screen of my hops function. The curve data is internalized.
And the caller:
Correct, the Hops error message is clear. Without any input, it won’t even try. This old trick doesn’t help:
3. Attach minimal versions of all the relevant files
Bur don’t bother now, I already went to the trouble of creating my own code to test it.
Thank you for your quick response!
Hmm. Okay. So the problem wasn’t with the internalization of the data. The problem was that the “Get Geometry” component doesn’t seem to recognize data being fed into it and requires the caller to provide it. This is different behavior than the other components (e.g. Get Boolean, Get Point).
Can you prove that with examples? I’m not gonna write more test code.
It required some extra work on my part but I see your point. When Get Geometry is removed, the other three work.
I’ve never seen Context Print before and am surprised it works with Hops.
This is interesting and perhaps your solution? It’s been a very long time since I worked with Hops.
hops_get_2023Jan26c.gh (10.4 KB)
P,S,
After spending some more time looking at this, I am pretty sure this is an issue with Rhino Compute. I need to do a little more research but it looks like most of the Geometry data types will not use any ‘default’ data. That is data that is passed to the input component, whether a “Get” component or one marked as “RH_IN”. Rhino Compute just ignores the data.
It is a known issue. I just had the wrong initial assumption of what was going on.
