Component Placeholders Still Missing

We’ve been there before, but it is a very big problem when opening GH definitions and find “holes” in the definition due to missing - or the actual problem - unknown missing components, when a plugin is missing or a component is no longer compatible.

Since there is some info about the components in the .gh/.ghx file, a placeholder should be put in place, even a panel with all available info dumped into it, or a dummy component with the connections preserved. One idea for this would be to attach a C# ScriptComponent and autogenerate Params and connect them, + inject a silly error message yelling at the world about its soul being lost.

Or something. Whatever we can or cannot, we cannot have “holes” in the definitions. Especially bad now when in a transition period going from R5 to R6. Mistakes are made way too easy. If saving such a file then… its broken and irrecoverable definitions lost (especially if its a def by someone else and you don’t have a clue what was there, or how)

A placeholder should be introduced asap. Critical.
// Rolf


Even with placeholders, it will still be broken, the only feature you gain is that you are now able to save the file on a version which cannot run it, and still read it back in a version that does. Do you want people modifying files that they cannot run or test?

I’d much rather invest effort into getting Yak populated with more plug-ins, so that the auto-install doesn’t fail 9 out of 10 times. @will is there a time-frame within which we expect the most common plug-ins to be available through Yak?

I’m not disagreeing that it wouldn’t be nice to have ghosted components where the missing ones are supposed to be, but I do think it’s somewhat lipstick-on-pig. It would also require some pretty hefty redesigns of the core code and I’m worried about introducing serious bugs or behavioural changes at this point in the release cycle.

Yes. Another important reason for this is when “trivial” components are missing from a plugin which easily could be replaced with (one or more) std components and so make it independent of a plugin.

I’m all in also for the Yak approach. These two apporaches should not be mutually exclusive.

However, third party plugins are not always what you want when making solutions that needs to be “future proof”. Yak may be OK as a temp fix, but extra plugins tends to be “silently contaminating” definitions and so they may pass unnoticed.

In any case, a new test command “ShowContainingPlugins” for current definition would be gold (highlighting the components, or an option to navigate to them). A way to ensure “clean” definitions when need be.

// Rolf

Wow, ok, I wouldn’t want people changing my code blind, but to each his own.

How do you know whether a component that is missing was trivial and what component might replace it?

I do think that some type of placeholder would be nice. Maybe an empty group on the canvas with the name of the plugin/component?

While certainly not a perfect solution, this was an idea I had for users to, at least, have the ability to “save” the plugin/component information that they used. Well, not really save, but at least give a list of which ones were used in the definition and write it to a panel.

This is why I suggested to inject all available info about a (missing) component into the placeholder. As a textfile or as a message in a ScriptComponent (as the placeholder, which provides with quite some fancy possibilities, out of the box so to speak), or whatever.

It is then up to the user to find out what needs to be fixed, if (s)he thinks (s)he can manually replace it, or if simply accepting Yak to replace the thing.

By user’s painful research (no way around that…) based on the info in the placeholder (like, component name, plugin name, and reading up on its description or other info etc).

It is then the user’s choice whether to try to replace the thing, to drop the attempt to open/run the definition altogether, or as a last resort, let Yak install the missing plugin.

// Rolf

Let me give you an example you might have missed here, David:
I have some old files lying aroung with Kangaroo components – sadly, they will report as missing, since Kangaroo2 is new and there is no auto-replacement (which is mostly a good thing at least with the standard comps, since you don’t want to break things. But the default comps also have a backup. Kangaroo 1 has not).
Well, you can still open this file, but it’s now garbage. Utterly useless.
I know that I could replace those missing pieces. But I don’t know which one belongs where. Which parameters went in there?

You’ll see, having no placeholders will be a pain in the arse suddenly. It is no “lipstick on a pig” at all, it should be a plain basic feature. Why? Because the user expects this behaviour.
I really can’t stress this enough.

True, it is very useful info enabling the user to do something about broken definitions (for eample, repair it, if only there’s info in there telling what to replace, and how to reconstruct connections). As it stands now, you can’t do enything about a broken definition, because the only tbing you know is that it is broken, not where and how. No choice, since the only option you have is to accept being defeated, cry and move on with your life. :slight_smile:

Info-placeholders isn’t cosmetics, instead it’s the one and only thing that gives you the option to fix things being broken. :wink:

// Rolf

Hey, thought I would poke this thread. We just introduced Placeholders in the Rhino WIP.
To give them a test, try the WIP: