Hello,
I am looking for a way to trigger a button once I move a slider.
Basically I have a kangaroo solver that I would like to reset when I change an input value without having to press a reset button. It would thus act like the button component: remain on true for like half a second then get back to false (so that the solver keeps running).
This might seem a little superfluous but I’m creating a cluster and really want to minimize the number of actions needed to make it work and not confuse the users.
Thanks 
Hello,
here’s a funky use of Anemone that might work for you.
The top version will go True for as long as it takes to count up to the input value. The lower, the faster, but it should be enough to trigger the K2 reset. The bottom will allow you to set a custom delay - so if the user updates the panel to a different number, there will be a short delay before the reset is complete. (This could all be hidden in the cluster, but Anemone will need to be installed).
timed reset.gh (11.5 KB)
2 Likes
Installing another add-on is probably a deal-breaker since that adds to the complication, so I dug a bit and found this thread:
This handy little python script by @AndersDeleuran seems to do the trick just fine …
180830_GHPython_PersistentLastCurrentValueCheck_00.gh (10.7 KB)
1 Like
In addition to what Nick proposed, you might also want to switch to using the ZombieSolver. This will perform all the dynamic relaxation iterations in one Grasshopper cycle (i.e. will not solve live), and is designing exactly for cases where you want to iteratively change the inputs (i.e. using Galapagos etc.).
3 Likes
While we’re on the topic, I figured I’d ask to build on this and hopefully not hijack the original post.
Is it possible to use the Zombie solver for goals that need the finesse of a slider? For example, to slowly increase the strength of a CoPlanar goal as Dynamic Weight is applied to inflate a mesh simultaneously?
The Zombie solver always solves all the way from initialization to convergence in one Grasshopper iteration.
This might be okay for small/simple simulations that converge very quickly, but for something more involved it would mean waiting a lot each time the slider input was changed, because it has to start from fresh each time, instead of from the previous state as with the regular solver.
What context is this in that makes the regular solver unsuitable?
Hi Daniel,
Out of curiosity, I tried it on your old PlanarHexShell example (attached for quick reference). I only tinkered around for a bit before asking the above (reducing the iterations, etc), but couldn’t get the CoPlanar forces to work properly through the Zombie.
PlanarHexShell_Zombie.gh (22.1 KB)
Ah, I see.
Yes, the approach of start with some goals at moderate strength, then ramp them up to 10^x so they act as hard constraints is a frequently useful one, but not easy to translate to a Zombie setup.
I have sometimes thought about a way that goals could include an option to set the strength as something dependent on the iteration count. Maybe I should take another run at this.
Even aside from Zombie mode, it’s not ideal to share a file where the user has to follow instructions to move a slider at the right time with a steady hand to get the same result.
1 Like
If only there were a multi-graph editor in grasshopper, it would make this (and many other things) much easier.
I wonder if https://www.food4rhino.com/app/riched-graph-mapper could be extended to something like this? @Dani_Abalde
If it could allow multiple curves on the same graph display, each with their own output parameter, and let the user set keyframes and interpolation types, I think it would become a powerful timeline type animation tool. You’d just use the different outputs to replace multiple sliders and boolean toggles (if you also include a curve type that is always either 1 or 0), and run/capture the animation from a single time input slider.
2 Likes
I do get only False values from the Foo output of this script.