I am a fan of the idea of the separate trigger input. It may not be as minimal a solution, but I think for the sake of clarity and ease of use it makes the most sense. And Fred's suggestion that it respond not to a specific value (such as TRUE) but to any update in value solves the problem I have. Having a separate input also sidesteps the necessity of a special option to choose between "auto-reloop" mode and the way it currently functions.

Despite Yiannis's concerns, I think having some way to cause the loop to automatically re-run on ANY update would be extremely valuable. His solution with freezing the GH interface while this runs does not seem like such a bad thing to me - I am more than used to waiting a minute or two for a complicated definition to respond to a change far upstream. 

The way I get around this limitation currently is simply to avoid using hoopsnake and manually link together copy-pasted sets of components, one for each step of the loop. This is inelegant and messy, but it gets the job done, updating automatically each time the input changes. Because each individual operation is relatively simple, it's actually perfectly fast for my purposes. Assuming that HS's looping is almost the same as or faster than this dumb stringing-copies method, I think the "clunky" processing that Yiannis fears is really not a problem. For me the crucial thing is to be able to include a recursive process in the middle of a definition, and not have to worry about the separate step of double-clicking the HS component, resetting it, and telling it to loop, every time I make an upstream change.

Hi everyone,

First of all, I would like to thank you all for your involvement and great ideas that help the development of this component, as well as Grasshopper in general I should say.

I've been thinking about it and I am convinced that indeed as you propose a separate trigger that checks for data changes is the way to go. The scheme I was considering is more or less similar to the image Fred posted, although as you can see the outputs are somehow different: iS outputs the iteration count, while iL outputs the loop count, i.e. the number of complete loops (till the B* turned false) that have occurred so far. It's not so much informative in itself, but the change it produces is useful to drive serially linked Hoopsnakes, adding to the already discussed ability to nest Hoopsnakes using iS.

I believe that it is a simple and relatively easy to understand scheme, and it doesn't prevent the use of Hoopsnake as it is currently being used. However, in order to implement it a fundamental re-working of the internals of Hoopsnake needs to be carried out and since I haven't even began with it I can't really foresee what obstacles would come up during development... but i'll give it a try anyway.

Still, that is a couple weeks away since I am currently quite busy with my graduation project and there are also a couple bugfixes that need to be done first..

So, thanks again for the great feedback and please do say what you think of it!

Cheers

Yiannis

I think it looks pretty good!

No surprise that you get feedback. Man! We've been waiting this for years now!

In the first hs component I connected T to the initial value (you know why) but can you plug in both init. value and nested loop's iL output?

Anyway, do graduate first.

++

Fred