This is possible by adding an integer item in the loop and add 1 in every iteration.
That’s just building a for loop your self. If i have to keep track of the iteration count my self, I may as well add that one compare node in the end and do all of the work to make a for loop.
With the various loop styles, i’m starting to suspect the proposed node is too complicated and the “helping” that we are trying to do isn’t really helping as much and is just getting in the way.
I feel it may almost be better just to have something like this as a base building blocks
Enter determines if the loop is entered, if false the input Geometry is passed through to the output
Exit determines if the loop is exited
enter and exit are not as ambiguous as break and output previous and it allows people to build
forstyle loopsdo { .. } while(x)loopswhile (x) { ... }loops (somewhat clumsy since you have to implement the test twice, both for enter and exit conditions)
sure it be easy to make an infinite loop but i feel max_iterations was just a band-aid at best for a that problem (to be solved outside of this proposal) anyhow. It’s only helping me half way with a for loop, it doesn’t protect for the locking up blender problem, so … why does it deserve to be there? It seemingly brings very little to the table.