104 lines
3.6 KiB
TeX
104 lines
3.6 KiB
TeX
\documentclass{article}
|
|
|
|
\title{Development Progress and Status report SQLization of stats}
|
|
\author{Giel van Schijndel, The Warzone Resurrection Project.}
|
|
|
|
% PDF options
|
|
\makeatletter
|
|
\usepackage[pdfdisplaydoctitle,
|
|
pdftitle={\@title},
|
|
pdfauthor={\@author}]{hyperref}
|
|
\makeatother
|
|
|
|
\begin{document}
|
|
|
|
\maketitle
|
|
\tableofcontents
|
|
\newpage
|
|
|
|
\section{Implemented}
|
|
|
|
The following STATS structures/classes have been implemented and are generated
|
|
entirely by the database scripts.
|
|
\begin{itemize}
|
|
\item BASE (inherited from by COMPONENT).
|
|
\item COMPONENT (inherited from by all other STATS except for a few
|
|
exceptional cases).
|
|
\item PROPULSION
|
|
\item SENSOR
|
|
\item ECM
|
|
\item REPAIR
|
|
\item WEAPON
|
|
\item BRAIN
|
|
\item CONSTRUCT
|
|
\end{itemize}
|
|
|
|
Of these the following structures/classes are being loaded by the generated
|
|
SQLite code.
|
|
\begin{itemize}
|
|
\item PROPULSION (loadPropulsionStatsFromDB)
|
|
\item SENSOR (loadSensorStatsFromDB)
|
|
\item CONSTRUCT (loadConstructStatsFromDB)
|
|
\end{itemize}
|
|
|
|
\section{TODO}
|
|
|
|
\subsection{Structure generation}
|
|
|
|
For these STATS structures\footnote{C structs and SQL table and view
|
|
definitions} still need to be generated:
|
|
\begin{enumerate}
|
|
\item These will certainly need to be done:
|
|
\begin{itemize}
|
|
\item BODY\_STATS
|
|
\end{itemize}
|
|
\item These might need another solution, \ldots, or not. Currently they don't
|
|
inherit from BASE \& COMPONENT like other STATS. While this isn't a
|
|
technical problem for the scripts in their current state for the purpose of
|
|
storing and loading, it might prove problematic for linking them to the
|
|
other STATS structures where appropriate. Need to look further into this.
|
|
\begin{itemize}
|
|
\item PROPULSION\_TYPES. How does this get linked to and used with
|
|
PROPULSION?
|
|
\item TERRAIN\_TABLE. This seems to be the only simple one as it's not
|
|
linked to any data structures, it's linkage to other data is defined
|
|
entirely by the code that uses its value.
|
|
\item SPECIAL\_ABILITY. Haven't yet investigated the purpose of this
|
|
structure.
|
|
\end{itemize}
|
|
\item These are all upgrades to other stats. The way in which it is decided to
|
|
which STATS they should be applied or how they should be applied is
|
|
something I haven't yet discovered (though I didn't investigate very
|
|
thoroughly up until now).
|
|
\begin{itemize}
|
|
\item WEAPON\_UPGRADE
|
|
\item SENSOR\_UPGRADE
|
|
\item ECM\_UPGRADE
|
|
\item REPAIR\_UPGRADE
|
|
\item CONSTRUCTOR\_UPGRADE
|
|
\item BODY\_UPGRADE
|
|
\end{itemize}
|
|
\end{enumerate}
|
|
|
|
\subsection{Function generation}
|
|
|
|
For these STATS, for which structures are already being generated, the following
|
|
still don't have any generated loading functions. Note that BASE and COMPONENT,
|
|
though they don't have a loading function of their own, are not mentioned in
|
|
this list because they are never loaded directly, but always as part of the
|
|
STATS that inherit from them.
|
|
\begin{itemize}
|
|
\item ECM. I'm not certain why I haven't yet implemented loading for this
|
|
STATS class. At first glance it seems simple enough. If next time I work on
|
|
this I discover (again) what its difficulty is I will document it.
|
|
\item REPAIR. This structure misses the ``body'' field, which is provided by
|
|
the COMPONENT class. I'm not yet certain how to work around this due to it
|
|
breaking the inheritance.
|
|
\item WEAPON. I'm not certain about the reason for not implementing this class
|
|
yet, though it might be related to its size.
|
|
\item BRAIN. Similarly to REPAIR this classes misses fields which COMPONENT
|
|
provides, specifically ``body'' and ``designable''.
|
|
\end{itemize}
|
|
|
|
\end{document}
|