\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}