Remove old sql doc.

doc/SQLite-stats-status.tex

@@ -1,103 +0,0 @@
-\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}