Page 1 of 1
Celestia 1.7.0 Freezing on Startup
Posted: 08.07.2018, 22:04
by CM1215
I know that I've given this problem as replies on some other topics, but since no one has given me a solution to this problem, I thought I might as well make a designated thread for this issue.
I am trying to load up Celestia 1.7.0 (The 6 June 2018 Build), but when I try, it gets to 100% files loaded, and then freezes. While it is frozen, it will slowly build up RAM usage until it eventually takes up most or all RAM memory. When I try it with the 1.7.0 dev 7 build, which has worked without problem for a while now, I discover that a similar problem has begun to occur. It will load for a second, but when it gets to stars.dat, It freezes (and builds up RAM usage).
The only version of Celestia that will load is the old x86 1.6.1 version.
Does anyone have a solution to this problem?
If anyone needs more info on this issue, please let me know.
Thanks,
CM1215
Posted: 09.07.2018, 07:57
by Janus
@CM1215
The first thing to do troubleshooting windows is to turn UAC off.
The second is to run the program in question using the admin account.
Newer versions of windows are as insane as linux about restricting programs.
I have many programs that will not run as anything but admin, and some of them freeze in a blank window if I try.
In order to troubleshoot this properly, a few things are needed.
OS, which windows version and bits, W7 & x64 for instance.
If using W10, which I do not recommend for anyone, be sure to include current patch and update versions and M$ replaced drivers.
M$ does not do proper testing of drivers with any but recommended specs, and cuts corners on that.
I often trace problems on customer systems and networks to drivers that windows update has replaced or updated.
Program Version, which you gave, and bits, x86 Vs x64.
Any active firewalls, antivirus or malware scanners.
Due to the way windows does file access, the firewall may be relevant.
Advanced troubleshooting will also need cpu, video, and ram.
Intel chipset video on laptops is picky, especially with dynamic textures.
Nvidia multiscreen setups tend to be unstable or simply picky.
I have seen many problems with nvidia hardware fixed by simply changing the installed driver version.
If you like I can put my fork up for you to test.
It is almost the same as the main line, but no audio support, and I have moved some stuff around along with RaDec/Dist being listed.
I can put up VS stand alone, no run times required.
I can also do QT versions, 5.6/8/10 in x86 or x64, though the VS version will 2013/5.
I can not run VS2017, it borks my setup when I try.
I run a heavily modified W7 setup altered to look and work as much like 2K/Xp as I can make it be.
My opinion of vista and later desktops is unfit for print, while I do not consider W8 or later to really be windows, and W10 is just a cloud account front end that does graphics. it is not an actual OS.
That is my opinion, and I understand that not everyone will share it.
Everyone should use what works for them, and if you are using W10, then good luck.
Given the way M$ is mucking about with it, altering things at random, whatever fixes it today, may not be relevant tomorrow.
Janus.
Posted: 09.07.2018, 17:05
by CM1215
I use Windows 10 with 16 GB of RAM. My system is 64 bit, and the versions of Celestia I am failing to run are also 64 bit. My graphics driver is an NVIDIA driver (GeForce GTX 1050 Ti). My antivirus programs or firewall aren't blocking Celestia. My CPU is an AMD Ryzen 5 1500X Quad-Core Processor (though this hasn't prevented it from working in the past).
My best diagnosis is a Windows Feature Update that was applied a couple months ago. Ever since this update, Celestia 1.7.0 hasn't been able to run.
Is this all the info you need?
Posted: 09.07.2018, 17:51
by Janus
@CM1215
I have uploaded a working directory and zip file of my fork in my downloads.
http://celestia.simulatorlabbs.com/Downloads/Look for celestia_qt56.zip (~56Mb) or just grab the directory of the same name if you prefer.
In it I have placed my fork compiled as x64 VS only, fully static linked, can be copied and used as is alone.
My fork compiled QT5.6.3 x64, with support DLLs included.
Executables are named to indicate my fork to prevent confusion with the main fork.
The directory is intended to run as a stand alone.
The QT version requires the VS2013 runtimes because the QT DLL libraries do.
The biggest difference relevant to today is I used my own support libs, and mine has no sound support.
This means no qtmultimedia required, which is the sort of thing M$ delights in breaking at random.
Tested in a clean install of W7 in a VM.
Also tested in a frozen snapshot of W10, again in a VM.
Janus.
Posted: 09.07.2018, 19:46
by CM1215
Thank you very much...this version works splendidly (though I had to disable Lua Edu Tools in order for it to work).
Posted: 09.07.2018, 23:30
by Janus
I am glad that helps.
Did both versions in the directory work?
The QT and the VS version both?
Just curious.
Also, for anyone who cares, the Lua is 5.3, the LibJpeg is 9.2b, LibPng is 1.6.26, not sure if any that effects anything.
Not sure what lua edu tools is, so I can't do anything about that.
Janus.
Posted: 10.07.2018, 01:11
by CM1215
I just tested the VS2013 versions, and both of them worked just fine as well (Both the normal and 1 Gigayear versions).
Posted: 10.07.2018, 01:35
by Janus
Thank you.
I am working on backporting the VS2013 code compile to work on XP and ReactOS as well.
While the latter will eventually support the newer exe formats, I want to get it working now.
I will post the QT5.10 version of my stuff when I get time.
Right now I am constructing an ssc entry to xyzv converter for a personal project.
I am hoping to show that 90482 Orcus is part of Halley's Comet's wobbly orbit issues.
Janus.