Why do we have STCs and SSCs?

[Malenfant]

Like the subject says - why do we have two separate input file types for objects in Celestia? Could we not merge them into one input type?

[chris]

It's an obvious and generally good idea to unify the two formats. But, it's a non-trivial amount of work to do so . . . Celestia originally allowed just a single star data file, and even though multiple files with star definitions are now allowed, the code is still structured so that all stars must be loaded before any planets can be defined.

When we do finally get around to unifying some of Celestia's data files, there will be some other issues worth revisiting such as how to better handle dpeendencies between catalog files.

--Chris

[Cham]

I like the way it is right now (two separate files for stars and planets). Things are well organised this way. When I see an STC file, I know exactly what kind of stuff is in there. Same thing for an SSC file. Why change this ?

[Malenfant]

I like the way it is right now (two separate files for stars and planets). Things are well organised this way. When I see an STC file, I know exactly what kind of stuff is in there. Same thing for an SSC file. Why change this ?

Because it means you can't do the same things to stars that you can do with planets and other objects (you can't animate a star with a Beginning and Ending, for example)?
Because it means you need two files to describe a system instead of one?

There's no reason for stars to be special objects that live in their own files, separate for everything else. I understand that it'd be difficult to merge them now, but it's a good idea for a later incarnation of the program.

[Paolo]

I would like to have a unique file extension for every kind of celestia data, even trajectories (.xyz), and star databases (.dat). Perhaps a packed format through zlib should be advisable.
I think that after 1.5.x it will be necessary to discuss about breaking the backward compatibility of data files (xml? lua? ...?).

Kind regards

[MKruer]

For what I do, is I have a data directory, for my project, then place in the stc file for all the star(s) and then create a separate ssc file for each planet. This way I can generate the stc file from my excel spreadsheet on a planet by planet basis. When dealing with 50 object in a file, it starts to make more sense to break it apart.

[Monolyth]

I will agree with the idea that stars and planets should be at least able to be defined in the same file. However I would keep the stc file for instances where defining a star or group of stars is all you want to do.

Secondly...and this is probly off topic but.....What about those puffy things that the galaxies are made of. I thought it might be cool to define their positions within some sort of file like an ssc or stc file. If their size and location and color colud be defined it would make for some neat effects in solar system files.

[Monolyth]

BTW....This is probly getting anoying to hear but I thought it is worth mentioning
I do have a program that helps with writing ssc files maybe I should consider making one to help with stars as well

any thoughts??

System Maker v1.4 has been hard to find but I finally got around to redisigning the download page

http://www.geocities.com/erinpatrickdun ... mMaker.htm

[selden]

Well, you don't need to mention it in every forum: there are few enough postings here most people read them all.

I think it would be nice if the main page described SystemMaker's goals. Right now it just presents it for downloading. While the "news" page is informative, it'd be nice if there were a main/summary page, too.

p.s. And, yes, a companion STC creator would be helpful, I'm sure.

[Monolyth]

Now that is just what I needed. Thanks for the feedback. I will do a little more tweaking of the web page...and now it seems that an STC editor is in order.

[duds26]

In the roadmap of celestia there is an addon manager.
But with that addon manager, there will be a new format (again) to define information about addons for the addon manager.

Mayby this is a chance to make a single format which describes everything in .stc, .ssc and .dsc files.

I will agree with the idea that stars and planets should be at least able to be defined in the same file. However I would keep the stc file for instances where defining a star or group of stars is all you want to do.

This can be handled by defining different catalogs in the new file format like this:

->catalogs for objects that are visible from outer space: space catalog: dscat
-> catalogs for objects that are NOT visible from outer space: local space catalog: lscat

scat can also do things that aren't visible but lscat shouldn't be able to hold things that are visible from outer space like stars or nebulae or galaxies.
(Because celestia will overlook them in order to be faster to render the stars and universe)
By keeping it separate, you can still make sure Celestia doesn't do unnecessary work (like going over all things that aren't visible).

(note: there are things that can belong to both but not on the same place and time, huge fictional space stations for example can exist on itself but also orbiting around a planet or sun)

For different versions, it should have a version numbering so Celestia and add on makers can know if it needs to be changed for a newer version. And this also makes older versions of Celestia recognize if it's newer than itself.

For demonstrating this, I'm going to assume a file format that I'm going to call celestia information catalog, with the extension .cic.
The contents of such a file would look like this (without everything between round brackets () ):


cic{0.0.5.2}

addoninfo
{
name "simple add on" (not necessary, celestia can use name of file that holds this information)
load y
version "0.5pre5"
license license.txt
authors
...
}

dscat
{
star (defining parameters)
star (defining parameters)
...
}

lscat
{
star(without defining parameters) + planets
star(without defining parameters) + planets
star(without defining parameters) + space stations??
star(without defining parameters) + comets
star(without defining parameters) + other things
}

If you want to separate it, this will work.
If you want to merge the two into one catalog. It could be a good idea to do it like this. However Celestia will run faster if it only has to look into the scats of a file. And defining a star in a local space catalog could be a bad idea.
But in addons, there aren't going to be like a 1000 or 10000 stars catalogged so it's not fatal for performance I assume. And Celestia can always skip the things that aren't visible like the planet's and so on.

(dscat stands for deep space catalog)

dscat
{
star(with defining parameters) + planets
star(with defining parameters) + planets
star(with defining parameters) + space stations??
star(with defining parameters) + comets
star(with defining parameters) + other things
}

Secondly...and this is probly off topic but.....What about those puffy things that the galaxies are made of. I thought it might be cool to define their positions within some sort of file like an ssc or stc file. I

For this something like the following could be written.

dscat
{
galaxie (with defining parameters) + puffy things
}

By the way, the puffy things of which you speak are actually suppose to represent nebulae of exploded stars.

[duds26]

There obviously are some drafts needed for something this big.

[selden]

Duds,

"scat" is not an appropriate filetype.
That word has, shall we say, inappropriate meanings in American English.

[duds26]

OOps, didn't know. Have replaced it with something better.
(This is terrible, an inapropriate word is standing in the way for a very little, slightly better performance of Celestia.)

Can this be something that's going to be integrated into Celestia in the future as replacement for ssc, stc and dsc??? Chris??

[selden]

As ChrisL mentions in his post near the top of this thread, a lot of code will have to be changed, as well as some serious thought given to how to handle inter-catalog dependencies. It won't happen soon

[duds26]

Well then. Mayby it's a good idea to make some drafts and let users do some input of what they would like to be changed and made better. This won't be done in a day or two.


Also not very like the idea of making an xml like file format. There is going to be a lot of work for the specifications. It will also make files bigger and be harder to write. The last two aren't worth having an xml. The most important of the celestia file formats is that they have open specifications, easy to write and as small as possible. Simple, functional and documented is a good motto to go along with.



(Let Celestia assume that everything is in the map with the .cic file which contains the addon description, belongs to the addon in that file.
There can than be only one addon definition but more than one .cic files in that folder. And if you want to include something from a different folder/addon. Just place a shortcut in the folder you're working from.)


(Handle inter-catalog dependencies in case of a conflict with an catalog hierarchy, alphabetically would be the most simple way of sorting.)


Example using relative paths:

Code: Select all

cic{0.0.2.1}

addoninfo
{
name "simple add on" (not necessary, celestia can use name of file that holds this information)
load y (for yes)
version "0.5pre5"
license license.txt
authors
dependencies \simple add on/dependencieaddon1/ And \simple add on/dependencieaddonhiresolutioncontent
(here comes relative link to other addon)
...
}


Example using names (Celestia can search the dependencies through the addon manager:

Code: Select all

cic{0.0.2.1}

addoninfo
{
name "simple add on" (not necessary, celestia can use name of file that holds this information)
load y (for yes)
version "0.5pre5"
license license.txt
authors
dependencies dependencieaddon1 And dependencieaddonhiresolutioncontent
(here comes name of other addon)
...
}