Another part of reformatting and clean up.

Signed-off-by: Lukasz Gromanowski <lgromanowski@gmail.com>
actorid
Lukasz Gromanowski 11 years ago
parent 2e5e9e0c44
commit 3b64de7441

@ -1,53 +1,53 @@
\section{Files and Directories}
\subsection{Introduction}
This section of the manual covers usage of files and directories by the OpenCS. Files and directories are file system concepts,
and you are probably already familiar with it. We won't try to explain this concepts, we will just focus on Open{CS}.
and you are probably already familiar with it. We won't try to explain this concepts, we will just focus on \OCS.
\subsection{Used terms} %TODO
\subsection{Basics}
\paragraph{Directories}
Open{MW} and Open{CS} uses multiple directories on file systems. First of, there is a \textbf{user directory} that holds configuration
OpenMW and \OCS{} uses multiple directories on file systems. First of, there is a \textbf{user directory} that holds configuration
files and few different folders. The location of the user directory is hard coded for each supported operating system.
%TODO list paths.
In addition to this single hard coded directory, both Open{MW} and Open{CS} need a place to seek for actual data files of the game:
In addition to this single hard coded directory, both \OMW{} and \OCS{} need a~place to seek for actual data files of the game:
textures, models, sounds and files that store records of objects in game; dialogues and so one -- so called content files. We support
multiple such paths (We call it \textbf{data paths}) as specified in the configuration. Usually one data path points to the directory
where original Morrowind\texttrademark is either installed or unpacked. You are free to specify as many data paths as you would like,
multiple such paths (we call it \textbf{data paths}) as specified in the configuration. Usually one data path points to the directory
where original \MW{} is either installed or unpacked. You are free to specify as many data paths as you would like,
however, there is one special data path that, as described later, is used to store newly created content files.
\paragraph{Content files}
\BS \MW engine is using two types of files: ESM (master) and ESP (plugin). The distinction between those
\BS{} \MW{} engine is using two types of files: ESM (master) and ESP (plugin). The distinction between those
is not clear, and often confusing. You would expect the ESM (master) file is used to specify one master, that is modified by the ESPs plugins,
and indeed: this is the basic idea. However, original expansions also were made as ESM files, even though they essentially could be
described as a really large plugins, and therefore rather use ESP files. There were technical reasons behind this decision -- somewhat valid
in the case of original engine, but clearly it's better to create a system that can be used is more sensible way. Open{MW} achieves
in the case of original engine, but clearly it's better to create a system that can be used is more sensible way. \OMW{} achieves
his with our own content file types.
We support both ESM and ESP files, but in order to make use of new features of OpenMW one should consider using new file types designed
with our engine in mind: game files and addon files together called ``content files``.
\subparagraph{Open{MW} content files}
\subparagraph{OpenMW content files}
Game and Addon files are concept somewhat similar to the old ESM/ESP, only in the way it should be from the very beginning. Nothing easier
to describe. If you want to make new game using Open{MW} as engine (so called ``total conversion'') you should create a game file.
to describe. If you want to make new game using \OMW{} as engine (so called ``total conversion'') you should create a game file.
If you want to create a addon for existing game file -- simply create addon file. Nothing else matters: The only distinction you should
consider is if your project is about changing other game, or creating a new one. Simple as that.
Other simple thing about content files are extensions. We are using .omwaddon for addon files and .omwgame for game files.
%TODO describe what content files contains. and what not.
\subparagraph{\MW content files}
Using our content files is recommended solution for projects that are intended to used with Open{MW} engine. However some players
wish to use original Morrowind engine, even with it large flaws and lacking features\footnote{If this is actually wrong, We are very
\subparagraph{\MW{} content files}
Using our content files is recommended solution for projects that are intended to used with \OMW{} engine. However some players
wish to use original Morrowind engine, even with it large flaws and lacking features\footnote{If this is actually wrong, we are very
successful project. Yay!}. Also, since 2002 thousands of ESP/ESM files were created, some with really outstanding content.
Because of this Open{CS} simply has no other choice but support ESP/ESM files. However, if you decided to choose ESP/ESM file instead
Because of this \OCS{} simply has no other choice but support ESP/ESM files. However, if you decided to choose ESP/ESM file instead
using our own content file types you are most likely aim at the original engine compatibility. This subject is covered in the very
last section of this 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 gonna focus only on details that you need to know
in order to create your first Open{CS} file while full understanding your needs. For now let's jut remember that content files
in order to create your first \OCS{} file while full understanding your needs. For now let's jut remember that content files
are created inside the user directory, in the the \textbf{data} subfolder (that is the one special data directory mentioned earlier).
\subparagraph{Dependencies}
@ -65,7 +65,7 @@ for addon files -- it can not depend on addon files.
%\subparagraph{Loading order} %TODO
\paragraph{Project files}
Project files act as containers for data not used by the Open{MW} game engine itself, but still useful for OpenCS. The shining example
Project files act as containers for data not used by the \OMW{} game engine itself, but still useful for OpenCS. The shining example
of this data category are without doubt record filters (described in the later section of the manual you are reading currently).
As a mod author you probably do not need and/or want to distribute project files at all, they are meant to be used only by you.
@ -76,12 +76,12 @@ with appended extensions. For instance swords.omwaddon file is associated with s
%TODO where are they stored.
Project files are stored inside the user directory, in the \textbf{projects} subfolder. This is the path location for both freshly
created project files, and a place where Open{CS} looks for already existing files.
created project files, and a place where \OCS{} looks for already existing files.
\paragraph{Resources files}
%textures, sounds, whatever
Unless we are talking about the fully text based game, like Zork or Rogue, you are expecting that a video game is using some media files:
models with textures, pictures acting as icons, sounds and everything else. Since content files, no matter if it is ESP, ESM or new Open{MW}
models with textures, pictures acting as icons, sounds and everything else. Since content files, no matter if it is ESP, ESM or new \OMW{}
file type do not contain any of those, it is clear that they have to be deliver with a different file. It is also clear that this,
let's call it ``resources file``, have to be supported by the engine. Without code handling those files, it is nothing more than
a mathematical abstraction -- something, that lacks meaning for human beings\footnote{Unless we call programmers a human beings.}.
@ -89,7 +89,7 @@ Therefore this section must cover ways to add resources files to your content fi
to do just that. Later, you will learn how to make use of those files in your content.
\subparagraph{Audio}
Open{MW} is using {FF}mpeg for audio playback, and so we support every audio type that is supported by this library. This makes a huge list.
OpenMW is using {FFmpeg} for audio playback, and so we support every audio type that is supported by this library. This makes a huge list.
Below is only small portion of supported file types.
\begin{description}
@ -102,16 +102,16 @@ As in the case of audio files, we are using {FFmepg} to decode video files. The
only the most significant.
\begin{description}
\item bik videos used by original Morrowind game.
\item bik videos used by original \MW{} game.
\item mp4 multimedia container which use more advanced codecs (MPEG-4 Parts 2,3,10) with a better audio and video compression rate,
but also requiring more {CPU} intensive decoding -- this makes it probably less suited for video games.
\item webm is a new, shiny and open source video format with excellent compression. It needs quite a lot of processing power to be decoded,
but since game logic is not running during cut scenes we can recommended it for use with Open{MW}.
but since game logic is not running during cut scenes we can recommended it for use with \OMW.
\item ogv alternative, open source container using theora codec for video and vorbis for audio.
\end{description}
\subparagraph{Textures and images}
Original \MW game uses DDS and TGA files for all kind of two dimensional images and textures alike. In addition, engine supported BMP
Original \MW{} game uses DDS and TGA files for all kind of two dimensional images and textures alike. In addition, engine supported BMP
files for some reason (BMP is a terrible format for a video game). We also support extended set of image files -- including JPEG and PNG.
JPEG and PNG files can be useful in some cases, for instance JPEG file is a valid option for skybox texture and PNG can useful for masks.
However please, keep in mind that JPEG can grow into large sizes quickly and are not the best option with DirectX rendering backend.

@ -1,16 +1,16 @@
\section{Record filters}
d\section{Record filters}
\subsection{Introduction}
Filters are the key element of OpenCS use cases by allowing rapid and easy access to the searched records presented in all tables.
Filters are the key element of \OCS{} use cases by allowing rapid and easy access to the searched records presented in all tables.
Therefore: in order to use this application fully effective you should make sure that all concepts and instructions written in
the this section of the manual are perfectly clear to you.
Don't be afraid though, filters are fairly intuitive and easy to use.
Do not be afraid though, filters are fairly intuitive and easy to use.
\subsubsection{Used Terms}
\begin{description}
\item[Filter] is generally speaking a tool able to ``Filter'' (that is: select some elements, while discarding others) according
to the some criteria. In case of OpenCS: records are being filtered according to the criteria of user choice. Criteria are written
to the some criteria. In case of \OCS: records are being filtered according to the criteria of user choice. Criteria are written
down in language with simple syntax.
\item[Criteria] describes condition under with any any record is being select by the filter.
\item[Syntax] as you may noticed computers (in general) are rather strict, and expect only strictly formulated orders -- that is:
@ -18,20 +18,20 @@ Don't be afraid though, filters are fairly intuitive and easy to use.
\item[Expression] is way we are actually performing filtering. Filter can be treated as ``functions'': accepts arguments, and evaluates
either to the true or false for every column record at the time.
\item[N-ary] is any expression that expects one or more expressions as arguments. It is useful for grouping two (or more) other expressions
together in order to create filter that will check for criteria placed in two (again: or more) columns (logical ``or'', ``and'').
\item[unary] is any expression that expects one other expression. The example is ``not'' expression. In fact ``not'' is the only useful
unary expression in OpenCS record filters.
together in order to create filter that will check for criteria placed in two (again: or more) columns (logical \textit{or}, \textit{and}).
\item[unary] is any expression that expects one other expression. The example is \textit{not} expression. In fact \textit{not} is the only useful
unary expression in \OCS{} record filters.
\item[nullary] is expression that does not accepts other expressions. It accepts arguments specified later.
\end{description}
\subsubsection{Basics}
In fact you do not need to learn everything about filters in order to use them. In fact all you need to know to achieve decent productivity
with OpenCS is inside basics section.
with \OCS{} is inside basics section.
\subsubsection{Interface}
Above each table there is a field that is used to enter filter: either predefined by the OpenMW developers or made by you, the user.
Above each table there is a field that is used to enter filter: either predefined by the \OMW{} developers or made by you, the user.
You probably noticed it before. However there is also completely new element, although using familiar table layout. Go to the application
menu view, and click filters. You should see set of default filters, made by the OpenMW team in the table with the following columns: filter,
menu view, and click filters. You should see set of default filters, made by the \OMW{} team in the table with the following columns: filter,
description and modified.
\begin{description}
@ -44,20 +44,21 @@ description and modified.
So let's learn how to actually use those to speed up your work.
\subsubsection{Using predefined filters}
Using those filters is quite easy and involves typing inside the filter field above the table. For instance, try to open referencables
table and type in the filters field the following: ``project::weapons''. As soon as you complete the text, table will magicly alter
and will show only the weapons. As you could noticed project::weapons is nothing else than a ID of one of the predefined filters. That is it:
table and type in the filters field the following: \mono{project::weapons}. As soon as you complete the text, table will magicly alter
and will show only the weapons. As you could noticed \mono{project::weapons} is nothing else than a~ID of one of the predefined filters. That is it:
in order to use the filter inside the table you simply type it is name inside the filter field.
To make life easier filter IDs follow simple convention.
\begin{itemize}
\item Filter ID filtering a specific record type contains usually the name of a specific group. For instance project::weapons filter
\item Filter ID filtering a specific record type contains usually the name of a specific group. For instance \mono{project::weapons} filter
contains the word weapons (did you noticed?). Plural form is always used.
\item When filtering specific subgroup the ID starts just like in the case of general filter. For instance project::weaponssilver will
filter only silver weapons (new mechanic introduced by the Bloodmoon, silver weapons deal double damage against werewolfs) and
project::weaponsmagical will filter only magical weapons (able to hurt ghosts and other supernatural creatures).
\item There are few exceptions from the above rule. For instance there is a project::added, project::removed, project::modyfied, project::base.
You would probably except something more like ``project::statusadded'' but in this case typing this few extra characters would only
filter only silver weapons (new mechanic introduced by the \BM{}, silver weapons deal double damage against werewolfs) and
\mono{project::weaponsmagical} will filter only magical weapons (able to hurt ghosts and other supernatural creatures).
\item There are few exceptions from the above rule. For instance there is a \mono{project::added}, \mono{project::removed},
\mono{project::modyfied}, \mono{project::base}.
You would probably except something more like \mono{project::statusadded} but in this case typing this few extra characters would only
help to break your keyboard faster.
\end{itemize}
@ -71,13 +72,13 @@ Finally, you will have to write this with correct syntax. As a result table will
Advance subsection covers everything that you need to know in order to create any filter you may want to %TODO the filter part is actually wrong
\subsubsection{Namespaces}
Did you noticed that every default filter has ``project::`` prefix? It is a ``namespace``, a term borrowed from the \CPP{} language.
In case of OpenCS namespace always means scope of the said object\footnote{You are not supposed to understand this at the moment.}.
Did you noticed that every default filter has \mono{project::} prefix? It is a \textit{namespace}, a~term borrowed from the \CPP{} language.
In case of \OCS{} namespace always means scope of the said object\footnote{You are not supposed to understand this at the moment.}.
But what does it mean in case of filters? Well, short explanation is actually simple.
\begin{description}
\item[project::] namespace indicates that filter is used with the project, in multiple sessions. You can restart Open{CS} and filter
\item[project::] namespace indicates that filter is used with the project, in multiple sessions. You can restart \OCS{} and filter
is still there.
\item[session::] namespace indicates that filter is not stored trough multiple sessions and once you will quit Open{CS} (close session)
\item[session::] namespace indicates that filter is not stored trough multiple sessions and once you will quit \OCS{} (close session)
the filter will be gone. Forever! Until then it can be found inside the filters table.
\end{description}
In addition to this two scopes, there is a third one; called one-shot. One-shot filters are not stored (even during single session)
@ -89,8 +90,8 @@ Still, you may wonder how you are supposed to write expressions, what expression
with nullary expressions that will allow you to create a basic filter.
\subsubsection{Nullary expressions}
All nullary expressions are used in similar manner. First off: you have to write it is name (for instance: ``string'') and secondly:
condition that will be checked inside brackets (for instance string(something, something)). If conditions of your expression will be meet
All nullary expressions are used in similar manner. First off: you have to write it is name (for instance: \mono{string}) and secondly:
condition that will be checked inside brackets (for instance \mono{string(something, something)}). If conditions of your expression will be meet
by a record (technical speaking: expression will evaluate to true) the record will show up in the table.
It is clear that you need to know what are you checking, that is: what column of the table contains information that you are interested
@ -99,27 +100,27 @@ you want to see, while the second one sets desired value inside of the cell. To
\paragraph{String -- string(``column'', ``value'')}
String in programmers language is often\footnote{Often, not always. There are different programming languages using slightly different terms.}
just a word for anything composed of characters. In case of OpenCS this is in fact true for every value inside the column that is not composed
of the pure numbers. Even columns containing only ``true`` and ``false`` values can be targeted by the string expression.
\footnote{There is no Boolean (''true'' or ``false'') value in the OpenCS. You should use string for those.} String evaluates to true,
just a word for anything composed of characters. In case of \OCS{} this is in fact true for every value inside the column that is not composed
of the pure numbers. Even columns containing only ``true`` and ``false`` values can be targeted by the string expression\footnote{There is no
Boolean (''true'' or ``false'') value in the \OCS. You should use string for those.}. String evaluates to true,
when record contains in the specified column exactly the same value as specified.
Since majority of the columns contain string values, string is among the most often used expressions. Examples:
\begin{itemize}
\item string(``Record Type'', ``Weapon'') -- will evaluate to true for all records containing ``Weapon'' in the ``Record Type'' column cell.
\item \mono{string(``Record Type'', ``Weapon'')} -- will evaluate to true for all records containing \mono{Weapon} in the \mono{Record Type} column cell.
This group contains every weapon (including arrows and bolts) found in the game.
\item string(``Portable'', ``true'') -- will evaluate to true for all records containing word true inside ``Portable'' column cell.
\item \mono{string(``Portable'', ``true'')} -- will evaluate to true for all records containing word true inside \mono{Portable} column cell.
This group contains every portable light sources (lanterns, torches etc.).
\end{itemize}
This is probably enough to create around 90 string filters you will eventually need. However, this expression is even more powerful
-- it accepts regular expressions (also called regexps). Regular expressions is a way to create string criteria that will be matched
by one than just one specific value in the column. For instance, you can display both left and right gauntlets with the following expression:
``string("armor type", ".* gauntlet"))`` because ''.*'' in regexps means just: ``anything''. This filter says: please, show me ``any'' gauntlet.
\mono{string("armor type", ".* gauntlet"))} because \mono{.*} in regexps means just: ``anything''. This filter says: please, show me ``any'' gauntlet.
There are left and right gauntlets in the morrowind so this will evaluate to true for both. Simple, isn't it?
Creating regexps can be a difficult and annoying -- especially when you need complex criteria. On the other hand, We are under impression
Creating regexps can be a difficult and annoying -- especially when you need complex criteria. On the other hand, we are under impression
that in reality complex expressions are needed only in sporadic cases. In fact, the truth is: that most of the time only already mentioned
``.*'' is needed and therefore the following description of regexps can be skipped by vast majority of readers.
\mono{.*} is needed and therefore the following description of regexps can be skipped by vast majority of readers.
Before working with Regular Expressions, you should understand what actually are regular expressions. Essentially, the idea is simple:
when you are writing any word, you are using strictly defined letters -- that is: letters create a word. What you want to do with regular
@ -127,21 +128,22 @@ expression is to use set of rules that will match to many words. It is not that
you will clearly need way to determinate what letters you want to match (word is composed by letters).
Before introducing other ways to choose between characters, I want explain anchors. Anchors allows you to decide where to ``look'' in the string.
You surely should know about ``\^'' anchor and ``\textdollar''. Putting ``\^`` will tell to Open{CS} to look on the beginning of string,
while ''\textdollar`` is used to mark the end of it. For instance, pattern ''\^Pink.* elephant.\textdollar`` Will match any sentence beginning
with the word ''Pink`` and ending with '' elephant.``. Pink fat elephant. Pink cute elephant. It does not matter what is in between,
because ''.*`` is used.\\
You surely should know about \mono{\textasciicircum} anchor and \mono{\textdollar}. Putting \mono{\textasciicircum} will tell to \OCS{}
to look on the beginning of string, while \mono{\textdollar} is used to mark the end of it. For instance, pattern
\mono{\textasciicircum{}Pink.* elephant.\textdollar} will match any sentence beginning with the word \mono{Pink} and ending with
\mono{ elephant.}. Pink fat elephant. Pink cute elephant. It does not matter what is in between, because \mono{.*} is used.
You have already seen the power of the simple ``.*''. But what if you want to chose between only two (or more) letters? Well, this is when
``[|]'' comes in handy. If you write something like: ``\^[a|k].*'' you are simply telling Open{CS} to filter anything that starts with either
``a'' or ``k''. Using ``\^[a|k|l].*'' will work in the same manner, but it will also cover strings starting with ``l''.
You have already seen the power of the simple \mono{.*}. But what if you want to chose between only two (or more) letters? Well, this is when
\mono{[|]} comes in handy. If you write something like: \mono{\textasciicircum[a|k].*} you are simply telling \OCS{} to filter anything that
starts with either \mono{a} or \mono{k}. Using \mono{\textasciicircum[a|k|l].*} will work in the same manner, but it will also cover
strings starting with \mono{l}.
What if you want to match more than just one latter? Just use ``(|)``. it is pretty similar to the above one letter as you see, but it is
used to fit more than just one character. For instance: ''\^(Pink|Green).* (elephant|crocodile).\textdollar`` will be true for all sentences
starting with ''Pink`` or ''Green`` and ending with either ''elephant.`` or ''crocodile.``.
What if you want to match more than just one latter? Just use \mono{(|)}. it is pretty similar to the above one letter as you see, but it is
used to fit more than just one character. For instance: \mono{\textasciicircum(Pink|Green).* (elephant|crocodile).\textdollar} will be
true for all sentences starting with \mono{Pink} or \mono{Green} and ending with either \mono{elephant.} or \mono{crocodile.}.
Regular expressions are not the main topic of this manual. If you wish to learn more on this subject please, read the documentation on
Qt regular expressions syntax, or TRE regexp syntax (it is almost like in Qt). Above is just enough to use Open{CS} effectively to be sure.
Qt regular expressions syntax, or TRE regexp syntax (it is almost like in Qt). Above is just enough to use \OCS{} effectively to be sure.
\paragraph{Value -- value(``value'', (``open'', ``close''))}
While string expression covers vast group of columns containing string values, there are in fact columns with just numerical values like
@ -149,10 +151,10 @@ While string expression covers vast group of columns containing string values, t
inside brackets. Clearly, conditions should hold column to test in. However in this case wanted value is specified as a range.
As you would imagine the range can be specified as including a border value, or excluding. We are using two types of brackets for this:
\begin{itemize}
\item To include value use [] brackets. For value equal 5, expression value(something, [5, 10]) will evaluate to true.
\item To exclude value use () brackets. For value equal 5, expression value(something, (5, 10)) will evaluate to false.
\item Mixing brackets is completely legal. For value equal 10, expression value(something, [5, 10) will evaluate to true. The same expression
will evaluate to false for value equal 10.
\item To include value use [] brackets. For value equal 5, expression \mono{value(something, [5, 10])} will evaluate to true.
\item To exclude value use () brackets. For value equal 5, expression \mono{value(something, (5, 10))} will evaluate to false.
\item Mixing brackets is completely legal. For value equal 10, expression \mono{value(something, [5, 10)} will evaluate to true.
The same expression will evaluate to false for value equal 10.
\end{itemize}
\paragraph{''true`` and ''false``}
@ -161,7 +163,7 @@ and false (in case of \textit{false}) no matter what. The main usage of this ex
disable some part of the filter that makes heavy use of the logical expressions.
\subsubsection{Logical expressions}
This subsection takes care of two remaining groups of expressions: binary and unary. The only unary expression present in the OpenCS is logical
This subsection takes care of two remaining groups of expressions: binary and unary. The only unary expression present in the \OCS{} is logical
\textit{not}, while the remaining binary expressions are: \textit{or}, \textit{and}. This clearly makes them (from the user point of view)
belonging to the same group of logical expressions.
@ -170,8 +172,8 @@ Sometimes you may be in need of reversing the output of the expression. This is
expression will revert it: if expression was returning true, it will return false; if it was returning false, it will return true. Brackets
are not needed: \textit{not} will revert only the first expression following it.
To show this on know example, let's consider the ''string("armor type", ".* gauntlet"))`` filter. As we mentioned earlier this will return true
for every gauntlet found in game. In order to show everything, but gauntlets we simply do ''not string("armor type", ".* gauntlet"))``.
To show this on know example, let's consider the \mono{string("armor type", ".* gauntlet"))} filter. As we mentioned earlier this will return true
for every gauntlet found in game. In order to show everything, but gauntlets we simply do \mono{not string("armor type", ".* gauntlet"))}.
This is probably not the most useful filter on earth, but this is not a surprise: real value of \textit{not} expression shines when combined with
\textit{or}, \textit{and} filters.
@ -179,13 +181,13 @@ This is probably not the most useful filter on earth, but this is not a surprise
\textit{Or} is a expression that will return true if one of the arguments evaluates to true. You can use two or more arguments, separated by the comma.
\textit{Or} expression is useful when showing two different group of records is needed. For instance the standard actor filter is using the following
''or(string(``record type'', npc), string(``record type'', creature))`` and will show both npcs and creatures.
\mono{or(string(``record type'', npc), string(``record type'', creature))} and will show both npcs and creatures.
\paragraph{and -- and(expression1(), expression2())}
\textit{And} is a expression that will return true if all arguments evaluates to true. As in the case of ''or`` you can use two or more arguments,
separated by a comma.
As we mentioned earlier in the \textit{not} filter, combining \textit{not} with \textit{and} can be very useful. For instance to show all armor types,
excluding gauntlets you can write the following: ''and (not string("armor type", ".* gauntlet"), string(''Record Type``, ''Armor``))''.
excluding gauntlets you can write the following: \mono{and (not string("armor type", ".* gauntlet"), string(''Record Type``, ''Armor``))}.
\subsubsection{Creating and saving filter}
In order to create and save new filter, you should go to the filters table, right click and select option ``add record'' from the context menu.
@ -196,7 +198,7 @@ and write it down there.
Done! You are free to use your filter.
\subsubsection{Replacing the default filters set}
{OpenCS} allows you to substitute default filters set provided by us, with your own filters. In order to do so you should create a new project,
OpenCS allows you to substitute default filters set provided by us, with your own filters. In order to do so you should create a new project,
add desired filters, remove undesired and save. Rename the file to the ``defaultfilters'' (do not forget to remove .omwaddon.project extension)
and place it inside your configuration directory.

@ -3,7 +3,7 @@
\usepackage{babel}
\usepackage{txfonts} % Public Times New Roman text & math font
\usepackage[pdftex]{graphicx}
\usepackage[colorlinks,pdftex]{hyperref}
\usepackage[final,colorlinks,pdftex,pdfpagelabels=true]{hyperref}
\author{OpenMW Team}
\def\pdfBorderAttrs{/Border [0 0 0] } % No border arround Links
@ -13,11 +13,13 @@
pdfauthor={Copyright \textcopyright{} OpenMW Team },
pdftitle={OpenCS user manual}
}
\def\MW{\textit{Morrowind\texttrademark{}\ }}
\def\TB{\textit{Tribunal\ }}
\def\BM{\textit{Bloodmon\ }}
\def\BS{Bethesda Softworks\ }
\def\mono{\texttt}
\def\MW{\textit{Morrowind\texttrademark{}}}
\def\TB{\textit{Tribunal}}
\def\BM{\textit{Bloodmon}}
\def\BS{Bethesda Softworks}
\def\OMW{\hbox{OpenMW}}
\def\OCS{\hbox{OpenCS}}
\begin{document}

@ -1,8 +1,8 @@
\section{Tables}
\subsection{Introduction}
If you have launched OpenCS already and played around with it for a bit, you have probably gotten the impression that it contains lots of tables.
You'd be spot on: OpenCS is built around using tables. This does not mean it works just like Microsoft Excel or Libre Office Calc, though.
If you have launched \OCS{} already and played around with it for a bit, you have probably gotten the impression that it contains lots of tables.
You'd be spot on: \OCS{} is built around using tables. This does not mean it works just like Microsoft Excel or Libre Office Calc, though.
Due to the vast amounts of information involved with \MW, tables just made the most sense. You have to be able to spot information quickly
and be able to change them on the fly.
Let's browse through the various screens and see what all these tables show.
@ -12,7 +12,7 @@ Let's browse through the various screens and see what all these tables show.
\subsubsection{Glossary}
\begin{description}
\item[Record:] An entry in OpenCS representing an item, location, sound, NPC or anything else.
\item[Record:] An entry in \OCS{} representing an item, location, sound, NPC or anything else.
\item[Reference, Referenceable:] When an item is placed in the world, it does not create a new record each time. For example, the game world might
contain a lot of exquisite belts on different NPCs and in many crates, but they all refer to one specific record: the Exquisite Belt record.
@ -22,17 +22,17 @@ Let's browse through the various screens and see what all these tables show.
\end{description}
\subsubsection{Recurring Terms}
Some columns are recurring throughout OpenCS. They show up in (nearly) every table in OpenCS.
Some columns are recurring throughout \OCS. They show up in (nearly) every table in \OCS.
\begin{description}
\item[ID] Each item, location, sound, etc. gets the same unique identifier in both OpenCS and Morrowind. This is usually a very self-explanatory name.
\item[ID] Each item, location, sound, etc. gets the same unique identifier in both \OCS{} and \MW. This is usually a very self-explanatory name.
For example, the ID for the (unique) black pants of Caius Cosades is ``Caius\_pants''. This allows you to manipulate the game in many ways. For example,
you could add these pants to your inventory by simply opening the console and write: ``player->addItem Caius\_pants''. Either way, in both Morrowind
and OpenCS, the ID is the primary way to identify all these different parts of the game. %Wrong! Cells do not have ID, only name.
and \OCS, the ID is the primary way to identify all these different parts of the game. %Wrong! Cells do not have ID, only name.
\item[Modified] This column shows what has happened (if something has happened) to this record. There are four possible states in which it can exist.
\item[Base] means that this record is part of the base game and is in its original state. Usually, if you create a mod, the base game is Morrowind with
optionally the Bloodmoon and Tribunal expansions.
\item[Added] means that this record was not in the base game and has been added by a modder.
\item[Added] means that this record was not in the base game and has been added by a~modder.
\item[Modified] means that the record is part of the base game, but has been changed in some way.
\item[Deleted] means that this record used to be part of the base game, but has been removed as an entry. This does not mean, however, that the occurrences
in the game itself have been removed! For example, if you remove the CharGen\_Bed entry from morrowind.esm, it does not mean the bedroll in the basement
@ -49,7 +49,7 @@ This describes the general areas of Vvardenfell. Each of these areas has differe
\begin{description}
\item[Name:] This is how the game will show your location in-game.
\item[Map Colour:] This is a six-digit hexidecimal representation of the colour used to identify the region on the map available in
World > Region Map. If you don't have an application with a colour picker, you can use your favourite search engine to find a colour picker online.
World > Region Map. If you do not have an application with a colour picker, you can use your favourite search engine to find a colour picker online.
\item[Sleep Encounter:] These are the rules for what kind of enemies you might encounter when you sleep outside in the wild.
\end{description}
@ -59,8 +59,8 @@ why would the computer need to keep track the exact locations of NPCs walking th
be quite useless and bring your system to its knees! So the world has been divided up into squares we call "cells". Once your character enters a cell,
the game will load everything that is going on in that cell so you can interact with it.
In the original \MW this could be seen when you were travelling and you would see a small loading bar at the bottom of the screen;
you had just entered a new cell and the game would have to load all the items and NPCs. The Cells screen in OpenCS provides you with a list of cells
In the original \MW{} this could be seen when you were travelling and you would see a small loading bar at the bottom of the screen;
you had just entered a new cell and the game would have to load all the items and NPCs. The Cells screen in \OCS{} provides you with a list of cells
in the game, both the interior cells (houses, dungeons, mines, etc.) and the exterior cells (the outside world).
\begin{description}
@ -76,14 +76,14 @@ in the game, both the interior cells (houses, dungeons, mines, etc.) and the ext
Setting the cell's Interior Water to false tells the game that the water at height 0 should not be used. Remember that cells that are in
the outside world are exterior cells and should thus \textit{always} be set to false!
\item[Interior Sky:] Should this interior cell have a sky? This is a rather unique case. The \TB expansion took place in a city on
\item[Interior Sky:] Should this interior cell have a sky? This is a rather unique case. The \TB{} expansion took place in a city on
the mainland. Normally this would require the city to be composed of exterior cells so it has a sky, weather and the like. But if the player is
in an exterior cell and looks at his in-game map, he sees Vvardenfell with an overview of all exterior cells. The player would have to see
the city's very own map, as if he was walking around in an interior cell.
So the developers decided to create a workaround and take a bit of both: The whole city would technically work exactly like an interior cell,
but it would need a sky as if it was an exterior cell. That's what this is. This is why the vast majority of the cells you will find in this screen
will have this option set to false: It's only meant for these "fake exteriors".
but it would need a sky as if it was an exterior cell. That is what this is. This is why the vast majority of the cells you will find in this screen
will have this option set to false: It is only meant for these "fake exteriors".
\item[Region:] To which Region does this cell belong? This has an impact on the way the game handles weather and encounters in this area.
It is also possible for a cell not to belong to any region.
@ -93,11 +93,11 @@ in the game, both the interior cells (houses, dungeons, mines, etc.) and the ext
\subsubsection{Referenceables}
This is a library of all the items, triggers, containers, NPCs, etc. in the game. There are several kinds of Record Types. Depending on which type
a record is, it will need specific information to function. For example, an NPC needs a value attached to its aggression level. A chest, of course,
does not. All Record Types contain at least a model. How else would the player see them? Usually they also have a Name, which is what you see
does not. All Record Types contain at least a~model. How else would the player see them? Usually they also have a Name, which is what you see
when you hover your reticle over the object.
Let's go through all Record Types and discuss what you can tell OpenCS about them.
Let's go through all Record Types and discuss what you can tell \OCS{} about them.
\begin{description}
\item[Activator:] This is an item that, when activated, starts a script or even just shows a tooltip.
\item[Activator:] This is an item that, when activated, starts a script or even just shows a~tooltip.
\end{description}

@ -1,20 +1,20 @@
\section{Windows}
\subsection{Introduction}
This section describes the multiple windows interface of the OpenCS editor. This design principle was chosen in order
This section describes the multiple windows interface of the \OCS{} editor. This design principle was chosen in order
to extend the flexibility of the editor, especially on the multiple screens setups and on environments providing advanced
windows management features, like; for instance: multiple desktops found commonly on many open source desktop environments.
However, it is enough to have a single large screen to see the advantages of this concept.
OpenCS windows interface is easy to describe and understand. In fact we decided to minimize use of many windows concepts
applied commonly in various applications. For instance dialog windows are really hard to find in the OpenCS. You are free to try,
applied commonly in various applications. For instance dialog windows are really hard to find in the \OCS. You are free to try,
though.
Because of this, and the fact that we expect that user is familiar with other applications using windows this section is mostly
focused on practical ways of organizing work with the OpenCS.
focused on practical ways of organizing work with the \OCS.
\subsection{Basics}
After starting Open{CS} and choosing content files to use a editor window should show up. It probably does not look surprising:
there is a menubar at the top, and there is a large empty area. That is it: a brand new Open{CS} window contains only menubar
After starting \OCS{} and choosing content files to use a editor window should show up. It probably does not look surprising:
there is a menubar at the top, and there is a~large empty area. That is it: a brand new \OCS{} window contains only menubar
and statusbar. In order to make it a little bit more useful you probably want to enable some panels\footnote{Also known as widgets.}.
You are free to do so, just try to explore the menubar.
@ -23,19 +23,19 @@ just focus on the windows itself.
\paragraph{Creating new windows}
is easy! Just visit view menu, and use the ``New View'' item. Suddenly, out of the blue a new window will show up. As you would expect,
it is also blank, and you are free to add any of the Open{CS} panels.
it is also blank, and you are free to add any of the \OCS{} panels.
\paragraph{Closing opened window}
is also easy! Simply close that window decoration button. We suspect that you knew that already, but better to be sure.
Closing last Open{CS} window will also terminate application session.
Closing last \OCS{} window will also terminate application session.
\paragraph{Multi-everything}
is the main foundation of Open{CS} interface. You are free to create as many windows as you want to, free to populate it with
is the main foundation of \OCS{} interface. You are free to create as many windows as you want to, free to populate it with
any panels you may want to, and move everything as you wish to -- even if it makes no sense at all. If you just got crazy idea and
you are wonder if you are able to have one hundred Open{CS} windows showing panels of the same type, well most likely you are
you are wonder if you are able to have one hundred \OCS{} windows showing panels of the same type, well most likely you are
able to do so.
The principle behind this design decision is easy to see for \BS made editor, but maybe not so clear for users who are
The principle behind this design decision is easy to see for \BS{} made editor, but maybe not so clear for users who are
just about to begin their wonderful journey of modding.
\subsection{Advanced}
@ -46,9 +46,9 @@ All major graphical environments commonly present in operating systems comes wit
active window. It is very effective and fast when you have only two windows, each holding only one table. Sometimes you have to work
with two at the time, and with one from time to time. Here, you can have one window holding two tables, and second holding just one.
Open{CS} is designed to simply make sense and do not slowdown users. It is as simple as possible (but not simpler), and uses one
OpenCS is designed to simply make sense and do not slowdown users. It is as simple as possible (but not simpler), and uses one
flexible approach in all cases.
There is no point in digging deeper in the windows of Open{CS}. Let's explore panels, starting with tables.
There is no point in digging deeper in the windows of \OCS. Let's explore panels, starting with tables.
%We should write some tips and tricks here.
Loading…
Cancel
Save