Page 1 of 1

Extendable Object Descriptions

Posted: 14.07.2009, 06:21
by bixel
Whats really great about Celestia is the ability to dump assets into the Extras folder and have it work.

What could be even great functionality for multiple uses (educational etc..) is that ability to add a text file that extends an objects description. I think - the current modability is to replace that object entirely (or upgrade it). For instance most laymen would not look up the star, Epsilon Eridani, by HIP 16537 (curiously it cannot be located by typing HD 22049.)

Should something be implemented to allow dynamic extendability to object descriptions? I have seen the scc code for planets, but I dont know what the scc code for stars look like. But maybe some kind of file can be linked to the star file, and add some lines

for example, Epsilon Eridani's planet b looks something like this

"b" "HIP 16537"
{
...
}

extending it maybe could look like this

"b" "HIP 16537" extend
{
replace (b, Obscuria)
}

or

"b" "HIP 16537" extend
{
add (b, Obscuria)
}

the key words replace, replaces the name "b" with "Obscuria", or alternatively add will add an alternative name "Obscuria" to the Description.

If this become too much of resource hog, maybe a batch file could be created to find the original scc code, and append/overwrite it with the updated information. Additionally - it would really be awesome to have a command that exports the scc code of the object. For instance if I wanted to view the scc code for Tau Ceti, I could right click on the star and export it, modify the code, then use a batch program to append/overwrite it.

Re: Extendable Object Descriptions

Posted: 14.07.2009, 10:28
by duds26
This will get very messy when used on big object with many definitions.
Imagine a star system with a base definition and some 200 extends and stuff scattered along thirty or more files.
It's best to define something in one place, to avoid these problem's, mess.

It's like mother always says: "clean up your room!"
Here it's not the room but the code for the addons of course.

The idea of being able to replace an object with another object seems fine.
But extending will only result in mess! A lot of it! And a dependency hell! (google for dll hell!)

Re: Extendable Object Descriptions

Posted: 14.07.2009, 22:55
by bixel
Yeh you are totally right - I thought more about it when I was sleeping. What could be nice tho is to make a batch file to got an updated the scc file you want to replace - if say you have more information and stats and such. For instance how would one go about updating a particular star in the stars.dat? is there a way? Or can we make a little forms program that allows you to edit it?

Re: Extendable Object Descriptions

Posted: 18.07.2009, 13:02
by duds26
The replace command would come in handy.

You could replace the ssc if you have more stats.
This won't make a mess of things.
A replace command to replace particular objects in a ssc could be programmed.
It is NOT implemented but from a programmers standpoint, it is possible to add this functionality.
EDIT: It is, for ssc at least: https://en.wikibooks.org/wiki/Celestia/SSC_File#Editing_Directives
Then you could use that command to just replace that particular star in the stars.dat file.

It would be nice if you could make objects private to your own addon.
Then you could replace that star without affecting other addons negatively.

And you can always, to be sure, make a little forms program to edit it.
When making an addon, you could distribute the modified stars.dat with it with some notes.
I do not recommend doing so because many users will forget they have modified it if they are able to do that.

Anyway this are just some thoughts.
Are these answers to your questions?

Re: Extendable Object Descriptions

Posted: 06.08.2009, 13:59
by duds26
Also a command to use certain bodies or everything from a specified addon would be nice.

Something in the line of the editing directives:
https://en.wikibooks.org/wiki/Celestia/SSC_File#Editing_Directives

Something like:

Code: Select all

Add "addon name"

Add uses all the added objects for your addon from the used addon.

Modify "addon name"

Modify changes only the modified objects listed in the addon for your addon.

Replace "addon name"
Replace adds and replaces everything from the addon, so that you can use everything in your addon.


All these directives should able addons to use structures and stuff from the used addon without interfering.
The objects in the addons need to be explicitly used.


This is much safer and less interfering with current way of making addons: everything sees everything, also for name spaces and catalog files.
Because of addons using objects that are changed.
This brings also the possibility to program that Celestia tells the user that it is missing (an) addon(s) and give the addon name(s).
This would be great functionality for Celestia!

Of course the user could change the appearance through e.g. the use of virtual textures,
then Celestia should keep track of those changes.

When an object has multiple versions under the same name, this could be a problem.

The addons could follow a hierarchical scheme where the first or last addon added in the file and it's objects and replaces are favoured in the addon that is using the objects.
The addon developers would need something to use the right addon if they want to do something that diverts from the scheme. This could also be used to make sure that the correct object is used.
Maybe something like this:

Code: Select all

useaddon "addon name" {
 /*Code that uses that particular addon
 just to be certain, or to use the right object.*/
}


To solve duplication objects problems, display everything but distinguish between the "different, same" object with the addon names. The addon names must be unique.
Celestia could add other stuff from addons that build to the right, correct object(s), orbits, moons, ... without interfering or problems.

Furthermore, the duplicate versions that are not used could be hidden to improve visibility.
But this is not such a good idea because addon makers might overlook that they are dealing with
"multiple, the same"/duplicate objects.