Question to users who know C++

[don]

Howdy Cereb,

Welcome to Celestia!

I know some C++ but I have no idea how I can help... any sugestions?

Excellent question ... (See bottom of message for a suggestion.)

Hey group, I don't think there is anything in these forums that describes how a user can help with the Celestia project, is there? Selden's LONG List of Resources for Celestia (http://www.lepp.cornell.edu/~seb/celestia/) page is probably the closest thing we have right now.

We have a User's FAQ, but not a How Can I Help With the Celestia Project FAQ. Wow, this alone could be a project in itself, and should *probably* be located on the Celestia web site. This new FAQ would be a real good place to provide information for folks with various experience / backgrounds, such as:

Programmers
* Discuss SourceForge (what, where, how to use)
* Link to the Celestia SF Project page:
(http://sourceforge.net/projects/celestia/)
* Link URL that describes the Celestia code sections:
(http://cvs.sourceforge.net/viewcvs.py/celestia/celestia/devguide.txt)
* Link URL to the coding standards document:
(http://cvs.sourceforge.net/viewcvs.py/celestia/celestia/coding-standards.html)
* Link to the developer mailing list on SourceForge:
(http://sourceforge.net/mailarchive/forum.php?forum_id=9864)
* Link to page that describes how to use CVS:
(http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1)
* Link to Christophe's source Cross-Reference page:
(http://www.teyssier.org/lxr/http/source/)
* more

Graphics (texture) folks
* Graphic file types used in Celestia
* How textures are used / structure of the textures folders
* Discussion of Textures/VTs in Celestia
* Links to photo acquisition sites
* more

3-D modeling folks
* Model file types used by Celestia
* Where models are stored and how they are used
* Discussion of modeling for Celestia
* more

Astronomers / Physicists / Planet Builders
* Links to description of Celestias data files
* Description of how Celestia calculates things
* Links to code sections that handle astro computations
* more

Educators
* Links to Frank's educational-related files / activities
* Links to NASA's educational stuff?
* Links to exploratory Celestia scripts
* Discussion about writing educational materials
* more

Probably many others too <smile>
*
*

What do you think of having a FAQ / web page like this folks?

Anyone up to the task?

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
To answer Cereb's question ...

If you are interested in taking a look at the Celestia source code, you can find it via the Celestia project page (http://sourceforge.net/projects/celestia/) on the SourceForge.net web site. You may have to sign-up for a SourceForge account first. On the project page, there is a section that provides links to the individual areas within the project, and looks like the following:

Summary | Admin | Home Page | Forums | Tracker | Bugs | Support | Patches | RFE | Lists | Tasks | Docs | News | CVS | Files |

The only areas currently in use are:
* Summary (the project page),
* Lists (only "celestia-developers Archives"),
* CVS (source files), and
* Files (current final releases).

The CVS link is where you will find the source files. How you connect to the live CVS repository, in order to download the entire project to your system, and/or check-out source files, depends on what OS you are running. See the link on that page for more info.

Instead of posting patches (fixes, additions, etc.) to the Patches area, Chris (the project administrator and Celestia creator) prefers that they be sent to him via a Private Message (PM in the forums here) or via e-mail.

Christophe (the programmer responsible for the Unix/Linux version) has provided a Celestia source code cross-reference tool (http://www.teyssier.org/lxr/http/source/) that allows a person to search for just about anything in all of the Celestia source code files at once.

Hopefully, this will get you (and others) started.

Glad to have you on-board Cereb!

-Don G.

[Paolo]

No, I meant for Celestia (as a whole) that you discussed doing a while back, as a "beginning step" to learning the Celestia code.

I was waiting for a while for a new scratch as promised by Chris.
http://celestiaproject.net/forum/viewtopic.php?t=3174&start=15

Then I've started by myself adding Celestia Objects to my celui project.
I think that playing with these objects is the best way to understand how they work.

Since now I've studied the Parser and Tokenizer classes that are very interesting. Celestia uses these objects to read from ssc and other plain text files.

Now I am a little in trouble with celtxf classes that are used to write text on the OpenGL screen.

So my version of the complete hierarchy of Celestia Objects is far away.

Bye - Paolo.

[don]

Thank you Paolo, it never hurts to ask <smile>.

As for Chris saying he would do it (class hierarchy) -- Chris is VERY entheusiastic about everything related to Celestia (like, who isn't?), VERY willing to actually do everything himself too . . . but, believe it or not, Chris is a mere human being (not Superman <frown>) who has a VERY busy day job, and even a personal life away from computers (personally, I can't imagine how!).

Yes, Chris WANTS to do this (and many other things) for Celestia, but he simply does not have the time -- which is, or has become, very apparent to some of us, especially me.

So, what I'm saying is, don't hold your breath or wait for Chris to do this. In time, yes, I'm sure he would eventually get to it.

Therefore, if you still want to do this Paolo, I'm sure *every* new Celestia developer would be *thrilled* to have it for reference.

Thank you.

-Don G.

[Paolo]

I've started the primer for everyone who wants to compile the latest Celestia source code on Windows XP using Visual C++.

You can find it at:
http://ennui.celestiaproject.net/forum/viewtopic.php?p=25068

Perhaps I will finish it today.

Bye - Paolo

[don]

Howdy Paolo,

WOW!!! ...
That looks GREAT Paolo!!! ...

... Thank you VERY VERY much! ...

I hope to be using it in the next couple of days. Have one thing to finish first.

-Don G. (The C++ Cowboy)

[Christophe]

Hi Paolo,

I totally agree with your comments.

The coding conventions are defined (there is a detailed HTML file), but are too simple.
There are many coding C++ conventions that in some cases should result very handy e.g. the ones used by MFC (Microsoft Foundation Classes). Moreover from my experience using the Delphi conventions you always know if a data member or a method is private or public. In Celestia code simply looking at a variable name you never know which is its type. Since you haven't familiarized enough you always must search for the declaration.

I think most of these problems come from 'growing pains'. The Celestia code has evolved a lot in terms of functionnality but its structure has more or less stayed the same since its hard to change without a full rewrite.

Actually I think Chris as done a good job when chosing the structure, it's working quite well with many unforeseen uses at the time he started the project. The drawback of course, especially since we're dealing with OO code is that the interfaces between objects tend to blur with time. More and more variables are added, often made public to facilitate object interactions, and we end up with spaghetti code.

I think for 2.0 someone needs to sit down, draw the current class architecture and clean it. That's a major task, but that'd be a very good thing, and maybe that can be done little by little rather than in one big rewrite.

Celestia is essentially C++, whenever possible uses STL, streams and all the other OOP programming concepts. But uses OpenGL too. OpenGL have completely the opposite approach because is procedural. For a natural OOP amateur programmer like me starting with OpenGL was very difficult. I've used DirectX for a long time so I consider to know at least the basics of 3D graphic programming. But start with OpenGL was very difficult. As you can see from my website I've linked all the tutorials available on the web.
Celestia uses hardware extensions to manage the more complex visualizing effects stuff. The complexity of this part of the software is extremely high and is absolutely out of the common developers capabilities. Only developers with highest 3D hardware programming skill can contribute.

Just not to scare off would-be contributors, the Astronomical/OpenGL/Scripting and GUI parts of the code are neatly separated and anybody knowledgeable in only one of those fields could certainly contribute. I've myself made several additions to the Celestia core without any knowledge in OpenGL or astronomical calculations.

For a Celestia novice, to follow the code execution without an interactive debugging system it is absolutely impossible. There is a TXT file that explains generically the software functioning and the main internal objects but is only a trace. So first of all you need to configure a tool like VC++ to be able to debug interactively Celestia code. Actually this operation is absolutely painful. Refer to this thread for more info:
http://celestiaproject.net/forum/viewtopic.php?t=3376

I personnaly don't use a debugger to step through the code, and I don't feel the need too. So it's not a requirement either, but it's a nice addition if you're used to working this way.

Celestia is designed to be executed on multiple Operating Systems. This feature increases a lot the complexity of the project. Practically now the Celestia that runs on Linux is different from the ones that run on Windows and MacOS-X because have different user interfaces and not all the features are implemented on every platform.

Well, here I don't agree with you. I don't think it adds to the complexity of the code, on the contrary it has forced at least one clean interface between the core and the GUI, the platform specific code is kept in separate folders so it's easy to work with. One area that it does make more complex is the build system which is a terrible mess.

Talking about CVS I don't know which is the situation for other people but actually for me is a bloody bath. I'm able to connect to Sourceforge about 1 time every 10 tentative. When someone updates the stars.dat (often to correct 1 star a time) many tentative are necessary to update correctly. (:<<<)

True, the anonymous CVS access is very unstable, there are a lot less problems with the developers' one.

But I see other problems lie on the background of Celestia Project.
Since now I was not able to figure out if there is a clear implementation design schedule.
http://celestiaproject.net/forum/viewtopic.php?t=3023
Perhaps there are private messages between developers other than the ones at:
http://sourceforge.net/mailarchive/foru ... um_id=9864

Very few in fact.

I think that in the last version were added too many new features because for me it is abnormal that 11 pre releases were made before a final release.
http://celestiaproject.net/forum/viewtopic.php?t=3151
But the worst thing is that practically every Celestia user that browses Celestia Forums now had downloaded the 1.3.1 pre 11. This version should really be considered the 1.3.11.

The problem is that although we already had a pre-release out, new features kept going in. That's because we have only one branch, but considering the small number of active developers a separate development branch would be overkill.

I think that a better centralized support for add-on is absolutely requested.
Shatters.net often responds very badly.
http://celestiaproject.net/forum/viewtopic.php?t=3363

I still want to, but I confess I haven't yet started working on it. I'm still looking for an existing open-source project we could use to do that.

[Paolo]

Hi Christophe

I think for 2.0 someone needs to sit down, draw the current class architecture and clean it. That's a major task, but that'd be a very good thing, and maybe that can be done little by little rather than in one big rewrite.

I agree, the work should be done little by little but I think that defining a release date for the ver.2.0 should help a lot. Perhaps june 2004 if far enough to plan this work.

Celestia is designed to be executed on multiple Operating Systems. This feature increases a lot the complexity of the project. Practically now the Celestia that runs on Linux is different from the ones that run on Windows and MacOS-X because have different user interfaces and not all the features are implemented on every platform.

Well, here I don't agree with you. I don't think it adds to the complexity of the code, on the contrary it has forced at least one clean interface between the core and the GUI, the platform specific code is kept in separate folders so it's easy to work with. One area that it does make more complex is the build system which is a terrible mess.

We have already discussed a lot about this argument in other threads.
You don't conviced me plenty. I still belive that a multiplatform GUI should reduce even more the differences between the code for the different platforms and reduce the interfaces between the Core and the OS specific code. It should be another main task to consider for ver 2.0.

I think that a better centralized support for add-on is absolutely requested.

I still want to, but I confess I haven't yet started working on it. I'm still looking for an existing open-source project we could use to do that.

In my feature requests I've already proposed some very simple suggestion to improve the add-on management.
I don't know which is your project about this argument.
Please can you explain us what are you planning to do?

Bye - Paolo

[Christophe]

In my feature requests I've already proposed some very simple suggestion to improve the add-on management.
I don't know which is your project about this argument.
Please can you explain us what are you planning to do? :D

I think that has already been discussed in the forums too.

The basic plan is to define a package format for add-ons, very simply that would be a zip file including a defined folder hierarchy (depending on the add-on type) and a manifest file.

The manifest file would hold information like the add-on type, author, release date, changelog, objects provided, dependencies on the Celestia version or on other add-ons or on objects, screenshot, and so on.

We'd then have a central web repository for those add-ons, very similar (in my mind) to KDE-Look. Add-on creators would simply upload their zip files, and the database would be directly updated from the manifest file (no need to fill in a form).

The next step would be to make celestia able to connect to this site to download new add-ons or updated add-ons, eventually even dealing with dependencies by itself.

[don]

Howdy Christophe,

Your description is very good, but it only describes a central repository of add-ons and that their format should be pre-defined. It does not describe anything that I believe would be included in an "Add-On Manager", such as many programs use now.

In my mind, an Add-On Manager for Celestia would be no more than a list window that should be able to do the following things:

* List all existing and locally available (on disk) add-ons, with whatever other information (button) on them is required.

* The list display should include a button to connect the users machine to the Add-Ons repository, obtain a list of currently available add-ons and their descriptions, then list them with the users currently installed or on-disk add-ons (showing location of each -- installed, local disk, repository, etc.).

* The list display should provide a button for repository entries, that would open a web page describing the specific Add-On, along with pictures, from the repository site.

* The list display should provide a button that allows the user to install or remove any add-on, whether it is installed, stored on local disk or stored on the repository. This function will also be required to modify any existing files, such as solarsys.ssc, as necessary (described in the required Add-On manifest file), for both, the add and remove functions.

To me, this is a manager of Add-Ons <smile>. The repository and connect-to-repository features can be added later. A pre-defined file format and required content list (such as the manifest file) for add-ons can certainly be created now. When existing add-ons are modified to meet this requirement, they would automatically be eligible for automated Celestia Add-On Management (add/remove).

The manager part should be easy enough to code, but obviously will require a programmer to code it <smile>. It might be much more difficult to get everyone to agree on the file contents and format of the manifest file, ZIP or TAR file, etc., and then to find somewhere to host an all-encompassing Add-On repository.

-Don G.

[Christophe]

Of course that's what is intended.

[chris]

Regarding the management of add-ons . . .

I think that creating a central add-on repository with generous amounts of disk space and bandwidth would be the single most useful thing for Celestia users right now.

For a package format, I favor ZIP because of its ubiquity. It would be helpful to define custom file extension like .celz, because you don't want to associate Celestia with all .zip files. The manifest included in the package would have the name of the add-on, the author, a description, and some other yet-to-be-determined data. I think everyone agrees on these basics.

Celestia should include code to manage local add-ons and to get additions and updates from the central repository.

And it should all be as slick as Apple's iTunes

--Chris

[Christophe]

I think everyone agrees on these basics.

The road is straight but the slope is strong.

[don]

Howdy Christophe,

The road is straight but the slope is strong.

CAUTION! 10% DOWN-SLOPE beyond next crest!

Are you ready? Weeeeeeeeee . . .

There MUST be some GUI (list window) programmers out there, yes?

And someone who knows how to work with ZIP files, from a coding standpoint?

And someone who knows SQL and XML, for the repository.

So, it's just a matter of getting these folks what they need (tools, encouragement, a means to work together, etc.), so they can work on Celestia and its sub-projects.

[don]

Howdy Chris,

For a package format, I favor ZIP because of its ubiquity.

Does ZIP have an API so files can be extracted from within program code?

It would be helpful to define custom file extension like .celz, because you don't want to associate Celestia with all .zip files.

Why would there need to be an association? The "manager" would look for ZIP files in a sub-directory within Celestia.

The manifest included in the package would have the name of the add-on, the author, a description, and some other yet-to-be-determined data. I think everyone agrees on these basics.

Yep, plus...

* Version Number
* SSC mods (for default/existing objects)

And it should all be as slick as Apple's iTunes

Haven't seen that one yet. Have my own radio station on my disk (21,000+ MIDI files, 7,600+ MP3s), mostly 50's thru 70's -- not to mention a 200 CD carousel.

Have a great day!

-Don G.

[chris]

Why would there need to be an association? The "manager" would look for ZIP files in a sub-directory within Celestia.

It would be nice to be able to click on a package file--or a link to one in a web page--and have Celestia automatically pop up a package installation dialog. This is not an essential feature, but I do think that it'd be convenient.

The manifest included in the package would have the name of the add-on, the author, a description, and some other yet-to-be-determined data. I think everyone agrees on these basics.

Yep, plus...

* Version Number

Yes . . .

* SSC mods (for default/existing objects)

I'm not sure how to handle add-ons that modify an existing .ssc file. My temptation is to disallow them, as they make keeping track of versions a complete mess. If an add-on has to modify solarsys.ssc or extrasolar.ssc, you'll have to install it manually.

--Chris

[Christophe]

And someone who knows how to work with ZIP files, from a coding standpoint?

zlib allows to work with files inside zipfiles as if they where directly in the filesystem. No problem here.

And someone who knows SQL and XML, for the repository.

I do. I even do that for a living occasionaly but it is a lot of work. Nothing difficult, but that's probably something like one man month. Fitting that into one's spare time and not losing interest along the way is not an easy task.

That's why I think finding an existing code base is a requirement for this to succeed, development time would probably be brought done to a lot more reasonable one man week.

[Christophe]

I'm not sure how to handle add-ons that modify an existing .ssc file. My temptation is to disallow them, as they make keeping track of versions a complete mess. If an add-on has to modify solarsys.ssc or extrasolar.ssc, you'll have to install it manually.

I think we need some way to overwrite the default ssc files from the extra directory. That would allow to replace textures from an add-on without having to manualy chage the 'Alternate texture'.

[don]

It would be nice to be able to click on a package file--or a link to one in a web page--and have Celestia automatically pop up a package installation dialog.

Okay, that makes sense.

I'm not sure how to handle add-ons that modify an existing .ssc file. My temptation is to disallow them, as they make keeping track of versions a complete mess. If an add-on has to modify solarsys.ssc or extrasolar.ssc, you'll have to install it manually.

I would think that the first thing most Celestia users will want to do is install higher resolution textures for our own Solar System objects -- all of which reside in the solarsys.ssc file. Maybe Christophe's idea about a .SSC file within the extras folder/sub-folders overriding the default .SSC file or auto-adding as an Alternate Texture would work better?

To modify the .SSC file shouldn't be too bad. For adding or removing an Add-On, a template type of entry could be added to the .SSC file for each line modified, such as:

Code: Select all

#*** Begin new entry for <Add-On name> ***************
# Modified on: <date>
# Old entry: <commented entry>
# blank line
  <new required entry>
#** End new entry for <Add-On name> *****************


This way, a human will know what was done, and when, if the file is looked at. Then, to reverse the modification when an Add-On is removed is just a matter of searching for it's name, removing the added line of code, uncommenting the <commented entry> (original entry), and removing the Add-On section comments. Not sure what kind of start-up hit Celestia would take with all the added comment lines.

Maybe not so obvious, the manifest would include instructions such as:
Old line: Texture "earth.*"
New line: Texture "earth.dds"

Just one idea.

-Don G.

[don]

zlib allows to work with files inside zipfiles as if they where directly in the filesystem. No problem here.

Good to know Christophe. Thanks!

And someone who knows SQL and XML, for the repository.

I do. I even do that for a living occasionaly but it is a lot of work. Nothing difficult, but that's probably something like one man month. Fitting that into one's spare time and not losing interest along the way is not an easy task.

I am merely assuming that SQL (whatever brand/version) would be best for the database, and that XML would be used for remote control. Maybe there are better things to use?

No, creating the repository code would not be an "easy" spare-time task for one person, and would require lots of continued encouragement from other members.

But, this doesn't have to be a one-person job, and you don't have to have any C++ experience either. Maybe several people could work on different parts of this sub-project, to keep each individuals time to a minimum and "interest level" high? Does anyone else know:

* SQL (for the database part)
* XML (for remote control stuff)
* Web forms (CGI -- perl, php, other - for the UI)
* Other things that would be useful for the repository site

The Celestia Add-On Repository web site is more interactive web site design and coding, than anything else. However, the Add-On Manager side of this sub-project, built into Celestia, will probably be a lot of C++ coding.

That's why I think finding an existing code base is a requirement for this to succeed, development time would probably be brought done to a lot more reasonable one man week.

Agreed. But finding an open source code base might be more difficult / time consuming than just writing it. I've tried to do some preliminary searches and the only ones I found were retail versions.

-Don G.

[Paolo]

Hey guys this thread is extremely interesting, almost all my suggestions and feature requests as exposed in thread:
http://ennui.celestiaproject.net/forum/viewtopic.php?t=2752
and in my website:
http://members.xoom.virgilio.it/pangeli ... up%204.htm
will be implemented.

but...

please may I say one thing ,

one ,

just one,

only one.

Before starting with add-on management development should be better to release 1.3.1.
Don't you agree?


Bye - Paolo