How to detect an update/change of a number?

I discovered another problem with the script in Rhino 5. Changing the number by sliding the slider expires the componant. Once the number is set by tyling it doesn`t !? (4.4 KB)

That’s because sliding expires twice: once when sliding to a value and again upon releasing the slider knob. Typing in values only expires once upon entering the value.

How could a value be stored and be compared with an new value afterwards? Since I need an " autonomous" workflow for the optimization

That’s exactly what the script does. Perhaps it is more clear if we make a persistent list, instead of just one variable that we keep overwriting like in the examples above: (3.9 KB)


Hey Anders, could the second exire of the componant be done with a timer inside the script? Cause Input “CurrentValue” souldn*t be a slider but only a number which updates when the geometry changed e.g. the volume/ nuber of vertices etc.
Any Idea how to integrate that?

Any input should work, and you shouldn’t need a timer. If that doesn’t work as expected, please provide a file/example and I’ll have a look.

Hey Anders,
so this is what I want to archieve with the componant:

The script with the Process works but only for ONE Iteration with Octopus, since the “Balancing as Rigid Body” just gets an TRUE to reset in case the geometry of the Typology Optimization was updated. But after the RESET the Solver keeps been reset.

The attached File mimics just the core problem. So is you just scale the MeshBox in Rhino with the Gumball the Python Componant outputs a True since it expires once. I need now something which “automatically” expires the componant a second time so that it switches back to False. Thats why a timer would make sense? (5.5 KB)
180825_GHPython_PersistentLastCurrentValueCheck_02.3dm (49.8 KB)

1 Like

If Octopus changes your variables, Millipede can give you identical results, and you want to save computation time by not running Flexhopper again?

And while Flexhopper is running everything downstream is frozen until it has converged or reached a certain amount of iterations?

I guess the volume and/ or num of vertices of the mesh will never be identical to the previouse iteration of Millipede. The comparison of the Volume Mesh(current) with the previouse Mesh was just an idea of how to detect an geometry change and therefor to trigger Flexhopper again.

No not yet. But you’re right that needs to be done as well. Otherwise Octopus would start a 2nd iteration after the 1st Flexhopper Iteration. But Anemone has the option “Output after the last”. So there needs to be 2nd “outer” Anemone Loop with Flexhopper. What do you think?

I guess what you need is some kind of Flexhopper Zombie Solver (Kangaroo style), would solve both issues at the same time :wink:

I am not so familiar with Flexhopper, but why not take the source code of the engine component and modify it in a way that it just runs straightforward a certain amount of iterations ? Would probably be the safest and also avoid the whole double anemone loop.

EDIT: That would actually be quite easy, if not for some reason some of the custom classes in Flexhopper were not public even though all their fields / properties / methods are

Hi Kaspar, think I missed your reply. You can explicitly expire the component a second time after setting the foo variable to True like so: (5.9 KB)

Which I believe should behave like you need it to. That said, I would agree with dsonntag that the overarching problem here in terms of pipeline logic/dynamics is that Flexhopper needs a “zombie” solve mode, that would enable one to more easily implement it within a search feedback loop with e.g. Octopus, Galapagos etc.

You might consider switching out Flexhopper for Kangaroo2 if possible.

1 Like

I tried to skin down the engine component and reduce it to its minimum, unfortunately the helper classes (in this case ConstraintSystem) are not public, so not accessible this way, so doesn’t work :frowning:
One way to work around that would to change that in the source code and compile it again, no idea though if that might create an issue somewhere. I added it anyways here, in case somebody wants to play around with that…

EDIT: I updated the file, there were some stupid logical errors in the beginning creating NullReferenceExceptions. I tested it the way I said (make the helper classes public, compile new .gha file), seems to work. Maybe get in touch with Ben from FlexHopper, maybe they want to include a Zombie Solver anyways at one point… (6.4 KB)

1 Like

@AndersDeleuran thank you, that’s the solution I was searching for!!!

I tryed Kangaroo2 first, but ran into the problem that the RigidBody Componant doesn`t accept meshes!

@dsonntag you`re right this would absolutely make sense to do. But I have to admit that I’m not that fluent in writing scripts like you guys seems to be! I will first try how far I get with the double Anemone Looping :wink:

1 Like

Hmm, as far as I recall it should. Perhaps you could upload a file and @DanielPiker might help troubleshoot it.

Edit: It should work:

If I recall correctly, when I updated the rigid body component to take meshes, I left the old version of the component in, but hidden, so old files would still open.

This means though that if you want to take an old example file and modify it to use meshes, you might need to just delete the rigid body component in the canvas and drag in a new one from the toolbar.

1 Like

end of the process


any solution for that?

Found this very helpful for my project, thank you!

1 Like

Hi @AndersDeleuran
I did the same thing you advised here, but I’m trying to make a python component that only output the value if it’s changed. I did the following but you can see from the 15 ms color that the pipe component is still running even the value wasn’t changed. The idea is to freeze the value without updating it to avoid running a script after which might take 10 secs for each loop.

GHissue (10.8 KB)

Actually. all of this to achieve auto reading from a Gsheet and link the values with another huge script that will crash my GH if it’s running all the time. (14.3 KB)

I’m not really sure what the script is supposed to be doing. But I can see that there are three GHPython components, all with persistent variables, and one with a timer. This is likely needlessly complex and would be better managed with one component. If you’re looking to stop iterating once a certain condition has been met, you can do something like this:

And if the condition to check occurs downstream from GHPython component doing the iteration, you can use the sticky to pass this information upstream.