About the data folder...

[ElChristou]

I'm wondering if it could be possible to organize the data folder like this for example:



Note that the solarsys.ssc don't exist anymore, each planet get it's own system ssc; all locations files begin by locs_ (just for a question of sorting), also the binaries catalogues have been rename for the same reason. The asteroids files have been also renamed (asteroids_kuiper and asteroids_inner)...

Now I'm also wondering if it would be a problem for Celestia (speed at start up) to load several files instead of one (in case of minormoons for example)...

Opinion?

[Malenfant]

Actually, I was thinking the exact opposite - merge as many files as possible so you have less of this stuff. My counter-proposal would be this:

All the planets, asteroids, comets and moons in the solar system are in one file called "solarsys.ssc". At the very most, you could separate this into "planets.ssc", "moons.ssc", "comets.ssc", and "asteroids.ssc" (and maybe a "locations.ssc" file covering all locations on every body in the solar system. Moons with uncertain orbital characteristics can still be in a "poormoons.ssc" file though.

All extrasolar planets would be in a single "extrasolar.ssc" file.

All spacecraft would be in a single "spacecraft.ssc" file.

All multiple star systems would be in a single "multiplestar.stc".


And that would be that for sscs. no "minor moons", no "numbered moons", just keep all the moons together whether they're big or small or numbered or not. I would like to see as many as possible files combined and merged, not split into further subdivisions. This makes things a LOT easier to manage and keep track of.

[ElChristou]

Yes it's also a solution in which I was thinking, but the above is just to have a easy to read format (and also to update); you want to know all about jupiter system? just go to one place...

For the minor/numbered files I agree, here was just to keep the actual distinction...

Another solution would be a sub folder with all locs, another only comets, another only asteroid... (EDIT: as you (Mal) was proposing above...)

[Malenfant]

I have a bias against lots of subfolders myself, makes it hard to manage (plus it adds lots of unnecessary travelling through the folder tree to get to where you want to be). I'd rather have everything sitting in the data folder and that's it.

[chris]

I personally think that the current scheme strikes a nice balance between too few and too many files. But since Grant has been handling most of the updates to the data files, I'm inclined to let him choose the organization that he prefers.

--Chris

[ElChristou]

Yep, indeed Grant is the man to give a pratical opinion; I suppose if the files are what they are it's for good reasons, it's just sometimes it's not so easy to retrieve an update etc...

@Mal:

The only bad points in having such a solarsystem.ssc containing ALL stuff is that will be a pain to browse (ok, you can always use a search feature but it's not always practical...)

[BrainDead]

Yes it's also a solution in which I was thinking, but the above is just to have a easy to read format (and also to update); you want to know all about jupiter system? just go to one place...

Chris, I like the LOGIC of what you're laying out above, but I still agree with
Malenfant here. Wouldn't it be less program-intensive to have a single file
with all moon properties? Again, just my opinion, and obviously I don't have
a clue as to what it takes for Celestia to locate the proper files for a given
object.

Whatever you guys decide is fine with me. I just thought I'd make the
suggestion. That's all...

[ElChristou]

I start the topic having in mind a perhaps futur file manager or file installer; it would be easy to sort many files in a logic way with the sub folders. Let say that one want to install some trojans for jupiter, the new file could be created in the jupiter folder...
Pluto is not anymore a planet? remove the whole dir and update the adecate files; I suppose this scheme would permit whatever change keeping a great coherence within the files...

Now it's clear that if you browse your folders one by one it's not really pratical but for this there is in osX (and Windows) a list presentation like the above...

[Malenfant]

The only bad points in having such a solarsystem.ssc containing ALL stuff is that will be a pain to browse (ok, you can always use a search feature but it's not always practical...)

Maybe, but why would you want (or need) to browse it? The whole point is that it's the input file for Celestia - if you want to look at Dione, you go to Dione in Celestia and see the info given there if you have infotext or verbose mode.

And rather than creating new files, I think it would make more sense to edit existing ones. Otherwise you just end up with loads of little extra files everywhere.

[ElChristou]

The only bad points in having such a solarsystem.ssc containing ALL stuff is that will be a pain to browse (ok, you can always use a search feature but it's not always practical...)

Maybe, but why would you want (or need) to browse it? ...

In theory you are right, of course... but tell me, don't you never browse any of the data files? I pretty sure all of the "serious" (active) members have been browsing those files once or many times; it's also a way to learn lots of things I suppose...

[Malenfant]

The only bad points in having such a solarsystem.ssc containing ALL stuff is that will be a pain to browse (ok, you can always use a search feature but it's not always practical...)

Maybe, but why would you want (or need) to browse it? ...

In theory you are right, of course... but tell me, don't you never browse any of the data files? I pretty sure all of the "serious" (active) members have been browsing those files once or many times; it's also a way to learn lots of things I suppose...

I don't browse them actually. If I want planetary data I go somewhere like the NSSDC Planetary Data sheets. The format is much more convenient to read there.

[ElChristou]

The only bad points in having such a solarsystem.ssc containing ALL stuff is that will be a pain to browse (ok, you can always use a search feature but it's not always practical...)

Maybe, but why would you want (or need) to browse it? ...

In theory you are right, of course... but tell me, don't you never browse any of the data files? I pretty sure all of the "serious" (active) members have been browsing those files once or many times; it's also a way to learn lots of things I suppose...

I don't browse them actually. If I want planetary data I go somewhere like the NSSDC Planetary Data sheets. The format is much more convenient to read there.

Mal, don't take it bad, but I think you are too much focused on your own use; I try here to think in a very general scheme* for all kind of users... it's an anticipation exercice...
I know this topic is not very important but it's part of some polishing work that can be done "quite" easely right now. As I'm not an expert in coding nor in maths nor in physics nor in astronomy, let's say I represent the basic user; actually at first sight (remember the very first time you have open Celestia folders) things are not so easy to understand immediatly. With time we all know what is outersys.ssc for example, but no newbie will know it's a kuiper belt asteroid catalogue without opening it. Even some old folks (recently Bob) still have some trouble from time to time...

*Perso lately I don't browse those files much more...

PS: Tx for the link!

[rthorvald]

rather than creating new files, I think it would make more sense to edit existing ones. Otherwise you just end up with loads of little extra files everywhere.

Everybody obviously have their own routines, but as i see it, it is far more effective to work on many logically grouped files (either by subdirectories or by a naming scheme) than to put everything in one big single file.

It may be that it is more effective for the computer to load everything from one file, but for the editor, it is easier to work with the opposite.

When the Solar system files becomes complex enough, it *must* be easily browsable for a human. Else, it will be a nightmare to maintain for the developer. And trust me, i know - after working a year now on a Ran system that is just as complex as the default solar system installation. The only way to understand the layout and inter-dependability of thousands of objects without special software for it is to have it easily grouped and browsable from the outside.

I don??t know if ElChristou??s scheme is the best possible solution, but it is very much like what i have had to adopt myself already. And even *that* is a chore to navigate in.

- rthorvald

[ElChristou]

Now, I wondering if it could be possible to create 3 official data sets (low, medium; high)...

The low one would have all data reduced to minimum for people working on very specific issue (for example Nasa with shuttle visualisation or Esa with Mars missions); here no need of thousands of stars, no need of comets/asteroids, only a few deepsky objects, no need of binaries catalogues, no spacecrafts, no need of minor/numbered moons, no need of locations...
This set would be also very useful for testing purpose for dev team and addons creator to reduce the loading time to almost nothing...

The medium would be almost the same as the actual default set, perhaps with a troncated deepsky catalogue;

The high would have all data at full, including trojan asteroids, all serious catalogues (Selden's one for example), deepsky at full, Millions stars, pulsars, binaries, a few more spacecrafts etc...

To use such data sets, actually one would need 3 differents config files to load one of those data set... the good point of 3 data sets would be to point to 3 differents extra folder...

Now how to change the config files at start up?
Under linux I'm almost sure there is a command line for this, but for the basic (Windows) user?
Could it be possible to have a key binding at start up to load a choice panel? something like:

Code: Select all

---------------------------------------------
-            choose your config:            -
-                                           -
-                                           -
-                 * low                     -
-                 * medium                  -
-                 * high                    -
-                                           -
---------------------------------------------


if the key is not pressed, Celestia would load the default set (medium)...

opinion?

[chris]

Now how to change the config files at start up?
Under linux I'm almost sure there is a command line for this, but for the basic (Windows) user?

There's a command line option for all platforms that lets you select which configuration file to use. For Windows, we could create two shortcuts with different command lines:

Medium res:
celestia --conf celestia.cfg

And high res:
celestia --conf celestia-high.cfg

Could it be possible to have a key binding at start up to load a choice panel? something like:

---------------------------------------------
- choose your config: -
- -
- -
- * low -
- * medium -
- * high -
- -
---------------------------------------------

if the key is not pressed, Celestia would load the default set (medium)...

We could, but I prefer having the installer create two shortcuts so that I don't have to look at a menu every time I start Celestia.

--Chris

[ElChristou]

...I don't have to look at a menu every time I start Celestia.

Of course, I don't want too, perhaps I haven't express correctly the idea; here the sequence:

-double click on Celestia icon = loading default set (medium)

- a special key (must be define) + double click on Celestia Icon = Choice panel

[ElChristou]

Perhaps my idea on the data folder is not very exciting but at least it is relationed with an extraordinary fact (well, for me...); one of my very first post was a bug report about a strange behavior (see arrows in top picture) with Mars atmosphere using NVC+ARB VP...

Now I came over this: meanwhile I was playing with new data folders and new config files, I realize by accident that this bug (I live with it since I met celestia) has vanished!!

Here a pict: top: NVC+ARB VP using config file A, bottom: using config file B; the problem is that I'm unable to determinate what cause the bug or what eliminate it...



Here the config files: If someone has an idea... (between us I still cannot believe that the config file can be responsible of such bug!!)

Config A:

Code: Select all

Configuration
{
LuaHook            "luahookinit.lua"
StarDatabase         "data/Low/stars.dat"
StarNameDatabase      "data/starnames.dat"
StarCatalogs         ["data/revised.stc" "data/nearstars.stc"]
HDCrossIndex         "data/hdxindex.dat"
SAOCrossIndex         "data/saoxindex.dat"
SolarSystemCatalogs      ["data/EC_solarsys.ssc" "data/Low/asteroids_inner.ssc" "data/Low/comets.ssc" "data/Low/asteroids_outer.ssc"]
DeepSkyCatalog         "data/Low/deepsky.dsc"
AsterismsFile         "data/EC_asterisms.dat"
BoundariesFile         "data/boundaries.dat"
InitScript         "scripts/start.celx"
DemoScript         "scripts/demo.cel"
ExtrasDirectories      ["extras"]
Font            "sans12.txf"
LabelFont         "sans12.txf"
TitleFont         "sansbold20.txf"
FaintestVisibleMagnitude   6.0
RotateAcceleration      80.0
MouseRotationSensitivity   1.0
OrbitPathSamplePoints      100
RingSystemSections      200
ShadowTextureSize      256
EclipseTextureSize      128
AntialiasingSamples      1
#IgnoreGLExtensions      [ "GL_ARB_vertex_program" ]
LabelledStars         ["Le Soleil" "Sirius" "Canopus" "\u03b1 Centauri" "Arcturus" "Vega" "Capella" "Rigel" "Procyon" "Achernar" "Betelgeuse" "\u03b2 Centauri" "Altair" "Aldebaran" "Antares" "Spica" "Acrux" "Pollux" "Fomalhaut" "Deneb" "\u03b2 Crucis" "Regulus" "Adhara" "Castor" "\u03b3 Crucis" "Shaula" "Bellatrix" "Elnath" "Miaplacidus" "Alnilam" "Al Nair" "Alioth" "\u03b3 Velorum" "Dubhe" "Mirfak" "Wezen" "Alkaid" "\u03b5 Carinae" "\u03b2 Aurigae" "Polaris"]
}


Config B:

Code: Select all

Configuration
{
LuaHook            "luahookinit.lua"
StarDatabase         "data_low/stars.dat"
StarNameDatabase      "data_low/starnames.dat"
StarCatalogs         [
            "data_low/revised.stc"
            "data_low/nearstars.stc"
            ]
HDCrossIndex         "data_low/hdxindex.dat"
SAOCrossIndex         "data_low/saoxindex.dat"
SolarSystemCatalogs      [
            "data_low/Solar_System/Asteroids/pluto.ssc"
            "data_low/Solar_System/Comets/comets.ssc"
            "data_low/Solar_System/Earth/earth_system.ssc"
            "data_low/Solar_System/Earth/locs_earth.ssc"
            "data_low/Solar_System/Earth/locs_earth_capitals.ssc"
            "data_low/Solar_System/Earth/locs_moon.ssc"
            "data_low/Solar_System/Jupiter/jupiter_system.ssc"
            "data_low/Solar_System/Mars/mars_system.ssc"
            "data_low/Solar_System/Mercury/mercury_system.ssc"
            "data_low/Solar_System/Neptune/neptune_system.ssc"
            "data_low/Solar_System/Saturn/saturn_system.ssc"
            "data_low/Solar_System/Uranus/uranus_system.ssc"
            "data_low/Solar_System/Venus/venus_system.ssc"
            ]
DeepSkyCatalog         "data_low/deepsky.dsc"
AsterismsFile         "data_low/asterisms.dat"
BoundariesFile         "data_low/boundaries.dat"
ExtrasDirectories      [ "extras" ]
InitScript         "scripts/start.cel"
DemoScript         "scripts/demo.cel"
Font            "sans12.txf"
LabelFont         "sans12.txf"
TitleFont         "sansbold20.txf"
FaintestVisibleMagnitude   6.0
RotateAcceleration      120.0
MouseRotationSensitivity   1.0
OrbitPathSamplePoints      100
RingSystemSections      100
ShadowTextureSize      256
EclipseTextureSize      128
AntialiasingSamples      1
# IgnoreGLExtensions      [ "GL_ARB_vertex_program" ]
LabelledStars         ["Le Soleil" "Sirius" "Canopus" "\u03b1 Centauri" "Arcturus" "Vega" "Capella" "Rigel" "Procyon" "Achernar" "Betelgeuse" "\u03b2 Centauri" "Altair" "Aldebaran" "Antares" "Spica" "Acrux" "Pollux" "Fomalhaut" "Deneb" "\u03b2 Crucis" "Regulus" "Adhara" "Castor" "\u03b3 Crucis" "Shaula" "Bellatrix" "Elnath" "Miaplacidus" "Alnilam" "Al Nair" "Alioth" "\u03b3 Velorum" "Dubhe" "Mirfak" "Wezen" "Alkaid" "\u03b5 Carinae" "\u03b2 Aurigae" "Polaris"]
}


[dirkpitt]

...I don't have to look at a menu every time I start Celestia.

Of course, I don't want too, perhaps I haven't express correctly the idea; here the sequence:

-double click on Celestia icon = loading default set (medium)

- a special key (must be define) + double click on Celestia Icon = Choice panel

I've been wondering for some time whether to implement this (option key pressed during Celestia launch bringing up a menu) on the OS X version of Celestia. While specifying a command-line parameter is possible on OS X (and is in fact implemented), it is much more unintuitive than for Windows or Linux.

For example, on OS X, I have to type:

Celestia.app/Contents/MacOS/Celestia --whatever

Creating a shortcut that specifies the option for the user is also possible, but involves creating a shell script.

[ElChristou]

I've been wondering for some time whether to implement this (option key pressed during Celestia launch bringing up a menu) on the OS X version of Celestia...

Cool, I think it worth a try...

[ElChristou]

(between us I still cannot believe that the config file can be responsible of such bug!!)

AArrghh!! found it... the config files have nothing to do with that of course...
It's a normal map declaration which is responsible of this bug...
I'll have to live with it till I change my laptop I fear...