Sorry, that is not what I mean. What I mean is, this is not a Value List.
This is.
In my opinion changing the mode algorithmically is an advanced use case.
Prove of that is people is been using Human for years and they have to switch using the context menu.
To me adding more inputs is just adding more complexity for a regular use.
2 Likes
I indeed want to drive my scripts based on attributes and chain several attributes, objects and layers together in a multi-step procedure. I’ll check the example tomorrow on my PC, it’s a bit hard to tell on mobile.
Nothing to do with the algorithm, it it just more practical with value list as the menu is already exposed.
Often having both options (context and value list) is the best for everybody.
Also I don’t think it is coherent for the component to offer some possibilities in x state (no button connected) while not in y state. (with button connected).
Because all baking solutions whether you are talking about Elefront or Human have always had these, so it’s a kind of logic as well as syntax that I (and I would expect many others are used to/ familiar with). By having a True/ False input, you can easily follow where the baking condition comes from downstream in the script, because the Content Cache is one of the few milestone components in every script. It’s where all logic converges/ culminates.
If instead you use a gate for the name or content, the script is branching off at a non-milestone point and thus requires checking less visually obvious components - i.e. the structure becomes muddled.
What’s the hold-up for adding the True/ False input? That other components don’t have this? Kangaroo has True/ False for runs, which like Push/Pull/Bake can take some time to compute, hence the added True/False precaution to prevent Grasshopper from slowing down to a crawl or freezing. It’s easier to remember to save before hitting the True/False button than it is prior to connecting yet another wire.
The component will take the Action or True/False. Tue False will activate the default Button Action, which is set by right clicking on the component. (Push is the initial default.)
The old tooltip was confusing since a True/False could be interpret to do something different than the default action. If the icon reflects the default action in the new release and True triggers the action, that’d be perfect. However, this means you can not do the push>bake algorithmically, hence it’s best to have both inputs with the default action button (for the value list) hidden by default.
This post is coming from someone who hasn’t drank the R8 Kool-Aid or followed the discussions that rationalize an overloaded “Purge, Push, Bake, Pull” component instead of two intuitively obvious components that Bake (to layer) and Delete (by layer).
Is it really worth years of confusion over this issue? Years of explaining a counter-intuitive way to do these things that only a few think is cool 
I believe not.
This is 4.5 years old, open source Python by someone (me) wholly unqualified for the task. A project driven by desperation, warts and all, yet easier to understand than this R8 weirdness.
If you feed in the sting “Bake” or the string “Push” it will conduct that action. No need to use True/False.
So that first panel will, without any other input:
- Purging the first item (deleting and item, purging a block, purging a layer and then deleting all the objects on that layer as Rhino uses both terms)
- Push the second item
- Bake the third item
- Pull the 4th item (note: technically the others 3 also Pull)
Hi Scott, thank you. I think most here already understand how it works after 66 comments.
The discussion has shifted specifically into separating the True/False into another single input. Rather than have a single input take True, False, -1, 0, 1, 2.
Sure, I get that. I wanted to show how it currently works.
What I am wondering is whether both behaviours, the one you describe to algorithmically Push/Pull/Bake and the one I describe with usimg True and Falses could both be achieved with a slight redesign of the component (i.e. add an input and if the True/False input is exposed, the Content Cache behaves differently). Alternatively, I could see there be a ‘Dynamic Content Cache’ and an ‘Explicit Content Cache’ component to satisfy both use cases.
I want to send a message to the Rhino development team to not get discouraged by the users that just want a “Push button to bake” component, have not explored R8, and are piling on the Content cache hate wagon because it has the ability to do that. But they do not care about its many other uses, as they do not want to use a “Cache”. I currently have multiple scripts that use the push/pull workflows to enable adjustments from the user into mostly generated geometry, and it has been lovely.
It you wanted to go scorched earth (please don’t) you could just remove the Bake option from the Cache altogether.
From what little I know of R8, it’s the only way to bake geometry, eh?
I don’t like it because it’s difficult to explain and understand, which is poor UI.
The townsfolk uncomfortably go along with the pretense, not wanting to appear inept or stupid, until a child blurts out that the emperor is wearing nothing at all.
1 Like
I think this is a flawed argument. Rhino is a specialist software. Grasshopper is an even more specialised subset of tools in Rhino. People will spend weeks, months or years fully “getting” Grasshopper and it’s intricacies.
Now programmatically baking, pulling, pushing from/to Rhino is a further special use case. In my 10 years or so of using GH I have built around 5 or so very large scripts which contain some way of either getting stuff from Rhino or automatically baking.
I have used Human, Elefront, Heteroptera and either C# or Python components.
The ONLY reason I ever had problems with any of those ways was because there was some stupid default, a button on a component being the only way to trigger something or some other weirdness around baking to Rhino.
Not once did I think “wow, I wish this was more simplified, giving me less options”, but always the other way round. More options are almost always better. New users will learn them quickly if they are clearly labeled and make sense.
Coming up with these complicated defaults and methods just to save 1 input will cause the opposite. Now new users have to learn what this special kind of input means, what it means to have a button connected and what it means to have something else connected.
I admire your desire to keep things simple, but I fear in pursuit of this you are actually making it more difficult, because it is no longer intuitive.
In programming you would also not build a function where 1 parameter does 2 things depending on the datatype input. You would just have an integer for the method and a bool to trigger it.
Thanks for considering.
3 Likes
This the point, in Grasshopper in general there is no parameter that does nothing.
The component runs whenever the input values change.
The Action input is not special, it is not the one that triggers the component, all inputs cause this, so Action is not doing two things as you mention.
My point is that having a boolean input here is just a rare case to force triggering. It looks more like a hack that for some strange reason no other component needed before.
I understand your position, yet I think that if you need to wait seconds or minutes for a Push/Bake, it can be disruptive. Just the option to trigger the component through some sort of logic would be a net positive (and I’ll leave the discussion with that). I really like the potential of the Content Cache component, but for what I need (which I know from the Beta), a True/False trigger is quite important. 
E: Imo True/ False input should be added as a hidden input and none of the existing functionality should be taken away. If the True/False input is removed with the (-) button, the Action input would solely responsible for the component’s behaviour (as is now).
Whats the expected output of the component when false is provided?
Nulls??
If a component may be slow you can control it using Trigger component.
You can use it to temporary lock these conflictive components.
Nulls, unless there was a previous Push, then the data of the last Push should be output (like a data dam). This also applies to bakes and Pulls.
For a Purge, a true should be temporary (x ms) if a Purge was trigerred and then be false again.
So true does the action false does a pull?
What does temporary mean here?