Starry sky mod ?
-
Impressive luxorion!
-
You probably tried during an update. It is Ok now. The CSV is enough for BMS
http://www.astrosurf.com/luxorion/Documents/stars-catalog-vizier-forBMS.csvGreat, I have begun programming based off the first csv but with the updated one, I see that Ra Decimal and Dec Decimal repeat themselves twice for each star. Did the new update change anything else? If it did, could you upload a new file with the changes, but without the repeated variables?
-
… I see that Ra Decimal and Dec Decimal repeat themselves twice for each star. Did the new update change anything else?
Oops. Sorry. It is corrected. Now there are only one decimal column for RA and one for Dec.
http://www.astrosurf.com/luxorion/Documents/stars-catalog-vizier-forBMS.csvBetween the first upload and this last, only the column “Name” (star description) has been completed where fields were empty (complete with their HD ref)
I haven’t noted this duplicata. It came from the xls that included many functions to convert data and that I had hidden but that were exported…
Now for amateur astronomers (not BMS), I have a full catalog up to mag 6 listing much more parameters
(right-clic on link to download and open in Excel) :
http://www.astrosurf.com/luxorion/Documents/Bright-Star-Catalog-Vizier.csv -
Did anyone look at how the night sky with stars operates/rotates in Falcon? Indeed there are no true to life constellations here. And sadly I doubt they will be ever. It appears that two sets of stars are “attached” to two sky spheres which rotate in opposite directions. It maybe that northern and southern hemispheres are displayed at the same time, which could be perhaps looked into and eventually corrected by coders. It may also be that then we see that stars were in RL constellations. Right now it is impossible to sort that out visually.
-
Of course we can also hope that a sympathetic developer creates a patch from scratch but as you say, Polak, we can wait for…
Now there is maybe an alternative to program it.
If all interested players from this site + fb + checksix contribute in donating some money to an amateur or pro willing to program it for BMS 4.32 update 8 or 9, why not. I am sure that together we can find this money.
It should be an interesting question to submit to the “board” that decide whether a release can be developed and planned. -
It has been longstanding and very noble policy of BMS development group to keep all development totally and completely free. We are all thankful.
-
I need to add that strange double stardome rotation could have been caused by me having several weather files in the folder. This need to be further investigated. Also I have noticed that some theaters take star.dat from its own add on/terrain/weather folder and some from main Terrain for original Korea. Many factors can affect this so all poking and testing needs maybe more time.
-
I have fixed various other parts of the database that had missing constellation and bv columns, and it is all added to the converter. Now just need to figure out how the hex file is set up, and then convert the coordinates and possibly colors/whatever else might be moddable if it is possible, and then create the new .dat.
-
I have managed to create stardome and star.dat with only one star. That should allow us to try to deduce what are the values in star.dat file for. Also we could check if weather file where the geo position of the theater has any impact on what is displayed. And some other things. I need some time though because I have none. If someone wants to push forward send me PM.
-
Here is an example of the skydome with 3 stars:
00 00 00 00 00 00 00 00 00 00 00 00 26 bf 68 41 ab aa 71 c2 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 26 bf 68 41 ab aa 71 c2 00 00 00 00 00 00 00 00 00 00 00 00 c3 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 75 b9 d5 40 af a6 84 c1 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 09 19 5e 40 63 c9 1c c1 00 00 00 00 00 00 00 00 00 00 00 00 57 00 00 00Notice that there are 4 sets of coordinates and magnitudes. However, coordinates of the 1st star are identical (2 lines) because of course they belong to the same star with “blinking effect” between mag ff hex-255 dec and c3hex 195 dec . Magnitudes of other 2 stars are stable an they did not blink when tested.
I think that proves where are the values of magnitudes in star.dat file. It remains to establish how and in what format are the coordinates given and from what absolute starting point.
-
So far i know <00 00 00 00 00 00 00 00 00 00 00 00 26 BF 68 41 AB AA 71 C2 00 00 00 00 00 00 00 00 00 00 00 00 FF> is a little over west.
In decimal this equals (38 191 104 65, 171 170 113 193).
In Octal this equals (046 277 150 101, 253 252 161 302).For astronomers, do these look like like the format of a star a little right from heading 270 west and somewhere between 0 degrees from the horizon, up to less than 45 degrees from the horizon? If so, then bingo because I am trying to figure out the coordinate systems out there…
I have attached a picture of the star, the time was 00:00:00 aka midnight. You may have to click and zoom in, the star is just to the right of the hud and near the top of the screen.
-
So far i know <00 00 00 00 00 00 00 00 00 00 00 00 26 BF 68 41 AB AA 71 C2 00 00 00 00 00 00 00 00 00 00 00 00 FF> is a little over west.
In decimal this equals (38 191 104 65, 171 170 113 193).
In Octal this equals (046 277 150 101, 253 252 161 302).For astronomers, do these look like like the format of a star a little right from heading 270 west and somewhere between 0 degrees from the horizon, up to less than 45 degrees from the horizon? If so, then bingo because I am trying to figure out the coordinate systems out there…
I have attached a picture of the star, the time was 00:00:00 aka midnight. You may have to click and zoom in, the star is just to the right of the hud and near the top of the screen.
Earlier iterations of F4 source code exits… The star map prob hasn’t changed since.
The source would explain how co-ords are distributed unless this was changed post BMS 4.
-
26 BF 68 41 AB AA 71 C2
My vote is for 2 sets of floating point data describing 1st latitude over the equatorial plane or celestial equator and 2nd longitude from 0 meridian. But this is just pure guess which requires verification.
-
My vote is for 2 sets of floating point data describing 1st latitude over the equatorial plane or celestial equator and 2nd longitude from 0 meridian. But this is just pure guess which requires verification.
You are indeed correct, it is in ra then dec and they are floats. Am working on figuring out how those floats are represented in hex though….
-
Maybe this could be of some help.
http://vterrain.org/Atmosphere/thesky.htm -
So far i know <00 00 00 00 00 00 00 00 00 00 00 00 26 BF 68 41 AB AA 71 C2 00 00 00 00 00 00 00 00 00 00 00 00 FF> is a little over west.
In decimal this equals (38 191 104 65, 171 170 113 193).
For astronomers, do these look like like the format of a star a little right from heading 270 west and somewhere between 0 degrees from the horizon, up to less than 45 degrees from the horizon? …Do you know to what celestial coordinates (AD, DEC) refer these data ? That 'd be a good start to infer what they represent.
Probably that the magnitude is included if they represent the all data set.First, I don’t know coordinates in 4 groups (except in 4D !!. Something that authors of “Contact” or someone from NSA could resolve, Hi!
For me, only the galactic longitude and the azimut expressed either in degrees or radians can exceed 60, it is between 000 and 359.9 but it is a single group (in decimal).
You data, 38 191 104 65 and 171 170 113 193 at midnight look strange. Blocks of 2 and 3 digits exceeding 60 and even 180
So they could be something related to Azimut and elevation but in what format ? 4 times 3 numbers look strange.
Without knowing the format or the formulae, I can’t tell you what it could be.NB. If someone needs some formulae to convert equatorial coordinates (AD, Dec) into Azimut/elevation for a specific latitude and elevation, (e.g. centered on the airplane), on my web I published some years ago a short exercise. It is in French but I presume that is easily readable in English as numbers are international
The 4th exercise (with the green ellipse, juillet 1982) ) explains how to convert one system in another.
http://www.astrosurf.com/luxorion/mecaniqueceleste-ex4.htm -
Ok I think I have solved it, the first star which is in the screenshot is west, and I conveted the hex to decimal then converted the decimal to ra, and then looked up psi fornacis which is a star called the West Tiger or something like that in Chinese, which probably means it is to the west. The star in the picture is westward, and this psi fornacis is also to the west and has ra 02h53m34.40s which almost lines up with my bms star which supposedly has 03h12m54s and is just further in the declination axis. For now my brain is exploding, from trying to read c/c++ and how to read star coordinates, and editing in hex so I will check it more closely tomorrow since I am supposed to be busy anyways.
-
yeap I believe that’s it… as I see it in star.h that must be it for the coordinates rad hours minutes secs… It looks dynamic as it get’s your current position in the world, and counts month etc.
the code (star.cpp) says minint=0.5f (for magnitude as I understand it) and maxint=1.0f
Also has a function for Constellation that I can’t make off…
Also has Julian and dim
for julian (Julian (1980,1,0.0f) Julian (2000,1,1.5f) if set uses julian else calculates realtime (LocalSiderialTime)float CStar::Latitude; float CStar::Longitude; float CStar::sinLatitude; float CStar::cosLatitude; float CStar::UniversalTime = 0.0f; float CStar::UniversalTimeDegree = 0.0f; float CStar::LocalSiderialTime = 0.0f; float CStar::deltaJulian = 0.0f; float CStar::CurrentJulian = 0.0f; float CStar::Julian1980 = Julian (1980,1,0.0f); float CStar::Julian2000 = Julian (2000,1,1.5f); int CStar::Year; int CStar::Month; int CStar::Day; int CStar::ExtraDay = 0; int CStar::mustSetLocalSiderialTime = 0; int CStar::mustSetdeltaJulian = 0; int CStar::DaysInMonth[12] = { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }; StarData *CStar::CurrentStarData = 0; float CStar::SunAz; float CStar::SunAlt; float CStar::MoonAz; float CStar::MoonAlt; float CStar::Horizon = (float) (-PI/2); // default ==> show all stars float CStar::HorizonRange = (float) (-PI/2); // default ==> don't dim stars float CStar::IntensityRange = 1.0f; int CStar::minStarIntensity = 0;
-
To be accurate, if the atmospheric extinction seems to be taken into acccount in calculations, then know that its value is equal to 1 arcmin at 45° of elevation. It is not much.
Not sure that such a low value has an impact on screen at resolution at which work BMS on our 17" to 24" wide screen.In addition, most of the time, a kind of haze or the mist or fog prevents to see stars below say 20° of elevation if the airplane flies low level.
The problem is different aloft as at 18000-40000 ft high (depending on the latitude), close to the tropopause the atmospheric extinction tends to be very low : 90% of the air is below the tropopause and 50% below 16500ft or 5000 metres (standard atmosphere).
So the extinction also depend on the airplane altitude.Remain to know if the mist is taken into account in BMS and is set depending on the airplane altitude to design the lower part of the atmosphere (the higher the aiplane, the thiner is the haze layer).
I personnaly 'd be interested to know what atmospheric factors are taken into account to display the sky and atmosphere.
Till thanks for your time and investigations. -
as I see it it calculates the horizon in the code also (not sure) it takes to account the altitude. also sun moon position.