AE:Plugins
Plugins are instance files that do not conform to the "level#_Final" naming convention. The "level ID" field at the beginning of every instance in a .dat file stores a hashed difference between "_Final" and the suffix of the plugin. Instance files can only be used by Oni under the name specified at the time of their creation.
The retail versions of Oni do not accept plugins as valid "level files", however, this has been fixed for all major versions of Oni as of May 2008. It is thus possible to generate (with OniSplit) and use (with patched Oni engines) a variety of plugins both for "level 0" and for "chapter" levels. Note, though, that just because a feature is new doesn't mean it's as revolutionary/user-friendly/recommendable as you'd like it to be. There's about the same amount of science to making and using plugins as there is to OBD and BSL.
Below is an overview of the basic functionality of plugins, and a few words of wisdom as for the philosophy.
Oni loads instance files in a certain order. On NTFS partitions of Windows and on Mac OS X that order will be ASCII-based (case-sensitive, "B" before "a", etc). On Windows 98 and such the order is more random and depends on dates of creation. As for what happens to the instances in the files being loaded, there is no such thing as "overriding" - more like the first instance registered with a certain name being the only one accessible by that name. Instances without raw parts typically follow the intuitive rule "plugin loaded first - instance registered first". For things like OBJC, the order is reversed, i.e., in order to "override" a level's OBJC you have make sure that the overriding plugin's name comes after level2_Final or whatever you're "overriding" (so, e.g., level2_OBJC). Finally, some instance types are stored dynamically in an array, so: 1) if you have, e.g., several instance files containing ONCCs, they will all end up in the "shapeshifter" array (first the ones from the first loaded instance file, ordered by name, then the ones from the second instance file, also ordered by name, etc); 2) If two of those instance file have an ONCC with the same name, both of them be loaded, at their respective places in the array: both will be accessible with F8 and by ID, but only the one loaded first will be accessible by name.
Now busting a few opinions about how plugins are much cooler than user-side use of OniSplit, shell scripts and delta patches. Of course the fact that you can "just" put the plugin in your GameDataFolder and play makes it look like it's user-friendlier than OniSplit and somehow "empowers dummies" to access modded content without the need for complicated installation routines, with or without a GUI. However, one thing plugins are definitely not is foolproof. They are not "just files" that you put into your GameDataFolder "and see what happens" (and then whine about crashes). They all have their compatibility issues, that imply thorough testing and public release notes. Both the modder and the user should be just as careful when working with plugins as when rebuilding "_Final" levels. One should also be careful not to expect too much from plugins in the big scheme of things.
To create a plugin version of the Edition, for example, is a naive wish. A key feature of the Edition is the "globalization" of virtually every character, sound and texture in Oni. Distributing such a plugin in ready-to-use form would amount to distributing a large part of Oni's content for free, which is very "legally challenged". Also, the download sizes would reach a few hundred megabytes. Last but not least, such a "global" plugin would be redundant of the un-globalized content in the end user's "chapter levels", so: 1) Oni will take up more space on the user's HDD; 2) Oni will load redundant instances simultaneously (thus, in every level, there would be a range of globalized ONCC from the plugin and then the ONCC originally present in that level), possibly resulting in overflow.
Another issue is that a modder has to provide both a "sep" and a "no-sep" version of every plugin if he wants users of all platforms to enjoy his stuff. Considering all of the above, plugins are not likely to be used on a systematic basis for anything but "100% new" content, and in the scope of projects like the Edition, they hardly make any sense at all, because OniSplit is irreplaceable when it comes to globalization.
One thing plugins are useful for is testing of new content during development. It takes OniSplit much faster to build a small plugin than a chapter level, let alone level0 with full globalization. Note, however, that while working with "hot" file buffers during a modding session, OniSplit can generate a 500-MB level0_Final.dat in about 30 seconds; rebuilding levels after a long break takes considerably longer.
The only thing you should be careful about when working with such plugins is dependencies. Typically your plugin will be all the smaller as it uses global content, but whoever you give that plugin to should be aware of the globalized resources involved. Otherwise you'll get pointless crash reports all the time just because you assumed people would only use your plugin in tandem with the Edition, etc.