Slaving multiple inputs to a single input

So I have a definition that is fed a number of inputs by udp at different rates (which I can't change) and I want the main body of calculations to only trigger when say Input A updates.

Data Dams update according to time intervals which doesn't work for me, tricks like misusing Longest List only work for a single input and multiple static variables, and from what I understand scripts will still update (triggering the rest of the definition) when any of its inputs update even if the outputs stay the same.

Any one have any crafty ideas/solutions?

Replies to This Discussion

Permalink Reply by David Rutten on August 4, 2016 at 5:27am

You'll have to do a fair bit of hacking because this goes directly against the core process Grasshopper operates by. There are two approaches I might consider fruitful:

Use Visual Studio to create a new GH_Component and specifically override the expiration behaviour of the component, so that the component itself and its downstream objects only expire when a certain input expires, but not when other inputs expire.
Put the other inputs into some dead-end object which may update all the time, and harvest the data inside that object whenever you need it. This means one object depends on another without a specific wire connection between them (could be confusing), and you may run into trouble when the data matching becomes difficult.

Permalink Reply by Daniel González Abalde on August 4, 2016 at 6:01am

Do not know if this will work, but it's an attempt.

Attachments:

TrySendData.gh, 10 KB

Permalink Reply by Vongsawat Wongkijjalerd on August 4, 2016 at 11:36pm

Seems to be working! :)
Added an input to Receiver to act as the trigger instead to suit my use-case.
With 'Send' set to always true, so long as nothing updates downstream of the receiver, this seems to work perfectly.
It doesn't seem to know how to deal with data trees but so long as it doesn't confuse the order of items that's easily worked around.

Just wondering, might be a stupid question, but Receiver can't fire off before Sender runs right? even if there were computationally heavy stuff in-between Output A and Sender or something?

Anyways, thanks for this either way :D

Attachments:

TrySendData2.gh, 13 KB

Permalink Reply by Vongsawat Wongkijjalerd on August 5, 2016 at 5:00am

Hm, this was working perfectly, except sometimes the Receiver breaks, refusing to properly output the values, deleting and replacing it seems to work so far though.

RSS