Organization of .ssc files

[emgi]

Recently I have been playing with all kinds of add-ons and this made it necessary to modify object definitions in the ssc file. What I found is that the location of objects is sometimes not where one would expect it to be.
This is the case with moons. They can either be in 'numberedmoons', 'minormoons' or sometimes in 'solarsys'.
Also; is Ceres a dwarfplanet or an asteroid? The good thing is that I haven't found any duplicate entries and neither do I want to sound critical about such a minor issue in this great program.
In fact, I was looking into solutions to generate ssc-files from a database that holds all parameters for any object in the program. This would require creating separate tables for planets, major- or numbered moons and minor moons.
Separate tables are desirable to optimize the number of records in each table against the type of object. For example, minor moons and asteroids do not have an atmosphere, so putting them in a table with other objects that do would waste space and could make the extraction of the correct data needlessly complex.
So, separate tables are needed. The result would then be several tables where each table contains objects of a distinct class: Planets, minorplanets, majormoons, minormoons, asteroids, comets, spaceships, exoplanets and a few more.
This would result in a set of files with the above names that would be easy to manage.

Am I missing something obvious that explains why things are not organized in this way?
And if I may ask: How are the ssc-files maintained ?

[selden]

Grant Hutchison is the person who maintains the catalogs of planetary moons. He doesn't browse the Forum regularly, so you probably should try contacting him directly with a PM.

A thought: trying not to "waste space" in a database with only a few hundred rows probably is inappropriate considering the advantages of a uniform design.

[emgi]

A thought: trying not to "waste space" in a database with only a few hundred rows probably is inappropriate considering the advantages of a uniform design.

This would apply if one was intending to add almost half a million asteroids as well.
Not that it is my intention to load them all at the same time but at least the objective is to assemble a complete set.
I would simply like to preserve the option to load any object that exists if need should be.

It would also create the possibility to maintain info about add-ons like models and textures.

[granthutchison]

The file extrasolar.ssc is already maintained as you describe, using a table in which the published parameters are compiled, combined with some code which exports the ssc file in a form Celestia understands.
The entries for planetary moons are largely generated directly from JPL's Horizons ephemeris data: a bit of code parses the raw e-mail response to a Horizons query, and outputs the Celestia parameters.
The reason for the current distribution of planetary moons between several files is essentially historical, and I do try to describe the reason for the continuing existence of numberedmoons.ssc in the comments at the start of that file. Last time I discussed this with Chris (several years ago) we decided that the issue of backward compatibility outweighed the issue of logical file structure: potentially many more users would be inconvenienced by duplicate or missing entries if we started moving data around between files, than are at present inconvenienced by having to make a fairly brief search to find an entry they're looking for.

I have no strong feelings. If the development team is convinced a change is required, I can certainly implement it without much difficulty.

Grant

[emgi]

Thanks Grant,

This at least answers my questions. You do not need to bother about changing things.
The reason as given are both logical and satisfactory to me.
I am not a developer and I do not consider myself authorized to tell others what to do.
Perhaps I will start an experiment with a DB for our own solar system. For a start, this will be on my own system and when I consider the results satisfactory I will let you all know.

regards,
Leo

[John Van Vliet]

--- edit ---

[ajtribick]

I'm in the "this doesn't make sense" camp on this issue. As has been discussed in this thread, it is confusing to newcomers... those who have been using Celestia for years will of course not have any problems because they have had a long time to get used to it. At some point you have to decide whether a messy situation perpetuated by backwards-compatibility demands is worse than a one-time inconvenience to users from a reorganisation of the file structure. There are various oddities in Celestia like this (e.g. what units do we use for right ascension?), might be worth using the upcoming qt4 release as an opportunity to push a major version number and eradicate some of the inconsistencies.