Hi folks,
I've just posted new software on the Web site. Aside from containing
all the bug fixes mentioned earlier, and one minor change in Ax.0 handling,
it's the same as the 30 January version. (More on that one minor change
below.)
I am indeed paying attention to the assorted thoughts for improvement...
but for the next few months, I plan to avoid making many big changes in
the software.
The reason for that is that I hope (maybe with excessive optimism) to
have Guide 8 out the door in two or three months. This means that my main
priority will be to get the software stable (purge the crashes we've been
seeing lately) and to get all the data together for the two CD-ROMs
(images and Tycho-2, primarily).
I'll have to revise the software to handle the new data and to handle
the idea of multiple CDs more smoothly. But aside from that, I'll
restrain my usual impulse to sit down and start writing software when
somebody suggests a nifty idea. Such things will wait until Guide 8 is
shipped; I can become "experimental" again then.
SAx.0 USAGE:
A warning: display of Ax.0 data using lines such as
A1_PATH=14.3;e:\Usnosa10
in GUIDE.DAT, and display of Ax.0 (or SAx.0) using the "Get A1.0/A2.0
Data" function in Extras, are two very different things, independent of
one another.
The first only works with A1.0 and A2.0; you cannot get it to understand
an SAx.0 disk. When used with Ax.0, though, it will display data from
that catalog whenever your limiting magnitude is (in the above case) fainter
than 14.3. The data just "appears", with no extraction step needed. You
can use a full path specifier, as in the above case.
The second method, the "Get A1.0/A2.0 Data" function, used to be the
_only_ method, and it's the one Joe Mize should use, because it's the
only one that will let him get data from SAx.0. It's intended to extract a
small chunk of SAx.0 or Ax.0 data from a CD-ROM for display in Guide.
I agree with Denis Boucher; Guide is probably trying to get the data
from the wrong drive. To check this, edit the file STARTUP.MAR and look
for this line:
63 real CD e
Change the 'e' to match the actual letter of the hard drive. Because
it's CD-ROM oriented, it does expect that you'll be just giving a letter;
63 real CD e:\Usnosa10
won't work.
You have a lot of company in running into this problem. After sending out
plenty of e-mails describing it, I've done what I should have done in the
first place, and made it possible to select the drive from inside the
"Get A1.0/A2.0" dialog box. That's the "one small change" I mentioned in
the first paragraph.
CALENDARS:
Having Guide figure out the Gregorian/Julian switchover would indeed be
a horrible mess... Paul Schlyter gives an example of how horrible it would
be for Sweden, and there are some other ugly cases. I'd consider making
the 1582 date changeable, so that (for example) a Russian could make it
1918, and so on. Not that this helps in a situation such as Paul describes!
SATELLITE POSITIONS:
Christian, the 'missing satellite' problem is somewhat odd... it _could_
be that you chose objects with older (less-recently updated) elements, but
I'd expect at least _some_ successes.
I'd suggest taking a look at the 'general-purpose' checklist for
positional errors in Guide:
http://www.projectpluto.com/faq_curr.htm#positions
I've occasionally done the sort of thing you're discussing, using 7x50
binoculars. Of course, in that case, I'm looking at brighter and presumably
better-tracked objects; but they generally land in the exact location
predicted.
All this reminded me that the Shuttle is on one of its rare missions
inclined enough to see from my (N 44) latitude... it caused me to get
elements in hopes of finding a visible pass from here. I think the
extension for the radar mapper might be visible with those 7x50 binox.
However, it doesn't look as if I'll get a visible pass from here. Maybe
someone else will be better placed:
STS-99
1 26088U 00010A 00044.71026157 .00075662 23632-7 55340-4 0 72
2 26088 57.0071 297.7926 0013247 277.7054 41.5133 16.14834215 324
I was about to post all this when I saw Masaki Kouda's comments about
.TLE troubles. The problem with the STS99.TLE file is in the first data line:
1 26088U 00010A xxx44.32217346 .00074258 22767-7 55412-4 0 68
The three 'x' characters are all spaces in the original file. They
ought to be zeroes, to indicate the year ('00' = 2000) and day (044.332).
It's odd that they were left out; I've never seen that done before!
MOUSE DRIVER IN DOS:
Chris, what type of mouse... PS/2? Serial? Microsoft compatible, or
Logitech or Brand X?
If you have a Microsoft-compatible serial mouse, try running DOSGUIDE as
dosguide -m(port)
where (port) is the COM port (1, 2, 3, or 4) to which your mouse is
attached. This causes DOSGUIDE to read the 'raw' mouse data. These days,
I think most mice are either MS-compatible or have a switch for that purpose.
LINE 66 IN STARTUP.MAR:
Thomas Roehr noticed a problem when altering this line. I've altered
http://www.projectpluto.com/mar_fmt.doc
to document this line. The two numbers in question reflect the settings
in the Backgrounds dialog (color mode, display of a filled horizon, and
of objects on the horizon). I'd try different color modes and see if
turning the horizon or the objects on caused trouble. It _could_ just be
that you selected an invalid color mode, though; that would be easy
enough to do. (Altering STARTUP.MAR by hand can be a dangerous business!)
-- Bill