Trigger Block Unstoppable Loop

[Joseph_Oster]

@themarcosutra

A fix would be to limit the solver to when inputs have changed. The timer on the trigger seems to trigger the solver regardless of whether the input data has changed. Quite a simple fix since that is how the GH normally works so it would be disheartening if the devs ignore it.

Good suggestion. But consider that the same flaw has existed for years in Data Dam (right?) without being fixed.

Do Trigger blocks also share the same ‘leak-at-starup’ defect as Data Dam, where the downstream code is executed once when the file is opened, regardless of the ‘Never’ (manual trigger only) setting?

Data dam toggle/trigger

Yes, it would be nice to have a ‘trigger’ input for Data Dam. But I don’t agree that either of the proposals in the thread you refer to are a solution. The one in testDataDam.gh using VB Script appears to trigger all data dams? The one using Metahopper appears to be more selective using its “Get objects in group” feature but it’s a little obscure. The connection is only “explicit” in the sense that Data Dam and ObjFromGroup (and only those two components?) must be in the same group, a condit…

And there is serious flaw with Data Dams, mentioned a few days ago by @ivelin.peychev in another thread: they leak and pass data once when a GH file is opened! Very bad.

Going large: advice/resources for optimising

Hi @jeremy5, There is one thing you need to take note when using data dams. Even if they are set to Never they are calculated when you open (re-open) a gh definition. This leads to a long wait (depending on the definition). Along with data dams I use a python script with a Togglethat my wire goes through before entering the data dam. This script sets the output of my ghpython, respectively the input of the datadam to Null. I turn this off when saving the gh file. I use this wherever I have a…