Hi folks,

I've procrastinated on writing this post, and as a result, I've
got a _lot_ to write about. In no special order:

ASTEROID ACCURACY: Matt's correct in stating that MPC updates its
elements on a nearly continuous basis, and it's usually the best place
to go for accurate elements. But in this case (through no fault of MPC),
it's better to go with Guide's built-in data.

The reason is that the built-in data gives elements at a much more
current epoch. The elements are stored at 50-day epoch intervals; the
MPC uses a 200-day interval. Thus, right now, Guide would be
ignoring perturbations between now and 25 July (if you used its built-in
data), or between now and 13 September (if you used MPC's elements,
which have a 13 September epoch right now).

Normally, ignoring up to 100 days worth of perturbations would not
matter. It might push the asteroid off course by a few hundred km,
but no one would ever notice. The problem here is that with an NEA,
a few hundred km _is_ noticeable, and using elements with as current
an epoch as possible really _does_ matter.

(To add to this confusion: if Guide did a full-fledged numerical
integration, none of this would matter, because perturbations would
be handled "right up to the instant". Unfortunately, it doesn't.
This is one of those features which is very rarely requested, but which
I'd sort of like to add anyway, just because I personally think it would
be pretty nifty.)

The MPC data has the advantage that it includes recent observations
not available when the Guide data was compiled. That can be _very_
important, but generally doesn't matter much for numbered asteroids;
their arcs are already decades in length, and the new data makes a
negligible contribution to accuracy.

OBSERVING LOGS: As I've mentioned, my current plan is a pretty
bare-bones one of providing a way to put Guide's notes for a given
object into a text editor, where you can change them freely. This
will involve perhaps 10% of the programming work of a "real" observer's
log, but might well make about 90% of Guide users somewhat happy.
(And the remaining 10% could get any of the really quite good
single-purpose observing logs already on the market. It would be
cruel of me to force the authors of those programs into bankruptcy <g>.)

As Paul Schlyter suggested, it would be quite possible for me to
keep a staff of programmers busy. I generally have enough projects
going to keep about five people busy, which means that about 80% of
them never get done. However, (a) I doubt the increase in sales
would justify the extra salaries; (b) the current job market is such
that good programmers are nearly impossible to hire (especially at the
very modest salaries I'd be able to pay; (c) switching from programming
to managing programming is not something I'd want to do anyway.

I've considered more seriously the route Chris Marriott has taken with
SkyMap. He's turned over the "grunt labor" (everything except development)
to a software distributor, freeing him up to work full-time on the parts
he's best at and enjoys most. I am naturally hesitant to entrust Guide,
my great artistic accomplishment, to the hands of a distributor... but
it _would_ have advantages.

SLIDE SHOW: Frank Leiter mentioned this feature in passing. I added
it a few years ago when he asked if there might be some way to rig up
such a thing. It's not a wonderful setup, since I set it up to get
him through a demo and then forgot about it until he mentioned it.

It works as follows. Load up a given mark file. After that, each
time you hit F7, Guide will load up the next mark file in the list.
When it reaches the end, it cycles to the top.

To get a desired sequence, you may have to edit MARKS.NAM and sort
things out a bit. Skip that step, and Guide will cycle through its
assorted built-in mark files (an eclipse or two, Mars transiting
Jupiter, Saturn transiting the Sun as seen from Uranus, and so on.)

ASTRO-PHYSICS MOUNTS: Chris Spratt mentioned a weird behavior where
the scope keeps slewing in declination. If anyone else has tried an
AP scope, I would indeed be interested in your experiences. In theory,
Guide's LX-200 control ought to handle this scope correctly. (The AP
_does_ have some commands that differ from pure LX-200 compatibility,
but Guide doesn't use those commands.)

AMD CHIPS AND THE ECLIPSE-CHART FEATURE: I just got an inquiry from
Eric-Sven Vesting, who distributes Guide in Germany. He had just gotten
an inquiry from a gent running Guide on an AMD-based computer, who was
getting an odd display when he attempted to show the path of an eclipse:
it showed a uniform partial event over the entire earth. I'd never heard
of this. It _may_ (or may not) be related to the fact that the computer
had an AMD chip. If anyone else has seen such a thing, could you please
send me a private e-mail? It might help me debug this one.

EQUATORIAL COMPENSATION: Most likely, the first step for this would
be the "multi-star offset" I described a few e-mails back. I doubt it
will happen right away, with Guide 8 on the horizon, but I also doubt
I can avoid tackling it forever (I expect it to be a nasty job!)

-- Bill