A New Celestia Data Model Proposal
By Paolo
Angeli ver. 01 2004/11/24
In order to prepare Celestia 1.x to manage add-on automatically it is
necessary to redefine the data model to reorganize the structure of the folders
and to introduce the necessary files.
To develop the data model I’ve used Access that allows to represent graphically the tables and the relations
between them. The resulting scheme reports all the fields of the data model.
I’ve used Access to prototype the forms that are necessary for the
implementation of the add-on manager client included in Celestia.
The server side of Motherlode should be
implemented using this data model. Motherlode
actually is developed upon my-sql and using php. I have competence for a realization that uses Access
and asp. It is necessary that someone implements the data model for Motherlode. As the analysis is almost complete it shouldn’t
be very difficult indeed.
Using the Access schemes I’ve prepared the following specification.
In order to
get the optimal functionalities from the automated add-on management system it
is necessary to revise completely the folders structure of Celestia.
…
1 Celestia
1 UI
1 System
1 Schemes
1 [a]
1 [b]
1 [..]
1 Data
1 Temp
2 system.cdb
1 System
2 authors.cdb
2 contributionTypes.cdb
2 configurations.cdb
2 installation.cdb
(*)
2 installationModules.cdb
(*)
2 modules.cdb
2 sections.scb
2 sectionTypes.cdb
2 versions.cdb
1 Modules
1 Standard
2 manifest.cdb
2 *.jpg
2 *.dat
2 *.xyz
2 *.ssc
2 *.dsc
2 *.cmod
2 *.3ds
2 *.cel
2 *.celx
2 *.*
1 [m1]
2 manifest.cdb
2 ...
2 *.*
1 [m2]
2 ...
1 […]
1 Develop
1 [d1]
1 [d2]
1 […]
* These file area used by the add-on manager
·
cdb : Celestia Database (New Hashed container of all
Celestia data)
·
dat : Celestia data usually star definitions
(deprecated)
·
ssc : Celestia bodies data used for planets,
moons, probes, locations, etc (deprecated)
·
xyz:
Model path typically is used to drive probes (deprecated)
·
jpg:
Textures
·
png: High quality textures and effects
·
dds: Large textures optimized for Graphic board
memory
·
3ds:
Models for bodies and probes
·
cmod: Models Optimized for Celestia usage
·
cel: Old style Celestia script
·
celx: Celestia script in LUA language
·
Galaxy
·
Nebula
·
Star
·
Barycenter
·
Planet
·
Moon
·
Asteroid
·
Comet
·
Spacecraft
·
Location
The
Celestia data model relies upon the following basic concepts:
·
Data
files
·
Objects
·
Modules
·
Sections
·
Configuration
The Celestia data files contain specific information about Celestia
objects and about their properties such as model files, ZXY paths, textures and
so on.
The modules are the containers for the distribution of Celestia data. A
module can be considered as the collection of data files. When distributed as
add-on the module is a zip file that when unpacked spreads the data file into
Celestia.
The sections are the logical containers of the Celestia data. A module
can contain data of different sections. The usage of sections
have many useful advantages. First of all can
categorize the Celestia data in families or groups. Some examples should
be:
·
system
(all the data that are at least necessary for the correct Celestia functioning)
·
real/Sol
comets
·
real/Jupiter
minor moons
·
real/Sol
asteroid belt objects
·
real/Sol
kuiper belt
objects
·
real/Stars
within 25 Ly
·
real/Galaxies
·
real/Quasars
·
fictional/Star
Wars
·
fictional/Star
Trek
·
etc.
The full
implementation of the Sections concept should allow the Celestia user to switch
on and off some of them interactively in order to get an extremely realistic and
complete configuration or a completely fictional and very light one.
The
configuration is the list of modules and sections that the user prefers to
enjoy Celestia. The user can create many configurations each containing a
different list of modules and of sections. The configuration can contain also
the Celestia set-up preferences. This allows to create completely different
environments that the user can choose when Celestia starts.
This chapter describes briefly how should function the add-on manager
system on the local user machines.
First of all when the synchronization procedure is started, if an
internet connection is available, Celestia uses its internet module, connects
to Motherlode and downloads the file [system.cdb] in a temporary
local folder.
Celestia compares the entries in this temporary file with the entries in
the local [system.cdb] file
already present in the data\system
folder. If the entries are different then downloads and overrides the necessary
file in the data\system folder and
then overrides the file [system.cdb].
If a new version of [modules.cdb] is available
then Celestia:
·
opens
the local file [localmodules.cdb];
·
adds
the new Module IDs present in [modules.cdb];
·
updates
the Module IDs that have been updated with new versions by the authors in Motherlode since the last connection;
·
marks
all the modules that are suitable for an update,
·
marks all the modules that are ob
Celestia add-on manager prompts the user with a checklist for the
selection of the modules suitable for update. The marked modules will be downloaded
to/removed from the local repository in the folder data\modules.
User can check some options in the add-on manager that allows to:
·
keep the preferred sections (I.e. “Fictional/Star Wars”) updated automatically;
·
keep
the modules already downloaded updated automatically when newer version is
available in Motherlode;
·
remove automatically the ob
When the file are downloaded then Celestia
creates the appropriate folders in data\modules
and unpacks them automatically (Add-on data modules are zip format).
Each zip data module represents a folder that contains all the add-on
files without a further internal folder subdivision. Models, textures, scripts,
catalogs etc. are contained in the same module folder.
Celestia objects (stars, planets, moons etc) that are defined more than once are
overridden and the last one takes priority. So the loading order of the modules
is very important. By default the order is defined by Motherlode
administrator that updates the order field in table modules that generates the
[modules.cdb].
The order can be redefined locally by the user using the add-on manager that
updates the file [localmodules.cdb].
To function correctly each module folder must contain
a file named [manifest.cdb] that Celestia uses to
load the Celestia data and all the related models, textures and so on.
The user can define many configurations to use different modules
separately.
Through the add-on manager, the user can build his own configuration
using a check list that reports the available modules downloaded by Motherlode. Then Celestia updates the [configurations.cdb].
In the modules present in a configuration there are many sections.
Through a check list the user can define which sections are included in the
configuration. Celestia Updates the configurations.cdb
When installed
Celestia creates the file [installation.cdb].
It contains the data used by Celestia Motherlode to
keep track of the synchronizations performed by all the installations worldwide
that connects for updating.
#
# Celestia current installation
#
Installation “ffes4563fettsd3245” #UCIID Universal Celestia Installation
Identifier
{
Version 1.4.1
Installed @2004:
Updated @2004:
}
With the standard distribution package there is [system.cdb].
This file contains the system cdb modules and is used
for the synchronization with Celestia Motherlode.
#
# Celestia system
#
SystemFile “Authors”
{
Version 75
Updated @2004:
}
SystemFile “Versions”
{
version 23
Updated @2004:
}
SystemFile “Modules”
{
version 135
Updated @2004:
}
SystemFile “ContributionTypes”
{
Version 3
Updated @2004:
}
SystemFile “Sections”
{
Version 25
Updated @2004:
}
SystemFile “SectionTypes”
{
Version 5
Updated @2004:
}
The [authors.cdb] is used only by the add-on
manager. It generates a C++ STL map of records that are used for display authors information about the modules.
#
# Celestia Authors file Ver.
123 Date 2004/11/22 15:02:09.012
#
Author 1
{
nickname “chris”
name “Chris”
surname “
location “
email “
url “www.shatters.net”
date @2004:
}
Author 2
{
...
}
Author n
{
...
}
The [versions.cdb] is used to resolve the
version requirements of the various modules. It generates a C++ STL map of the
Celestia versions. If an add-on requires a beta version of Celestia, the data
used to warn the user is extracted from this map.
#
# Celestia Versions file Ver.134 Date
2004/11/22
#
Version “1.4.0.6”
{
notes “Beta six: Bug fixing.”
date @2004:
}
Version “1.4.0.5”
{
notes “Beta five: Implemented Multiple eclipse shadows.”
date @2004:
}
...
Version “1.3.2”
{
notes “Minor release see changes log.”
date @2004:
}
...
The [configurations.cdb] will generate a C++ STL map of the
configurations that the user can create to manage different Celestia
environments. When Celestia starts loads this file and prompts the user for
choosing one configuration. When started
the user can change configuration and Celestia unloads all the old
configuration modules
and loads the new configuration modules.
#
# Celestia Configurations file
#
Configuration “Default”
{
modules [ 1 3 4 7 8 9 12 14 15 18 25 27 28 30 35 37 39 40
42]
sections [ 1 2 5 6 8 23 ]
}
Configuration “Star wars”
{
modules [ 1 3 4 8 12 14 18 25 28 35 37 39 40 42 52 53 54 55
56 58 59]
sections [ 1 2 12 13 14 23 ]
}
Configuration “My development”
{
modules [ 1 3 4 8 12 42 52 59]
sections [ 1 2 12 ]
}
...
The [sections.cdb] is used to store data about
the groups of Celestia objects. It generates a C++ STL map of sections that are
to categorize the Celestia objects.
#
# Celestia Authors file Ver.
123 Date 2004/11/22 15:02:09.012
#
Author 1
{
nickname “chris”
name “Chris”
surname “
location “
email “
url “www.shatters.net”
date @2004:
}
Author 2
{
...
}
Author n
{
...
}
The [localmodules.cdb] is the list of the modules
in the system:
#
# Celestia Installation modules
#
Modules
[
{ID 1 avail 2004/11/22 updated 2004/11/22}
{ID 2 avail
2004/11/22 updated 2004/11/22}
{ID 3 avail
2004/11/22 updated 2004/11/22}
{ID 4 avail
2004/11/22 updated 2004/11/22}
{…}
{ID 60 avail
2004/11/22 updated 2004/11/22}
}