We released earlier this week a new Rhino WIP version that implements Placeholders in Grasshopper for unknown components missing dependencies in Grasshopper definitions.
Download Rhino WIP (Work-In-Progress) for Windows…
The placeholder will keep the component placement and the connections for the definition. So, if later the correct dependencies are found it will stay connected.
This is a work in progress, please give it a try.
Is there any information about how to work with placeholders?
I have some in an early RiR WIP file; as might be anticipated, the components were replaced during development and I now have placeholders (which I could work around).
My trouble is that the placeholders cannot be selected, move nor deleted… they seem to be permanent, ha!
Interesting problem. I will need to report that and see if there is a tool we could provide to solve this?
That is correct, since it is not known what the object is, it is not known how it would react to being moved or selected. A good guess could be made, but it is also possible that by setting certain values directly the object becomes invalid, which would defeat the purpose.
The object could probably be deleted without issue, sadly the Grasshopper UI can only delete selected objects, so because not A therefore not B…
Great idea!
My I suggest making it a bit more distinctive visually? I would go for black, just to make it easier to spot in large defs.
Could you say ‘if invalid then ____’ ?
In this way it could become an object that can be selected.
The placeholder are more like a tear in the canvas right now… wire connections can be isolated using relays but somehow the placeholder remains linked to a group and can be copy/pasted into a new definition.
Sadly no, validity is defined by the code of said object, and since that object is not loaded by definition, nothing is really known for certain.
Like I said, I can make a guess as to what the object is really about, which is going to be correct 99.9% of the time, but the whole point of a placeholder is to keep an unknown object intact through an open-save cycle, and that just precludes modifying its data in a top-down fashion.
Deleting is technically possible and should be available as an option, but modifying an object behind its back is just asking for problems.
What if each plugin will specify this for each component:
if it can be safely moved or not.
And this info would be also saved for each placed component in definition, so when opening it later with plugin unavaible - it will read this data and allow or not moving it.
And similar thing for object name, aka cache it in .gh file during saving.
I mean, i guess most components can be just moved around without corrupting anything?
Is a bit late to start putting additional restrictions and demands on grasshopper 1.0 plugins…
Absolutely. But what good is a data retention feature if it’s unreliable?
Yes, so I guess for Gh2
… Maybe I just didn’t understood this well, sorry. I mean why it would be unreliable.
Each object in a grasshopper document is responsible for writing itself to a file and restoring its state by reading from the file. When I run into an object which is not currently loaded, the code which is needed to perform these two actions is missing. So what I do now is just remember that part of the file which I couldn’t read and write it back into the new file upon save.
I do try (and almost always manage to) find the bounds of the unknown object in canvas coordinates, as well as sources for parameters. If this part were to fail, it just wouldn’t draw the placeholder in the correct location, or perhaps there’d be missing wires.
In order to set the location of an object if have to actually change the blob of bytes which is supposed to get written back into the next file. If that fails, the object might no longer know how to deserialize itself.
I have some of those zombie components from tests I did with a plugin I got rid of.
But now, I can’t delete the zombies, and GH keeps pestering me about missing plugins.
So what’s the deal ? Re-install plugin, delete components, re-delete plugin ?
This is sub-optimal…
Thanks ! This allowed me to kick those zombie asses out of my definition !
