--- In guide-user@yahoogroups.com, Bill J Gray <pluto@...> wrote:

>
> John Greaves wrote:
>
> "...There's an easy answer to that one, Roger ol' lad, it's

called V435

> Vul not being in Namelist 78...
>
> ;)
>
> It were in namelist 77."
>
> Yes, but the Name List 77 _and_ 78 stars (and all previous Name

List

> stars) are in 'iii.dat'. Still puzzling this out.

Specifically Roger reckoned he couldn't find it either whilst using
namelist 78 and the tdf for namelist 78, which isn't an "official"
Guide tdf, but something I stuck up on the baavss alert group some
while back. He couldn't find it there because it isn't there.


Now then, Roger also noted that he _could_ get hold of some other
namelist 78 object though, however, I'm not entirely clear whether via
iii.dat or the namelist 78 table off of the IBVS site and its TDF.

Users having problems with this ought to test a few of these namelist
78 objects. Again, iii.dat is alphabetical. Sometimes, on rare
occasions, these online data lists get a nonalphabetical, but
invisible, character code tucked inside them somewhere, which has in
teh past put everything out of kilter row and column's wise, so Guide
doesn't find the coordinates because they aren't where they ought to
be. This may well not be a problem nowadays, but I've seen it happen
in the past, just one byte somewhere in the middle of a large ascii
file causing all subsequent entries to be offset from true.

So, if Roger and the others really want to test this they need to
select a few random NL 78 objects, from constellations in various
positions of the alphabet. With this Vul example being so near the
end, a red herring could be occuring clue-wise.

Does V454 And work in the new test version, for instance?

I believe Guide can readily work with variable length rows nowadays,
so that shouldn't be it, but iii.dat is certainly not a fixed length
record data file. Oh, wait a minute, tDFs were adapted to cope with
variable length lines a while ago, but what about the internal data
reading gubbings? Bill's own large ascii file reader shows this lines
as wrapped, each new line starting immediately on the same line as the
ending carriage return and line feed characters in the file, instead
of actually starting a new line as they should, you see. So, that
program can't read the line lengths and separate lines, so maybes
Guide can't???? Dunno, guessing.

But my suspicion is it ain't Guide, but the iii.dat data file, that
needs staring at, and my first instinct is to note that it doesn't
have padding spaces at line ends to make it fixed length record rows.



I always kind of liked your old idea of sticking all the data into the
tdf scheme and losing the internal data access help, rather than some
internal to the executable and some accessed via TDFs, because it gave
us a chance to sort out stuff ourselves and left you free to do
chewier stuff.

I suppose, though, that that wouldn't allow for the summary help files
that list up the details for objects from many catalogues in one help
file, or at least that'd be a nontrivial fix.

But this would allow extension, for example it's relatively easy to
convert remarks.res into a note file, just be adding a ~ at front of
every other line and inserting a carriage return at the 13th or 14th
character position at every other line, a macro in a text editor does
this quite quickly, and marcoes can be recorded. Then if it was a tdf
hookup to iii.dat via adding a simple line would be possible.

However, few datasets have old style freeflow text information content
notes like GCVS, and for an other example WDS, have, so there likely
wouldn't be much utility in it.

Cheers

John