Feature Request - Editing or Deleting STC Catalogues...

[Dollan]

...Or, rather, portions of them.

I've just finished modifying the Xi Ursae Majoris system, updating it with currently know values (and further tweaking those for my own purposes). Unfortunately, when I eventually get this to the Motherlode, anyon downloading it will have to either modify their nearstars.stc catalogue themselves, or I will have to provide the modified version of that file with the add-on itself.

The ability to have a "modify" or even a "delete" decalration in an stc file would be of immense help, I think.

...John...

[t00fri]

John,

do I get it right, you request a GUI feature to "click away" scientific data?

Bye Fridger

[Dollan]

Simply making a request, Fridger, nothing more.

...John...

[selden]

Fridger,

People need to replace stellar information for many different reasons. For example, they may have access to updated orbital parameters which are not yet published or are not yet in the catalogs that were used to create Celestia's catalogs.

it would be best if one did not have to edit STC and DSC catalogs manually, just as one does not have to edit SSC catalogs manually.

[t00fri]

Fridger,

People need to replace stellar information for many different reasons. For example, they may have access to updated orbital parameters which are not yet published or are not yet in the catalogs that were used to create Celestia's catalogs.

it would be best if one did not have to edit STC and DSC catalogs manually, just as one does not have to edit SSC catalogs manually.

That I understand of course, but then I'd do that with a simple text editor? Did I still get something wrong?

Bye Fridger

[selden]

Fridger,

As you know, it's much too easy to damage text catalogs and then spend quite a while trying to determine exactly what is wrong. If the operators Add, Modify, Replace and Delete were available for all of Celestia's catalogs it would greatly reduce that waste of time.

[t00fri]

Fridger,

As you know, it's much too easy to damage text catalogs and then spend quite a while trying to determine exactly what is wrong. If the operators Add, Modify, Replace and Delete were available for all of Celestia's catalogs it would greatly reduce that waste of time.

I have generated the largest .dsc data sets for Celestia and never experienced any "waste of time" ...

I am also convinced that Grant never experienced any "waste of time" by using his rather "elementary" methods of editing huge amounts of stc data in the course of time...

But it's of course all fine with me as long as someone else is ready to code this "urgently requested" feature...

Bye Fridger

[Dollan]

Now, where did I mention that this feature was "urgently requested"?

It would be nice to be able to do, this simple request. It's not neccessary, it's not urgent. It is a simple request.

Ruffling feathers was not my intention; I can simply email such requests to Chris in the future (although I think this is only my second or third such request since 2003).

...John...

[t00fri]

Now, where did I mention that this feature was "urgently requested"?

It would be nice to be able to do, this simple request. It's not neccessary, it's not urgent. It is a simple request.

Ruffling feathers was not my intention; I can simply email such requests to Chris in the future (although I think this is only my second or third such request since 2003).

...John...

Sorry John,

indeed you didn't but Selden is defending it like Hell

Bye Fridger

[Dollan]

I really don't mean to be on the offense, Fridger. I certainly respect you as a scientist, and as a programmer for Celestia. But I don't see a reason why such a simple request needs a defense.

The request was made, reasons were given. Why the debate? It will either eventually be implimented, or it won't. Either way is fine with me.

...John...

[t00fri]

I really don't mean to be on the offense, Fridger. I certainly respect you as a scientist, and as a programmer for Celestia. But I don't see a reason why such a simple request needs a defense.

The request was made, reasons were given. Why the debate? It will either eventually be implimented, or it won't. Either way is fine with me.

...John...

Of course. Yet anything that requests programmer time in a way needs a defense, doesn't it? Since after all during the same time it takes, other projects could be implemented.

I was just expressing my opinion about the request. As I wrote, if Chris likes to code it ...perfect.

Bye Fridger

[selden]

Fridger,

You may be a perfect typist, but I certainly am not. I much prefer modifying parameters without touching the standard catalog files. That way I only modify the parameters of bodies that I want to modify, without having to worry about breaking other things. Too often I don't notice the damage until much later when I've long forgotten what I was working on that might have done the damage.

[t00fri]

Fridger,

You may be a perfect typist, but I certainly am not. I much prefer modifying parameters without touching the standard catalog files. That way I only modify the parameters of bodies that I want to modify, without having to worry about breaking other things. Too often I don't notice the damage until much later when I've long forgotten what I was working on that might have done the damage.

As you presumably know, I never type anything much by hand in these catalogs. Actually, I am a badly hampered left-hander forced to write with his right hand in early youth ...

I let PERL do almost any editing that exceeds a few lines...

Bye Fridger

[ajtribick]

I guess this is where it comes down to a difference in the big catalogue implementation approach and the detailed approach which tries to render a single system in as much detail as possible.

While for the default distribution of Celestia, the big catalogue approach is definitely appropriate, and also can be appropriate for add-ons, the detailed approach is definitely within the scope of add-ons.

For the detailed approach, PERL scripts aren't going to be much help! In the case of an add-on writer trying to implement more detailed information about a certain system that is already partially implemented in the big-catalogue approach, it is easy to run into problems with Celestia's current support for deletion/modification of objects!

The current solution involves writing a readme file instructing the user to comment out a certain part of the default files, etc. Now I know we all like to go on about how users should read these instructions, but unfortunately in the real world they don't. Having to modify the default files breaks the modularity of add-ons and makes uninstallation more difficult (particularly if multiple add-ons that require modification of the default files are involved - in which case redownloading the file off the CVS would not solve the problem!)

There is a good case to be made for implementing this stuff, though obviously there are other priorities as well.

[t00fri]

While I see some demand superficially from add-on writers (ONLY!), I think to be able to modify/ overwrite individual catalog entries in the way you or John advocate is enormously prone of errors. The main reason is that one may easily forget about taking these modifyers out again at a later stage!

How would you be warned that Celestia is now using the wrong parameters for some 'nearstars' binary system for example??

Bye Fridger

[Dollan]

Just to make certain that we're on the same page, I was talking about being able to use the "modify" declaration, at least, in an stc file.

For example, the Xi Ursae Majoris system I'm working on required me to go in and actually delete the entry from the nearstars.stc file, and then to make a whole new stc file for that star (forget the reasons why I did so for the moment). Simply making a new stc file without deleting the previous entry would not work, not without actually doubling up the stars of the system.

Being able to write an stc file and use a "modify" declaration, as can be done within an ssc file, would have been much easier, and would not require messing with a core data file for the program.

Also, I can certainly see how such a thing would be very useful even for truly scientific representations. One never knows when, for example, some nearby star might be found to have a new compaion star, or some parameter of it might be refined to some degree.

...John...

[t00fri]

...
Also, I can certainly see how such a thing would be very useful even for truly scientific representations. One never knows when, for example, some nearby star might be found to have a new compaion star, or some parameter of it might be refined to some degree.

...John...

In case of scientific news, Grant adapts our official data usually within a VERY short time and everybody is welcome to download the changed files from CVS. ...and unlike an unspecified number of unexperienced users, Grant does such kind of scientific updates CORRECTLY!

Yesterday , for example, Grant has updated 3 (!) location files, with the new IAU location names for Enceladus & Titan, Venus and Mars!

OK, suppose there were some people being so impatient as to need that new compagnon star you mentioned before Grant has calculated and implemented the proper adapation of its data to the Celestia frame.

Why would that be in any way inconvenient to do with a simple editor!

I doubt that a user unable to use a simple editor will be able to calculate the correct orbital transformations for Celestia ...just to stay with your example.

Bye Fridger

[Dollan]

Well, regardless of a person's ability to CORRECTLY do something, I still don't see the big deal about being able to use a "modify" declaration. Some folks have other reasons for changing the data.

But again, this is a simple requestr. And yes, I know there are far more important things to spend coding time on. That's why there are prioritized lists of things to do!

Anyway, I've given my request, I've given my reasons. There's really no need to keep hashing this out over and over. As I said, it will either eventually be implimented, someday, or it will not. The point is that the request is on record.

Thanks for you input.

...John...