Page 8 of 9

Posted: 10.09.2019, 11:54
by pirogronian
Actually I'm not waiting for 1.7 nor any other release, just waiting for my life energy to return :hi:

Posted: 10.09.2019, 12:23
by Lafuente_Astronomy
pirogronian wrote:Actually I'm not waiting for 1.7 nor any other release, just waiting for my life energy to return

Ahhh. Wanna have an energy drink?

Posted: 10.09.2019, 14:48
by fyr02
nice one.

Posted: 10.09.2019, 15:17
by pirogronian
Lafuente_Astronomy wrote:Ahhh. Wanna have an energy drink?
I'd prefer a new liver, pancreas and spleen. Maybe something more. Time will came, we will see. :wink:

fyr02 wrote:nice one.
What exactly?

Posted: 10.09.2019, 21:55
by fyr02
Smooth transition by Lafuente_Astro.
I'd prefer a new liver, pancreas and spleen. Maybe something more. Time will came, we will see.
Ahhh, the nice scent of surgical tools that comes when you realize that you've been working on this stupid space simulator for too long.

In all seriousness, you should probably release whatever you have for 1.7 as "1.7.0-pre1" or something

Posted: 10.09.2019, 23:03
by Lafuente_Astronomy
Actually, it's ok if you take your time or your energy in making AstroDB. I'm just interested in the prospects that such a database would bring to Celestia as a whole. And the prospects are huge

Posted: 23.09.2019, 18:54
by barrysingh101
As Celestia have now ability to import new data, provided by user, there is a queston about translating such a data (for example - celestial object names, user defined category names etc). Current approach is usage of gettext, as for every other translatable string. But users providing new string are unable (without messing with system files) to provide translation for it. I see to solutions (not secessarily exclusive):

Allow users to bind own text domains and use dgettext when translating particular string.
Allow users to provide translations directly.
In both cases there would be a new class, incorporating string and translation method: domain name or array with translations.

Posted: 23.09.2019, 19:47
by pirogronian
To be precise, this mechanism isnt a part of official Celestia yet.
As I can remember (I stalled my work a bit), domain is automatically set to directory of processed data file.

Posted: 24.09.2019, 13:27
by Lafuente_Astronomy
barrysingh101 wrote:As Celestia have now ability to import new data, provided by user, there is a queston about translating such a data (for example - celestial object names, user defined category names etc). Current approach is usage of gettext, as for every other translatable string. But users providing new string are unable (without messing with system files) to provide translation for it. I see to solutions (not secessarily exclusive):

Allow users to bind own text domains and use dgettext when translating particular string.
Allow users to provide translations directly.
In both cases there would be a new class, incorporating string and translation method: domain name or array with translations.

Could you clarify to me what these things are?

Posted: 27.09.2019, 14:33
by onetwothree
barrysingh101 wrote:Allow users to bind own text domains and use dgettext when translating particular string.

That's what being implemented. Afair it's implemented for categories already.

Posted: 30.09.2019, 10:01
by pirogronian
Changelog update:
* Added Lua interface for names manipulation. It means user is now able to add and remove names of objects from Lua. Names local tova planetary system aren't supported yet.
* ...and somw bugfixes related to it.
* I started new branch as a merge proxy between master and AstroDb. It's still local, but you may notice recent commits in astrodb focused on avoiding name conflicts. It's my another try to merge it with possibly painless way. Perhaps many other changes could be done yet, but it become extremly difficult to maintain such a big branch separately. I'm only praying to God for @onetwothree acceptance, when it will become soon a pull request... :wink:

Posted: 30.09.2019, 15:35
by Lafuente_Astronomy
pirogronian wrote:Changelog update:
* Added Lua interface for names manipulation. It means user is now able to add and remove names of objects from Lua. Names local tova planetary system aren't supported yet.
* ...and somw bugfixes related to it.
* I started new branch as a merge proxy between master and AstroDb. It's still local, but you may notice recent commits in astrodb focused on avoiding name conflicts. It's my another try to merge it with possibly painless way. Perhaps many other changes could be done yet, but it become extremly difficult to maintain such a big branch separately. I'm only praying to God for @onetwothree acceptance, when it will become soon a pull request... :wink:

Amen to that, brother! I mean, the updates do look good in all parts. So, does that mean I can add any names to objects other than stars? Because so far, I can only add names to stars through the starnames.dat file. Also, do you mind sharing the link to the AstroDB's github here?

Posted: 30.09.2019, 16:25
by pirogronian
Lafuente_Astronomy wrote:So, does that mean I can add any names to objects other than stars? Because so far, I can only add names to stars through the starnames.dat. Also, do you mind sharing the link to the AstroDB's github here?

Yes, You can add any name to any object: DSO, body, even Location. All

object:addname(string canonical, string nls-domain, bool greek) : bool
or
object:addalias(string canonical, string nls-domain, bool greek) : bool

Second argument is a local directory name, where gettext translations are placed. Default is null.
Third argument is flag whenever to replace greek abbreviations by ordinary greek letters. Default is true.
Difference between functions is the first one place added name as "primary" one, returned by getName method.
Both methods returns true on success, false otherwise.

To remove name, call
object:removename(string canonical/nameobject name, bool greek) : bool

First parameter is canonical name string or "name object" (see below).

To list all objects' names (but not catalog numbers):
object:getnames() : table

This method return table of name objects. Name objects is new type, representing name, its translation and context. Methods:
name:getcanonical() - get canonical name
name:getlocalized() - get translated name
name:getobject() - get object name belongs to.

For anyone who wants to test - AstroDB branch is where it was from beginning, and here is a link: https://github.com/CelestiaProject/Celestia/tree/astrodb

Posted: 01.10.2019, 13:01
by Lafuente_Astronomy
Those sound quiet complicated. But I'll try them nontheless. Thanks a lot

Posted: 07.12.2019, 13:21
by pirogronian
Bad news. Due to health problems, I have to withdraw from active developement (and modering). All code from AstroDb branch is free to use (as always). Best wishes for everyone.

Posted: 07.12.2019, 19:35
by onetwothree
Omg! It's a pity to hear that you have so serious problems. My best wishes and I hope everything will be fine with you!

Posted: 07.12.2019, 19:39
by Janus
@pirogronian

Best wishes, I hope all goes well for you.


Janus.

Posted: 07.12.2019, 20:51
by pirogronian
Oh, maybe it's wrong statement. Perhaps I should to write "personal problems" or so, because while my health is heavely involved, I'm surely not going to die... Just not have enough "resources" anymore to participate in the project. And let's say it - I didnt add much to the project. Importance of my biggest effort (astrodb) is questionable for me - maybe I was too ambitious. Meanwhile I see that Celestia's developement is going forward and in good direction and it's fine and most important.

Posted: 07.12.2019, 21:39
by Anthony_B_Russo10
Hopefully you can keep some kind of involvement in this project.

Posted: 08.12.2019, 08:15
by Markerz
I hope whatever you have going on will go well, you had surely contributed a lot to keep it going.

unfortunately, I currently am also quite occupied, with my job and job hunting, otherwise I can see what I can do with your existing work from now on.