|
|
|
@ -1,8 +1,8 @@
|
|
|
|
|
\section{Files and Directories}
|
|
|
|
|
\subsection{Introduction}
|
|
|
|
|
This section of the manual describes the directories and file types used by OpenCS. A file is a resource for storing data, identified by its
|
|
|
|
|
filename extension (e.g. .exe, .jpg, .txt), whereas a directory is a folder or file system structure in which these files are stored. You
|
|
|
|
|
are most likely already familiar with these concepts.
|
|
|
|
|
This section of the manual describes the directories and file types used by OpenCS. A file is a resource for storing data (e.g. .exe, .jpg, .txt),
|
|
|
|
|
whereas a directory is a folder or file system structure which points to these files (or other directories). You are most likely already familiar
|
|
|
|
|
with these concepts.
|
|
|
|
|
|
|
|
|
|
\subsection{Used terms} %TODO
|
|
|
|
|
|
|
|
|
@ -15,7 +15,7 @@ files and several other folders. The location of the user directory is hard code
|
|
|
|
|
%TODO list paths.
|
|
|
|
|
In addition to the user directory, both \OMW{} and \OCS{} need a place to store the game’s actual data files: for example, the
|
|
|
|
|
textures, models, sounds and records of in-game objects. We support multiple paths to these files (termed \textbf{data paths}),
|
|
|
|
|
as specified in the configuration. Usually, one data path points to the directory where \MW{} is installed, however, you are
|
|
|
|
|
as specified in the configuration. Usually, one data path points to the directory where \MW{} is installed; however, you are
|
|
|
|
|
free to specify as many data paths as you would like. In addition, one particular data path, as described below, is used to store
|
|
|
|
|
newly created content files.
|
|
|
|
|
|
|
|
|
@ -23,7 +23,7 @@ newly created content files.
|
|
|
|
|
\BS{} \MW{} engine uses two file types: ESM (master) and ESP (plugin). The distinction between the two is often confusing.
|
|
|
|
|
You would expect that the ESM (master) file is used to specify a single master which is modified by the ESP files (plugins), and indeed:
|
|
|
|
|
this is the basic idea. However, the original expansions are also ESM files, even though they can be described as very large plugins.
|
|
|
|
|
There were technical reasons behind this decision -- somewhat valid in the case of the original engine, but a more logical file system is
|
|
|
|
|
There were technical reasons behind this decision -- somewhat valid in the case of the original engine -- but a more logical file system is
|
|
|
|
|
much preferable. \OMW{} achieves this through the creation of our own types of content file.
|
|
|
|
|
|
|
|
|
|
We support both ESM and ESP files, but, in order to make use of \OMW{}'s new features, one should consider using new file types designed
|
|
|
|
@ -42,9 +42,9 @@ Furthermore, our content files’ extensions are .omwaddon for addon files and .
|
|
|
|
|
\subparagraph{\MW{} content files}
|
|
|
|
|
Using our content files is the recommended solution for projects that employ the \OMW{} engine. However, some players will wish to use
|
|
|
|
|
the original \MW{} engine, despite its large flaws and lacking features\footnote{If this is wrong, we are a very successful project. Yay!}.
|
|
|
|
|
In addition, since 2002 thousands of ESP/ESM files have been created, some with truly outstanding content. Because of this, \OCS{} is
|
|
|
|
|
committed to supporting ESP/ESM files. If you do decide to use ESP/ESM files rather than our own content files, you are most likely aiming
|
|
|
|
|
for original engine compatibility. This subject is covered in the very last section of the manual.
|
|
|
|
|
In addition, since 2002, thousands of ESP/ESM files have been created, some with truly outstanding content. Because of this, \OCS{}
|
|
|
|
|
will support ESP/ESM files, although this will impose limitations on the user. If you do decide to use ESP/ESM files rather than our own content
|
|
|
|
|
files, you are most likely aiming for original engine compatibility. This subject is covered in the very last section of the manual.
|
|
|
|
|
%not finished TODO add the said section. Most likely when more features are present.
|
|
|
|
|
|
|
|
|
|
The actual creation of new files is described in the next chapter. Here we are going to focus only on the essential information needed
|
|
|
|
|