I've made some progress with the MacOS X port, but there's this problem: "Sol" seems to be missing from the star database.
As I understand it, "Sol" should be in the stars.dat file with catalog number 0. I believe this file is sorted by catalog nuber, so Sol should be at the beginning of the file. But the file seems (according to hexdump) to begin with catalog number 1, not 0.
When catalog number 0 is looked up (during solar system file loading, for instance), the first entry is returned, but this has catalog number 1, so the lookup fails (there's a check to verify the catalog number).
Can anyone shed any light on this?
- Hank
"Sol" missing on MacOS X
-
Topic authorHankR
I believe I have found the problem which caused "Sol" to be missing from the star database on MacOS X.
There is a check for input errors in StarDatabase::loadBinary() which terminates the star loading loop.
The code is:
if ( !in.good() )
break;
But (on MacOS X, at least) this causes a break after reading the last star record, which happened to be "Sol". So "Sol" didn't get into the database. Apparently on MacOS X, in.good() returns false when in is at end-of-file. Evidently the behavior on other platforms is different; I don't know which is correct. Anyway, I changed the code to:
if ( in.bad() )
break;
and it's working now. Presumably this will still work on the other platforms as well.
- Hank
There is a check for input errors in StarDatabase::loadBinary() which terminates the star loading loop.
The code is:
if ( !in.good() )
break;
But (on MacOS X, at least) this causes a break after reading the last star record, which happened to be "Sol". So "Sol" didn't get into the database. Apparently on MacOS X, in.good() returns false when in is at end-of-file. Evidently the behavior on other platforms is different; I don't know which is correct. Anyway, I changed the code to:
if ( in.bad() )
break;
and it's working now. Presumably this will still work on the other platforms as well.
- Hank