add-in's

[ogg]

Ultimately, the ideal way of organising solar system objects for all stars might be to store them all in a single binary: a centralised database something analogous to the windows registry, with nested 'folders' with keys and string values defining unique objects by hierachy without the possibility for doubleup.

Of course, this would requre a regedit-analog client to view and hack the thing, and as I'm not a programmer I have no idea if this idea is feasible in terms of time economics. I *am* a type-A-personality tweaker from way back though, and it seems to me that what you're wanting is a way of keeping a single Celestia universe defined without conflicts arising, just like a single registry (except smaller and simpler!). Then you could bypass the whole problem of reading ssc's directly and distribute them like .reg files: packets of text that you can selectively import into (or export from) the object registry.

single branches might look like:

STARID\Planet name\Moon name
STARID\Comet name
STARID\Planet name\Sattellite name
STARID\Space probe name

with the same string values we already use at each level, defining/describing that object (but not the star, which is just an anchor). Not the most direct, hands-on-code approach for you script-jocks out there, but safer, more powerful and more user-friendly if you ask me. And that way you could tweak, try, add, backup and delete whole systems of planets to your heart's content. You could also perhaps tag different objects by status (ie scientifically established, nominal, fictional...) with an in-UI option to filter and display only certain objects or swap the entire file with one for an alternative universe, just like (essentially) we're doing now with copying over the solsys.ssc.
Updating new extrasolars or orbital elements for example would be easy: just import the new data into the object registry without copying over anything except the updated values. And newly supported values ('orbitcolour=rrggbb" perhaps, or 'alwaysdisplayorbit=true'?) could progressively make their way in without having to dump your entire old solar system for the upgrade (ie back up the old one then import it or something like that).

Would it be all that difficult then to eventually be able to load whole different object registries (ie alternate possible ways the universe might be, given that the stars are the same) from inside Celestia without copying-deleting at all? Ie have a standard file format for Celestia where each file contains a single, coherent definition-set for all sub-stallar objects; that you can load, import-export from, edit and save like any other file type.

It seems to me that this would be a logical next step for Celestia anyway; from universe assembler (from many different, potentially cluttered input scripts) to universe viewer-tweaker (...to universe editor?). Then save your universe and distribute it I guess. Fictional astronomy as art.

Anyway. Just thinking on the keyboard. Viable?

ogg

[Silh]

Ick, single binary Windows registry-like structure = bad.

A text file format is much nicer for hand-editing, searching/modifying with standard tools, reading/generating data with scripts, etc. I would find having to use an extra program to manipulate the data rather annoying as well.

My suggestion for handling multiple definitions in .ssc files in the extras/ directory is to parse them in some recognized order, such as alphabetical. Any re-definition would simply override the previous one (and the data/ default definition, if applicable). If I remember correctly from my days of playing around with Quake, it dealt with the .pak files (yet another annoyance to edit, albeit convenient for distributing multiple models/graphics/maps/etc. in a single package) in numerical order, as the files were restricted to pak[0-9]*.pak. If I wanted to override something (eg. temporarily), I would just stick a new definition in the next higher numbered .pak, usually with a symlink. Granted, using symlinks to organize the .ssc files would not be an option for everyone, and they would have to copy/rename files.

Something which might be useful would be the ability to reload the data/textures without restarting the program. I haven't delved into the code too much yet, so I'm not sure how difficult this would be to implement. Maybe close/restart the renderer, except don't run start.cel, but keep the old coordinates?

And one last feature request (I'll be looking at the code later today after I get Mesa working on my system here) is for rendering of stars as both dots and circles, so that they end up as dots when far enough away.

[Matt McIrvin]

And one last feature request (I'll be looking at the code later today after I get Mesa working on my system here) is for rendering of stars as both dots and circles, so that they end up as dots when far enough away.

This is how the stars-as-points mode (control-S) already works. The stars are still rendered as spheres close up.

Or did you mean that circles would be used for the brightest stars even at large distances? That could be used to extend the apparent dynamic range of brightnesses.

[Silh]

Yeah, that's what I meant, so that the brightest stars are circles if they are bright enough, and otherwise a point. I find that stars as circles makes them look much too large; stars as points looks good, especially with the stars visible maxed out, except I can't pick out the brightest stars (eg. constellations) anymore.