Celestia 1.7 Installation
-
Topic authorFarGetaNik
- Posts: 484
- Joined: 05.06.2012
- With us: 12 years 5 months
- Location: Germany
Celestia 1.7 Installation
I'm currently setting up my new computer (Win 10 64bit) and wanted to install Celestia. I installed the 1.6.1 version and made sure it launched, then downloaded the Celestia 1.7 25.11.17 binary along with all its components and dumped it into my main Celestia directory. I also needed to install the Visual C++ Redistributable 2012 to get it to launch without producing an error. But now all it does is quickly load data files up to 100% and then it's stuck... slowly filling up my RAM without actually doing anything. I killed it with the task manager, at this point it already was at 8GB+ RAM usage and it can't possibly load so much temporary data with an empty Celestia installation right?
How can I get it to work? On my old Laptop I still have an older version from august 2017 that still worked.
How can I get it to work? On my old Laptop I still have an older version from august 2017 that still worked.
Sorry John 71, I'm a noob on this, but I wonder why it's not possible to make an installer containing all the needed stuff, I mean usable (only!) files from 1.6.1 plus the new files for 1.7.
I find actual 1.7 installation difficult and with problems, moreover.
Any info, please?
Thanks a lot.
Goofy
I find actual 1.7 installation difficult and with problems, moreover.
Any info, please?
Thanks a lot.
Goofy
"Something is always better than nothing!"
HP Omen 15-DC1040nl- Intel® Core i7 9750H, 2.6/4.5 GHz- 1TB PCIe NVMe M.2 SSD+ 1TB SATA 6 SSD- 32GB SDRAM DDR4 2666 MHz- Nvidia GeForce GTX 1660 Ti 6 GB-WIN 11 PRO
HP Omen 15-DC1040nl- Intel® Core i7 9750H, 2.6/4.5 GHz- 1TB PCIe NVMe M.2 SSD+ 1TB SATA 6 SSD- 32GB SDRAM DDR4 2666 MHz- Nvidia GeForce GTX 1660 Ti 6 GB-WIN 11 PRO
This is why I try to statically link everything I can in mine.
DLL Hell is a thing in windows.
Though I suspect Linux has its own version of it.
It is possible to make an installer that contains all the needed support files, however, it is complicated and not straight forward.
I am currently working on updating my fork with code changes in the main branch, downloaded today.
I have a few days while a customer runs their machines and collects me enough crash logs to find a place to start.
Just got done updating Lua to 5.3.4 as a static lib project.
Compiles with VS2013/15 in x86 & x64 both.
I will add Mingw once I get the x64 linking properly, it is currently having a tantrum.
Once I have that all working, I will be verifying the compile and run with QT.
Which I am getting close to being able to compile and link with the Mingw that comes with it.
My goal is VS 2013/15 W/QT5.4/5.6/5.8/5.10 & Mingw w/ x86 & x64
Once I have the VS version working, I will post it for those that are interested.
I will of course be posting the source as usual.
I will also be posting a version with the latest Celestia-Origin version already installed and working.
Ironically, avoiding the DLL hell in windows with VS is easy, just select use standard windows libraries in your solution/project/subprojects, and compile.
Saves so many headaches, and makes your program portable.
I often use Celestia from a USB stick when showing it to people.
Janus.
DLL Hell is a thing in windows.
Though I suspect Linux has its own version of it.
It is possible to make an installer that contains all the needed support files, however, it is complicated and not straight forward.
I am currently working on updating my fork with code changes in the main branch, downloaded today.
I have a few days while a customer runs their machines and collects me enough crash logs to find a place to start.
Just got done updating Lua to 5.3.4 as a static lib project.
Compiles with VS2013/15 in x86 & x64 both.
I will add Mingw once I get the x64 linking properly, it is currently having a tantrum.
Once I have that all working, I will be verifying the compile and run with QT.
Which I am getting close to being able to compile and link with the Mingw that comes with it.
My goal is VS 2013/15 W/QT5.4/5.6/5.8/5.10 & Mingw w/ x86 & x64
Once I have the VS version working, I will post it for those that are interested.
I will of course be posting the source as usual.
I will also be posting a version with the latest Celestia-Origin version already installed and working.
Ironically, avoiding the DLL hell in windows with VS is easy, just select use standard windows libraries in your solution/project/subprojects, and compile.
Saves so many headaches, and makes your program portable.
I often use Celestia from a USB stick when showing it to people.
Janus.
-
Topic authorFarGetaNik
- Posts: 484
- Joined: 05.06.2012
- With us: 12 years 5 months
- Location: Germany
john71, how did you install it exactly? It took me a while to figure out how to place all the dll and as I said, I needed a 3rd party one as well that Alexell didn't include in his package. Also I simply put the platforms folder included into my main Celestia directory.
Janus, I aprechiate your effords. I can imagine putting a proper installer together would be kind of a hastle for an in-dev version but at this point I don't see another way getting Celestia to work. I guess I have to continue with my older in-dev version for now...
Janus, I aprechiate your effords. I can imagine putting a proper installer together would be kind of a hastle for an in-dev version but at this point I don't see another way getting Celestia to work. I guess I have to continue with my older in-dev version for now...
Yahoo, now it works, thanks a lot John 71, appreciated.
Bye.
Goofy
Bye.
Goofy
Last edited by Goofy on 12.05.2018, 20:51, edited 1 time in total.
"Something is always better than nothing!"
HP Omen 15-DC1040nl- Intel® Core i7 9750H, 2.6/4.5 GHz- 1TB PCIe NVMe M.2 SSD+ 1TB SATA 6 SSD- 32GB SDRAM DDR4 2666 MHz- Nvidia GeForce GTX 1660 Ti 6 GB-WIN 11 PRO
HP Omen 15-DC1040nl- Intel® Core i7 9750H, 2.6/4.5 GHz- 1TB PCIe NVMe M.2 SSD+ 1TB SATA 6 SSD- 32GB SDRAM DDR4 2666 MHz- Nvidia GeForce GTX 1660 Ti 6 GB-WIN 11 PRO
-
Topic authorFarGetaNik
- Posts: 484
- Joined: 05.06.2012
- With us: 12 years 5 months
- Location: Germany
FarGetaNik wrote:john71, I got the exact same problem. It's loading, filling up my RAM and not actaully laucnhing properly
I'm afraid it is not Celestia 1.7's fault then...
Added after 4 minutes 10 seconds:
Try to uninstall/delete Celestia from your PC, clean regedit too, use Ccleaner after that, and try to reinstall it.
A quick note for those caught in the VC runtime quandary that QT gives us.
Until QT creator can use msbuild instead of nmake, or jom can call msbuild, ALL qt builds using visual studio as a compiler will require the accompanying runtimes.
This means if you compile with QT & VS2017, which is what I believe Alexell does, that build will require the VC2017 runtimes.
There is not currently a way around it.
The least messy way I have found for dealing with VC runtimes is this.
http://www.majorgeeks.com/files/details/visual_c_runtime_installer.html
It (re)installs all of them at once as needed.
I hope this helps.
Janus.
Until QT creator can use msbuild instead of nmake, or jom can call msbuild, ALL qt builds using visual studio as a compiler will require the accompanying runtimes.
This means if you compile with QT & VS2017, which is what I believe Alexell does, that build will require the VC2017 runtimes.
There is not currently a way around it.
The least messy way I have found for dealing with VC runtimes is this.
http://www.majorgeeks.com/files/details/visual_c_runtime_installer.html
It (re)installs all of them at once as needed.
I hope this helps.
Janus.
-
Topic authorFarGetaNik
- Posts: 484
- Joined: 05.06.2012
- With us: 12 years 5 months
- Location: Germany
john71 wrote:Try to uninstall/delete Celestia from your PC, clean regedit too, use Ccleaner after that, and try to reinstall it.
I doubt that will help as my installation was as fresh as it could have been since I'm on a new computer... I de- and reinstalled Celestia nontheless, as I remembered what a hastle it is to work with it on the default program files directory on Windows. Didn't help though. I'm just gonna settle with the older version until there is another update. What changes occured between the august and november version anyways?
Janus, have to try that. Right now I'm still a bit confused
Hi.
Where did you install Celestia i.6.1?
In C:\Program Files or in c:\root?
Many times it was suggested here to choose the second option, because for some strange reason the first one could give problems...
Just a thought...
Bye
Goofy
Where did you install Celestia i.6.1?
In C:\Program Files or in c:\root?
Many times it was suggested here to choose the second option, because for some strange reason the first one could give problems...
Just a thought...
Bye
Goofy
"Something is always better than nothing!"
HP Omen 15-DC1040nl- Intel® Core i7 9750H, 2.6/4.5 GHz- 1TB PCIe NVMe M.2 SSD+ 1TB SATA 6 SSD- 32GB SDRAM DDR4 2666 MHz- Nvidia GeForce GTX 1660 Ti 6 GB-WIN 11 PRO
HP Omen 15-DC1040nl- Intel® Core i7 9750H, 2.6/4.5 GHz- 1TB PCIe NVMe M.2 SSD+ 1TB SATA 6 SSD- 32GB SDRAM DDR4 2666 MHz- Nvidia GeForce GTX 1660 Ti 6 GB-WIN 11 PRO
A quick note.
Installing anything in C:\Program Files or C:\Program Files(x86) is problematic.
Those are mostly read only directory trees for anything installed in them.
If your program may store files locally, then use something like C:\Celestia instead.
Of course it is better to trim your 'C' drive as much as possible by restricting it to OS & Utilities only.
Then save your files outside your user profile, preferably on their own drive letter.
That way when windows borks itself, and it will, your data is safe.
Most of the programs I use are setup to store data where I want it, not where M$ expects it.
Janus.
P.S. I have my current fork, updated to match the github archive as of a few days ago if you want to try them.
They are in x86 & x64, VS2013 everything static, no support DLLs needed.
Installing anything in C:\Program Files or C:\Program Files(x86) is problematic.
Those are mostly read only directory trees for anything installed in them.
If your program may store files locally, then use something like C:\Celestia instead.
Of course it is better to trim your 'C' drive as much as possible by restricting it to OS & Utilities only.
Then save your files outside your user profile, preferably on their own drive letter.
That way when windows borks itself, and it will, your data is safe.
Most of the programs I use are setup to store data where I want it, not where M$ expects it.
Janus.
P.S. I have my current fork, updated to match the github archive as of a few days ago if you want to try them.
They are in x86 & x64, VS2013 everything static, no support DLLs needed.
-
Topic authorFarGetaNik
- Posts: 484
- Joined: 05.06.2012
- With us: 12 years 5 months
- Location: Germany
I had Celestia installed on my D: drive on my laptop. On my new computer I only have 1 drive and I just installed it on the default programs directory at first. Later while setting up my content I remembered that that's a bad idea because of the restrictions that come with it so I changed it to C:\Celestia.
I would really appreciate that!
Janus wrote:P.S. I have my current fork, updated to match the github archive as of a few days ago if you want to try them.
They are in x86 & x64, VS2013 everything static, no support DLLs needed.
I would really appreciate that!
@FarGetaNik
Okay, here is something for you to play with.
The executables inside are labelled as my fork to avoid confusion with the main fork.
No dependence on runtimes at all.
In my fork I have moved a few things.
It also displays realtime RaDec for things, not all yet, it is part of a work in progress.
I moved the OBS distance to the lower right, where it makes more sense to me.
I have updated the LUA to 5.3.4 current.
Still testing that LUA works perfectly, let me know about any glitches.
Tested in a bare Win7 VM with nothing installed except my fork of explorer++, the one that comes with WIn7 is broken by design.
Removed: Please see post 34 instead.
Janus.
P.S. Apparently the QT libraries themselves are linked to use VS runtimes, which I am going to test by recompiling them once I figure out how.
Okay, here is something for you to play with.
The executables inside are labelled as my fork to avoid confusion with the main fork.
No dependence on runtimes at all.
In my fork I have moved a few things.
It also displays realtime RaDec for things, not all yet, it is part of a work in progress.
I moved the OBS distance to the lower right, where it makes more sense to me.
I have updated the LUA to 5.3.4 current.
Still testing that LUA works perfectly, let me know about any glitches.
Tested in a bare Win7 VM with nothing installed except my fork of explorer++, the one that comes with WIn7 is broken by design.
Removed: Please see post 34 instead.
Janus.
P.S. Apparently the QT libraries themselves are linked to use VS runtimes, which I am going to test by recompiling them once I figure out how.
Last edited by Janus on 21.05.2018, 20:49, edited 1 time in total.
-
Topic authorFarGetaNik
- Posts: 484
- Joined: 05.06.2012
- With us: 12 years 5 months
- Location: Germany
-
Topic authorFarGetaNik
- Posts: 484
- Joined: 05.06.2012
- With us: 12 years 5 months
- Location: Germany
The OBS distance display seems to work properly.
I'm not sure how the RA Dec and distance parameters work. Are they relative to Earth?
One small thing I noticed after setting up my installation properly is that my costum celx startup script produces an error and doesnt get executed entirely. I can use Celestia normally after that though.
I'm not sure how the RA Dec and distance parameters work. Are they relative to Earth?
One small thing I noticed after setting up my installation properly is that my costum celx startup script produces an error and doesnt get executed entirely. I can use Celestia normally after that though.
Hi. I was comparing the 1.7 with the old 1.6.1 versions, and I have some doubts.
In the attached images, showing the same image of the Moon, with same time, distance, FOV, surface luminosity (none for 161, cursor totally on left for 1.7), you can see the luminosity of them is very different.
Provided that I absolutely prefer the 161 one, the 170 is too clear and contrasted, IMHO. What is the reason of this?
Anyway, can it be tuned differently, so to allow a dimmer luminosity7cointrast?
Another thing: I like to show the full screen image when I make projections for scholars, and find that the instrument bar on top is distracting, and moreover useless when using a script.
Is thare any way to close and/open it if needed?
Last thing: when i use VT textures, I have always the doubt if I really have reached the maximum definition or not, I mean if I reached e.g. Level5 or Level6 and so on.
Proposal: could we have a small number somewhere on the screen, giving the shown level?
Sorry for troubling.
Bye and thank you for all your effort.
Goofy
In the attached images, showing the same image of the Moon, with same time, distance, FOV, surface luminosity (none for 161, cursor totally on left for 1.7), you can see the luminosity of them is very different.
Provided that I absolutely prefer the 161 one, the 170 is too clear and contrasted, IMHO. What is the reason of this?
Anyway, can it be tuned differently, so to allow a dimmer luminosity7cointrast?
Another thing: I like to show the full screen image when I make projections for scholars, and find that the instrument bar on top is distracting, and moreover useless when using a script.
Is thare any way to close and/open it if needed?
Last thing: when i use VT textures, I have always the doubt if I really have reached the maximum definition or not, I mean if I reached e.g. Level5 or Level6 and so on.
Proposal: could we have a small number somewhere on the screen, giving the shown level?
Sorry for troubling.
Bye and thank you for all your effort.
Goofy
"Something is always better than nothing!"
HP Omen 15-DC1040nl- Intel® Core i7 9750H, 2.6/4.5 GHz- 1TB PCIe NVMe M.2 SSD+ 1TB SATA 6 SSD- 32GB SDRAM DDR4 2666 MHz- Nvidia GeForce GTX 1660 Ti 6 GB-WIN 11 PRO
HP Omen 15-DC1040nl- Intel® Core i7 9750H, 2.6/4.5 GHz- 1TB PCIe NVMe M.2 SSD+ 1TB SATA 6 SSD- 32GB SDRAM DDR4 2666 MHz- Nvidia GeForce GTX 1660 Ti 6 GB-WIN 11 PRO
-
Topic authorFarGetaNik
- Posts: 484
- Joined: 05.06.2012
- With us: 12 years 5 months
- Location: Germany
Goofy wrote:In the attached images, showing the same image of the Moon, with same time, distance, FOV, surface luminosity (none for 161, cursor totally on left for 1.7), you can see the luminosity of them is very different.
Provided that I absolutely prefer the 161 one, the 170 is too clear and contrasted, IMHO. What is the reason of this?
Anyway, can it be tuned differently, so to allow a dimmer luminosity7cointrast?
You are clearly using a LunarLamber parameter for the moon that is way lower than 1 or it is not defined, hence 0 (1 is the value defined in Celestia 1.6.1 data files). I'm using a value of 0.9 for the most realistic render. I noticed that how Celestia treats the lunar lamber light distribution is different for 1.6/1.7 and that might be the reason the moons looks different now. Maybe changing this value will help. I would appreachiate Celestia setting its default value to 0.5 which is a good approximation for most solid surfaces (not cloud layers though). Seeing an object in Celestia with lunar lambert at 0 really aches me as for me it makes it so obvious that its a render and not a photograph.
As for VT's I am actually mildly annoyed that Celestia only seems to load the next layer when the previous one already got visibly blurry. So I certainly can tell where the layers change. It's a shame Celestia doesn't use its full potential with VT's because of this.