Cold you please elaborate this a bit more.
What is the goal? and how would you like to connect this component to a button?
In this case, why would you need a gate?
It will not push until the component sees a True.
Hi @kike,
Right now, if you use the value list method to set the action for the content cache, there is no way to control that you want to bake the objects you feed into the content cache.
In this trivial example, I may not want to bake the circle if the radius exceeds 50.
Or actually, I want to make sure that I only bake objects that I deem fit. Say I add some values in user text or some other parameters, all objects (each intermediate stage) is baked this way, unless I manually specify it to bake like this:
This safeguards me from baking 100s of circles when I, for example change this slider around.
The same applies to pushing, pulling or purging data.
The point is that I want to set the default mode (push/ pull/ bake/ purge) with the value list AND have a true/ false input which I use to set the bake condition, so I can trigger the Content Cache whenever a certain set of conditions is met.
Also, could the Content Cachevs icon reflect the Push/ Pull/ Bake/ Purge state when the value list is attached? In my examples, you’ll still see the egg crate icon.
This is done on latest RC.
1 Like
Thanks!
But why should we be managing the incoming values for the content cache with gates and or filters when there could be a True/False input? All baking pligins since Elefront and Human have been using this convention, where a True activates a component. The Content Cache is inconsistent with this established convention and adding gates makes a definition more convoluted to read.
2 Likes
I don’t quite understand this but please remember that not everyone uses icons.
For good reason 
There is no other component in Grasshopper that needs an extra input to trigger it.
Why is this one different in your opinion?
Is it? Then how/for what is the Button component used in Grasshopper?
I don’t think it is different, multiple GH components make use of the Button component to activate things.
Kangaroo makes extensive use of this too.
You can still activate it with Right-Click > Bake, as all other GH components.
This one just happens to have the option to be actionable with a button, which is faster and more comfortable than Right-Clicking all the time.
I was thinking on a Grasshopper built-in component.
To be more specific, on components that expose an input that has no other effect than triggering the component, but don’t care about the actual value of it.
‘RemeshByColour’ resets it’s internal value, so it has an effect on the other side.
In my opinion every input should be meaningful, else we can add this extra input to every component. It may be potentially useful on every single component.
But if the user wants to trigger based on a condition has to use its own logic before.
I don’t follow but maybe it helps you to think about it this way:
Ultimately the goal of GH is to bake geometry to Rhino. Content Cache is just as a gate acting between the Rhino document and GH.
Also continuing with the railroad analogy, if a grasshopper definition is a railroad, the components are the modular segments of the road, it makes sense that the last one is different, because it is the end of the road. 
I don’t see Content Cache as the end of the road.
You can keep doing with the Result.
Even considered end of the road as it may be ‘Custom Preview’, I don’t think "end of the road component perse should have an “Activate!!” input.
Because Grasshopper already provides a way to do that.
2 Likes
Of course Custom Preview should not have an active input.
- Custom Preview component is not baking anything. A boolean toggle is not a button. Bad example.
- If you don’t want it to display you just Right-Click turn preview off or disable it.
- You don’t need to touch it as often as a baking component. Not to mention you can control the preview of all components in GH, I rarely even use Custom Preview.
Content Cache component is used for a fundamentally different task in a fundamentally different context which involves different frequencies of use or needs.
- You are baking to the active Rhino document and deciding a moment in time to do so. Hence the need for an input to be activated at a specific time.
- Righ-Click to bake is slow and uncomfortable specially if you bake periodically. Additionally sometimes you want to bake multiple things at the same time with a single button. You don’t have this need with Custom Preview
- Most user most likely will interact with Content Cache baking things than with the Custom Preview.
Then how is RemeshByColour different? Content Cache also has an effect on the other side if used as you showed with Push option.
In any case, you turned a simple bake component into a frankenstein swiss army knife. named it “Content Cache” so no one could find it and made it perform all kinds of functions with multiple options of inputs into a same input (true false, -1 0, 1, 2) that no one understands how to use.
But yet you are talking about coherence with native GH components.
For reference, Offset Component converts True False into a 0 or 1.
You might want to revise that to… how can you sleep knowing it behaves differently!?
I really don’t understand your logic. The Content Cache already accepts a Button as an input… which bakes when it is pressed. All I am saying is to separate the function into another input to not have a single input manage ‘type’ and ‘activation’ simultaneously.
This will also enable the user to keep changing the function type with a value list while activating with a button.
Right now if you connect a button you are forced out of the option to change function type with value list.
I am sorry if this breaks your stupid coding dreams.
This is about ease of user not nonsensical made-up puristic coding rules of apparent coherence.
Not everything is perfectly coherent in developing terms in Grasshopper and @DavidRutten has mentioned many things that are not along the years. Not even in Rhino not even in any software in general.
Code for your clients and the people who use the software, not for yourself.
You think someone will lay out all GH native components into the canvas an evaluate the inconsistencies or differences between all of them?
They will look and say: This component alone expose an input that has no other effect than triggering the component, but don’t care about the actual value of it. 
Spolier: NO ONE CARES.
1 Like
I don’t see the value list component in your screenshot. 
V8.11 will be available tomorrow probably.
Please test it, this way we can keep talking about the same.
1 Like