It seems like the structure of Hops outputs are bugged again. As a test, I compared the Divide Length GH component against a Hops wrapper of it:
The Hops inputs were set to item access with Tree Access turned off.
tree_structure_mismatch.gh (19.7 KB)
divide_length_wrapper.gh (3.9 KB)
I am running v0.15.5. An old post claimed to have fixed this but apparently not.
@AndyPayne Is the above expected behaviour? Why does Hops seemingly flatten the output before returning it?
You just have to set the Tree Access on the Curve (context get component) to True. You’re passing in a data tree of curves, so you should set the input parameter access accordingly.
So is the advice here to turn Tree Access on whenever you expect a tree input? Wasn’t there some Hops functionality regarding trees where if you have Tree Access turned off, each branch is then run on a separate thread to speed things up? How would that be useful if your tree structure gets destroyed?
I’m trying to write a library of reusable functions and I thought I could depend on Item/List Access working like it does in every other GH component to make my life easier. Instead it seems like I’m forced to use Tree Access for every single input, as I can’t anticipate what structure my users will feed in. This means I’ll have to program defensively and do the data matching manually, making all my functions much more complicated than it needs to be.
Furthermore, the Hops component does not work correctly even for list input. Here is the same test with the input curves flattened:
As before, the Hops inputs were set to item access with Tree Access turned off. I only get the “correct” answer if Tree Access is on. Why do I need to turn it on if I’m only passing in a list? @AndyPayne Are you able to replicate this on your end?
As a sanity check, for the list input test, I’ve added a GhPython wrapper of Divide Length with all input properties set to Item Access:
GhPython works as expected. Hops is the odd one out here.
tree_structure_mismatch.gh (23.3 KB)
@AndyPayne Are you able to replicate the comparison above? I set my Hops inputs to item access and I passed in a list. Passing in a list means I do not expect to use Tree Access, even if my output structure will be a tree. However, the output structure is wrong. Hops seems to have flattened my output and put it into a single branch.
I’m not sure what’s going on here… but I can’t replicate your error. I’ve created a similar definition on my end and I get the same result (see image). The first image is the hops definition that I load into Hops. I’ve set the AtMost value in the Curve context get parameter to unset to tell it that I’ll be passing in a list. However, I’ve left the AtMost in the Divisions context get component to 1 because I’m only passing in a single value. The second image is the loaded Hops definition where I compare the output with the output from another Divide Curve component with the same values. The output tree is the same.
DivideCurve_Hops_2.gh (10.5 KB)
DivideCurve_Hops.gh (3.3 KB)
Hi Andy, thanks for the reply. I’m not sure you understand what I’m trying to test.
In your definition above, you are setting the AtMost values in the Curve context get parameter to unset, which according to the docs makes this input have list access. List access, as defined for all GH components, means that if I have a list, the list will be passed in as a single input. Consequently, if I have a tree with 5 branches, each branch is treated as a list, so 5 lists will be passed in.
List access is not what I want to use. I want to use item access. Item access means that if I have a list, each item in that list will be passed in as separate inputs. Consequently, if I pass in a datatree, each item in the tree will be passed in as separate inputs.
The Divide Length component in my example is a one-to-many component, which means that its inputs are item access. I can pass in a single item, a list, or a datatree, and it will do the appropriate data matching automatically. So if I give it one curve input and one length input, it will run Divide Length once and give me a list of points. If I give it a list of 6 curves and one length input, it will do the matching and run Divide Length 6 times, and then combine the resulting 6 lists into one tree, each list being a branch in that tree. My point is that Hops behaviour is not consistent with this. I set AtMost to 1 for both context get parameters, because I want item access, irrespective of whether I actually pass in a single value or a list or a tree.
If you run the attached file in post #6, do you get the same results as in the screenshot?
FYI. I am looking into this. I will let you know what I find as soon as I make some headway. Cheers.
I appreciate it. I’m just hoping I managed to get my point across!
@hkit.yong I have just published Hop 0.16.0 which I think will now fix the data structure issue that you reported. See this post about the new release. Please download the latest version and test this out and let me know if this resolves this issue. Cheers.
Thank you very much Andy! I’ll put it through its paces and let you know how it goes soon.
Looking forward to your feedback. I tested this myself with several different definitions and couldn’t get it to fail… but I’d love to get feedback from others with their own files 
@AndyPayne Here’s a definition that failed for me!
This time at least it’s given me an error message, though I don’t know what to make of it. The Hops inputs are set to Item Access as always.
I must say, the patch has otherwise held up quite well! Thanks a lot!
divideLengthWrapper.gh (4.0 KB)
main.gh (19.6 KB)
So from my testing, the same error occurs even if I try and do the data matching manually:
It looks like all manner of tree/list interactions are bugged.
divideLengthWrapper.gh (4.3 KB)
main.gh (24.3 KB)
Ok. I’ll have to take another stab at this. Thanks for testing with all of these different examples. They are helpful to see where the bottlenecks lie.
Hi Andy,
Firstly thank you very much for your work! A major game changer in every turn.
Secondly I have a similar data mismatch issue which I’m not sure how to resolve.
When I open the standalone script it seems to work fine, but when I call it through Hops, I get a different result.
I’ve tried marking all inputs as Data Trees but it doesn’t work.
It seems that there is an issue with the data flow within the script when it is called through Hops, but I’m not sure how to debug it as it works fine when opened directly.
Every help would be very much appreciated.
The data in the standalone script:
The data after calling the script through Hops:
Calling through Hops.gh (72.8 KB)
Standalone script.gh (122.8 KB)
Many thanks,
Yoav
Hi Yoav.
When I try to open your file, it says I’m missing two plugins (Pufferfish and treesloth). Is it possible that one of these components are causing the issue? Is it possible to create a simplified example file which doesn’t contain third party components but still retains the data tree output issue?
