A metaplugin won't function unless all of its component plugins are available. There are two possible scenarios: the metaplugin can contain links to its components, or the plugins can be embedded within the metaplugin DLL. This topic deals with the first scenario, a linked metaplugin.
Since a link is an absolute path to a component DLL, links can break, e.g. if you move your plugins around, or rename folders. This is very likely to happen if you distribute a linked metaplugin, because the recipients probably won't have organized their hard drives in the same way as you.
When a linked metaplugin is loaded, it checks for broken links. If components aren't where they're supposed to be, the metaplugin searches for them, using a specific strategy. A linked metaplugin looks for its component plugins in the following places, in order:
Option #1 is the most efficient. Option #2 is useful with hosts that require all Freeframe plugins to reside in a specific folder. Regarding option #3, note that Application Data\FFRend\Plugins is also used for unpacking embedded plugins. The environment variable is discussed below.
Error handling
If one or more components aren't found in any of these places, the metaplugin disables itself. A disabled metaplugin has no effect on its input, and doesn't expose any parameters to the host. The metaplugin also writes an error message to a log file indicating which plugins are missing. The log file (Application Data\FFRend\MetaFFRend.log) is a text file, and can be viewed with Notepad or any text editor.
Broken links can be repaired by importing the metaplugin as a project. The import displays the missing files dialog, which allows you to search your hard drive for the missing plugins. If the plugins are found, you can save the repaired links by re-exporting the metaplugin.