Celestia 1.7.0 Development Thread

[pirogronian]

I agree with @Alexell. I see no sense in participating both in official and fork repo. If I would obey official repo administration. I would just reset it to and keep synced with @onetwothree's fork. I see no problem with redo all my already pulled stuff again, with demanded modifications.

[SpaceFanatic64]

Alexell, does this also mean that FarGetaNik and Hungry4Info will loose their status as moderators due to being inactive?

[Janus]

@onetwothree

On recording.
This is strictly my personal opinion, but I would rather see a file written directly that contains NOTHING! except what we want.
I have had many customers over the years who have been stung by macro expansion, or "extra" features giving them files that are not what they expected.

If you want multiplatform creation of files.
I would recommend a modern alternative the the admittedly aging avi file.
For this project, I believe MKV would be perfect.
It is open source, works the same everywhere, and is codec agnostic, just like avi is.
I used the open source Lagarith (Lossless) codec, which I believe could be included just like jpeg, png and others.
MKV also supports chapter markers, built in sub titles, and multiple audio streams.
This means you could in theory create a video with built in chapter markers and multilanguage subtitles to take the place of on screen printing.
Celesta:Print could be aided by Celestia:Subtitle which only does anything while recording.
Or Celestia:Document which calls print during viewing, and Subtitle during recording.

Just create the simple video file in Celestia before taking it into real tools to edit properly.
Not meaning to ramble, simply typing out loud.


Janus.

[pirogronian]

@Janus

I think ffmpeg usage fullfills all of your demands and many more. However, I would lke it in c++ wrapper, as well as Lua api. And, probably, as a plugin

@onetwothree
After short research I found Boost library contains nice, header only, plugins support: Boost.DLL (not only Windows dlls, as name may suggests).

[Croc]

pirogronian wrote:
I have some questions. What is the main reason for plugins? Reducing binary executable size? Reduced memory overhead? Faster launch? Another reason?

onetwothree wrote:
Other reasons
1) I do not think that every single function should be in the kernel . Low quality is especially rarely used.
2) Independent development. If you have an error in your plug-in, you will correct it and release it. If its functions are in the kernel, you wait until the new version is ready.
3) We can provide compiled plugins with different dependencies, ig to provide celx associated with lua5.1, 5.2, 5.3 or luajit.
4) New features can be developed independently so that users can try this before without compiling from git.

I met Celestia 1.6.1 in 2012 - a great program, but ...
interface Celestia - an anachronism in the era of Widows XP!
In 2007, a member of the Celestia development team, Vincent Giangiulio, developed the Lua Edu Tools graphical interface, which is better than the Celestia interface. After version v1.2beta8 (03/09/2010) the graphical interface has not been updated. Lua Edu Tools did not change the Celestia interface.
onetwothree, your developmental views and those of Vincent Giangiulio are well matched.

Since 2012, I have been upgrading the Lua Edu Tools graphical interface (the new name is Lua Universal Tools). Gironde has been actively involved in this work for almost 2 years. Lua programming language. Creating scripts on Lua using CELX Lua Methods is not difficult.
It is very disturbing that the CELX Lua Methods library in the planned version is practically not updated. For comparison:

• CELX commands added with 1.5.0 - 26 teams viewtopic.php?p=126048#p126048
• CELX commands added with 1.6.0 - 41 teams
• CELX commands added with 1.6.1 - 8 teams
• CELX commands will be added with 1.7.0 - 5 commands (last publication 03/20/2017 )

Such a number of new teams (+ ~ 10-15 unpublished) correspond to version 1.6.2 (this opinion and Alexell). This is very bad !

English is not my first language, so I want to continue the topic. I want to continue the topic in a personal message.

[Askaniy]

English is not my first language, so I want to continue the topic. I want to continue the topic in a personal message.

For the same reason, we are planning to create a separate Russian-language topic with Onetwothree. ~70% of the posts here were written by Russian-speaking forum participants.

[Croc]

For the same reason, we are planning to create a separate Russian-language topic with Onetwothree. ~70% of the posts here were written by Russian-speaking forum participants.

--------
The language of the international forum is English (Alexell).
Private correspondence in any language.
============================
Forum "Celestia in Russia" works! There you can communicate in Russian.
I am also a moderator there.

Access path:
Celestia Home => Documentation => Related Sites => Celestia Russian Forum

https://celestia.space/ru/forum/

[pirogronian]

But you will post here your conclusions? I and probably others too, would rather not to be separated from Celestia developement by language barrier...

[Joey P.]

I might join if I have the time.

[Alexell]

SpaceFanatic64, No. FarGetaNik and Hungry4Info may be moderators. In the future, if they are inactive for a very long time, Croc will make a decision.

Added after 36 seconds:
Before blaming me for merging all the changes, ask yourself: what did you do when Celestia began to die?
How many of you took any action to revive the Celestia forum?

I am not a very smart programmer and admit it. But I always liked Celestia, so I agreed with Chris about reviving the forum and moving the repository to GitHub.
Chris allowed me to do this, not because I'm smart, but because I took the initiative.

My task was to revive the Celestia forum, update the website and the design forum, and find new people on GitHub who will be developing.
Now Celestia has people like 375gnu and pirogronian, so Celestia can develop and I did everything I had to.
I leave the project because I have more priority goals and objectives.
----------

I ask you to negotiate with each other and just take control of the Celestia repository. I see no reason to create a new fork when we are already waiting for Celestia .Sci

Take Celestia and make it better! I am waiting for a PM from you.

[onetwothree]

I would just reset it to and keep synced with @onetwothree's fork. I see no problem with redo all my already pulled stuff again, with demanded modifications.

Ok, sounds good for me.

For this project, I believe MKV would be perfect.
It is open source, works the same everywhere, and is codec agnostic, just like avi is.

Yes, it seems that today MKV is a container №1.

I used the open source Lagarith (Lossless) codec, which I believe could be included just like jpeg, png and others.

Hmmm,

Lagarith was last updated on December 8, 2011.

Not very fresh. Maybe in FFmpeg it's in better shape.

MKV also supports chapter markers, built in sub titles, and multiple audio streams.
This means you could in theory create a video with built in chapter markers and multilanguage subtitles to take the place of on screen printing.
Celesta:Print could be aided by Celestia:Subtitle which only does anything while recording.
Or Celestia:Document which calls print during viewing, and Subtitle during recording.

Could you create a new topic for this? Before implementing something we should discuss it and formulate technical specification.

After short research I found Boost library contains nice, header only, plugins support: Boost.DLL (not only Windows dlls, as name may suggests).

Let's check. Frankly speaking I'd avoid that begemoth (boost) And if we need a proper plug-ins support we need we need to think about their architecture first, so I'd postpone this topic to 1.8.0 and now focus on releasing 1.7.0.

Such a number of new [CELX] commands (+ ~ 10-15 unpublished) correspond to version 1.6.2 (this opinion and Alexell). This is very bad !

Croc, of course we can create 100500 new unneeded clex command just to have a big numbers in a new release. Should we?

What addons author actually need?

But you will post here your conclusions? I and probably others too, would rather not to be separated from Celestia developement by language barrier...

I will. Not only conclusions. I'll duplicate topics here so world-wide is able to participate in decision making.

Before blaming me for merging all the changes, ask yourself: what did you do when Celestia began to die?

Why do you think that I'm blaming you? It's a free software so if I'm unsatisfied with your work I just fork and do it better. Then somebody may do the same with my fork. That's how thing are done in FLOSS.

I ask you to negotiate with each other and just take control of the Celestia repository. I see no reason to create a new fork when we are already waiting for Celestia .Sci

I'm afraid that thermal death of the Universe is closer that the 1st Celestia.Sci release.

[john71]

Thanks onetwothree and Alexell for keeping the project alive!

Because of the GAIA data integration it would be an excellent time to speed up development, in my opinion anyway...

[Croc]

onetwothree:
Croc, of course we can create 100500 new unneeded clex command just to have a big numbers in a new release. Should we?
What addons author actually need?

In celestia 188 object types and methods, of which designed for versions
1.5.0, 1.6.0, 1.6.1 - 63.

1. I found only 1 required method which is not listed CELX Lua Methods.

In ssc-files there is such a parameter (an example from asteroid 476 Hedwig):

Code: Select all

UniformRotation
{
Period 27.33
}

There is no similar (and concise) command in the CELX Lua Methods list.

2. Currently it is not possible to disable / enable:

• all asteroids
• all comets
• all spacecraft: [/ list]
  See screenshot:
  

  

  

  
  
  Note: на скриншоте дополнительно отключаются/включается 3 класса объектов. Предложение от Gironde 7 классов:
  
  • Planets
  • Dwarf Planets
  • Moons
  • Minor Moons
  • Asteroids
  • Comets
  • Spacecrafts

3. Среди классов объектов есть классы - астероиды, кометы.
Нужна дальнейшая детализация:
Asteroid Orbit Classes - need to add 14 arguments to the command celestia:setorbitflags()
Comet Orbit Classes - need to add 16 arguments to the command celestia:setorbitflags()

4. The number of planetary types of locations is 58, for more details see https://en.wikipedia.org/wiki/Planetary_nomenclature
In the CELX Lua Methods list, the setlocationflags command provides only 32 arguments, incl. International Astronomical Union (IAU) locations - 29.
You need to add an additional 58-29 = 29 locations!

5. Drawing orbits:
complete line
fading line.

6. Stars with rays in the style of Chris Laurel

7. The topic was postponed for discussion in personal correspondence ....

[onetwothree]

@croc

1) UniformRotation implementation requires some time
2) sounds easy to add
3) needs to check what is supported what isn't
4) sound easy to add
5) should be easy
6) nope. star rendering will be implemented differently. Chris himself isn't a fan of that method. He has proposed a faster way, that's why I need a new star texture.
7) have no clue what are talking about

[Janus]

In my own personal use fork(s) I have added CELX commands for several things.

Distance between objects.
Nearest neighbor.(Of type)(By RaDec)(By Dist)(For stars).
{Currently only as seen from earth, debating adding from observer view if I can figure out how.}
Stars within(LY).
Stars by type within(LY)
Lookup stars by RaDec.
Stars by Dist.
Stars(objects at time) within a degree of given RaDec.
GetRaDecDist of star/object.(At clock time).

Limit FPS while recording.
Load extras in alphabetical order instead of at random.

Still trying to find a way to script control show multiple orbits.
Debating on making nearest neighbor work on all objects at time.

None of these are organized, and scattered across a couple of dozen versions I use for things.
If any of these are of interest, I can collect and clean the code up, then present it to be integrated by real C/C++ programmers.


Janus.

[Croc]

@onetwothree
1. reassuring answer
2.Google knows Russian badly.
Currently it is not possible to disable / enable all asteroids using the "View Options" panel. But this is possible with the help of the ssc-file with the "modify" and "visible" operators. A lot of handmade. Celestia must make it fast. See modifying keys from project "Celestia Origin" all asteroids.zip
3. It turns out that there are no problems to create 100,500 unnecessary commands, but to add several dozens of necessary problems?
...................
7. The celestia.sci project is very closed. I do not know what tool is in the above image. Explain what it is.

[onetwothree]

@Janus, send everything

[pirogronian]

@onetwothree
What exatly are 1.7 targets now?
Imho if plugin architecture is definitely needed, I think we should start with it as soon as possible. Othetwise a more functions we will add now (especially celx) a more code we will have to refactoring later.
I found another plugin lib, much smaller than boost: pluma.

Apart if plugins, what about CelestiaCore interface with its hardcoded key codes, driving commands? I tried to cover these commands with regular c++ merhods by creating subclass CelestiaCoreApplication. You checked my code but didnt add it to your fork. Do you suggest anither approach or just need of polishing?

[onetwothree]

I suppose either we release 1.7 in the nearest months or never So I'd concentrate on bugfixing and polishing Qt5 GUI, adding non-intrusive changes like additional location features. In this case we postpone all global changes to post-release time.

Alternative approach is to release a new version when a new feature is stabilized.

Regarding your CelestiaCoreApplication. I changed my opinion on it looks like an workaround rather than actual fix. And frankly speaking current approach with emulation of user input is more adequate than creation of new public methods for every possible action. We just need to add an abstraction layer, so celestia core will work with _messages_ emitted by input layer handler or scripts. Technically messages are just uints. So GUI will accept user input, convert it into messages and send them to the core.

[Alexell]

The topic is closed until administrative issues are resolved.