mirror of
https://github.com/OpenMW/openmw.git
synced 2025-01-16 03:29:55 +00:00
Another part of reformatting and clean up.
Signed-off-by: Lukasz Gromanowski <lgromanowski@gmail.com>
This commit is contained in:
parent
2e5e9e0c44
commit
3b64de7441
5 changed files with 111 additions and 107 deletions
|
@ -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…
Reference in a new issue