sirherrbatka
11 years ago
commit
6bf643ea79
@ -1,74 +1,119 @@
|
||||
\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}.
|
||||
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 \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 files and few different folders. The location of the user directory is hard coded for each supported operating system.\\
|
||||
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: 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, however, there is one special data path that, as described later, is used to store newly created content files.
|
||||
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 \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}
|
||||
Bethesda Morrowind\texttrademark 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 this 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}
|
||||
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. 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.\\
|
||||
\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. \OMW{} achieves
|
||||
his with our own content file types.
|
||||
|
||||
Other simple thing about content files are extensions. We are using .omwaddon for addon files and .omwgame for game files.\\
|
||||
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``.
|
||||
|
||||
%TODO describe what content files contains. and what not.
|
||||
\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 \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.
|
||||
|
||||
\subparagraph{Morrowind 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 successful project. Yay!}. Also, since 2002 thousands of esp/ems 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 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.
|
||||
Other simple thing about content files are extensions. We are using .omwaddon for addon files and .omwgame for game files.
|
||||
|
||||
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 are created inside the user directory, in the the \textbf{data} subfolder (that is the one special data directory mentioned earlier).\\
|
||||
%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 \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 \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 \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}
|
||||
Since addon is supposed to change the game it is logical that it also depends on the said game. It simply can't work otherwise. Just think about it: your modification is changing prize of the iron sword. But what if there is no iron sword in game? That's right: we get nonsense. What you want to do is to tie your addon to the files you are changing. Those can be either game files (expansion island for a game) or other addon files (house on the said island). It is a a good idea to be dependent only on files that are really changed in your addon obviously, but sadly there is no other way to achieve this than knowing what you want to do. Again, please remember that this section of the manual does not cover creating the content files -- it is only theoretical introduction to the subject. For now just keep in mind that dependencies exist, and is up to you what to decide if your content file should depend on other content file.\\
|
||||
|
||||
Game files are not intend to have any dependencies for a very simple reasons: player is using only one game file (excluding original and dirty esp/esm system) at the time and therefore no game file can depend on other game file, and since game file makes the base for addon files -- it can't depend on addon files.\\
|
||||
|
||||
\subparagraph{Loading order}
|
||||
%TODO
|
||||
|
||||
Since addon is supposed to change the game it is logical that it also depends on the said game. It simply can not work otherwise.
|
||||
Just think about it: your modification is changing prize of the iron sword. But what if there is no iron sword in game? That is right:
|
||||
we get nonsense. What you want to do is to tie your addon to the files you are changing. Those can be either game files (expansion island
|
||||
for a game) or other addon files (house on the said island). It is a good idea to be dependent only on files that are really changed
|
||||
in your addon obviously, but sadly there is no other way to achieve this than knowing what you want to do. Again, please remember that
|
||||
this section of the manual does not cover creating the content files -- it is only theoretical introduction to the subject. For now just
|
||||
keep in mind that dependencies exist, and is up to you what to decide if your content file should depend on other content file.
|
||||
|
||||
Game files are not intend to have any dependencies for a very simple reasons: player is using only one game file (excluding original
|
||||
and dirty ESP/ESM system) at the time and therefore no game file can depend on other game file, and since game file makes the base
|
||||
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 Openm{MW} 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 don't need and/or want to distribute project files at all, they are meant to be used only by you.\\
|
||||
As you would imagine, project file makes sense only in combination with actual content files. In fact, each time you start to work on new content file and project file was not found, it will be created.\\
|
||||
Project files extension is, to not surprise ``.project''. The whole name of the project file is the whole name of the content file with appended extensions. For instance swords.omwaddon file is associated with swords.omwaddon.project file.\\
|
||||
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.
|
||||
|
||||
As you would imagine, project file makes sense only in combination with actual content files. In fact, each time you start to work
|
||||
on new content file and project file was not found, it will be created.
|
||||
Project files extension is, to not surprise ``.project''. The whole name of the project file is the whole name of the content file
|
||||
with appended extensions. For instance swords.omwaddon file is associated with swords.omwaddon.project file.
|
||||
|
||||
%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.\\
|
||||
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 \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} file type do not contain any of those, it's 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.}. Therefore this section must cover ways to add resources files to your content file, and point out what is supported. We are going to do just that. Later, you will learn how to make use of those files in your content.
|
||||
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 \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.}.
|
||||
Therefore this section must cover ways to add resources files to your content file, and point out what is supported. We are going
|
||||
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. Below is only small portion of supported file types.
|
||||
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}
|
||||
\item mp3 popular format and \textit{de facto} standard for storing audio. Used by the Morrowind game.
|
||||
\item mp4 format with a better compression rate than mp3, but also requiring more {CPU} intensive decoding -- this makes it probably less suited for video games.
|
||||
\item ogg open source, audio container file using high quality vorbis codec. Recommended.
|
||||
\item mp3 (MPEG-1 Part 3 Layer 3) popular audio file format and \textit{de facto} standard for storing audio. Used by the Morrowind game.
|
||||
\item ogg open source, multimedia container file using high quality vorbis audio codec. Recommended.
|
||||
\end{description}
|
||||
|
||||
|
||||
\subparagraph{Video}
|
||||
As in the case of audio files, we are using {FFmepg} to decode video files. The list of supported files is long, we will cover only the most significant.
|
||||
As in the case of audio files, we are using {FFmepg} to decode video files. The list of supported files is long, we will cover
|
||||
only the most significant.
|
||||
|
||||
\begin{description}
|
||||
\item bik videos used by original Morrowind game.
|
||||
\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}.
|
||||
\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 \OMW.
|
||||
\item ogv alternative, open source container using theora codec for video and vorbis for audio.
|
||||
\end{description}
|
||||
|
||||
\subparagraph{Textures and images}
|
||||
Original Morrowind game uses dds and tga file 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.
|
||||
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.
|
||||
|
||||
\subparagraph{Meshes} %TODO once we will support something more than just nifs
|
||||
%\subparagraph{Meshes} %TODO once we will support something more than just nifs
|
||||
@ -1,74 +1,103 @@
|
||||
\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 doesn't mean it works just like Excel or Calc, though. Due to the vast amounts of information involved with Morrowind, 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.
|
||||
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.
|
||||
|
||||
\subsection{Used Terms}
|
||||
|
||||
\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 doesn't 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. In this case, all those belts in crates and on NPCs are references. The central Exquisite Belt record is called a referenceable. This allows modders to make changes to all items of the same type. For example, if you want all exquisite belts to have 4000 enchantment points rather than 400, you will only need to change the referenceable Exquisite Belt rather than all exquisite belts references individually.
|
||||
\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.
|
||||
In this case, all those belts in crates and on NPCs are references. The central Exquisite Belt record is called a referenceable. This allows modders
|
||||
to make changes to all items of the same type. For example, if you want all exquisite belts to have 4000 enchantment points rather than 400, you will
|
||||
only need to change the referenceable Exquisite Belt rather than all exquisite belts references individually.
|
||||
\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. 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.
|
||||
\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 \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[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[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 doesn't mean the bedroll in the basement of the Census and Excise Office in Seyda Neen is gone. You're going to have to delete that reference yourself or make sure that that object is replaced by something that still exists otherwise you'll get crashes in the worst case scenario.
|
||||
\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
|
||||
of the Census and Excise Office in Seyda Neen is gone. You're going to have to delete that reference yourself or make sure that that object is replaced
|
||||
by something that still exists otherwise you will get crashes in the worst case scenario.
|
||||
\end{description}
|
||||
|
||||
\subsection{World Screens}
|
||||
|
||||
The contents of the game world can be changed by choosing one of the options in the appropriate menu at the top of the screen.
|
||||
|
||||
\subsubsection{Regions}
|
||||
|
||||
This describes the general areas of Vvardenfell. Each of these areas has different rules about things such as encounters and weather.
|
||||
|
||||
\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.
|
||||
\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 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}
|
||||
|
||||
\subsubsection{Cells}
|
||||
Expansive worlds such as Vvardenfell, with all its items, NPCs, etc. have a lot going on simultaneously. But if you are in Balmora,
|
||||
why would the computer need to keep track the exact locations of NPCs walking through the corridors in a Vivec canton? All that work would
|
||||
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.
|
||||
|
||||
Expansive worlds such as Vvardenfell, with all its items, NPCs, etc. have a lot going on simultaneously. But if you are in Balmora, why would the computer need to keep track the exact locations of NPCs walking through the corridors in a Vivec canton? All that work would 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 Morrowind 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 game, both the interior cells (houses, dungeons, mines, etc.) and the exterior cells (the outside world).
|
||||
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}
|
||||
\item[Sleep Forbidden:] Can the player sleep on the floor? In most cities it is forbidden to sleep outside. Sleeping in the wild carries its own risks of attack, though, and this entry lets you decide if a player should be allowed to sleep on the floor in this cell or not.
|
||||
\item[Sleep Forbidden:] Can the player sleep on the floor? In most cities it is forbidden to sleep outside. Sleeping in the wild carries its
|
||||
own risks of attack, though, and this entry lets you decide if a player should be allowed to sleep on the floor in this cell or not.
|
||||
|
||||
\item[Interior Water:] Should water be rendered in this interior cell? The game world consists of an endless ocean at height 0. Then the landscape is added. If part of the landscape goes below height 0, the player will see water. (See illustration.)
|
||||
\item[Interior Water:] Should water be rendered in this interior cell? The game world consists of an endless ocean at height 0. Then the landscape
|
||||
is added. If part of the landscape goes below height 0, the player will see water. (See illustration.)
|
||||
|
||||
Setting the cell's Interior Water to true tells the game that this cell is both an interior cell (inside a building, for example, rather than in the open air) but that there still needs to be water at height 0. This is useful for dungeons or mines that have water in them.
|
||||
Setting the cell's Interior Water to true tells the game that this cell is both an interior cell (inside a building, for example, rather than
|
||||
in the open air) but that there still needs to be water at height 0. This is useful for dungeons or mines that have water in them.
|
||||
|
||||
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!
|
||||
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 \textit{Tribunal} 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.
|
||||
\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".
|
||||
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 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.
|
||||
\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.
|
||||
|
||||
\end{description}
|
||||
|
||||
\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
|
||||
when you hover your reticle over the object.
|
||||
|
||||
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 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,29 +1,54 @@
|
||||
\section{Windows}
|
||||
\subsection{Introduction}
|
||||
This section describes the multiple windows interface of the OpenCS 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, 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.
|
||||
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 \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 \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's it: a brand new Open{CS} 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. \\
|
||||
You probably founded out the way to enable and disable some interesting tables, but those will be described later. For now, let's just focus on the windows itself.
|
||||
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.
|
||||
|
||||
You probably founded out the way to enable and disable some interesting tables, but those will be described later. For now, let's
|
||||
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.
|
||||
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 \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.
|
||||
is also easy! Simply close that window decoration button. We suspect that you knew that already, but better to be sure.
|
||||
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 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 able to do so.\\
|
||||
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 \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 Bethesda made editor, but maybe not so clear for users who are just about to begin their wonderful journey of modding.\\
|
||||
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}
|
||||
So why? Why this is created in such manner. The answer is frankly simple: because it is effective. When creating a mod, you often have to work only with just one table. For instance you are just balancing weapons damage and other statistics. It makes sense to have all the space for just that one table. More often, you are required to work with two and switch them from time to time. All major graphical environments commonly present in operating systems comes with switcher feature, that is a key shortcut to change 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.\\
|
||||
So why? Why this is created in such manner. The answer is frankly simple: because it is effective. When creating a mod, you often
|
||||
have to work only with just one table. For instance you are just balancing weapons damage and other statistics. It makes sense
|
||||
to have all the space for just that one table. More often, you are required to work with two and switch them from time to time.
|
||||
All major graphical environments commonly present in operating systems comes with switcher feature, that is a key shortcut to change
|
||||
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 flexible approach in all cases.\\
|
||||
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 New Issue