Future Development suggestion.

[mstshtml]

Now, I am not too sure how the source code runs but it seems, the more textures installed the more ram it takes up...so..I have seen this before and if it is not already programmed like this maybe this would help the mass ram and cpu usage. It seems that it loads all the textures at once and keeps them loaded into the program so maybe you can make it so only visible objects on the screen are loaded from the files this way keeping the processing down.
If i am wrong then forget it. Just thought to give it a try.
-Steve

[BlindedByTheLight]

I am not a developer (though I'm sure you'll hear from one soon) but I have read quite a bit on the subject and, I believe, that Celestia only loads textures that are visible on-screen.

In fact, on second thought, you can verify this for yourself by pulling up what I believe is called the "console" by hitting shift-tilde - at least on Mac... though I think it's platform-independent.

That pulls up a small text based overlay that shows you when the textures, etc are being loaded as you fly around the universe.

[Slalomsk8er]

Celestia loads things as needed. If you do scripts you know there is a command to preload textures, so your script will run better if it get to an object with a loaded texture. But this topic is a little bit tricky, because there is the memory of the graphiccard and your system main RAM.

The bottom line is simple the more you have of both and the more of it is used, the better Celestia will look

[Sky Pilot]

I can't help but chirp in here. I think it's becoming clear to some of us "add-on gluttons" that Celestia will bring even the most RAM and disk happy machines to their knees eventually. The more add-ons you install, the closer you get to the limit of any machine.

Is there anything on the horizon that will help us manage the way Celestia loads add-ons into RAM? It would be nice to have the ability to turn certain add-ons ON or OFF depending on what we want to do with Celestia at the time. I guess some kind of an add-on manager.

Is anything in the works?

[Paolo]

Is there anything on the horizon that will help us manage the way Celestia loads add-ons into RAM? It would be nice to have the ability to turn certain add-ons ON or OFF depending on what we want to do with Celestia at the time. I guess some kind of an add-on manager.

Is anything in the works?

The add-on management was argument of a long discussion about one year ago. Christophe was heavily involved in order to study this new kind of tool.

Unfortunately this VERY important issue is dead from a long time. This is a shame because the biggest obstacle to the implementation was the availability of a huge web space with huge bandwidth. Now this is available through Celestiamotherlode. So is really a shame that we don't exploit this opportunity.

It should be interesting if this discussion should re-start.

To poke the flame I would like to see fully functional Add-On management in the Celestia 2.0 version. Why 2.0? Because IMHO this requires at least a partial rewrite of the Data model, so by design no backward compatibility with the current add-ons will be guaranteed. If not there is the risk of a huge amount of work in order to prevent the compatibility breakdown.

But it seems that not many people is interested in these discussions.....

[Sky Pilot]

Excuse me for being a complete bonehead on this (I'm NOT a software writer!), but could it be possible to create a small application that allows the user to select which add-ons he wants to load, and when he presses the commit button it re-writes the celestia.cfg file (and launches Celestia) to only load those add-ons that were specified in the application?

[Paolo]

Excuse me for being a complete bonehead on this (I'm NOT a software writer!), but could it be possible to create a small application that allows the user to select which add-ons he wants to load, and when he presses the commit button it re-writes the celestia.cfg file (and launches Celestia) to only load those add-ons that were specified in the application?

Yes in theory it is possible, but...The question goes far beyond this. The add-on manager as thought a long time ago should at least be able to allow the user to:
a) select which add-on to use at runtime even without restarting the Celestia program when a change is made;
b) browse, download and install the new add-on from the web repository (now Celestiamotherlode).

In my thoughts I went beyond this introducing the concepts of module and section.
You can consider the module as the name of the add-on aka the package aka a conventional name for the zip file.
You can consider the section as the argument aka the family of the objects included in the add-on.

The section has a type that can be: System, Scientific or Fictional.
So it will possible to have e.g. these kind of Sections:
- "Sun asteroid belt" - "Jupiter minor moons" - "Extrasolar planets" (Scientific) etc.
- "Star wars"-"Babylon5"-"Star trek" - "My personal universe" (Fictional) etc.

The add-on manager should be smart enough to allow to the user to enable-disable at runtime all the objects of the Section types Scientific or Fictional. Or enable-disable a single section or a single module.

To resume the whole thing, a module will contain object definitions, textures, scripts etc. The object definition files will contain sections names. Inside the sections there will be the objects

Code: Select all

File solarsys.ssc in module "Celestia 1.4.0 Default"

Section "Standard 1.4.0"
{

  Type "System"

  Planet "Mercury" "Sol"
  {
    Texture "mercury.*"
    BumpMap "mercurybump.*"
    BumpHeight 2.5
    Radius 2440
    ...
    Albedo 0.06
  }

  Planet "Venus" "Sol"
  {
    ...
  }
  ...
}



Etc. etc. etc.
This is why I think that it will be necessary to rewrite the data model and to break the backward compatibility.

The question involves the server side too, because the Celestiamotherlode must prepare some files with the resume of all the available add-on modules with the status (preliminary, under test, definitive, approved), the number of revision etc.
So the user should tell to the Celestia Add-on manager something like this: Dowload and install automatically all the new or revised and approved add-on modules that has scientific content.

The thing is not very difficult to do but requires a lot of coding time.

[mstshtml]

Yes, It would be really nice to have an add-on manager. If anyone has used the SkyChart program "Cartes du Ciel" it has a really thoughtout Add-On Manager and is exactly what people would want with Celestia. With some experience in scripting I think it would require a major re-write of the engine.
It would be a monumental jump for the Program Celestia I think and would make many people very happy.
-Steve

[t00fri]

Yes, It would be really nice to have an add-on manager. If anyone has used the SkyChart program "Cartes du Ciel" it has a really thoughtout Add-On Manager and is exactly what people would want with Celestia. With some experience in scripting I think it would require a major re-write of the engine.
It would be a monumental jump for the Program Celestia I think and would make many people very happy.
-Steve

As always in the past, I have no sympathies for getting involved with a download manager project.

We had extensive disputes about this issue several times before. There was even a group being formed to deal with it...and fell asleep soon after

A download manager would need a lot of sophistication (and thus coding and debugging efforts) to really work. One aspect is due to the fact that many add-on creators (often from the Windows environment) apparently cannot manage to adopt standards valid across the various platforms that Celestia supports. As Paulo pointed out, if it was to be done, it should serve quite a number of non-trivial functions.

What is asked here (again) is that a small group of developers is to spend a huge amount of their available coding time just to spare lazy users reading the instructions of how to handle add-ons.

Instead, the same developers could spend their time in bringing Celestia to new frontiers of precision simulation and 3d graphics display! So many issues that are belonging to the "core tasks" for Celestia, are still waiting to be implemented.

Last not least, as experience has shown, many users enjoy learning and knowing a bit how Celestia works, since this way many of its great features may be better exploited! An add-on manager is a most effective tool to prevent the users to learn, know and enjoy by "doing"!


Bye Fridger

[mstshtml]

Well, I agree that people should learn how celestia works on their own. But what I am trying to say, even if it doesnt involve an add-on manager is to having specific addons be enabled through a built-in program. For example, when you check "Render->Galaxies" all the addons are rendered. So if you dont want to have nebula for example, you cant because you are limited to what addons you want to use within the program. It is either use all addons or none...unless you want to cut and past folders out of the "extra" folder every time you want to disable something. But I agree that people should learn how to use celestia and install and make addons on their own.
-Steve

[Paolo]

For example, when you check "Render->Galaxies" all the addons are rendered. So if you dont want to have nebula for example, you cant because you are limited to what addons you want to use within the program. It is either use all addons or none...unless you want to cut and past folders out of the "extra" folder every time you want to disable something. ...

In order to avoid these kind of problems and starting an extremely basic semi-automatic but yet a lot hand work add-on manager, it will be sufficent to extend the celestia file parser in order to make it capable to understand something like this:

Code: Select all


File "minormoons.ssc"



It is the Columbus Egg don't you agree.

This really simpe addition should literally change the way add-on will be written and the way the users manages the extras foder and the all related add-on stuff.

I've managed this in Celui in order to implement Skins management and so I can load and reload at runtime a single UI file instead than browse all the data subfolders. Only the files contained in the UI file will be processed even if many others are present in the subfolders.
BTW In order to easily debug the file (add-on) loading, in Celui I've extended the original Celestia logging capabilities, so all the errors occured at loading time are written in a text file. Even lower case file names conventions for dummy Windows (not Unix aware) add-on creators!

Implementing something like this in Celestia will allow the users to create different (hand made) startup files. These files should be launched via command line parameters (shortcuts) and so we will have a:
- unique Celestia installation,
- a unique Extras folder with all the data inside,
- many different Celestia throug simple start-up files.

Obviously it should be rather better if all this should be managed via the UI and at runtime in a way transparent to the final user, but for now it should be better than nothing. It's really something small....

Instead I repeat myself, IMHO to manage the whole thing correctly and automatically it is necessary to:
- rewrite entirely the Data Model and the object naming,
- brake the backward compatibility,
- and so start with a New Major Release of the program (2.0).

So many very important decisions by Chris are required and consequently the things are quite sooooooo far to come.

[Paolo]

Take a look at this:

http://cvs.sourceforge.net/viewcvs.py/c ... iew=markup

At the method uiManager::fparseCUIFile