@ShynnSup Bake will create a new copy each time it’s fired, Push will update the existing object
Hi,
On my side, I am getting a new bake each time I press the button, with no replacement.
Button gives value ‘1’ when pressed. According to this ‘1’ should ‘push’ aka replace.
test.gh (11.6 KB)
Your Content Cache component is not up to date. You will have to install a newer service release…
The component with the egg is not the latest one. Try to replace it with a new Cache Content component… You should see an Egg crate.
The latest component mutates depending on the input. You can do this manually by removing inputs or when you input a button it mutates automatically into a fried egg into whatever you used before? Seems confusing.
What is wrong about it is that whatever function you define before connecting a button is the one that the button will be performing. And you can’t change it anymore unless you create a new component or disconnect the button.
Right-click shows no options to change the baking method.
While if you disconnect the button you get the options back.
The reason the options disappear when you have a control connected to the input is because the component is using the Volatile Data coming from the input as the data it will use in the component. By removing the source input, the options become visible again and you can set them manually, which is basically setting the Persistent Data on this input. Volatile Data will always supersede Persistent Data (if that make sense). The options are hidden because it doesn’t really matter what you set as Persistent Data whenever you have an input source connected because the input will always override whatever you set manually. Does this make sense?
What does not make sense is that when you first connect the button you don’t know which function you are going to get (pull, bake, push, purge). It seems it is based on the last used? Which is strange.
Further it does not make sense that you cannot change this function unless you first disconnect the button.
This is not the case. Manually changing the function of the component say Purge vs Bake, changes the behavior of what the button press does.
These four behave differently despite having a button connected to them.
Hi @ShynnSup,
We did some changes in this area on v8.11.
Now you can set the Default Action while the button is connected.
But remains grayed out when feed with a specific value.
We have also added a quick picker to internalize the Action.
Awesome!
Makes sense.
Correct, but, In programming, true
is often equivalent to 1
, and false
is equivalent to 0
.
In fact is says so in the help.
As the Action (A) input takes only integers as input (-1, 0, 1, 2) I thought the button would activate Action 1 (Push) when True.
IMO, I think the button should not be connected to Action. These are two different inputs.
There should be a different input that is a simple boolean to activate the component.
Well, the issue is not only 1
is equivalent to True
.
All numbers are true but 0
.
In order to support this setup the ‘Default Action’ is taken when a True
is provided.
Here the component Bakes because is its default action.
Please have in mind that the Action may be different for each piece of content.
If your intention is to have a kind of lock on this component with this last suggested input, I would use Trigger like this.
The tooltip shows same information as help, and here if the component default action is Bake it shows it as well.
Not sure where you are going with this. That is not a problem. You are inputting integers. Not booleans. It is like the Help menu I showed before that says:
Null → Nothing
False/0 → Pull Content
True/1 → Default Action (Push)
-1 → Purge
2 → Bake
If you would input ‘2’ it will not get converted to ‘True’.
On the other hand if you input ‘True’ it will get converted to ‘Default Action (Push)’ (as the help says).
The tooltip is misleading as proven here:
‘True’ can actually perform all actions shown here. Not just Default Action (Bake).
I am not trying to do this, no.
I appreciate the fixes you mentioned in your first post. Those are great.
All I am trying to say is that, still, for the average user, and what he is used to (elefront, human, etc) the way the ‘Content Cache’ component is set up is pretty obfuscated.
Ideally you would want to separate the Trigger from the Action selection. That is all.
It is strange that you ‘Activate/Trigger’ the component with the same input that you select the action.
Specially given the very likely confusion given the juxtaposition of True False with 1 and 0.
The Tooltip and the help is dynamic if you show the Tooltip on each of these components you have it will show the correct information on each component.
The help says:
Supported values:
• Null → Nothing
• False → Pull content from the model
• True → Default Action (XXXXX)
• -1 → Purge content from the model
• 0 → Pull content from the model
• 1 → Push content into the model
• 2 → Bake content into the model
Connect a 'Value List' to have a more friendly picker.
Where XXXXX is the current Default Action in this component.
Maybe should read as
• True → Current Default Action (XXXXX)
Or if this is confusing just this?
• True → Current Default Action
Ah I see this. That is good. I had not noticed this before. It is a tiny detail that goes unnoticed.
Yes agree that adding ‘current’ might be better.
I would leave the clarification in brackets clarifying which the current default action is.
Compared to Human is not that different.
I renamed ‘Bake?’ to ‘Action’ here but the concept is the same.
True
may mean:
- Bake
- Delete and Bake. (Similar to Push but does not keep the ids).
Without the ability to switch mode programmatically (based on an input)
Using ‘Content Cache’ True
may mean also several things and is controlled by the Default Action in the context menu as well.
Compared to Elefront is a bit different but not that much.
The presence or not of BakeName controls the mode.
All three components are activated by the “Action” input or any other input of the component.
With the difference that you can provide several actions if you like to ‘Content Cache’ and it honors it.
I had meant to comment on this very topic before it showed up in this thread.
It is true that it is confusing that a “true”/“false” value provided to the Action input of the Content Cache component results in an action dependent on what the default action of the Content Cache component is. It is not immediately apparent that this relationship is dynamic and it was worse when changing the default action was not immediately accessible from the context menu when the action input was exposed.
Once you understand it, the way it functions makes sense. But I still don’t like it. This because there is an established implicit translation of boolean values to integers and vice-versa and no other component in Grasshopper other than the Content Cache component chooses to distinguish a difference in a value based on its type. It is also why people who a familiar with “true”->1 for an input that expects integers will, as Shynn did, get confused at first with the Content Cache component.
In a way, I have to ask, why is there even a default action? This is meant sincerely. I see alot of times examples of the Content Cache component being used with the action input exposed and toggle attached. Who is going to be using the Content Cache component this way?!? Isn’t that the entire point of the integrated toggle when the action input is collapsed? But this has to do with a larger discussion of how the Content Cache component is set up with collapsable input and outputs that I should maybe save for later.
No numbers any more on the UI to avoid this confusion with the True
.
Conversion from number will remain for backwards compatibility.
So how do you control an action with true/ false then? The only thing I can think of is use a gate to prevent the content input from feeding into the component, doesn’t there need to be a True/ False input to hook up to a button?