I worked with JSON extensively writing web applications so I understand you, but as a user, I don’t care. Same goes for list access vs. tree access - it’s Grasshopper, tree access of course, even if it wasn’t implemented when Hops was first released. I have no knowledge or experience with GhPlayer so having it bake Rhino geometry, in the conventional sense, is odd when there is no Bake component in standard GH. What about layer and other baking attributes?
“Contextual” doesn’t mean anything, in this context. Something like Response makes sense for Hops but maybe not for GhPlayer. Is there any good reason from a user’s POV that they must be the same? By the way, I don’t see any reason to have a right-click option for type of geometry. Can you imagine how painful it would be to have list/tree and type options on all GH components? Not good.
I don’t think it’s as simple as that. I just tried @maje90’s code again and after resetting the Hops path, I only had to reconnect his ‘Curves’ param to trigger a successful response. Don’t know how I missed that earlier. I asked earlier but don’t know if it works differently with “Referenced Circular Curve” vs. internalized geometry?
Here it is.
I guess each version have its own bugs/perks.
It’s probably better (bug-reporting-wise) if you use the latest one.
You can always revert back to older version.
It should work with inputs=whatever but outputs=only group+name method. I didn’t manage to make it work with contextual bake, if input is a simple list.
Uh, yeah, once this is fixed, Hops should totally be shipped with rhino!
I personally don’t use hops, only a bit of player, as I work almost alone with GH.
But, I make GH courses here and then, and working teams really find useful to have shared GH functions to use as rhino buttons or hops.
Last lesson (yesterday), I were like: “… and then, after grasshopperplayer, see this neat thing: Hops!” … and it didn’t work! But at least next lesson I will show them the named group method…
Very interesting. I can see now that my version is old but had no clue. Trust me, I’m not the only one who doesn’t follow all these details. But if I install the latest, Hops won’t work so why bother? Thanks for the warning. You’re on the bleeding edge.
Hello @maje90 Were you able to get your Hops components working with Tree Access set to false? I believe I have the same issue; see my thread from a couple of days ago, and this post by another user from much earlier.
The second post mentions this bug being introduced upon updating Hops to 0.15.0, so I’m in the process of trying some of the earlier versions now. So far, 0.14.1 still has the bug.
Edit: I can confirm that this bug is not in 0.13.1. So perhaps reverting to this version is an option if you have no need for Tree Access (introduced in 0.14) and Internalize Definition (introduced in 0.15).
I don’t think the bug is related to Context Bake. The old group naming method did not fix the errors described by @maje90 in the first post, at least based on my testing. It seems to be related to the Tree Access implementation instead, as the bug is present from 0.14.0 onwards.
@Joseph_Oster@email@example.com I’ve just published a new build of Hops (0.15.5) which should fix the issue you were seeing before where it would ask you to supply at least one item. Can you please test on your end and let us know if this resolves the problem. Also, does this also fix the Context Bake issue? I didn’t change anything in the code for that component, but in my testing this seems to still be working as expected. I’d just like to know if I can close that other YT item, or if I need to do some more digging.
Great. I’m glad it’s working again. Also, the groups issue appears to be repeatable on my end as well. I’m pretty sure groups were working a while ago, but I’ll have to dig in a little bit to see why they aren’t being returned. Thanks for reporting this.