A Forking Commit Thread.

[Kristallporing]

Cool. Thanks for the shared ideas here.

[Lafuente_Astronomy]

Cool. Thanks for the shared ideas here.

You're welcome

[Janus]

Okay, here is some fun.
This is something of a butcher job, but there is no greeking going on.
Commit 5466 with degreeking only, no other tweaks or mods.
I can post one later with the rest included if wanted.

For me it is very nice not to see all the shorthand.
I realize my preferences may not be to everyone's liking.
However, it is easier, simpler, and preferred by me to read alpha, than ALF, or the α symbol, and the same applies to the rest.

If no one else cares, I can keep this tweak to myself.
I am currently working on a full substitution to turn the shorthand/symbols into real words.
I will post it once I finally get it working.

What I think however, is all this greeking around with the text is breaking addons and textures.
I could be wrong, but that is part of what this is intended to test.
Looking for feedback on whether this helps, hurts, or has no effect on addons.


Janus.

[Lafuente_Astronomy]

Well, I downloaded it but I haven't checked it yet. It looks promising, though that would mean I'll have to add additional names to the starnames.dat file

[Janus]

Speaking strictly for myself, losing all the greek shorthand would be nice.
If people want to see it, they should be able to though.
However, none of the search/find functions support anything except ascii {0x20-0x7F}, so the source data needs to stay clean.
Letting any multibyte chars into the source data will result in problems.
Every OS & Compiler handles localization in its own way, and windows at least, has schizophrenia I think.
Hence the code was designed to work with the base subset common to all localities.

Have a routine that will optionally transform all the ascii versions of shorthand into whatever you like, but display only.
If the display is turned on, then go from shorthand to back ascii before searching.
That would give you a transparent user experience, while content creators would also have a completely predictable environment.

My hope in trimming the greeking out is to verify what I believe is name mismatches behind the texture problems.
I could be wrong, but the change being able to turn the greeking off would be very nice.
It shouldn't be very hard to add a greek setting to the cfg file for default behavior.


Janus.

[Lafuente_Astronomy]

Well, in relation to the Proper Motion data that you want to propose, is there also a way to include galactic proper motion so that we can see how galaxies move throughout the millions of years, and especially the fated Milky Way Galaxy and Andromeda Galaxy collision that will result into a new elliptical galaxy?

[Janus]

Include, certainly.
Use, for DSOs, not so much.

I mean all I am talking about is an epoch or two, out to maybe a mega year or two.
Barely even long enough for current events in Andromeda to catch up here.
Nothing in Laniakea is going to move enough to detect that quickly.
As for the real DSOs, those are stationary on anything below galactic rotation time scales.
Andromeda will be dropping by for tea by the time those move enough to be interesting.

The Magellanic cluster(s), and their siblings, will certainly move visibly that soon, that could be fun to watch.
But nothing remote is going to move delectably, unless we can image Andromeda a lot better some time in the immediate future.

Besides, beyond a couple of galactic degrees, distortion due to readings and unimaged items is going to render the render meaningless.
Statistical forecasting of stellar movement on the mega year scale is why I am working on the DP stellar position code.
Tracking that many individual stars is beyond my data processing at the moment.
So instead, I am going to try to predict shifts in galactic density using fluid dynamics.
Which I will do with gravity density mapping to approximate shockwave flow.
Those shockwaves, or density variances, are what cause the ripple(s) on top of a drain with a coriolis induced spiral around it.
Looking at the structure of a spiral galaxy, I believe the arms are reminiscent of those spirals.

I could be wrong, but at least it is an interesting problem to study.
That I also get to study other things I want to know in answering that question, is just one of those little bonuses life offers.
Celestia itself is only going to provide the shape of the program I will need to model what I want to know.
While it will be interesting in and of itself, this is just a small step.
If others can use what I make while researching, great, I am happy.


Janus.

[Lafuente_Astronomy]

Alright! Thanks! Looking forward to more of your future work soon!

[Janus]

So, was anyone else aware there is a branch of celestia with Double precision rather than simple float for star positions?
Well, there is.

Unfortunately however, it still loaded SP data from the database.
I know, that doesn't make any sense, why load SP data, into a DP position.
So I fixed it.

Attached here is a CUSTOM compile of celestia.
This compile is from the double branch which is at commit 5446.
IT IS NOT COMPATIBLE WITH THE STANDARD DATABASE.
It requires the custom database included in this attachment.

To use this CUSTOM COMPILE, you will need to do the following.
Goto the data directory within celestia.
In it, you will need to rename your stars.dat, to something like stars.tad to preserve it.
You will then need to copy the stars.dat in this archive to the data directory.
The stars.dat in the archive is a double precision database.

I repeat, where the legacy stars.dat is an SP file, the stars.dat in this archive is a DP file.
Stellar positions are recorded as DP instead of SP, resulting in nine(9) more digits of accuracy in their position.
I regenerated it from the same source after modifying the perl script to emit double instead of float.

Other than making it compile on windows, and load a DP database, there is one other change.
I enabled stars at 100Gly, seven times the visible limit of the known universe.
Some of you have generated stars at great distances, and noticed a layering in their positions.
This should fix that limitation.

I do not know yet if the DP is used in the display of positions, but I know it is held in memory that way.
I will be posting a ready to compile for windows via VS2015 archive on my site once I am sure it is stable.
I will be including my other tweaks in my next compile of this branch, but only after I am sure it remains stable.


Janus.

P.S. Here are some checksums because I want to be sure no no one uses the wrong version.

e55e5d719211874e2b804d15d334f1f9 stars.dat
15912fd877a4d33001a960a5d4d6e904 celestia-5466-Double-Database-x64.exe
0a73cea3a9d42554de99fc456b96a61d celestia-5466-Double-Database-x86.exe

MD5 generated by hashcheck.

[Lafuente_Astronomy]

So, was anyone else aware there is a branch of celestia with Double precision rather than simple float for star positions?
Well, there is.

Unfortunately however, it still loaded SP data from the database.
I know, that doesn't make any sense, why load SP data, into a DP position.
So I fixed it.

Attached here is a CUSTOM compile of celestia.
This compile is from the double branch which is at commit 5446.
IT IS NOT COMPATIBLE WITH THE STANDARD DATABASE.
It requires the custom database included in this attachment.

To use this CUSTOM COMPILE, you will need to do the following.
Goto the data directory within celestia.
In it, you will need to rename your stars.dat, to something like stars.tad to preserve it.
You will then need to copy the stars.dat in this archive to the data directory.
The stars.dat in the archive is a double precision database.

I repeat, where the legacy stars.dat is an SP file, the stars.dat in this archive is a DP file.
Stellar positions are recorded as DP instead of SP, resulting in nine(9) more digits of accuracy in their position.
I regenerated it from the same source after modifying the perl script to emit double instead of float.

Other than making it compile on windows, and load a DP database, there is one other change.
I enabled stars at 100Gly, seven times the visible limit of the known universe.
Some of you have generated stars at great distances, and noticed a layering in their positions.
This should fix that limitation.

I do not know yet if the DP is used in the display of positions, but I know it is held in memory that way.
I will be posting a ready to compile for windows via VS2015 archive on my site once I am sure it is stable.
I will be including my other tweaks in my next compile of this branch, but only after I am sure it remains stable.


Janus.

P.S. Here are some checksums because I want to be sure no no one uses the wrong version.

e55e5d719211874e2b804d15d334f1f9 stars.dat
15912fd877a4d33001a960a5d4d6e904 celestia-5466-Double-Database-x64.exe
0a73cea3a9d42554de99fc456b96a61d celestia-5466-Double-Database-x86.exe

MD5 generated by hashcheck.
ATTACHMENTS
Celestia-5446-Double-Database.7z
(5.45 MiB) Not downloaded yet

Is there a version for commit 5466 or any of your latest commits with all features from your previous commit and features that you have made but haven't added yet? Thanks in advance

[Janus]

@Lafuente_Astronomy

The double branch only goes to commit 5446, no further.
I do not have a diff/patch or equivalent compared to the regular 5446 commit.
As indicated, I am not going to generate one until I am sure my changes are stable.

This compile is experimental, and breaks backwards compatibility, hence my muticolored warnings.
When and only when I am sure this is stable, or the double branch is brought forward, will I add features.

While it would be nice to see this integrated into the main branch, it would cause breakage.
The database has been stable for many years, this breaks that.
It changes the DB entry size from 4 + 4 + 4 + 4 + 2 + 2 upto 4 + 8 + 8 + 8 + 2 + 2 bytes.
Or, from 20 to 32 bytes, 1.6 times as big.

If I can find the HIP source file for 2 million stars, I am going to make a DP database of it.
Until then, I am simply waiting to be sure what I have already done works for others.


Janus.

[Janus]

With no feedback on the double database version, I am dropping it.
Now that I have played with the astrodb branch, and decided it isn't ready to be tinkered with.
I decided to go ahead and post a vanilla commit 5471 for anyone who wants it.

I am behind schedule because I am on standby for a customer, so I got brave.
I tried once more to get VS2017 working, and wasn't able to salvage my win7 install this time.
So I have been doing a reinstall, which has been even less fun than it sounds like.

I will be bringing some of my stuff over to it over the next few days now that I have that part of things working.

I had to add iob_func_shim.cpp back because of libjpeg-turbo requiring it.
I also added some missing defs to winsplash.h which are in mingw, but not VS.


Janus.

[Janus]

As there was an update, here is an update.

Commit 5475, basically vanilla.
I made asterisms brighter, because I do not keep my monitor(s) set for full brightness.
I also bypassed greeking, but left shorthand expansion.
I know I may be the only one, but I absolutely dislike, and nearly hate, all those glyphs, they are just noise to me, so I muted them.

If there is interest, I can bring some of my other toys forward.
I am adding a details filter to the RaDecDist display, so it can be turned off if desired.
As I said though, if there is interest.


Janus.

[Kochav Israel]

Hello,

I apologize for long delay and not replying. I simply had to prepare for standardized testing that was important for entering college since I will be entering astronomy department, which is my passion so yeah. Now that school is over I will read into this.

[Lafuente_Astronomy]

Hello,

I apologize for long delay and not replying. I simply had to prepare for standardized testing that was important for entering college since I will be entering astronomy department, which is my passion so yeah. Now that school is over I will read into this.

It's ok man. Your time at the Astronomy Department in your college will be important, since you'll have up to date knowledge of the celestial objects, and can make addond based from that. Keep up the good work!

[Kochav Israel]

Woah.

Imagination is an extremely fluid thing, and computers can't keep up fast with it.

Speaking of the stars, I wonder if it is possible to pull out the stars.dat file or at least somehow remove all the stars in it? This way I can center the universe on my own galaxies and circumvent bad renderings and bad precision.

[selden]

Here's an empty star data file. It's named stars_empty.dat. To begin with, in Celestia's data directory, you should rename your existing stars.dat to something else (perhaps stars_original.dat) and rename stars_empty.dat to be stars.dat

Don't forget that all of Celestia's objects are defined with respect to Celestia's internal coordinate system, with the Solar System's Barycenter at [0,0,0]. To eliminate Celestia's Sun, planets, nearby stars, etc., you'll have to eliminate all of Celestia's textual catalog files (*.stc, *.ssc and *.dsc) and replace them with your own.

stars_empty.zip

empty star data file

(194 Bytes) Downloaded 325 times

[Kochav Israel]

Thanks.

[Janus]

Okay, here is a question for anyone still reading this thread.

I am working on timing issues.
In this case, what I mean is time during scripts and while recording.
I got here while trying to put getn back into lua5.3 because # is a horrible replacement, going back to 5.1
Anyway, where I started was putting a real time check into the wait command.
That way I could have accurate waits regardless of other activity.

While I was playing with that, I tried some recordings.
Which brought me to how long it takes to record some scripts.
And that ended up with me making a tweak that used the celestia internal time.
Which didn't give me all the results I wanted, but gave me another idea that should be simpler to implement than keeping two different forks.

So my idea is this.
Make LUA use celestia's internal time for wait, and everything else.
Then in celestia have two states for keeping track of time while recording.
Real time with frame skipping.
Or frame advance so rendering can happen at greater than real time.

The latter being callable from a script to set/unset it, and it only applies while recording.
This also means being able to start recording using a script, then stop it.

This would enable developing scripts and recording them in real time.
While also leaving open the idea of using frame based time.
Thus a system capable of rendering >100fps could record a script with proper relative timing, faster than one that can only do real time.

Thoughts?
Or was I clear enough.


Janus.

[wmurphy]

Continuing the idea of using alternate galaxies, is it possible to replace the references in the navigation menu from Sol to Origin?

I looked into it and found that translations substituted strings for "Select _Sol" and changing that string in the source would break all of the translations and that string was set in each front end source.

There has to be a better way. New LC_MESSAGES file? Custom build?

Thoughts?