The bug (scoped)
When D4 cross-library import brings in a condition that uses a plugin (e.g. camera) from a second YAML, the plugin is added to the target protocol with a filename prefix — e.g. P014_experiment__camera. That name is exported as the plugin_name, and at runtime it fails: plugin names in the experiment YAML must match the rig YAML's names (camera / backlight / temperature) to inherit the rig's config. A prefixed plugin gets none of the rig config and breaks.
Expected: an imported plugin that corresponds to a rig/built-in plugin keeps its canonical name (camera) on export — no prefix.
Why it happens: D4 only avoids prefixing when it can merge with a plugin the target protocol already declares (same class + config). In the scenario above the target has no camera yet, so there's nothing to merge with and import falls back to namespacing (<prefix>__camera).
Fix options
Note — post-v0.20
v0.20 added an in-tool "+ Add plugin…" dropdown, which resolves the original "I couldn't find a way to add the camera plugin" part of this report (you can now add camera directly with its canonical name). The remaining actionable bug is strictly the D4 import path still prefixing plugin names, described above.
Original report (Lisa)
I did a test where I imported a yaml file without the camera plugin or any camera commands. I wanted to then edit it to include the camera, but couldn't find a way to do that. So instead I clicked the "Import from Yaml" button because it said you can import conditions and plugins from other yamls.
I chose a second yaml with the camera plugin and added a condition from that yaml which uses the camera. This worked in that the camera plugin became available, along with that condition, in my original yaml. However, the camera plugin's name was P014_experiment__camera. It adds the yaml's filename to the front of "camera" as the name of the plugin.
That's fine on the editor itself, but it also imported a yaml with "P014_experiment__camera" as the plugin name, and this will cause the plugin to fail. Plugins are defined in the rig yaml as "camera," "backlight," and "temperature,". The rig file contains the configurations for them. When they are defined in the experiment yaml, the name needs to match what's in the rig file or else the experiment yaml won't get any of the config info stored in the rig file, and the plugin will fail. You could create a plugin called "P014_experiment__camera" in the experiment yaml but you'd need to include all the camera configuration stuff with it so it doesn't need anything from the rig file, which of course is not done by the editor. When exporting, at least, the editor needs to remove whatever it added to the front of an imported plugin name.
The bug (scoped)
When D4 cross-library import brings in a condition that uses a plugin (e.g.
camera) from a second YAML, the plugin is added to the target protocol with a filename prefix — e.g.P014_experiment__camera. That name is exported as theplugin_name, and at runtime it fails: plugin names in the experiment YAML must match the rig YAML's names (camera/backlight/temperature) to inherit the rig's config. A prefixed plugin gets none of the rig config and breaks.Expected: an imported plugin that corresponds to a rig/built-in plugin keeps its canonical name (
camera) on export — no prefix.Why it happens: D4 only avoids prefixing when it can merge with a plugin the target protocol already declares (same class + config). In the scenario above the target has no
camerayet, so there's nothing to merge with and import falls back to namespacing (<prefix>__camera).Fix options
camera/backlight/temperature) on import — treat them as canonical. No rig parsing required.Note — post-v0.20
v0.20 added an in-tool "+ Add plugin…" dropdown, which resolves the original "I couldn't find a way to add the camera plugin" part of this report (you can now add
cameradirectly with its canonical name). The remaining actionable bug is strictly the D4 import path still prefixing plugin names, described above.Original report (Lisa)
I did a test where I imported a yaml file without the camera plugin or any camera commands. I wanted to then edit it to include the camera, but couldn't find a way to do that. So instead I clicked the "Import from Yaml" button because it said you can import conditions and plugins from other yamls.
I chose a second yaml with the camera plugin and added a condition from that yaml which uses the camera. This worked in that the camera plugin became available, along with that condition, in my original yaml. However, the camera plugin's name was P014_experiment__camera. It adds the yaml's filename to the front of "camera" as the name of the plugin.
That's fine on the editor itself, but it also imported a yaml with "P014_experiment__camera" as the plugin name, and this will cause the plugin to fail. Plugins are defined in the rig yaml as "camera," "backlight," and "temperature,". The rig file contains the configurations for them. When they are defined in the experiment yaml, the name needs to match what's in the rig file or else the experiment yaml won't get any of the config info stored in the rig file, and the plugin will fail. You could create a plugin called "P014_experiment__camera" in the experiment yaml but you'd need to include all the camera configuration stuff with it so it doesn't need anything from the rig file, which of course is not done by the editor. When exporting, at least, the editor needs to remove whatever it added to the front of an imported plugin name.