COEF Overview

COEF ("Common Oblivion Engine Framework") is an API and utility library for OBSE plugins. It makes plugins simpler and faster to write and more likely to be compatible with other plugins.

COEF is not a mod itself, just a resource. It is not an OBSE plugin itself, and OBSE will not load it or even "see" it. Only plugins that use COEF will interact with it. It can be uninstalled at any time, if no plugins are installed that use it.

Engine API

The main feature of COEF is it's C++ API for Oblivion and the TES IV Construction Set. For those familiar with C++ programming, this is basically a set of header files that define the classes used by the engine. The API conforms to several guidelines:

Dynamic Linkage : Projects that use this API link directly to the Game/CS executable as if it were a dll. When a plugin calls an API method, it is directly calling the corresponding code in the Game/CS.

Definition Only : No function bodies, and nothing that does not exist in the Game/CS. Any new functionality that might be added is put in the Utility or Component libraries (see below).

Modularity : Classes are split into their own headers as much as possible, and cross dependencies are minimized. This is mostly a "good practice" thing, to promote encapsulation.

Readability : Class definitions have a consistent format, so they can be readily browsed. Member offsets are included as an aid for anyone looking at the engine disassembly.

Completeness : Class names, sizes, and inheritance hierarchies are reproduced exactly. The virtual method table is reconstructed to it's proper size, and as many member functions as possible are included. Among other things, this means that plugin authors can safely derive from the API classes, and use them with the dynamic_cast and typeid operators.

Most existing plugins use the class definitions included with OBSE to interact with the game & CS engines. This code was written for internal use and can be a bit hard to use in plugins. Also, it contains many additional functions that replace or reproduce things in the engine. Including such code in a plugin can lead to incompatibilities later on. The COEF API is meant as a clean, minimalist alternative.

NOTE: In cases where COEF and OBSE define the same class, the two definitions cannot be included together in a single file. Plugin authors must choose either the COEF definition or the OBSE definition. Because the OBSE code is not always modular (including one header may indirectly include many others), this makes it very difficult to use a combination of OBSE and COEF code in the same project. This is the main drawback of COEF, especially since there are still classes that haven't been added to the API yet (working on it!).

Utilities

In addition to the API, COEF offers a small utility library for plugin authors. This includes the core files from the OBSE "common" project (redistributed with permission), as well as additional classes for advanced output logging and writing patches/hooks. These are found in the Utilities/ directory. See the comments at the start of each header file for details and usage.

Component Library

Finally, COEF includes a growing set of "Components". Each Component is basically a mini-mod that patches the Game/CS to allow some kind of extended behavior. Examples include registering callbacks for in-game events, allowing for new form types, or custom records in esp files. These features are either too complex for most plugin authors to implement on their own, or would cause incompatibilities if implemented by multiple plugins. Each component is dormant and does absolutely nothing until it is activated by a plugin that wants to use it.

Components can be found on the Components/ directory. See the comments at the start of each header file for details and usage.